aliast
Если я правильно понял, то получается, что при запаковке в Rezfile какие-то лумпы подвергались изменению (переворачивались байты), а какие-то нет. Ну, про смысл данных манипуляций я молчу, но как это решается скриптом Rezfile? Там ведь не предусмотрен механизм индивидуального подхода к пакуемым файлам.

Так ведь скрипт rezfile этими вещами не занимается по идее. Это всё делает конвертер карт, оставшийся где-то за кадром, либо даже какой-то 3DOшный редактор карт и графики, которые нам никто не дал. makerez же просто берёт набор файлов (уже порезанные лумпы и готовую графику) и пихает их в контейнер BRGR. Игра соответственно тоже работает с файлами из rezfile, а не с вадами.

Да, проник туда и посмотрел.

Во что нашёл - http://doomwiki.org/wiki/Doom_utilities сорцы какких-то утилит для Дума. Там кстати используется пакер lzss, но пока не разбирался что там за проги и за что отвечают. Завтра попробую собрать exe файлы. Вроде бы wadlink режет вады на лумпы, а lumpy их наоборот собирает лумпы в wad. Да только ведь это всё не для 3DO :(

aliast, тебе памятник поставить нужно, хотя бы виртуальный, за такие находки.

А в 135 файле не должно быть еще надписей Secrets, Finished, Entering? Просто распаковались только Kills и Items.

Secrets у меня распаковался и всё, больше там ничего нет (только Kills, Items и Secrets). Finished, Entering наверное по буковкам формируются.
Кусок кода из InMain.c

и чуть ниже отдельно

Вывод на экран происходит в функции IN_Drawer()

т.е. эти надписи выводятся разными способами.

Да, secrets присутствует, его я проглядел. Спасибо за инфу, теперь все понятно.

aliast
Как дела с конвертером карт? Получилось?

Да застрял я на последнем лумпе. Не знаю как там найти одинаковые последовательности и удалить дубли.

aliast
Запости сюда проблему, может помогу чем.

Нуу.. в оригинальном ваде идут такие байты-оффсеты:

т.е. цифры с шагом 2 (342, 344, 346), а на 3DO

имеем одно повторяющееся смещение.
Вся эта канитель ведёт сюда. PC wad:

а на 3DO:
оффсет 0x0D00
т.е. на PC имеем 28 разных смещений на 28 ОДИНАКОВЫХ последовательностей байт, а на 3DO они объединены единым повторяющимся смещением 00 00 0D 00 и единственной цепочкой байт, т.е. нехило так ужали данные. Но как это реализовать я не соображу.

Прочитать в PC WAD последовательность 00 00 FF FF, и посчитать сколько их. Там, где эти последовательности заканчиваются, пойдет другой алгоритм. То есть, мы просто игнорируем эти повторы. Я правильно понял?

Да не игнорируем, просто 28 раз переходим на оффсет 0D00 и в итоге получаем длинную цепочку. Но в файле она хранится один раз. Как-то так. Ну хорошо, посчитаю я количество 00FF, а как быть с остальными повторами? Они могут быть какими угодно. Нужно как-то найти все такие повторы и заменить одним. В общем, нужно делать фунцию поиска в массиве, а я в этом не силён(

aliast
Как я понял, нужно сделать чтение лумпа и его анализ на наличие повторений подобного формата. То есть, читаем по 4 байта запоминаем каждую последовательность в массив, сравниваем последующие 4 байта с каждым элементом массива. Если повтор, то берем на заметку. Если не повтор, просто читаем дальше. Как-то так. Посмотрю подобные функции, может напишу чего. А там уж вкорячишь код в свою прогу.

Похоже, я изначально неправильно понял задачу. У нас есть группа байт, которые указывают на другие байты далее в файле. То есть, группа байт



указывает на



Если читать в строку, то это будет примерно так:


В 3DO же, картина следующая:
группа байт



указывает на

находящимся в одном месте. То есть, если в строку читать, то получится:


Я правильно понял?

Ну да, всё так. Ну и не знаю важно это или нет. 0342 на PC указывает на оффсет 0684 в этом же файле, т.е. 0342 * 2. А вот 00D0 на 3DO уже будет указывать на офсет 00D0 в этом файле без всяких умножений на 2.

Отлично, в голове уложилось. Теперь буду пробовать. Правда, с налету на "сях" не получилось что-то годное сваять. Не страшно, если ответ на "дельфях" будет?

Да поди нет. Я хоть Делфи и не знаю, но поди уж разберусь с алгоритмом.

Здорово, что работа продвигается! Мне не понятно одно, зачемы было так старательно ужимать и обрезать данные везде, где это возможно. Неужели потом восстановление данных не добавило тормозов в работе игры? Что они пытались выиграть? Уменьшить нагрузку на сидюк? У них компакт диск с игрой можно сказать пустой.

Author
Хрен его знает... Единственное, что приходит на ум, так это уменьшение загружаемых с диска данных в процессе игры. Там музыка постоянно долбит диск, а когда приходится подгружать уровень, он иногда заходится в приступах. Но все равно, считаю, что такое ужатие данных ни к чему.

Добавлено спустя 1 минуту 54 секунды:
Кстати, спросил у Ребекки на счет добавки наших экспортированных данных из REZFILE, заинтересовалась. Отправил архив ей. Вроде, должна обновить соответствующий раздел на github-е.

Ещё раз что нужно сделать. Есть последовательность байт между 00 00 и FF FF. Между ними может находиться любое число байт, кратное двум, от нуля (0000FFFF) до... есть вроде ограничение на максимум, надо поискать на doom.wikia.com. К примеру, здесь
00 00 1E 01 1F 01 20 01 21 01 22 01 23 01 24 01 25 01 26 01 27 01 2C 01 FF FF
мы наблюдаем цепочку длиною 11 слов (1 слово = 2 байта; 0000 и FFFF я не считаю, т.к. это байты начала и конца цепочки). Наша задача найти одинаковые цепочки и удалить их все, кроме самой первой. Ну и потом заменить все ссылки на неё в начале файла одним оффсетом к первой найденной цепочке.
Задача усложняется переменной длиной цепочки. Ещё раз. Все цепочки всегда начинаются с 0000 и кончаются FFFF.
Ну а дальше косметика. Превратить 0000 в 00000000; FFFF в FFFFFFFF; 2901 в 00000129 и т.д. Из-за этих преобразований цепочки удлиняются и то что было по смещению 0640 оказывается по смещению 0D00.

Правильно ли это? Не окажется, что мы грохнем цепочки, которые к этому не относятся? Дурацкий вопрос, но не знаю, как лучше сформулировать.

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

Это вот эта?


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

Вот это не совсем понял. Можешь выложить 2 куска (PC и 3DO) и показать, что на что указывает?

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

PC 3DO
Синяя цепочка на скрине 3DO занимает три строчки. Также можете сравнить одну и ту же цепочку на PC, оффсет 0x6F0 и выделенная синим цветом на 3DO (от 0x0D08 до 0x0D28)

aliast
Спасибо, посижу на досуге, подумаю.

Блин, я забыл или никогда не знал что означает префикс 80 в таблице оффсетов к файлам в Rezfile. Это файлы D0001, D0134, D0152, D0153, D0154, D0162, D0163, D0164, D0172, D0173, D0174, ... т.е 3 последних лумпа всех 24 карт, BIGNUMB (текстуры чисел?) и самый первый файл. Остальные файлы без префикса.

Добавлено спустя 5 часов 8 минут 54 секунды:
https://yadi.sk/d/8qb4mMTTgXSMR
Первая пробная версия упаковщика Rezfile. Кидаем в папку с DoomRezPacker.exe распакованные файлы, которые ОБЯЗАТЕЛЬНО должны быть вида Dxxxx где xxxx цифры от 0001 до того числа, которое вы укажете первым аргументом (если не укажете, тогда до 473 по умолчанию). Запускать можно просто DoomRezPacker.exe или так: . Например, так:
Если запаковать прогой оригинальные распакованные файлы и сравнить с оригиналом Rezfile то будет около 50 отличий. Это из-за непонятного флага 0x80 (см. мой пост выше), но игре на этот флаг как будто бы плевать
Изменять карты и перепаковывать пока не пробовал.
По поводу моего конвертера карт с недоделанным конвертом последнего лумпа. Там на выходе получаются файлы lump01, lump02... их нужно как-то переименовать в Dxxxx. Как это лучше сделать я сейчас думаю.

Вах, какой праздник! Сейчас это осознать нет возможности, подробно почитаю потом.

aliast
Пишет, что не является приложением Win32...

Может антивирусник режет? Должно быть всё ок, в проекте стоит win32 и запускается на Win64. В Win32 не пробовал.

Антивирь выгрузил, та же фигня. С предыдущей твоей прогой также было.