Costume Quest, архивы компьютерной версии Опции

[Siberian GRemlin]

Заголовок для архива (.~h). Тупоконечная запись значений.
По следующим смещениям хранятся.
$0C - смещение на таблицу. (dword)
$14 - смещение на имена файлов. (dword)

Таблица содержит.
dword - длина названия (архива?).
string - название, включая ноль.
переменное выравнивание нулями, чтобы следующее значение начиналось со смещения кратного четырём.
dword - кол-во файлов в архиве.
dword - неизвестно.
dword - неизвестно.
Затем идёт массив с записями по 16 байт на каждый файл. Собственно загвоздка здесь, где предположительно хранятся размеры файла в сжатом и несжатом виде и смещение. Значения какие-то оторванные от действительности.

Дальше идут имена файлов.

Сами файлы хранятся в архиве (.~p). Данные либо в чистом виде, либо сжаты Zlib. Идут с выравниванием кратным $800.

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

Скачать образец файлов. (<1)

Скачать игру. (~500)

[-=CHE@TER=-]

Смотрел только маленький архив.

Смещение $20 - судя по всему количество файлов в архиве ($DF).

Заголовок таблицы:
DWORD - SLEN длинна имени структуры
CHAR[SLEN] - строчка с именем (BLOB) - выравнивается до ближайшей кратной 4 границы
DWORD - неизвестно (?)
DWORD - точно не количество файлов, потому что файлов $DF, а тут $BD
DWORD - неизвестно (не используется, походу filler $CC)

Далее идёт таблица. На глаз структура таблицы примерно следующая:
DWORD - USIZE - (USIZE >> 9) = размер распакованного файла
DWORD - PSIZE - (PSIZE >> 1) = размер упакованного файла
DWORD - FOFFS - (FOFFS >> 3) - смещение файла в архиве
DWORD - NOFFS - (NOFFS >> 11) = смещение до начала имени файла, относительно начала секции строк: 0, 30, 58, ...

>> - битовый сдвиг вправо (shr)
Т.е. читаем, к примеру, поле USIZE, затем, чтобы получить размер распакованного файла, сдвигаем это поле вправо на 9 бит.

Если USIZE = PSIZE (!!!без сдвигов - как было в файле!!!) - файл не упакован и любое из этих полей сдвинутое вправо на 9 даст размер файла.

Поля имеют какие-то байты FOFFS (всегда 1), NOFFS (2 или 4), которые при сдвиге отбрасываются, но за что они отвечают - я не знаю. Точно не за сжатие.