Engine(Direct3D + OpenGL): Vertex Menager

MagicWolf

http://gamedesign.narod.ru - вроде как давно не обновлялся.
Каких-то конкретных требований по классам я не встречал.
По Terrain есть книга:
Создание 3D-ландшафтов в реальном времени с использованием C++ и DirectX 9 (+ CD-ROM) - http://www.ozon.ru/context/detail/id/2403841/

ypp

MagicWolf писал(а):

По второму методу можно предложить такое решение: делаешь виртуальный класс GraphicObject у него метод render, и потом лепишь потомка GraphicObject_Mesh_OGL, или GraphicObject_Mesh_D3D в нем уже соответственно, что тебе надо помещаешь в метод render.

Подобное решение я и имел ввиду. Одной из причин "некрасивости" данного решения является та же сильная связность классов. В твоем примере при изменении представления мэша в GraphicObject_Mesh нужно будет изменить еще 2 класса: GraphicObject_Mesh_GL и GraphicObject_Mesh_D3D. (Здесь я подразумеваю существование класса GraphicObject_Mesh. Если такового не имеется, тогда дела еще хуже.)

MagicWolf писал(а):

Более того при этом методы ты можешь иметь классы типа GraphicObject_Mesh_OGL_Win или GraphicObject_Mesh_OGL_Linux

Если чесно, я не совсем понимаю для чего нужны эти классы.

З.Ы. Для себя я избрал иной вариант: рендеринг только через OpenGL. Это дает ряд преимуществ:
1) Пропадают описанные выше проблемы: каждий графический обьект рендерит сам себя с помощью вызовов OpenGL-функций.
2) Отпадает необходимость в изучении DirectX. ИМХО, лучше знать только одно API, но на профессиональном уровне, чем два на базовом уровне.
3) Шейдеры. Недавно перешел с Cg на GLSL. Едиственное, что могу сказать: Cg _далеко_ позади GLSL. А как извесно, Cg и HLSL (DirectX-овый) - почти близнеци. Отсюда, могу предположить, что GLSL лучше HLSL.

eNrix

"Создание 3D-ландшафтов в реальном времени с использованием C++ и DirectX 9" - где бы эту книгу в инете в русской версии достать. Дальше урр я думаю, что это как раз будет подходить, а эти классы должны унаследованы соответственно от GraphicObject. Дальше MagicWolf писал:

Цитата:

По второму методу можно предложить такое решение: делаешь виртуальный класс GraphicObject у него метод render, и потом лепишь потомка GraphicObject_Mesh_OGL, или GraphicObject_Mesh_D3D в нем уже соответственно, что тебе надо помещаешь в метод render

Так как этот метод Рендер к дочерних классов Graphic Object: GraphicObject_Mesh_D3D и GraphicObject_Mesh_OGL делать у класса геометрии объектов - опять указатель в классе делать на дочернии классы Render? Если так хорошо вы урр знаете OpenGL могу предложить совместное написание движка. Как насчет полной структуры как она должна выглядеть для всех классов я имею ввиду все унаследования и названия классов.

eNrix

В движке Борескова как таковой структурной унаследовательности не делаеться - для этого используются указатели. Как вы думаете это хороший метод? кто смотрел http://gamedesign.narod.ru тут как раз наоборот.(скачайте последнюю версию в разделе скачать - step5_5) Кстати я писал в гостевую но никто не ответил странно, но сайт заброшен !!!

eNrix

А как насчет обаботки Log файла и ошибок. Надо написать такой класс который бы при ошибке выводил окно с названием ошибки, место где она произошла. В Log файл записывается работа всего движка.

MagicWolf

ypp писал(а):

Подобное решение я и имел ввиду. Одной из причин "некрасивости" данного решения является та же сильная связность классов.

Связаность мне кажется будет возникать только тогда, когда GraphicObject_Mesh_GL, что-то надо будет в GraphicObject_Mesh, так что вначале думать что надо сделать в GraphicObject_Mesh_GL, а потом уже в GraphicObject_Mesh, так как фактически GraphicObject_Mesh хранить исключительно геометрию, и если не делать конструктора геометрии в этом же классе, в нем помимо данных больше ничего и не будет.

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

Потом может быть несколько вариантов GraphicObject_Mesh, функций для его вывода, например, вариант для ландшафта, вариант, для 3ds, для md3 или еще чего-то. Проще на мой взгляд, не увеличивать функциональность GraphicObject_Mesh, а делать ему подобные классы с другой функциональнсотью.

Здесь есть другая проблема! Дело в том, что такой подход не позволяет использовать одну и ту же геометрию для для нескольких игровых объектов!

ypp писал(а):

З.Ы. Для себя я избрал иной вариант: рендеринг только через OpenGL. Это дает ряд преимуществ:
1) Пропадают описанные выше проблемы: каждий графический обьект рендерит сам себя с помощью вызовов OpenGL-функций.

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

ypp писал(а):

2) Отпадает необходимость в изучении DirectX. ИМХО, лучше знать только одно API, но на профессиональном уровне, чем два на базовом уровне.

Если ты хочешь эти зарабатывать на жизнь - придется!

ypp писал(а):

3) Шейдеры. Недавно перешел с Cg на GLSL. Едиственное, что могу сказать: Cg _далеко_ позади GLSL. А как извесно, Cg и HLSL (DirectX-овый) - почти близнеци. Отсюда, могу предположить, что GLSL лучше HLSL.

Это интересно наблюдение! Спасибо!

MagicWolf

eNrix писал(а):

"Создание 3D-ландшафтов в реальном времени с использованием C++ и DirectX 9" - где бы эту книгу в инете в русской версии достать.

Не знаю

.

MagicWolf

eNrix писал(а):

В движке Борескова как таковой структурной унаследовательности не делаеться - для этого используются указатели. Как вы думаете это хороший метод? кто смотрел http://gamedesign.narod.ru тут как раз наоборот.(скачайте последнюю версию в разделе скачать - step5_5) Кстати я писал в гостевую но никто не ответил странно, но сайт заброшен !!!

Да похоже нато. Скорее всего забугор ...

MagicWolf

eNrix писал(а):

А как насчет обаботки Log файла и ошибок. Надо написать такой класс который бы при ошибке выводил окно с названием ошибки, место где она произошла. В Log файл записывается работа всего движка.

Здесь вроде как ничего сложного нет. Пишешь CLog, в него суешь нужные функции, типа записи в файл сообщений, потом оставляешь глобальный указатель на него и пользуешься им.

ypp

Цитата:

А как насчет обаботки Log файла и ошибок. Надо написать такой класс который бы при ошибке выводил окно с названием ошибки, место где она произошла. В Log файл записывается работа всего движка.

Сходи на http://www.dtf.ru, там была статья (названия не помню, но что-то вроде "Методы отладки приложений. Протоколирование"). На ее основе я свой "систем лог" написал.

ypp

Цитата:

Если ты хочешь эти зарабатывать на жизнь - придется!

Здесь и согласен, и не_согласен. Одновременно.
1) Придется. Недавно пробовал устроится в одну гейм-дэв контору. Даже тестовое задание выполнил всрок. По-моему, единственным небостатком было мое незнание DirectX, потому и не берут... пока.
2) Заработать можно. Посмотреть хотя бы на Unigine (http://www.unigine.com) - движок OpenGL-ный. Да и перспективы у него очень хорошие, ИМХО. И вообще, дело не в графической библиотеке, а в команде которая работает над проэктом.

MagicWolf

2 - согласен ...
unigine - посмотрел, это нечто! :yeah:

- но это годы работы!

MagicWolf

Насчет Log, вот такой прием можно юзать:
class ACLog {
//--------- log error/message

public:

ACLog ()
{
global_log = this;
max_error = MESSAGE_LOG_NORMAL;
}

~ACLog ()
{
global_log = 0;
}

virtual void puts (EType_Message_Log tm, char * str) = 0;
virtual void printf (EType_Message_Log tm, char * format, ...) = 0;
virtual char * get_last_str () = 0;
EType_Message_Log get_max_error () { return max_error; }

static ACLog * global_log;
static bool is_error;
EType_Message_Log max_error;

};

Смысл в том, что делаешь global_log - глобальную переменную, затем ее можно юзать так:

void log_message( char * fmt, ... )
{
va_list argptr;
memset(str,0,1000);
va_start(argptr, fmt);
vsprintf(str, (const char *)fmt, argptr);
va_end(argptr);

_strtime(caTime);
ACLog::global_log->printf(MESSAGE_LOG_NORMAL,"%s:/MESSAGE/ %s\n", caTime, str);
}

ACLog::global_log - так вызываешь текущий лог файл.

Можешь потом сделать class CFile_Log : public ACLog, а далее class CHtml_Log : public ACLog. Затем в одном месте! пишешь CHtml_Log log_file("steps1.log.html",true); - глобальный лог готов к работе.

Ну и как по простому организовать html, хотя по мне и CFile_Log вполне хватит:

#define COLOR_RED ""
#define COLOR_ORANGE ""
#define COLOR_YELLOW ""
#define COLOR_GREEN ""
#define COLOR_BLUE ""
#define COLOR_PURPLE ""
#define COLOR_BLACK ""
#define COLOR_WHITE ""
#define COLOR_GRAY ""

#define END_STR " \n</BODY></HTML>"

void CHtml_Log:: puts (EType_Message_Log tm, char * str)
{
char * clr;
if ( h_file!=-1 ) {
_lseek(h_file, -14, SEEK_END);
switch ( tm ) {
case MESSAGE_LOG_DEBUG: clr = COLOR_BLUE; break;
case MESSAGE_LOG_ERROR: clr = COLOR_PURPLE; break;
case MESSAGE_LOG_ALRAM: clr = COLOR_RED; break;
default:
clr = COLOR_BLACK; break;
}
::_write(h_file,clr,(unsigned int)strlen(clr));
::_write(h_file,str,(unsigned int)strlen(str));
clr = END_STR;
::_write(h_file,clr,(unsigned int)strlen(clr));
}
if ( tm>max_error ){
max_error = tm;
strcpy(str_max_error,str);
}
}

eNrix

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

Код:

c:\Programming\Engine\source\Render.cpp(2): fatal error C1010: unexpected end of file while looking for precompiled header directive

Посмотрел header вроде все нормально. Весь код можете посмотреть на http://defg.narod.ru там заменен архив со старым движком на новую разработку. В ней пока я только начал делать. Дальше я хочу свой движок сделать в .dll я создал проект c export symbols - зачем это я не знаю но помню пишут что нужно поставить его. Еще я не пойму обязательно мне ставить DEFG_API возле каждого класса(напр class DEFG_API Render это если проект с .dll называется defg). В своем движке мне наверное в каждом классе прийдеться делать всю абстракцию(в OpenGLRender и Direct3DRender). И еще как вы мне предложите совместить способы вывода вершин в OpenGLRender и Direct3DRender? Пока я сам делать буду Direct3DRender если есть желающие содействовать в разработке движка приглашаются. Боресков как я понял просто сделал вывод в OpenGLView полигона и абстракцию смешивания и наложения текстуры. Если совмещать две библиотеки то прийдется писать новые классы для работы с текстурами, шрифтами. По сути я думаю может для Direct3DRender хватит и одного IDirect3DVertexBuffer и одного IDirect3DIndexBuffer или прийдеться писать класс для их хранения ? А как насчет шейдеров выходит что если используешь Direct3D то HLSL а если OGL то GLSL или все таки можно какой то общий язык в движке использовать ?

MagicWolf

eNrix писал(а):

Ок посмотрю пока этот способ работы с LogFile наверное его возьму, а теперь вернемся к тому что обсуждалось так вот.

Это один из возможных вариантов.

eNrix писал(а):

У меня во время компиляции движка вылазит вот такая ошибка:

Код:

c:\Programming\Engine\source\Render.cpp(2): fatal error C1010: unexpected end of file while looking for precompiled header directive

Где-то есть #ifdef, а #endif не стоит...

eNrix писал(а):

Посмотрел header вроде все нормально. Весь код можете посмотреть на http://defg.narod.ru там заменен архив со старым движком на новую разработку.

А кто код заменил? И что изначально код не компилировался?

eNrix писал(а):

В ней пока я только начал делать. Дальше я хочу свой движок сделать в .dll я создал проект c export symbols - зачем это я не знаю но помню пишут что нужно поставить его.

Это экспортируемые символы, т.е. процедуры или переменные которые будут видны в dll, другим прогам.

eNrix писал(а):

Еще я не пойму обязательно мне ставить DEFG_API возле каждого класса(напр class DEFG_API Render это если проект с .dll называется defg).

Так наверно задается экспорт в dll. Какое там определение.

eNrix писал(а):

В своем движке мне наверное в каждом классе прийдеться делать всю абстракцию(в OpenGLRender и Direct3DRender).

Не свосем понял о чем речь, какую абстракцию?

eNrix писал(а):

И еще как вы мне предложите совместить способы вывода вершин в OpenGLRender и Direct3DRender?

В каком смысле совместить?

eNrix писал(а):

Пока я сам делать буду Direct3DRender если есть желающие содействовать в разработке движка приглашаются.

Увы, я пас. Можно дать объявление на сайт о том, что ты набираешь команду.

eNrix писал(а):

Боресков как я понял просто сделал вывод в OpenGLView полигона и абстракцию смешивания и наложения текстуры. Если совмещать две библиотеки то прийдется писать новые классы для работы с текстурами, шрифтами. По сути я думаю может для Direct3DRender хватит и одного IDirect3DVertexBuffer и одного IDirect3DIndexBuffer или прийдеться писать класс для их хранения ?

Для хранения чего?

eNrix писал(а):

А как насчет шейдеров выходит что если используешь Direct3D то HLSL а если OGL то GLSL или все таки можно какой то общий язык в движке использовать ?

Ни как. Там микропроги на по разному написаны, так что для каждого эффекта будут свои проги, и вывод их будет разный, только эффект один и тот же. Вот так я это понял :sex:

PMG

Engine(Direct3D + OpenGL): Vertex Menager

Кто сейчас на конференции