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

все это хранить в тхт или хмл (пока не решил) и т.п.
xml

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

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

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

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

Не нужно json. Серьезно.

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

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

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

Для 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 вне конкуренции.

Почему?

успехов в годном начинание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

а вот кстати, на что видео записывал?

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

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

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

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

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

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

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

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

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

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

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

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

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

О, у моего вброса появилось продолжение :)

Почему?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примерно такая же ситуация (про эклипс). Не на блендере случаем платформер делаешь?

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

VTZ - Throwin Bos

а вот кстати, на что видео записывал?

Видео как обычно, записывалось RecordMyDesktop-ом, редактировалось в блендере.

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

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

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

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

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

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

Не на блендере случаем платформер делаешь?

Нет, я не настолько извращенец :)

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

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

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

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

А чем плохо на бледнере?

А чем плохо на бледнере?
2d

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Люто плюсую!
А почему именно MyGUI?(Я бы выбрал CEGUI)

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

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

А исходники есть? Будут?

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

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

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

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