LINUX.ORG.RU

Сплю с огром :)

 , ,


1

4

Кто с кем, а я вот с огром в последнее время «сплю» :) Собираю движок, наконец-то закончил основу Ogre+Bullet+MyGUI+OpenAL, так что осталось не так много до полноценного движка: написать менеджер сцен, менеджер игровых состояний, типы объектов разделенные на статические, динамические, специальные (свет, звук и т.п.), все это хранить в тхт или хмл (пока не решил) и т.п. После этого можно набросать фичей редактору сцен, пока он умеет разве что меши двигать. В общем работы эдак на полгода с моей медлительностью, но я верю — все получится.
>Видео<

>>> Просмотр (1440x900, 767 Kb)



Проверено: JB ()

Ответ на: комментарий от KennyMinigun

Почитайте сравнения тут, например: http://ru.wikipedia.org/wiki/JSON

Не надо JSON, серьезно. Для XML есть и XSD с нормальной валидацией, и SAX парсеров нормальных полно, и полиморфные элементы в нем удобнее хранить. А JSON советуют просто потому что это модно и молодежно. Для сложных структур данных XML вне конкуренции.

theos ★★★
()

Ты просто Молодец.
Так же хочу, но горы не пускают. :(

amorpher ★★★★★
()

Тоже интересна эта тема. Но я пишу свой рендер, но дальше cubemapping пока не зашло.

sol_linux ★★
()

Это наверное какое-то обострение, но недавно тоже начал писать игру. 2d-платформер, правда. За эклипс плюс. Раньше на него внимания не обращал, нопосле стрима нотча, увидев что с ним можно вытворять, только в эклипсе и пишу.

Dragon59 ★★
()
Ответ на: комментарий от theos

Для XML есть и XSD с нормальной валидацией, и SAX парсеров нормальных полно, и полиморфные элементы в нем удобнее хранить.

http://ru.wikipedia.org/wiki/JSON

Я не имел ввиду JSON. Просто в той статье сравнение неплохое. Но раз за JSON - так за JSON.
Во-первых для последнего есть куча парсеров на любой вкус (свободных, лёгких, простых, быстрых). Тут хорошее обсуждение. А Тут приличный список JSON библиотек для разных ЯП (и платформ). Во-вторых валидаторы схемы для JSON тоже есть (Тут и Тут тоже).

А JSON советуют просто потому что это модно и молодежно.

Поддержу Ваше мнение: а XML - это по старпёрски.

и полиморфные элементы в XML удобнее хранить.

Тут согласен. Если сериализовать обьекты определённого класса, то логично предположить такую семантику:

<namespace:SomeClass><!-- Описание внутренней структуры --></namespace:SomeClass>

Но ведь в JSON никто не запрещает добавить поле для идентификации типа:

{ type: "SomeClass", namespace: "namespace", /*  Описание внутренней структуры */ }

Для сложных структур данных XML вне конкуренции.

Почему?

KennyMinigun ★★★★★
()
Последнее исправление: KennyMinigun (всего исправлений: 5)
Ответ на: комментарий от KennyMinigun

Но ведь в JSON никто не запрещает добавить поле для идентификации типа:

Потому что в этом случае для него стриминговый парсер писать сложнее, чем для XML.

Во-вторых валидаторы схемы для JSON тоже есть

Да я знаю, но они и близко не развиты по сравнению со всей инфраструктурой XSD

приличный список JSON библиотек для разных ЯП

И? ДЛя xml еще больше.

Для сложных структур данных XML вне конкуренции.

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

theos ★★★
()

Клёво:) Программировать графику - это вообще классно:)

А что за музыка на фоне играет в видео?

mega_venik ★★★
()
Ответ на: комментарий от mega_venik

Видимо это минус на песню Born Divine - Money comes easy

xSudo ★★★
()

но я верю — все получится.

Я верю - город будет
Я верю - саду цвесть
Когда такие люди
В стране советской есть.

vada ★★★★★
()

Отличная работа! все получится у тебя!

Int64 ★★★
()

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

netcat ★★
()
Ответ на: комментарий от theos

JSON советуют просто потому что это модно и молодежно.

JSON советуют потому что компактно и читабельно. А если данных много, то стоит задуматься и о бинарном формате. А то я как-то видел игрушку с сейвами в XML... по 150 мег каждый.

А следуя твоим аргументам за XML, может, сразу писать све на дотнете под винду? А что, популярно и есть куча всего готового.

segfault ★★★★★
()
Ответ на: комментарий от segfault

JSON советуют потому что компактно и читабельно.

Для сложны полиморфных структур данных - XML читабельней.

<objects>
<point x="10" y="20/>
</objects>

"objects": [
  {"type":"point", "x":10, "y":20}
]

Ну и где принципиальная разницав объеме? На больших объемах данных удобно иметь текст закрывающего тэга - потому что «открывающего» ты не видешь.А учитывая что саксом парсить удобнее первую - то в чем вообще прикол?

А если данных много, то стоит задуматься и о бинарном формате.

Безусловно. Но если в размер идет на мегабайты - XML отлично будет перевариваться.

А следуя твоим аргументам за XML, может, сразу писать све на дотнете под винду?

А следуя твоим - давайте писать под все под QNX на Haskell - ибо модно и малораспространено. Передергивать то не надо. Просто на ЛОРе модно ругать XML, это я уже много где видел.

theos ★★★
()
Последнее исправление: theos (всего исправлений: 2)
Ответ на: комментарий от KennyMinigun

Почему?

потому что нехер лезть с советами не зная конкретики структуры данных. твой json удобен для веба в обмене мелкими не сильно структурированными данными. сложные структуры одуреешь втискивать. загляни для примера в потроха svg-картинки (если у тебя установлен inkscape, то открой вот этот файлик /usr/share/inkscape/examples/car.svgz )

Deleted
()
Ответ на: комментарий от theos

Для сложны полиморфных структур данных - XML читабельней.

Ну не все из них состоит. Иногда полиморфизм вообще не нужен.

А XML я ругал еще до знакомства с ЛОРом.

segfault ★★★★★
()

Из форматов для подобного - XML, JSON - Годно. Но как только появится необходимость тащить за собой сотню-другую объектов да текстур да шейдеров да прочей дряни - подумайте не о архивчиках, а о бинарном формате. Любопытно, как кто придумает вязать его с огром. Вродь есть у него чтение из потока...

С буллетом гораздо интересней: с ним будет интересно делать джоинты. С тримешами в нем несложно, а вот с джоинтами вы намучитесь порядочно ;) Пример, на котором стоит тестировать будущий функционал (просто вброс для раздумий): слепить полноценную машинку из кучи разных объектов в вашем будущем редакторе.

И еще одно: подумайте о том, чтобы выхлоп из редактора можно было обернуть в какой-нибудь bundle: скинул другу файлик по почте/скайпику/whatever - и он уже оценивает. При том учесть надо, что у друга Ogre/Dev environment нету ;)

Удачи! Будет любопытно поглядеть на результат =)

shybovycha
()
Ответ на: комментарий от mega_venik

там Ogre3D, вся графика готова. и физика из движка взята, и звук в OpenAL, и UI готовый. там пишется все, кроме графики, физики и звука с мордой.

x0r ★★★★★
()
Ответ на: комментарий от Deleted

Ну, svg - это совсем не идеал использования xml. Мягко говоря. Я бы даже его привел в виде примера, как не надо использовать xml.

В сравнении json vs xml у xml'а главное преимущество - наличие горы всевозможных парсеров под разные случаи жизни при сравнительно небольшой разнице в объеме. Наличие потоковых парсеров еще и облегчает чтение сжатых данных.

Я бы еще посоветовал взглянуть на wbxml или на ebml.

CybOrc
()
Ответ на: комментарий от segfault

Ну не все из них состоит. Иногда полиморфизм вообще не нужен.

Бинго. Поэтому я и прошу разделять маленькие серверо-браузерные сообщения и большие сложные документы. И для каждого свой инструмент.

theos ★★★
()
Ответ на: комментарий от netcat

Круто, а я пока с сюжетом мучаюсь.

Скинь на лор как напишешь, интересно будет почитать. Кстати как с освоением Cafu успехи? Вообще, было бы хорошо, если замутишь свою ветку уроков по нему, с одной стороны сам учишься, с другой пропиаришь на лоре чуток, а то тут кроме квейковских движков, альтернатив не знают :]

makeB
() автор топика
Ответ на: комментарий от BambarbiyaKirgudu

Это будущий движок для игр?

Ну да, думаю да. Хотя по честному, не знаю для чего я это делаю, просто нравится.

makeB
() автор топика
Ответ на: комментарий от OpenMind

очень годно. А как у него с быстродействием?

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

makeB
() автор топика
Ответ на: комментарий от CybOrc

Ну, svg - это совсем не идеал использования xml. Мягко говоря.

ну да, ты это еще авторам ODF скажи. они ж там все такие лохи сидят, куда им до наших онолитиков лора :D

Deleted
()

надумаеш делать игровой бенчмарк - пиши есличо - у меня есть пара идей на консервации

wst ★★★★
()
Ответ на: комментарий от makeB

Для разрушеных объектов лучше сделать чтобы они теряли физические свойства от растояния и при состоянии покоя. Так и на вид незаметно будет, и нагрузка низкая.

OpenMind ★★★★
()
Ответ на: комментарий от Dragon59

Я может чего пропустил, но давно из блендера сделали графический редактор?

А что мешает запретить движение по вектору высоты? В остальном разницы не будет, я кстати делал платформер на блендере, единственная проблема — производительность.

makeB
() автор топика
Ответ на: комментарий от makeB

2d-платформер и 3d-игра с видом сбоку немного разные вещи. Или ты мне предлагаешь 2d-графику натягивать на плоские полигоны и ставить камеру сбоку? Это даже не бдсм, это что-то ещё более изощрённое :)

Dragon59 ★★
()
Последнее исправление: Dragon59 (всего исправлений: 1)
Ответ на: комментарий от Dragon59

Или ты мне предлагаешь 2d-графику натягивать на плоские полигоны и ставить камеру сбоку? Это даже не бдсм, это что-то ещё более изощрённое :)

Именно :] Ниче, я делал, вообщем-то удобно, зато полноценный редактор с плюшками, и прогаешь не выходя из блендера, короче все в нем считай делаешь, кроме текстур естественно.

makeB
() автор топика
Ответ на: комментарий от makeB

^Там ортогональная камера для таких вещей есть

makeB
() автор топика
Ответ на: комментарий от theos

Поэтому я и прошу разделять маленькие серверо-браузерные сообщения и большие сложные документы.

А как быть с большими и сложными серверо-браузерными сообщениями и маленькими документами? А большими структурами с низкой долей полиморфизма? Не в мире все делится на черное и белое.

Я и не собираюсь доказывать, что XML не нужен. Меня бесит другая крайность - когда его считают панацеей.

segfault ★★★★★
()
Ответ на: комментарий от segfault

Меня бесит другая крайность - когда его считают панацеей.

А что, экономия пары байт делает JSON чем-то принципиально лучшим решением? Меня не интересует экономия 10 байт (она особенно смешная если использовать формат в духе ODT - запакованный в архив XML), и читать я могу и то и другое (хотя XML в среднем удобнее, потому что тип объекта вижу сразу).

Меня бесит другая крайность - когда его считают панацеей.

Чувак ты вообще за тредом следишь? Задача в данном треде вполне конкретная, и ее решение и обсуждается.

theos ★★★
()
Ответ на: комментарий от makeB

это решаемая проблема. Там вполне можно запилить так, что оно летать будет. Например если поперикрывать все нивидимые места оклудом, для объектов создать отдельно упрощённую колизию и проч.

OpenMind ★★★★
()
Ответ на: комментарий от I-Love-Microsoft

makeB, можно я буду тебе вопросы задавать на тему этого движка?

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

makeB
() автор топика
Ответ на: комментарий от OpenMind

Например если поперикрывать все нивидимые места оклудом

Речь шла о платформере, оклуды там попросту негде применить.

для объектов создать отдельно упрощённую колизию и проч.

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

makeB
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.