мля... опять движки
По идее первый случай удобнее для многомодульной и легкомодифицирующейся системы, а другой - проще.
Кто что думает по даному поводу?
Стоит ли разделять в движке данные об обьектах на части: типа физ. данные, граф. данные и т.д., тоесть фактически получится несколько бд со связью или хранить все вместе?
По идее первый случай удобнее для многомодульной и легкомодифицирующейся системы, а другой - проще.
Кто что думает по даному поводу?
Мое скромное ИМХО:
Вообще-то все зависит от структуры твоего движка... рендеринг всех обьектов, апдейт по таймеру (физика, анимация), и т.д.
Я например для каждый класс помещаю в отдельный модуль. И такие данные графические, игровые,и другие, храняться в разных классах отсортированых по типам. К примеру все объекты сцены имеют VertexBuffer, матрицу положения в глобальной системе - создаем такой класс, следующий класс создаю потомком от него и добавляю поле "текстура" и например поля необходимые для проверки столкновения(не все ведь объекты должны иметь текстуру и могут сталкиваться с другими), так же как и не все объекты должны быть подвласны законам физики, так зачем хранить например поле "масса обьекта" в общем котле. Так что я бы посоветовал хранить все отдельно в нарастающих/потомственных классах - меньше лишнего кода, легче отлаживать. Что касаеться физики: для этого наверное подошел бы отдельный класс, который будет полем основного класса-движка, этот подкласс и будет обрабатывать объекты которые должны реагировать на законны физики.
Мое скромное ИМХО:
Вообще-то все зависит от структуры твоего движка... рендеринг всех обьектов, апдейт по таймеру (физика, анимация), и т.д.
Я например для каждый класс помещаю в отдельный модуль. И такие данные графические, игровые,и другие, храняться в разных классах отсортированых по типам. К примеру все объекты сцены имеют VertexBuffer, матрицу положения в глобальной системе - создаем такой класс, следующий класс создаю потомком от него и добавляю поле "текстура" и например поля необходимые для проверки столкновения(не все ведь объекты должны иметь текстуру и могут сталкиваться с другими), так же как и не все объекты должны быть подвласны законам физики, так зачем хранить например поле "масса обьекта" в общем котле. Так что я бы посоветовал хранить все отдельно в нарастающих/потомственных классах - меньше лишнего кода, легче отлаживать. Что касаеться физики: для этого наверное подошел бы отдельный класс, который будет полем основного класса-движка, этот подкласс и будет обрабатывать объекты которые должны реагировать на законны физики.
А ты какие движки разрабатываешь? :)
В принципе все я примерно так себе и представлял. Просто интересно не будет ли это потом ударять по универсальности и расширяемости движка?
А ты какие движки разрабатываешь? :)
В принципе все я примерно так себе и представлял. Просто интересно не будет ли это потом ударять по универсальности и расширяемости движка?
Движки :)? да в принципе пытаюсь пока хоть один завершить :).
Универсальность зависит от того как ты организуешь ядро движка, которое потом обрастет классами, эфектами, и т.п.
Расширяемость... хм... ООП в данном случае дает возможность легко модифицировать иерархию объектов, что включает и добавление новых и удаление ненужных. Или ты не про это?
Из 2-х способов которые ты предложил для обсуждения: как организовать всю эту кашу через несколько бд, я себе слабо представляю, поэтому отстаиваю другой способ.:)
Движки :)? да в принципе пытаюсь пока хоть один завершить :).
Универсальность зависит от того как ты организуешь ядро движка, которое потом обрастет классами, эфектами, и т.п.
Расширяемость... хм... ООП в данном случае дает возможность легко модифицировать иерархию объектов, что включает и добавление новых и удаление ненужных. Или ты не про это?
Из 2-х способов которые ты предложил для обсуждения: как организовать всю эту кашу через несколько бд, я себе слабо представляю, поэтому отстаиваю другой способ.:)
Гы. Весь прикол в том что я хочу написать движок, который можна было бы бесконечно расширять :). Просто как я себе представляю. Если у меня каждый обьект в нескольких БД, то допустим физ. движку я уже могу передавать только какую-то одну БД, а не все данные. Вроде должно быть очень быстро. С другой стороны связь между БД, я их даже инжексирую, ударит по скорости. Дилема. К тому же цельная модель имеет свои преимуществапри работе с консолью(опять не надо делать связывание БД), а не цельную по-идее легче разрабатывать - вот блок для физики, вот для графики, и т. д.
Гы. Весь прикол в том что я хочу написать движок, который можна было бы бесконечно расширять :). Просто как я себе представляю. Если у меня каждый обьект в нескольких БД, то допустим физ. движку я уже могу передавать только какую-то одну БД, а не все данные. Вроде должно быть очень быстро. С другой стороны связь между БД, я их даже инжексирую, ударит по скорости. Дилема. К тому же цельная модель имеет свои преимуществапри работе с консолью(опять не надо делать связывание БД), а не цельную по-идее легче разрабатывать - вот блок для физики, вот для графики, и т. д.
А если так... Например, нужно обработать объект в физ. движке. Передаем этому движку адрес объекта, а не все его поля или его целиком (адрес, если не ошибаюсь = 4 байта). Физ. движок по этому адресу вытащит из объекта только те поля, которые ему нужны (модифицирует их и ... объект готов к рендерингу), в твоем случае ты хранишь необходимые поля в БД и тебе после их обработки нужно их еще и прочитать, и наверное, опять где-то (в другой БД) провести изменения ... Хотя тут вопрос еще... можно ведь и БД организовать как список адресов на объекты обрабатываемые в физике. Вариантов много ;) нужно потестить, наверное, что б найти самый гибкий и быстрый.
Но если очень надо то в процессе Loading читаем все из БД в память(или в отдельные классы) а потом работаем RAM <-> Video
Если у юзера стоит видеокарта с AGP то потери будут не очень большие
Юзать же БД будет снижать скорость
Я бы не стал вообще юзать БД
Но если очень надо то в процессе Loading читаем все из БД в память(или в отдельные классы) а потом работаем RAM <-> Video
Если у юзера стоит видеокарта с AGP то потери будут не очень большие
Юзать же БД будет снижать скорость
А я все почему-то думал что БД подразумеваеться своя искуственная типа как динамический массив/список, а не прям Paradox7 например ;)
А я все почему-то думал что БД подразумеваеться своя искуственная типа как динамический массив/список, а не прям Paradox7 например ;)
Есс-но своя ;)
Блин все равно думаю, что нужно придумать какую-то модульную архитектуру. Просто легче скажем сначала написать часть класа обьекта связаную с физикой, потом графикой, потом с звуком или еще чем-то...
А я все почему-то думал что БД подразумеваеться своя искуственная типа как динамический массив/список, а не прям Paradox7 например ;)
Конечно не Paradox ))
Но ведь сначала эта "БД" будет на диске, я и думал что ты хочешь каждый раз ее оттуда читать
З.Ы: я юзаю для этого скрипты. Если надо могу помочь
Конечно не Paradox ))
Но ведь сначала эта "БД" будет на диске, я и думал что ты хочешь каждый раз ее оттуда читать
З.Ы: я юзаю для этого скрипты. Если надо могу помочь
Хранить то все равно где-то надо. И естественно в память подружаються только те объекты, которые нужны для текущей сцены, а не все сразу.
Что конкретно ты делаешь скриптами?
То что находится в его "БД" я делаю через скрипты
Для меня консоль удобнее
Конечно не Paradox ))
Но ведь сначала эта "БД" будет на диске, я и думал что ты хочешь каждый раз ее оттуда читать
З.Ы: я юзаю для этого скрипты. Если надо могу помочь
Помоги плиз :) Есть какая-то инфа?(Кинь тогда на мыло.) А то я себе не представляю зачем здесь нужны скрипты.
Кстати вот еще один мучающий меня вопрос. Допустим что весь мир состоит из "кубов" заданого размера. Есс-но что нужно делать просчет физики и графики в даном "кубе". Вроди так, а как быть на границах, где видно другой "куб". Как-то надо отделить нужную часть соседнего "куба" которую надо просчитать и отрендерить. Как? Неужели рейтрейсить :( ??
Кстати вот еще один мучающий меня вопрос. Допустим что весь мир состоит из "кубов" заданого размера. Есс-но что нужно делать просчет физики и графики в даном "кубе". Вроди так, а как быть на границах, где видно другой "куб". Как-то надо отделить нужную часть соседнего "куба" которую надо просчитать и отрендерить. Как? Неужели рейтрейсить :( ??
Не знаю что ты имеешь ввиду под словом "рейтрейсить"...
В идеале наверное нужно было б нарисовать и соседний куб, но это неэкономично ;), тогда можно попробывать этот самый соседний разбить на еще меньшие кубы и рисовать только видимые.
Помоги плиз :) Есть какая-то инфа?(Кинь тогда на мыло.) А то я себе не представляю зачем здесь нужны скрипты
Может я просто не понял проблемы
Опиши подробнее
Кстати вот еще один мучающий меня вопрос. Допустим что весь мир состоит из "кубов" заданого размера. Есс-но что нужно делать просчет физики и графики в даном "кубе". Вроди так, а как быть на границах, где видно другой "куб"
В некоторых играх(например Morrowind) каждую сторону куба скриншотят и когда ты переходишь из одного куба в другой ты видишь только этот скриншот
Как-то надо отделить нужную часть соседнего "куба" которую надо просчитать и отрендерить. Как? Неужели рейтрейсить :( ??
?
В некоторых играх(например Morrowind) каждую сторону куба скриншотят и когда ты переходишь из одного куба в другой ты видишь только этот скриншот
Это наверное для перехода между локациями в Рпг-играх? (Извени в Morrowind не играл.)
Я о кубах для отсечения в одной локации..
Это наверное для перехода между локациями в Рпг-играх? (Извени в Morrowind не играл.)
Я о кубах для отсечения в одной локации..
Хорошо. Как ты тогда предлагаешь представлять сегменты в движке ориентированом на открытое пространство? Я вижу самым хорошим решением - "куб" определенного размера, а точнее много довольно мелких кубиков, скажем что-бы их висело постоянно в памяти 27. Тогда при переходе из центрального куба в боковой будет происходить подгрузка местности, в освободившиеся "кубы". Как по-другому сделать я не очень представляю...
2Proger_XP
А че подробно описывать. Вот движок хочу написать... Если есть че-то почитать на тему - кидай на мыло или здесь выложи. Я уже сам разберусь. Просто вот со скриптами ты меня немного озадачил. Не пойму я зачем скрипты? И что они делают, если можно конкретней.
Просто вот со скриптами ты меня немного озадачил. Не пойму я зачем скрипты? И что они делают, если можно конкретней
Похоже я все-таки не понял чего ты хочешь ))
Ну играл ты в Quake, CS или Crimsonland?
Там есть консоль, в ней пишешь команды(вечный god или impulse :)) и так отлаживаешь
Попробуй меня понять ))
Похоже я все-таки не понял чего ты хочешь ))
Ну играл ты в Quake, CS или Crimsonland?
Там есть консоль, в ней пишешь команды(вечный god или impulse :)) и так отлаживаешь
Попробуй меня понять ))
Хе, значит мы на разных языках говорим ;)
Ты имеешь ввиду проедуру написаную програмистом, которая просто вызывается из консоли с некоторыми параметрами, и которую именуют скрипт.
Я имел ввиду, тот код для описания мира, который написан дизайнером левела, и который движок должен разобрать и обработать.
Вот, к примеру, задал левел-дизайнер что на вот этом обьекте будет вот такая-то анимированая текстура, которая описывается вот таким кодом... Короче какая-нить трехмерная функция от времени. Насколько я понимаю язык для написания вот таких скриптов придется писать самому и вдобавок еще и интерпретатор. Или я ошибаюсь? А если не ошибаюсь, то кто что рекомендует включить в такой язык?
Хорошо. Как ты тогда предлагаешь представлять сегменты в движке ориентированом на открытое пространство? Я вижу самым хорошим решением - "куб" определенного размера, а точнее много довольно мелких кубиков, скажем что-бы их висело постоянно в памяти 27. Тогда при переходе из центрального куба в боковой будет происходить подгрузка местности, в освободившиеся "кубы". Как по-другому сделать я не очень представляю...
"довольно мелких кубиков" - понятие относительное. Вот от их размера по моему завит нужно ли их разбивать на еще более мелкие, скажем так, не для открытого пространства. А так вообще нечего против не имею ;)
Хе, значит мы на разных языках говорим ;)
Ты имеешь ввиду проедуру написаную програмистом, которая просто вызывается из консоли с некоторыми параметрами, и которую именуют скрипт.
Я имел ввиду, тот код для описания мира, который написан дизайнером левела, и который движок должен разобрать и обработать.
Вот, к примеру, задал левел-дизайнер что на вот этом обьекте будет вот такая-то анимированая текстура, которая описывается вот таким кодом... Короче какая-нить трехмерная функция от времени. Насколько я понимаю язык для написания вот таких скриптов придется писать самому и вдобавок еще и интерпретатор. Или я ошибаюсь? А если не ошибаюсь, то кто что рекомендует включить в такой язык?
Интерпритатор не сложно делается и язык придумать довольно легко
Например тоже что ты описал я бы сделал скриптом типа:
load texture TextureID FileName
new cube X Y Z TextureID
set texture animate TextureID TID1 TID2 TID3
"довольно мелких кубиков" - понятие относительное. Вот от их размера по моему завит нужно ли их разбивать на еще более мелкие, скажем так, не для открытого пространства. А так вообще нечего против не имею ;)
Так вот и я думаю что это хорошо. "Куб" он же виртуальный. Ну то-есть его размер в памяти зависит только от количества обьектов на нем. Но это не очень важно. Важно, как я говорил - организовать просмотр видимой части соседних кубиков, и соответственно физику в ихней видимой части.
2Proger_XP
Понимаешь, пока что вся проблема в строке:
load texture TextureID FileName ;)
К тому же проблема, что-бы по необходимости при выполнении строчки:
set texture animate TextureID TID1 TID2 TID3
битмап если надо то уже изменлся.
Понимаешь, пока что вся проблема в строке:
load texture TextureID FileName
Ты не можешь загрузить текстуру?
Скажи на чем ты собираешься писать(Direct3D или OpenGL)
К тому же проблема, что-бы по необходимости при выполнении строчки:
set texture animate TextureID TID1 TID2 TID3
битмап если надо то уже изменлся
Ты же должен указать на что он должен изменится ))
Ты не можешь загрузить текстуру?
Скажи на чем ты собираешься писать(Direct3D или OpenGL)
К тому же проблема, что-бы по необходимости при выполнении строчки:
set texture animate TextureID TID1 TID2 TID3
битмап если надо то уже изменлся
Ты же должен указать на что он должен изменится ))
Еще раз обьясню, что текстура, это не обязательно битмап. Битмап - частный случай. Более общий случай текстуры - скрипт, по которому генерится битмап. Писать буду есс-но на OpenGL.
Еще раз обьясню, что текстура, это не обязательно битмап. Битмап - частный случай. Более общий случай текстуры - скрипт, по которому генерится битмап. Писать буду есс-но на OpenGL.
А я не говорил про BMP ))
На OpenGL текстуры грузятся легко
Могу кинуть юнит GLEx там есть функция грузящая BMP, RGB, RGBA и JPG в текстуры
А я не говорил про BMP ))
На OpenGL текстуры грузятся легко
Могу кинуть юнит GLEx там есть функция грузящая BMP, RGB, RGBA и JPG в текстуры
Да причем здесь JPEG. Текстура может выглядеть, к примеру, так:
for (i = 0; i<32; i++)
for (j = 0; j<32; j++)
image[i,j] = cos(i)*sin(j)*255;
Только нужно еще продумать скрипт, которым можно будет ее задавать в динамике, чтоб он был относительно прост, и максимально гибкий. Это и будет загрузка текстуры - одна из функций в скрипте:
load texture TextureID FileName
new cube X Y Z TextureID
set texture animate TextureID TID1 TID2 TID3
Текстура может выглядеть, к примеру, так:
for (i = 0; i<32; i++)
for (j = 0; j<32; j++)
image[i,j] = cos(i)*sin(j)*255;
Это уже динамическая текстура
Только нужно еще продумать скрипт, которым можно будет ее задавать в динамике, чтоб он был относительно прост, и максимально гибкий
Можно сделать как в макросах A86:
#i0-32
#j0-32
set texture pixel TextureID i j cos(i)*sin(j)*255
Но для реализации нужно будет сделать функцию компилятора, т.е считать выражения
Желательно ее сделать на асме
З.Ы: похоже тебе понравились скрипты ))
Это уже динамическая текстура
Только нужно еще продумать скрипт, которым можно будет ее задавать в динамике, чтоб он был относительно прост, и максимально гибкий
Можно сделать как в макросах A86:
#i0-32
#j0-32
set texture pixel TextureID i j cos(i)*sin(j)*255
Я думал - динамическая текстура - изменяется со временем, а процедурная - тоже генерируется, но не изменяется. Но ... неважно как ее называть,я вот и говорю что мне надо придумать скрипт для генерирования таких вот текстур. Вот и спрашиваю есть ли у кого-нить идеи по этому поводу, только хочу чтоб можно было абсолютно любые текстуры генерить. И нету ли каких-либо библиотек с даными фичами?
[QUOTE]Originally posted by Proger_XP
Это уже динамическая текстура
Только нужно еще продумать скрипт, которым можно будет ее задавать в динамике, чтоб он был относительно прост, и максимально гибкий
Можно сделать как в макросах A86:
#i0-32
#j0-32
set texture pixel TextureID i j cos(i)*sin(j)*255
Я думал - динамическая текстура - изменяется со временем, а процедурная - тоже генерируется, но не изменяется. Но ... неважно как ее называть,я вот и говорю что мне надо придумать скрипт для генерирования таких вот текстур. Вот и спрашиваю есть ли у кого-нить идеи по этому поводу, только хочу чтоб можно было абсолютно любые текстуры генерить. И нету ли каких-либо библиотек с даными фичами?
Ты хочешь попиксельно генерить текстуру? Это долго
А чем тебе мой код не понравился
Библиотек таких я не знаю
Ты хочешь попиксельно генерить текстуру? Это долго
А чем тебе мой код не понравился
Библиотек таких я не знаю
НЕ обязательно попиксельно. Это пример такой. А вообще я думаю над "языком" который позволит писать скрипты, причем абсолютно любой сложности.
НЕ обязательно попиксельно. Это пример такой. А вообще я думаю над "языком" который позволит писать скрипты, причем абсолютно любой сложности
Абсолютно? А какая раздница?
З.Ы: Я на OpenGL пишу что-то вроде интерпритатора команд OpenGL
Абсолютно? А какая раздница?
З.Ы: Я на OpenGL пишу что-то вроде интерпритатора команд OpenGL
Я вот подумал - если я буду рефрешить такую динамическую текстуру каждый раз в памяти, а их к примеру будет несколько, то у меня уйдет дохрена ресурсов на это дело. Интересно - как это можно обойти? Сохранять в памяти все возможные варианты битмапов? Оба решения мне что-то не очень нравятся.
Я вот подумал - если я буду рефрешить такую динамическую текстуру каждый раз в памяти, а их к примеру будет несколько, то у меня уйдет дохрена ресурсов на это дело. Интересно - как это можно обойти? Сохранять в памяти все возможные варианты битмапов? Оба решения мне что-то не очень нравятся.
Здесь выбор юзеру(или разработчику) - если важна скорость - юзай память(мне это больше нравится), мало памяти - юзай процессор
Интересная прога(не моя (( )
Здесь выбор юзеру(или разработчику) - если важна скорость - юзай память(мне это больше нравится), мало памяти - юзай процессор
Интересная прога(не моя (( )
Прга прикольная, только у меня че-то глючит хапись в файл.
Прога прикольная, только у меня че-то глючит хапись в файл
Удобная вещь но эффектов мало ((
Ты умеешь что-нибудь подобное делать?
У меня все ок
Удобная вещь но эффектов мало ((
Ты умеешь что-нибудь подобное делать?
У меня все ок
Когда-то тоже хотел написать просто огонь - написал, посмотрел, ужаснулся от того что получилось и забил :)
Вот - посмотри
Когда-то тоже хотел написать просто огонь - написал, посмотрел, ужаснулся от того что получилось и забил :)
Вот - посмотри
Не так уж и плохо
Посмотри плиз сюда:
http://forum.codenet.ru/showthread.php?s=&threadid=24658
Не так уж и плохо
Посмотри плиз сюда:
http://forum.codenet.ru/showthread.php?s=&threadid=24658
Я видел это обьявление. Только максимум что я знаб - пару тегов в HTML. Никак не возьмусь книгу по Perl перечитать :(
А огонь очень просто біл сделан - генерировались "палочки" разной длины и размsвались :)
Я видел это обьявление. Только максимум что я знаб - пару тегов в HTML. Никак не возьмусь книгу по Perl перечитать
Жалко
А огонь очень просто біл сделан - генерировались "палочки" разной длины и размsвались
Ясно ))
Стоит ли учить движок читать из *.max файла или делать свой редактор, формат со всеми выхордящими отсюда последствиями, учитывая что куча возможностей 3d studio max мне точно не понадобится????
Вот у меня другая проблема, скорее дилема :)
Стоит ли учить движок читать из *.max файла или делать свой редактор, формат со всеми выхордящими отсюда последствиями, учитывая что куча возможностей 3d studio max мне точно не понадобится????
А зачем рефрешить всю БитМапу??? разве нельзя обращаться к тем ее участкам которые будет изменяться???
Хотя Прогер прав, лучше при инициализации первой, чтобы эти БитМапы все на диск записалисьЮ загрузка быстрее, чем обработка)))