Попутно возник еще один вопрос. Сейчас мы достраиваем заголовки, а что нужно будет сделать, чтобы подготовить исходный файл к запаковке в rezfile? Порезать ему заголовки? Или это делает утилита makerez?

В общем допилил обработку пакетных файлов с картинками. Из 140 файла (по стрим ридеру) дёргаются надписи режимов сложности.

Есть баг Out of Memory, пока не стал вникать. Некогда.
....
Баг поправил, архив перезалил. Теперь на одну картинку больше извлекается из 140 файла :) Удачи!

Спасибо, мужики! Радуете!

Наверно makerez это умеет,либо burgerlib, либо придётся самим резать, фиг знает.

Получается, что данные не запакованы никаким LZSS? А как на счет BIG/LITTLE ENDIAN? Тут есть соответствие со словами Ребекки?

Versus, данные тут в 3DO'шых endian'ах, если не ошибаюсь это BIG ENDIAN. Про сжатие не уверен, может какие файлы и запакованы.

Исправил небольшой баг, из-за которого не открывался D0131 (первое смещение может быть больше 0x50,увеличил его до 0x1ff - может быть и его не хватит, надо тестить)
https://yadi.sk/d/zt1cxRnteKC8E

Author, а чего ты DoomFile.Size закомментировал? Превышение размеров самого файла гарантировало бы что это не массив картинок, а что-то другое. А тут неизвестно хватит ли 0x1ff или найдётся файл ещё больше...

aliast
Супер! Буковки распаковались!

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

Если я правильно понял механизм работы скрипта для rezfile, то команда COMPRESS глобальная, то есть, затрагивает все файлы сразу.

Можно попробовать объединить (GetSwap32(Strange)<$1ff) and(GetSwap32(Strange)<DoomFile.Size), я прикинул, что одного первого условия достаточно будет, т.к. 1ff (или 50 как было) явно меньше всего файла. Надо проверять как лучше работает. Структура всех заголовков неизвестна, поэтому это всё не строго. Хочешь поменяй :)

Новая версия - всё таки решил сделать проверку на превышение размера файла и ещё исправил незначительную фигню. Ты там в секции PLUT пишешь константу 0x10, а должно быть половина размера данных секции. На что влияет неизвестно, но так оно правильнее будет)
https://yadi.sk/d/WQECkcDLeKFoi

aliast
При попытке обработать все файлы что-то делает, вешается наглухо, создает D0325_0.cel весом в 1,5 Gb, D0175_0.CEL весом в 68 Mb, ну и так, по мелочи.

Хмм, вероятно я неправильно понял фразу

Как-то в голове осело, что надо дописать х10 и всё )


что-то зациклилось видимо.

138 распаковался (рожи), 139 дополнительный череп вытащился, в 142 добавился бегунок.

Не знаю есть ли смысл навешивать на программу проверки, блокирующие обработку заведомо неграфических файлов. Проще не кидать ей эти файлы :) В частности, D0325 и D0175 это лумпы THINGS карт MAP04 и MAP19 и картинок в них быть не должно. Тогда уж проще писать полноценный распаковщик, который будет определять тип файлов по порядковому номеру и правильно его обрабатывать.

Вот именно, что проще не кидать или кинуть, не съела, следующий :)

Вообще странно, а где же монстры, оружие?? Ничего такого не извлеклось ещё.

Это спрайты. Может, они по-другому движком обрабатываются?

Добавлено спустя 1 минуту 52 секунды:
Да ладно, монстры! Стены где?

Оружие и монстры в файлах 385 - 473. Стены где-то в начале 2 - 118. Формат у них вроде бы не CEL, а чисто думовский, зашитый в Doom.WAD.
Глянул 385-473 (не все конечно, выбороно) - CEL в них есть по 3-6 штук в каждом, но формат не вписывается в наш распаковщик. Надо разбираться.

aliast, интересно, значит ли это, что утилиты для ПК Doom'a смогут их открыть?...хотя, big endian, это же их свапить целиком придётся, даже если формат совпадает.

Хм... Тогда я не совсем понял. Стены в начале. А где сам Doom.wad? Уровни-то лежат отдельно. Получается, что его раздербанили на текстуры и просто кинули в начало REZFILE?

Doom.wad разделён на лумпы точно также как и файлы карт. Только если в картах по 10 лумпов, то в doom.wad их жопой жуй.. штук может 50, точно не скажу. А может и все 115. По этой причине ПК утилиты не подойдут пока не склеишь лумпы. А там есть отличия: на ПК данные по 2 байта, на 3do по 4 байта, первые байты везде с ноликами. Плюс на 3DO вместо текстовых названий текстур стоят индексы. Ну и плюс endian разный.

Хмм, из 387 взял дробовик. Там смещения ведут не сразу к сигнатуре,а к ещё какой-то хрени 4х байтовой. Так что там Cel'ы. Ох и огород нагородили. Честное слово, так нельзя писать игры (работу с ресурсами).

Это в doomrez.h номера строк? Эти?

Добавлено спустя 10 минут 36 секунд:
Author
Может, проще будет изменить что-то в исходниках, чтобы читались pc wad файлы? Не в чистом виде, с преобразованием, но тем, который мы предусмотрим, а не такую свистопляску... Грубо: поменять текстуры на cel-ки, сделать swap байт.

С индексами пока не разбирался. Скорее всего нет, что-то другое.

Ага) тоже уже разобрался. Что за 4 байтовая хрень спереди пока не пойму :(
В D0396 (Имп) формат опять другой, но похожий. В начале идут смещения, которые явно напрашиваются на AND с неким числом, а дальше уже идут нормальные смещения к началу CEL минус 4 байта.

Изменить исходники 3DO Doom'a? Это весьма непросто на мой взгляд. Или же править ПК ресурсы в 3DO формат? Это вероятно попроще.

Author
Я могу только предполагать. Без правок кода все равно не обойтись. Мне кажется, будет проще взять обычный pc wad, написать утилиту, которая бы заменяла текстуры в нем на cel-ки, и, соответственно поправить исходники в части чтения ресурсов из WAD. Также поступить со вспомогательной графикой, но ее запихать в другой файл или просто положить на диск в неизменном виде. Так будет проще делать моды.

У каждого спрайта в D0396-D408 есть несколько состояний (враг бежит, стоит, атакует). Все они описаны в файле Info.c
{Spr(rSPR_IMP,20),-1,0,0}, // S_TROO_XDIE8
где 20 - номер спрайта. Максимальный номер для импа (D0396) = 25 что соответствует 26 спрайтам.
Открываем D0396 и видим в начале 8 смещений с префиксом 40 00, 18 смещений без префикса (ведущие напрямую к 18 ПОСЛЕДНИМ картинкам). Итого 8+18 = 26.
Совпадает? Да только дальше в файле идут 5 добавочных смещений, которые нужно добавлять к первым 8 смещениям с префиксом 40 00, потом идут ещё несколько чередующихся смещений с префикcом 80 и без префикса, итого 58 картинок :(
Тут надо распаковать один файл и глянуть что там за 32 "лишних" спрайта. Скорее всего это спрайты с разных ракурсов для вращения. Префикс 40 00 насколько я вкурил показывает что спрайт может вращаться, а 80 00 что спрайт может быть flip (?) т.е. /* Reverse horizontal */
Я не понял что это значит. If your character needs to walk on the ceiling, let's use the FLIP command for that
Нужно распаковать один и думать дальше.

Это серьёзный вынос мозга. До этого цветочки были :) А главное, как потом это собрать назад в аналогичный файл? Вот так задачка. Спасибо за разбор полётов!

Вот я об этом и говорю. Может, не привязываться к этому формату?

Versus, лопатить исходники Doom'a на предмет разбора этого файла и их замена отнимут не меньше времени. MakeRez-то нормально собрать не получается :(

В теории, можно сделать так. Не менять размеры картинок,(спрайтов) внося изменения (другие монстры, текстуры и т.п.). Тогда их можно просто вернуть назад в "архив", с теми же параметрами, что не потребует изменений смещений.

Author
В инклюдах makerez присутствует burger.h. Но в чистом виде наш 3DO-шный burger.h, естественно, не пашет. Особенно ругается на строки /*3DO Specific*/.
Если из инклюдов его убираешь, ругаться начинает вообще капитально. Разобрать, что именно он хочет у меня не получилось. Библиотеки burger под Apple II у нас нет.
Может, нужно взять лишь некоторые функции из 3DO-шного burger-а и запихать непосредственно в makerez.c?