Распаковка базы Database(lmp).res

[ELF]

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


KnightL, сиба большое за отзыв.

я даже попытался почитать исходный код...) Правда что-то там всего много.[right][snapback]41199[/snapback][/right]

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

Сейчас я пришёл к выводу, что вообще *db-файлы лучше считывать по принципу загрузки XML (родитель->дочерние элементы->братья родителя...). Это бы, думаю, упростило бы структуру считывателя с точки зрения восприятия кода. Соответственно настройку разбора формата (текстовые файлы) нужно было бы делать иначе (или теперь вообще уже не делать, так как все структуры уже довольно ясно выреверсированы). Но пока что всё осталось вот так, в виде спагетти внутри методов.

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

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

Неужели в Qt нету встроенных таблиц?[right][snapback]41199[/snapback][/right]

А вот хороший вопрос... =)
Как понял, разработчики библиотеки желают сразу же приобщить пользователя библиотеки к парадигме: модель->представление. Т.е. создаётся модель в виде таблицы, которая подключается к представлению в виде таблицы.
В самом общем (сферическом) случае модель в Qt позволяет создать, так скажем, табличную иерархию таблиц (где ячейка таблицы может адресовать вложенную таблицу). Соответственно, частными случаями этой мега-модели являются список, таблица и просто дерево.
В принципе "создать таблицу в Qt" -- это создать табличную модель. Хотя интерфейс управления такой таблицей мне не пришёлся по вкусу, так как он слишком универсален и неудобен для плотной работы с таблицей. Поэтому я сделал враппер (класс-обёртку) с более дружественным интерфейсом для работы с таблицами.

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

Кстати я удивлён, увидев, что pragma влияет на g++. Если верить тому, что я читал раньше, он должен был бы их игнорить.[right][snapback]41199[/snapback][/right]

Не знаю. Mingw под винду сделал это. А вообще, интересно, если pragma полностью игнорится, то как тогда в структуре адекватно считать 2-байтовые поля?

В коде кстати есть довольно странное условие, не знаю, так и надо или нет... if( offset < 0 || size < 0 )... бессмысленный код вроде if(false). Ведь offset и size по типу quint32, беззнаковые. (строки 79-81 файла qresreader.cpp ).[right][snapback]41199[/snapback][/right]

Есть такой момент. %) Забито автоматом на автопилоте, скорее всего. %) Всё-таки нужно в Индию съездить... вдруг там родственники есть.

И перевод из чисел в адрес клетки и из клетки в адрес можно было бы написать проще, за один проход и без дополнительных переменных.[right][snapback]41199[/snapback][/right]

Ты имеешь ввиду способ чтения/записи ячеек рабочих таблиц программы? Там пришлось в некоторых местах прибегнуть к дополнительным конвертациям. Вообще для чтения/записи ячеек используются variant-переменные, но почему-то (точню не припомню с ходу почему) при попытке записи чисел с точкой в ячейку с целым числом, когда я извлекал integer, почему-то из variant возвращался ноль вместо округлённого числа. Поэтому пришлось делать дополнительную конвертацию. Здесь я и сделал баг с округлением... =)

Кстати, а где вообще нужны signed long? я посмотрел таблицы, там не было чисел больше 2^31-1.[right][snapback]41199[/snapback][/right]

SignedLong'и попадаются по-идее там, где имеются поля типа FFFFFFFF или FFFFFFFE, ну и т.п... Порой такие поля попадаются.


Вообще очень приятно было услышать твоё мнение. Спасибо за замечания.