Войти
ПрограммированиеФорумОбщее

XML как формат хранения Game Contents - какая технология лучше

Страницы: 1 2 3 4 Следующая »
#0
17:00, 19 июля 2009

У меня следующий вопрос:
Для загрузки XML я пользуюсь MS XMLLite, но он имеет следующие недостатки:
- все значения узлов, параметров и текста читаются как строки const wchar_t*, а их перевод в float(float*), DWORD(DWORD*) и т.д. приходтся прописывать самостоятельно, в следствие чего количество потенциальных исключений для сложных схем растет в геометрической прогресии.
- нет встроенного парсера на предмет соответствия .XSD.
Я рассматривал использование технологий DOM и SAX, но на мой взгляд они слишком навороченные и неудобные.
Подскажите, какие из существующих XML-загрузчиков лишены недостатков XMLLite, но имеют более простой интерфейс, чем DOM и SAX. Желательно с поддержкой .XSD, обработкой искючений try/catch и без использования MS COM.


#1
0:59, 20 июля 2009

TinyXML + TICPP, рекомендую :)
Не знаю про поддержку XSD, пойди глянь на сайте TinyXML чтоли.
Храню параметры объекта в аттрибутах тэга, а содержимое во вложенных тэгах, очень удобно.
Функции для чтения и записи простых типов и списков простых значений пришлось написать свои.

#2
3:14, 20 июля 2009

>> Функции для чтения и записи простых типов и списков простых значений пришлось написать свои.

это в строку любой тип

    template<typename T >
    inline std::string toString (T p)
    {
      std::ostringstream stream;
      stream << p;
      return stream.str();
    }


это из строки любой тип

    template<typename T >
    inline T parseValue( const std::string& _value )
    {
      std::istringstream stream(_value);
      T result;
      stream >> result;
      if (stream.fail()) return T();
      return result;
    }


и бери парсер xml который удобнее =)

#3
8:26, 20 июля 2009

my.name
не...так не надо....по бустовски медленно :)

#4
9:47, 20 июля 2009

Эм, а зачем тебе проверка XSD? Если ты конечно, не собираешься редактировать XML ручками.

#5
12:04, 20 июля 2009

> Эм, а зачем тебе проверка XSD? Если ты конечно, не собираешься редактировать XML ручками.
Для автоматизации проверки соответствий parameter=value1|value2|value3|invalidvalue

#6
13:16, 20 июля 2009

MATov
Где там буст? о_О

#7
13:30, 20 июля 2009

destrator
Я имел в виду для чего в данной задаче ты их используешь? Есть готовые xml файлы в поставке с игрой, их считаем априори синтаксически и логически правильными. Редактор карт производит нормальные файлы. А если юзер распаковал, ручками поменял и накосясил в xml-файлах - это его половые трудности, имхо.

#8
19:17, 20 июля 2009

Iskander
+1... да и ресурсы как бы паковать положено...

#9
20:54, 20 июля 2009

San
> Где там буст? о_О

В бусте так же сделано, вот и сказал что по бустовски

#10
21:08, 20 июля 2009

XML, без Xpath  = куча геморроя...  если не выходит использовать полноценный парсер, то тогда лучше PugiXML, - там есть что-то похожее на XPath и  нечто вроде итераторов STL.

#11
21:14, 20 июля 2009

Да, pugiXML крутая вещь, сам его использую на работе

#12
23:28, 20 июля 2009
Iskander

>Есть готовые xml файлы в поставке с игрой, их считаем априори синтаксически и логически правильными.

А на хрена в таком случае вообще xml? Почему просто не хранить внутренние конфиги/скрипты в "откомпилированном" виде?
Я все время думал, что читабельные скрипты и конфиги в конечном продукте оставляют лишь для того чтобы юзеры могли поправить что-нибудь. А если на юзера мы кладем, то зачем тратить время/ресурсы на парсинг всего этого добра в ран-тайме?

>А если юзер распаковал, ручками поменял и накосясил в xml-файлах - это его половые трудности, имхо.

Если все равно хочется давать особо пытливому юзеру возможность ковырять конфиги, так можно мануальчик/компилер/декомпилер в архив с конфигами/скриптами класть.

Не то чтобы я был против xml вообще, но в данном случае оно зачем?

#13
23:28, 20 июля 2009

2Iskander
тоже придерживались такой точки зрения, видно зря, на вскидку три проблемы обнаружилось

1. разные системы и локальные языки выявили кучу проблем, как с русскими файлами (запретили) на и с кодировками внутри файлов (приняли утф8)
2. разные национальные варианты форматов дат флоатов и т.д. (при парсинге например флоатов, ставим флаг что не брать из этих настроек)
3. от пользователей с половыми проблемами получаем логи падений, где не сразу и понятно, что послужило причиной падения например при загрузке меша

так что пользователь сам расковырял сам виноват, это не всегда правильный вариант.

2MATov

>> по бустовски медленно:
минусы:
медленее при загрузке

плюсы:
  однотипный парсинг
  расширение своими типами
  понятный код и как следствие малая стоимость сопровождения

#14
1:19, 21 июля 2009

Вот вот "понятный код и как следствие малая стоимость сопровождения".
В крупных бизнес проектах это самое ценное.
Да и в казуальных играх, где производительность дело десятое, а скорость выпуска игры очень важна - тоже очень помогает. Так что понятный XML и понятный код чтения > скорость.

Страницы: 1 2 3 4 Следующая »
ПрограммированиеФорумОбщее

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