Войти
ПроектыФорумОцените

Программирование 3D-движка для FPS (6 стр)

Страницы: 1 2 3 4 5 6 7 Следующая »
#75
12:00, 28 авг. 2003

Altalert
Читал, да как-то без впечатлений, извини. Я вообще придерживался раньше процедурного подхода, и сейчас считаю, что он не так уж плох. Единственное что я понял - лучше всё-таки

object->Method()

чем Method( object_handle )

Всё-таки гонять хэндл по всем функциям не годится, там с ним возня - проверь выдели хэндл, проверь хэндл на правильность, удали по хэндлу...
В общем, классы так классы, но в глубоком наследовании и всеобщем полиморфизме я плаваю...

>QueryPerformanceFrequency, QueryPerformanceCounter
Ну да, единственный случай, что у меня был.

Вот какой у меня сейчас лог :)

//------------------------------------------------------------------
//    Файл:     e_log.cpp
//    Описание: Запись работы движка в журнал
//------------------------------------------------------------------
#include "stdafx.h"
#include "e_error.h"
#include "e_common.h"

#include <stdio.h>
#include <string.h>

FILE *g_fp     = NULL;
bool g_initlog = false;
bool g_tofile  = false;
bool g_tocons  = false;

//==========
// инициализация log-вывода
//==========
bool log_init( char *log_filename, logparam_t params )
{
	if (params & LOG_TOFILE)
	{
		if (!log_filename)
			return error( "не указано имя log-файла" );

		if (NULL == (g_fp = fopen( log_filename, "w+" )))
			return error( "ошибка при открытии файла %s", log_filename );

		setbuf( g_fp, NULL );
		g_tofile = true;
	}

	if (params & LOG_TOCONSOLE)
	{
		g_tocons = true;
	}

	g_initlog = true;
	log( "log-вывод инициализирован" );

	return true;
}
//==========
// закрытие log-вывода
//==========
void log_close()
{
	if (!g_initlog) return;

	log( "закрытие log-вывода" );

	fclose( g_fp );
	g_tofile  = false;
	g_tocons  = false;
	g_initlog = false;
}
//==========
// проверяет, создан ли log-вывод
//==========
bool islog()
{
	return g_initlog;
}
//==========
// вывод сообщения в log
//==========
void log( const char *msg, ... )
{
	if (!g_initlog) return;

	va_list     argptr;
	static char s[MAX_STRING];

	va_start( argptr, msg );
	vsprintf( s, msg, argptr );
	va_end( argptr );

	strcat( s, "\n" );

	if (g_tofile)
		fputs( s, g_fp ); // записываем строку

	//if (g_tocons);

}
[code]

Да. И зачем тут класс? И вообще,
log( "ky-ky" )
писать проще чем
g_log.add( "ky-ky" );

А вообще, что-то мы отдалились от темы. Структура двига ещё не обсуждена, принципы взаимодействия участников тоже. Надо с этого начинать.

Да, и ещё - мне этот Grom почему-то всегда с первого взгляда читается как Gnom :)


#76
13:58, 28 авг. 2003

Джо
>> И зачем тут класс?
Если понадобиться дополнительный лог создать или создать на его основе наследника другого типа вывода( например оконного )

FOutput* GProjectLog = ( Log* )new FStreamOutput(  );
FOutput* GDebugLog = ( Log* )new FStreamOutput(  );
FOutput* GWinLog = ( Log* )new FWinOutput(  );

а работаешь с ними независимо от типа лога по базовому интерфейсу( FOutput )

Кстати я ими( базовыми интерфейсами ) и планирую сейчас заниматься.
Вот чего пока получается

Чего собираешься делать ты

>> Структура двига ещё не обсуждена
Классы которые мы обсуждаем и есть его часть( тока самая его основа ).
Или ты хочешь сразу всю структуру в целом?

#77
21:52, 28 авг. 2003

Altalert
Посмотрел. Неплохой у стебя стиль, но скажем так идёт врозь с моим. Ладно, как-нибудь договоримся, главное из-за разногласий проект не бросать, иначе в одиночку мы его вообще не напишем, а? А у нас цель одна - шутер, а когда цель одна, то и идти надо к ней вместе, да?

#ifdef CORE_EXPORTS
  #define CORE_API __declspec(dllexport)
#else
  #define CORE_API __declspec(dllimport)
#endif

Вот это зачем? В таких вещах я не силён, пойми бывшего паскалиста. Да и вообще
class CORE_API FOutput
каждый раз писать это CORE_API ради чего-то не пойму чего и зачем не прельщает. А что,
писать придётся даже
class CORE_API ColliderSelector ?

В Quake ничего такого нет, а работал движок...

>Если понадобиться дополнительный лог создать или создать на его основе наследника >другого типа вывода( например оконного )
:) Как и интересно! А я думал сделать свой лог-вывод так
init_log( "engine.log", LOG_TOFILE ) - если нужен вывод построчно в файл.
init_log( NULL, LOG_TOCONSOLE ) - если только в консоль
init_log( "engine.log", LOG_TOFILE | LOG_TOCONSOLE ) - если туды и туды :)

log(...);
log(...);
log(...);

remove_log( LOG_TOFILE | LOG_TOCONSOLE );

Какие-то наследники и потоки так абстрактны, а моя реализация IMHO чётко указывает что делать и чётко это делает, больше от лога мне ничего не надо.

В принципе я функции низкоуровнего плана хотел бы видеть без ООП, он просто за ненадобностью здесь, в конце-концов стандартная библиотека С в виде отдельных функций и никто на это не жалуется. Тип консоли я тоже хотел бы слямзить с С-консоли, добавив к функциям, скажем, приставку cons или con или даже cn :))

extern CORE_API bool GIs3DNow;      // 3DNow instructions
extern CORE_API bool GIsMMX;        // MMX instructions
extern CORE_API bool GIsSSE;        // SSE instructions

В принципе, это не помешает, только вот я в MMX и SSE вообще не разбираюсь по причине того, что пока не понадобилось. Зачем добавлять в движок их определение, если мы эти инструкции юзать не будем??????? Вот заюзаем - тогда и прописываем в хидерах и имлементах функции и константы. Впрочем, если ты знаешь MMX и SSE и готов геометрическую библиотеку портировать на них - я всеми руками за!!!

В общем, ещё наобсуждаем, но неплохо, неплохо, ты я вижу, программировать умеешь, это хорошо :)

Да, стиль кодинга мы так и не выработали. От VD отказались, слава богу, предлагаю такие спорные квестшины решать и дальше аналогичным способом.
Ой, тут Семнадцать мгновений счас начнутся, пора закругляться... Вот, тут пара моих файлов - можно сказать, sample моего стиля кодинга, в таком стиле я тащил свой прежний движок на Delphi.

http://www.gamedev.ru/download/?id=159

>Классы которые мы обсуждаем и есть его часть( тока самая его основа ).
>Или ты хочешь сразу всю структуру в целом?
Да, структуру и ещё раз структуру. Начинать надо с этого.
Предлагаю: окончательно придумать название движка, утвердить участников проекта (т. е. мы с тобой), и открыть топик

<название движка> Шаг 01. Структура и общие принципы.
ЗЫ Спроси меня, как я предлагаю назвать движок.

ЗЗЫ. Надо GAMEdat показать кузькину мать...

#78
22:25, 28 авг. 2003

Джо
Козлище ты, а не агнец. Пришёл на геймдат, обосрал всех, сам же обиделся и убежал делать то же самое, на в другой топик... У вас, похоже, по жизнеспособнее, но у вас не меньшие шансы заГнуцца, чем у ГеймДат. Призываю к кооперации на более поздних этапах игры. Здась варианты - вы выживете, геймдат нет. Тогда, может быть, переползу к вам. Второй вариант, выжимет ГеймДат, а вы сгинете. Тогда надеюсь видеть вас на ГеймДате. Третий вариант, сдохнут оба. Тогда увы. А если оба выживут, можно бужет слепиться позже, взяв за основу более жизнеспособный подход и код.....

#79
23:47, 28 авг. 2003

Вобчем так: Али вы али мы. Мы за нас :) И выбора у вас нету :) Так штоль?

#80
4:00, 29 авг. 2003

SoRRoW, mcngine
Хмм, конкурирующая фирма...
Ваша подрывная деятельность в нашей песочнице не осталась не замеченной :)
Мы примем адекватные меры.


SoRRoW, mcngine,ZET
А кроме шуток, вливайтесь. Щас любое мнение ценно и может кардинально все паменять. Тем более название прожекта еще нет и обсуждается его компоновка.
В дальнейшем будет тока сложнее.

Джо
>> как-нибудь договоримся
>> главное из-за разногласий проект не бросать
Осилим. Я с тобой agree на все 100.

1. Название движка
Извини, я решил что ты согласен. Если нет - дык предлагай.

2. Разберемся, кто чего умеет:
  Я значицца так:  C++, VC 7, MFC, Win32, DirectX 8.0, wincore, пытаюсь моделить (MAX), опыт работы 5 лет.
Ты?

3. Распределение задач.
Думаю никакой иерархии и анархии. Каждый себе выбирает задачу по вкусу, но выполняет ее максимально качественно.

4. Связь.
ICQ, можно еще какую нить. Сеанс связи предварительно оговаривать.

#81
4:00, 29 авг. 2003

5. План движка.
Core - соответственно распологается в Core.dll модуле. Кстати CORE_DLL указывает компилятору, что объект находится в библиотеке и может быть использован, грубо говоря, основной программой.
Состав
  Config - класс доступа к конфигурационным файлам.
    Возможности:

[Engine]
  FirstRun      0
[Video]
  Driver        DirectX
  Fullscreen    0

  Fag( можно Mage ) - класс доступа к файловой системе.

  Heap - базовый класс доступа к памяти
    Модификации:
      DebugHeap - медленный мэнеджер, с возможностью выдать на Output свое состояние.
      WarHeap - оптимизированный для win32 мэнеджер памяти

  Arch - базовый класс serialization в поток/из потока.
    Модификации:
      BufferWriter/BufferReader - работа с динамическии массивом TDynar<uint8>
      DeviceWriter/DeviceReader - работа с хэндлом девайса( файл, RS, поток/консоль )
      NetSurfer - работа с сетью

  TDynar<T> - динамический массив элементов.

  TMap<K,V> - динамический массив соответствия пар: ключ - значение.

  THash<T,Size> - хэш таблица.

  Worm - динамическая строка

  Output - базовый класс ведения лога.
      Модификации:
      DeviceOutput - лог на хэндл девайса( файл, RS, поток/консоль )
      WindowOutput - оконный лог( завязка на MFC( CRichEdit )/работа в редакторах )

  Parser - просто парсер( тут надо подумать, может получиться очень функциональный класс, а пока это куча функций )

  Mat4x4, Mat3x3 - матрицы, надо полистать учебники за первый курс.

  Rect, Rectf - !?

  Uv, Uvf - текстурные координаты

  Vec2, Vec2f - вектор [2]

  Vec3, Vec3f - вектор [3]

  Vec4, Vec4f - вектор [4]

  Quat - кватерьен, что за хрень? надо разобраться, а то везде вопят типа добавляет производительности :)

  Aq, Aqf - rgba цвет

  Box - !?

  Cylinder - !?

  Sphere - !?

#82
4:01, 29 авг. 2003

Engine - соответственно распологается в 'название движка'.dll модуле. Использует всю функциональность core.dll и пишется на его основе.

  1. Теоретически: требования к разрешению/полигонам/текстурированию/освещению/теням.
    Здесь я предлагаю пока только текстурировать модели, разрешение эк. 600х800. До демы.

  2. Теоретически: Проработать модель( модели ) геймплея

  3. Теоретически: Проработать GUI элементы( в основном какие типы нужны ).

  4. Теоретически: Проработать механизм перехода между экранами GUI.

  5. Тут думать и думать!

  Интерфейсы

  Package - класс архива объектов

  Scene - собсна левел( сохранение сцены as Package any time решить в п2 )

  RenderDevice - базовый класс рендера
    Модификации:
      DxRender - DirectX 8.0 orient
      GlRender - OpenGL ?.? orient( возможно, по нахождению спеца )

  AudioDevice - базовый класс озвучки( музыка и звук )
    Модификации:
      DxAudio - DirectX orient( немного знаю )
      EaxAudio - EAX orient( возможно, по нахождению спеца )
      OggAudio - Ogg driver( сейчас изучаю )


Аргументы за разбиение на модули dll такие:
  1) Уменьшается время компиляции( я прикидываю как на твоей тачке будет коваться/отлаживаться серьезный проект и мне плохо становится )
  2) Логично разграничиваются функции частей системы.
  3) Возможно использование частей вне проекта( других проектах ) без перелинковки и даже без исходников.


Насчет синтаксиса:
Особых отличий я не вижу. Но мое предложение такое: каждый делает конкретную задачу независмо от других и на основе уже созданного. Соответственно, после креации будем стыковать.

Кстати скажи чего ты в gamedat спер :)

#83
10:55, 29 авг. 2003

SoRRoW
>Козлище ты, а не агнец
От козла и слышу!

Altalert
>Кстати скажи чего ты в gamedat спер :)
А ты почитай их первые топики. Там ужасть какие наполеоновские планы были. А в принципе, я им желал удачи, когда свалил.

>Engine - соответственно распологается в 'название движка'.dll модуле. Использует всю >функциональность core.dll и пишется на его основе.
IMHO начинать надо далеко не с этого, а с  гораздо более поверхностного уровня. Кстати, мож всё-таки от dll отказаться? Вот чего больше всего не люблю - dll. Мне нравится когда всё собрано в одном местечке, когда всё на ладошке...

>Аргументы за разбиение на модули dll такие:
>1) Уменьшается время компиляции( я прикидываю как на твоей тачке будет >коваться/отлаживаться серьезный проект и мне плохо становится )
>2) Логично разграничиваются функции частей системы.
>3) Возможно использование частей вне проекта( других проектах ) без перелинковки и >даже без исходников.
Чудненько, так и надо - только с аргументами.
Мои:
1) А как время компиляции можно уменьшить, что-то не догоняю, расскажи на примере. Да и не повод это - делать dll-ки для уменьшения время компиляции. dll, как я знаю, Microsoft для других вещей придумала - для экономии памяти, когда к одному коду обращаются несколько клиентов. Ну и для модульности.
2) Ну, не знаю. А папки в прожекте зачем?
3) Другие проекты это лучше бросить. Какие такие другие? А исходники лучше предоставлять, как Id, без исходников невозможно ничего изменить - например, доработать самостоятельно некоторые части движка, вон сколько Quake 2 переделок.

В общем, ладно. Остальные вопросы оставим "напотом". Этот топик был открыт мною для набора челов, авось кто откликнется. Можно сказать, что проектик неуверенно стартанул, хотя я и писал, что нужно где-то 3-4 программера, но по пути кто-то ещё может присоединиться.

Так, предлагаю пока придумать название проекта (как-никак, а это дело первостепенное) и открыть топик Шаг1.
Навание, хм-м-м. Grom что-то смахивает на Gnom, честное пионерское. Вот например мой уже бывший движок назывался Z-Trek - Z от того, что он для 3D (раньше я занимался на досуге DirectDraw и спрайтами), а Trek - как бы говорит, что он скоростной.

Впрочем, толкать бывшие свои названия как-то нехорошо, но всё же симпатично и нейтральное словцо. Если не согласен, слушаю другие предложения.

#84
13:16, 29 авг. 2003

Джо
Не понял Z-Trek - это предложение названия или это ты рассказываешь предисторию :)
Но ведь, то что тебе чудиться - это не аргумент.
Если не нравится - предлагай свой( тока название покороче )
Вообщето это не принципиально, поэтому я соглашусь. :)

>> А как время компиляции можно уменьшить

Возьмем core.dll - модуль как ты заметил содержащий в себе утилитарные функции( логи файлы и др. хрень ). Проектирую его для того чтобы можно было его подключать в разные проекты. Например в редактор объектов на уровне. Или совершенно посторонний проект.
( я планирую его использовать и в своей основной работе )
Я отвлекся.
Предположим мы разрабатываем и отлаживаем следующий уровень engine.dll. Так вот если у нас есть core.dll то он не перелинковывается каждый раз когда ты линкуешь engine.dll.
То же самое можно сказать и про Game.exe основанного на core.dll и engine.dll.

Второй чисто орг. момент:
  Как минимум будет три подпроекта:
  Движок.exe              Game.exe          GameEd.exe
и как ты планируешь без модульности нижнего уровня - пихать в каждый из этих проектов по копии одного и того же кода? Так в принципе не делается - это не правильный подход.

Следующий момент:
Предположим у нас готово все :) И распространено 8) во многих экземплярах. Но обнаружена ошибка при работе с векторами. Что делать. В твоем случае править ошибку и перекомпилировать все exe. В моем случае только dll за него отвечающую.

ЗЫ: И потом, технология отработана - никаких затыков нет.
ЗЗЫ: Падения производительности работы нет никакого( разве что только на начальном этапе инициализации )

>> топик Шаг1

:)  Трилогия "Гром"
    книга 1 "Движок"
      Раздел 1. "Коря движка"
        "Синопсис, или что было раньше"
        Введение. "Мы и Оно, что же все-таки делать"
        Гл1.  "Структура"
        ...

    книга 2 "Игра"
      ...

    книга 3 "Редактор"
      ...

Назовем глава1, а то с шагами - тут плагиатом попахивает.

#85
17:13, 29 авг. 2003

Altalert
Этак мы никогда не попадём в chapter 1. Давай сначала утвердим название будущего движка, а потом уже спорить насчёт dll и т. д.

>Если не нравится - предлагай свой( тока название покороче )
Да, что-то GROM не нравится. GNOM какой-то, с белоснежками...
Z-Trek это я предлагаю назвать так наш совместный движек, так назывался мой старый движек на Pascal. IMHO навзание симпатичное и нейтральное, лучше чем G.A.M.E.dat.

Если не согласен - предлагай ещё какие-нить названия, я тоже могу подумать.

PS. А в chapter 1 начнём обсуждать общую концепцию движка.

#86
18:23, 29 авг. 2003

Джо

Ок. Пусть будет Z-Trek.

#87
13:41, 30 авг. 2003

Джо, я бы очень хотел присоедениться, но к сожалению уже задействован в проекте (который сам и задумал). Наша игра называется SICH - это на всякий случай, если, как вы говорите, "дойдет до релиза" (Тут имеется в виду не Запорожская SICH, а SICH в смысле "резня". Украинец поймет). Хотел бы дать пару советов:

1. Пишите только под DX, желательно не 8.1, а 9.0! Поддержка OGL только убЪет время. Ничего принцыпиального это не даст. Такие фичи нужны либо на многоплатформенных приложениях, либо если у юзера не стоит DX. ( OGL есть даже в Win95 ). А DX нужен само собой.

2. Лучше не злоупотреблять дллками. Дело не в производительности. Может пострадать скорость писания движка! Во первых - для проверки длл нужна программа - ее тоже нужно писать. Во вторых -  идет время, пока вы кидаете длл, либ, Н-файл  из однойь папки в другую. Длл скорее всего нужны для мелких функций, не используемых в главном цикле, дабы не засорять код.

3. Не слушайте советы не учавствующих в проекте по согласованию имен типов! Как вам удобно, так и делайте. И кстати usint или как мы привыкли выражаться DWORD - очень нужный тип, особенно в играх - сами увидете.

Удачи! Ни в коем случае ничего не бросайте.

#88
13:58, 30 авг. 2003

Привет, Джо и Altalert!

Заполз я 29.08 на форум (в первый раз) и меня заинтересовала ваша тема. Скачал, прочитал. Неплохо начинаете! Я сам в программировании не особо еще шарю, но мысли по движку настойчиво лезут в голову.

У меня появилась одна мысля. Как говорил мой учитель по ООП, разработка любого проекта должна пройти четыре этапа: анализ, проектирование, эволюция и сопровождение.

1 - Анализ
Изучается предметная область и на уровня абстракций определяется каркас проекта. Для каждой абстракции определяются ее обязанности. Определяются сценарии работы, опять же только на словах - еще не применяются  проф. терминология (все документиируется, еще нет никакого кода!!!)

2 - Проектирование
На этом этапе рассматривается наиболее общий цикл работы системы, что позволит определить взаимосвязи абстракций (также все документируется).

3 - Эволюция
На основе диаграммы абстракций составляется диаграмма класса, определяются интерфейсы и собственно начинается кодирование (bменно здесь будет решено использовать dll или нет). И проект доводится до технологического демо, т.к. целью является именно это, насколько я понял.

4 - Сопровождение
Это очевидно. Исправление ошибок, патчи, add-on и т.д.

Из прочитанного в форуме я понял, что все началось где-то с середины 3-го этапа, т.е. с жмаканья по клаве. Я не сомневаюсь в ваших программистких способностях, но сразу лезть кодировать? Проект либо сразу загнется, либо на половине пути вы поймете, что получается полный отстой. И проект опять же загнется. Типичый тому пример - проект elf-nm'а.

P.S. Для примера вышенаписанного выложу для скачивания выдержку из моей курсовой (когда разберусь как выкладывать :) ).

#89
14:14, 30 авг. 2003

А вот и обещанная ссылка:

http://www.gamedev.ru/download/?id=165.

Страницы: 1 2 3 4 5 6 7 Следующая »
ПроектыФорумОцените

Тема в архиве.