Versus, у меня также

Да, как раз на 154 файле она вылетает. Кол-ко оказывается она правильно определяет 473. Где-то ещё свопа данных не хватает наверно. Может в самом алгоритме распаковки, том что на асме написан.

Так, Killing Time этой штукой тоже не распаковывает.
Author, это ты там что-то в настройках для этого химичишь?
Как ещё распаковать Killing Time и Каспера?

Конечно уже не будет распаковываться, данные же конвертятся в правильный Endian. Без этого как минимум кол-во файлов 473 не получится. Так что для ПКшной версии Killing Time она не будет пригодна. На счёт Каспера не знаю.

Тут мысля одна есть. Попробую.

Я не про ПКшную, а про 3DOшную.

ПАУК, у 3DO'шной Killing Time нет Rez файла, есть ZStream у которого совсем другой формат. Так что я не понял твоего замысла.

p.s. добавил своп данных перед отправкой в распаковщик, тоже не помогло (до этого этот блок я не трогал). Прога вылетает т.к. размер данных получается отрицательным, причём размер данных после распаковки. Сам распаковщик получает буфер с запакованными данными, буфер для распакованых данных, размер запакованных данных и размер распакованных данных. С последним как раз косяк и случается на 154 итерации. Таблица размеров распакованных данных начинается по адресу 5700(dec) или 1644(hex) как уже верно было замечено. Только, если это так, то файлов должно быть всего 216. В чём ошибка?

Добавлено спустя 1 час 16 минут 51 секунду:


Ты прав, только 80 и 20 одинаково указывают на сжатие данных, если посмотреть в двоичном виде, то у обоих чисел старший бит 1. Прога именно по этим цифрам ориентируется как данные обработать.

Выкладываю версию с отладочной инфой. Видно, где падает прога. К сожалению не знаю почему по адресу 1410665 прописан размер "FCF80000", но это действительно какая-то ошибка. Может оффсеты всё ошибочно взяты из таблицы?

---------------------
В общем сделал обход ошибки, если размер кривой, то переходим к следующему оффсету. Две версии, в одной есть своп данных перед распаковкой, в другой нет. Разницы не вижу, в обоих случаях "мешанина" в файлах. Может всё таки алгоритм упаковщика другой нужен? Исходники прилагаются. Кто найдёт время может поиграться с ними или попытаться править оригинальные, до моего вмешательства.

Добавлено спустя 1 час 46 минут 24 секунды:
Из Каспера 5я сборка тянет 25 звуковых файлов, при том, что ресурсах их гораздо больше 50. Всё же есть кривизна чтения данных.

Добавлено спустя 16 минут 32 секунды:
6я сборка без свопа размера распакованных данных похоже тащит все ресурсы из Каспера. Назвал отдельным именем.

711 файлов размером 26,7 МБ. REZFILE весит 17,9 МБ. Получается, что он в резфайле сжат

ПАУК, да, в REZ файлах встречаются запакованные данные и просто хранимые без сжатия.

Author
т.е. получается что у неупакованных данных (без префикса 80) размер файла ты берешь из смещения [оффсет_начала_файла+4], а если данные упакованы, то размер файла берется уже не оттуда, а из первых 4 байт данных? При этом такая логика иногда даёт сбой и размер не определяется... Ну ок, в KT всё так и было вроде как. Тогда остаётся вопрос за что отвечает [оффсет_начала_файла+4] в случае упакованных данных? Не просто же так он там прописан... И сам формат упакованных данных очень необычен - байты в них похожи на какие-то размеры или оффсеты или может опкоды, но на упакованные данные это не похоже совершенно..
1) Можешь добавить какой-нибудь префикс к имени распакованных файлов, чтобы отличать упакованные от неупакованных?
2) Почему в первом файле одни нули?

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



[оффсет_начала_файла+4] - не разбирается прогой, я так понял, что это уже данные попадающие в распаковку.

1) Почему нули не знаю, может неправильно распаковывает.
2) Префиксы можно добавить

8я сборка, заметил что файлов создаётся 456 штук...явно перебор.

Файлы с 119 по 142 (между ними есть парочка файлов с флагом 80) очень похожи на картинки CEL с порезанными заголовками CCB, PDAT, PLUT (как в KT), но восстановить их пока не получалось :( т.е. возможно я не прав, но уж очень похоже... Некоторые из них начинаются с таблицы офсетов к флагам CCB - видимо это файлы анимации, другие сразу начинаются с флагов и флаг там просматривается только один - это уже статическая картинка CEL. Но я пока не разобрался где брать размеры секций и возможно данные таки упакованы?

Добавлено спустя 58 минут 8 секунд:
В общем, нате вам первую выдранную картинку:

На скрине видно, какие данные я добавил в распакованный файл (оранжевый цвет, только секция PLUT осталась внизу за кадром). Другими словами я вставил заголовки секций CCB, PDAT и PLUT, их размеры и ВНИМАНИЕ - в распакованных файлах нет размеров картинки (ширинаХвысота). Их я поставил от балды чтобы картинка отображалась полностью. Где брать эти размеры - пока неясно.

Уря! Первая картинка!

Holks выложил распаковщик, но он кривой :( Даже те картинки, что Holks выкладывал для пример, не распковались... так что это немногим лучше того что у нас есть.

aliast ты молодец, так научился структуры файлов анализировать. Кстати мне нравится твой Hex редактор, он похоже навороченней чем Hex Workshop (правда у меня 4я версия).

А вот эта ссыль как-нибудь помочь сможет?
https://github.com/Olde-Skuul/burgerlib
Там выложено многое.

aliast, ты картинку из какого файла сумел достать??

Versus, исходники всегда пригодятся. Нашёл, что вызов декомпрессии сделан через

Burger::Decompress::Decompress(void) :
m_uTotalInput(0),
m_uTotalOutput(0),
m_uInputLength(0),
m_uOutputLength(0){}

А что там делается, всё равно тёмная история. Я не нашёл его в открытом виде.

Author
128 который 123524 байта (с заголовками будет на 40 байт больше, 123564)

Versus
Есть у меня смутное подозрение, что формат нашего файла немножко другой. Либа скорее всего правильная, на 3DO что-то поменяли.. хотя в PC-версии киллинг тайма тоже чёто не то... может я просто не догоняю :)

А кто-нибудь умеет пользоваться этим гитхабом? Как узнать доступны ли там либы 1996 года?! За 20 лет формат мог 100 раз поменяться, а нам нужны именно старые версии.

aliast, что за "гитхаб"?

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

Author
Там только графика и геометрия уровней.

гитхат

Похоже нет там старых ревизий. Только 2014 год.
Звуки в Думе вроде лежат отдельно в папке Sound как и музыка. Здесь же только текстуры, спрайты и карты. Может ещё что-то.

Да больше нечему.

Добавлено спустя 2 минуты 11 секунд:

Отвечала, а потом пропала из эфира. Результата пока нет. Позже буду снова ей писать.

Author
ы! В распакованных файлах байты перевернутые :) По идее переворачиваются только смещения к файлам, а сами данные трогать не надо.

Ок, сейчас перезалью. В общем CEL'ами отмечены все файлы, которые похожи своими заголовками. Ориентир брал с файла 128.

"47E642100000000000000070" по наличию этой последовательности можно судить о графике в файле. Число 70 может меняться.
"G.B........p" - тоже самое в виде текста. Буквы g и b могут быть маленькими. Эта комбинация плавает в заголовках файлов, перед этим идут какие-то данные. Первые 4 байта в таких случаях как раз указывают на начало "G.B.."

Всё больше и больше прихожу к выводу, что формат карт в Думе схож с форматом карт в Killing Time, т.е. отдельно идут файлы вершин с координатами VRT), отдельным файлом соединение вершин в прямоугольники стен (файлы fac) и отдельно файлы карт (map), назначения которых я не разгадал. В качестве примера сравните 163-й файл (утилитой Author этот файл не распаковывается! с файлами MAP из киллинг тайма - по мне так очень похоже. Первые 8 байт - ширина и высота карты в координатах, далее идут ширина и высота карты, измереная в прямоугольниках. Далее идут какие-то индексы. В конце списка индексов идут непонятные байты, разделенные FFFFFFFF. Что-то похожее на VRT и FAC файлы из KT я тоже находил, сейчас номера файлов не припомню... Ну и наконец самое главное - все эти файлы являются неким стандартом для 3DO, он упоминается в патентах. Так что неудивительно, если вообще все игры на 3DO хранят карты в этом формате :) Представляете - если разобраться в формате, получим универсальный Map Editor для всех игр на 3DO
Мечты-мечты... надо ради интереса поковыряться в форматах карт других игр - KT и Doom могли быть просто сделаны на похожем движке, что собственно так и есть.

Добавлено спустя 17 минут 15 секунд:

Маска ненадёжная :( ktrez132 - тоже картинка. Буква G там есть, а B нету. Сделай пока маску, что вместо букв B и b на этом месте может быть символ собаки @ думаю этого хватит пока.

Формат, похожий на MAP имеет каждый 10-ый файл, начиная с 153 по 383 (нумерация взята из распаковщика Holks'а), т.е. файлы 153, 163, 173 и т.д. т.е. 24 файла. Сколько в Думе уровней? Вроде бы где-то проскакивала инфа что именно 24 :)

aliast, да, программа действительно не всё извлекает. Причина->данные о размерах файлов, читаемые из REZ файла. Я не знаю, что делать, если выцепляется отрицательное число(кроме как свапнуть, но даже в этом случае может получиться гигантская величина и приплыли). Думаю, что в 4х байтах периодически, кроме размера указывается что-то ещё и вот это самое и нарушает логику алгоритма. Сейчас тащится 466 файлов. Из них есть какие-то с нулями внутри. 163 теперь тоже есть, но он похоже кривой. В общем, пока бросаю это дело. В целом и так понятно, где графика с учётом написанного ранее.

Всё подтверждается. Поигрался с первыми 4 байтами в файле 153 - получил прохождение сквозь стены, но только на 1 уровне. Поигрался с файлом 163 - получил прохождение сквозь стены на 2 уровне. То же самое у меня было и в KT. Можно играться дальше и вникать какие байты на что повлияют в игре.
Что любопытно - прохождение сквозь стены не прокатывает на бочках - сквозь стены хожу, а в бочки упираюсь. Значит расположение бочек находится отдельно от файла карт. В киллинг тайме за это (ящики с патронами, сферы, ключи, сосуды) отвечали файлы VNT.

Тебе лучше это куда-нибудь записывать...

А можно подробнее? Прохождение сквозь стенЫ или стенУ? 4 байта вряд ли будут влиять на проницаемость абсолютно всех стен на уровне.

Будут. Почему нет? Я удивлён, что их четыре, а не один. Там что, 4 разных стены?

Ну как... Уровень ведь не из одной комнаты состоит... И на каждой разная (предположим) текстура. По идее и условия столкновения с ними по-разному должны прописываться.