![]() |
Добро пожаловать, гость ( Вход | Регистрация )
![]() |
LexSafonov |
![]()
Сообщение
#1
|
Member ![]() ![]() Группа: Authorized Сообщений: 21 Регистрация: 29-October 20 Пользователь №: 18,034 Спасибо сказали: 1 раз(а) ![]() |
Всем привет, решил создать тему про разбор форматов ресурсов игры Alien Trilogy, преимущественно её ПК варианта. Некоторые ресурсы лежат довольно открыто, но есть некоторые, весьма нестандартные.
Но обо всём по порядку. Начну я вот с чего. Из довольно открытых ресурсов - это звуки, это обычные raw-данные без заголовка. Спокойно съедается через Sound Forge или аналогичные программы, достаточно выставить нужный битрейт. Так же из открытых ресурсов можно выделить текстуры, о них я напишу ниже, т.к. это напрямую связано с "секциями" BND(B16) файлов. Кстати говоря о этих файлах. Игра использует BND "архивы", для хранения ресурсов - моделей, текстур, спрайтов, текстурных сеток для моделей. Ещё есть аналог BND - B16, в которых лежат данные от 16 битных вариаций текстур\спрайтов. Вернёмся к так называемым "секциям". В файлах встречаются вот такие секции: F000(#1,2,3....) - F? - Frame, кадр, используется такая секция у спрайтов. Может внутри себя содержать несколько изображений. Об этом я напишу далее и расскажу об одной особенности. T000(#1,2,3....) - T? - Texture, текстура. Тут всё проще, у таких секций есть строгие параметры, как у обычных изображений, длина ширина, нет компресии(что самое главное), изображение содержит идексы цветов. Спокойно дёргается XWE редактором. Может быть несколько штук в одном месте. Вообще эта секция достаточно интересная, т.к. используется у моделей\карт, рядом с этой секцией обычно бывает лежит ещё секция с индексами полигонов. M000(#1,2,3....) - M? - Model, модель. Тут всё просто, эта секция отвечает за модели. Имет список квадов(не полигонов!)\вершин. Прикол с квадами очевидно связан с тем, что изначально игру лепили для двух приставок - PS и Sega Saturn. Так вот, на сколько помню у сеги вроде бы аппаратная часть лучше работала именно с квадами. И вроде бы(поправьте, если не прав) - сначала игру делали именно для сеги. Но не суть, в файле именно описание квадов. В одном файле может быть несколько штук таких секций. BX00(#1,2,3....) - BX? - прямоугольники для текстурирования квадов(полигонов) в модели.Что то типа текстурной сетки. CX00(#1,2,3....) - CX? - пока не разбирал и не смотрел реакцию игры на эту секцию. Вот описание формата моделей текстом от моего товарища по думу ZZYZX: Разбор формата PICKMOD.BND текстом - сначала заголовок файла: размер содержимое комментарий ------------------------------------------------------------------------------------------------------------------------- 0x04 46 4F 52 4D FORM 0x04 - размер данных файла в байтах, BIG-ENDIAN (перевёрнутый как на сраном арме) 0x04 - количество моделей в файле текстом. всегда 4 символа (формат %04d) - дальше идут модели по очереди. у каждой модели есть: размер содержимое комментарий ------------------------------------------------------------------------------------------------------------------------- 0x01 4D первая буква идентификатора M (M000, M001, ...) 0x03 - индекс модели текстом. всегда три символа (формат %03d) 0x04 - размер данных модели в байтах, BIG-ENDIAN 0x04 4F 42 4A 31 OBJ1 0x08 00 00 00 00 00 00 00 00 неизвестное значение 0x04 - количество прямоугольников в модели. LITTLE-ENDIAN 0x04 - неизвестное значение 0x14*N - прямоугольники по очереди (см. формат дальше) 0x08*N - вершины по очереди (см. формат дальше) - формат прямоугольника: размер содержимое комментарий ------------------------------------------------------------------------------------------------------------------------- 0x04 - индекс первой точки. LITTLE-ENDIAN 0x04 - вторая точка 0x04 - третья точка 0x04 - четвёртая точка. может быть -1 (0xFFFFFFFF), тогда это треугольник и надо продублировать третью точку. 0x04 - неизвестное значение - формат вершины: размер содержимое комментарий ------------------------------------------------------------------------------------------------------------------------- 0x02 - координата X (signed, LITTLE-ENDIAN, short) 0x02 - координата Y 0x02 - координата Z 0x02 - неизвестное значение, вроде бы всегда 0 А вот и текстурная сетка для моделек Разбор формата PICKGFX.BND текстом - сначала заголовок файла: размер содержимое комментарий ------------------------------------------------------------------------------------------------------------------------- 0x04 46 4F 52 4D FORM 0x04 - размер данных файла в байтах, BIG-ENDIAN 0x04 50 53 58 54 PSXT (вероятно идентификатор формата) - дальше идут (в произвольном порядке?) секции INFO, TP00, CL00, BX00. Возможно бывают *01, *02 и так далее, но мне не встречались. - секция INFO размер содержимое комментарий ------------------------------------------------------------------------------------------------------------------------- 0x04 49 4E 46 4F INFO 0x04 - размер данных секции в байтах, BIG-ENDIAN 0x02 - размер текстуры X 0x02 - размер текстуры Y 0x0C - неизвестная информация, 12 байт - секция TP00 тут тупо лежат WxH пиксели. каждый пиксель = 1 байт. смещение в палитру текущую экрана. найти можно в PALS/WSELECT.PAL (768 байт, 3 байта на каждый цвет, умножить на 4 каждый компонент) - секция CL00 тут лежит неизвестно что. не кантовать. - секция BX00 тут лежат прямоугольники текстуры для текстурирования квадов. размер содержимое комментарий ------------------------------------------------------------------------------------------------------------------------- 0x04 42 58 30 30 BX00 0x04 - размер данных секции в байтах, BIG-ENDIAN 0x04 - количество прямоугольников - - прямоугольники по очереди (см. формат дальше) - формат прямоугольника текстуры BX00 размер содержимое комментарий ------------------------------------------------------------------------------------------------------------------------- 0x01 - размер по X (-1 пиксель, т.е. 31 вместо 32 и так далее) 0x01 - размер по Y (-1 пиксель) 0x01 - неизвестное значение 0x01 - неизвестное значение 0x01 - смещение по X с конца (т.е. надо отнять ширину перед использованием) 0x01 - смещение по Y C000(#1,2,3....) - C? - Color, цвет, секция, очевидно отвечающая за цвет. У файлов B16, такая секция идёт в самом конце. Формат этой секции такой: 0x04 - С000 0x04 - кол-во байт, отведённых под цвета\палитру. 0x02 - непосредственно цвета, по 2 байта на цвет(обычно) У этой секции есть одна особенность - в некоторых файлах бывает так, что кол-во байт под палитру меньше 512, не понял с чем это связано. Если я правильно понимаю логику, то 512\2 = 256 ячеек(если отталкиваться от каких то простых форматов тип BMP). Вроде бы во многих мануалах пишут, что 16 бит именно так и работает, поправьте, если я не прав. Теперь вернёмся с секциям F000, которые отвечают за спрайты. Собрал небольшое описание, в основном из экспериментов с пожатыми данными в Hex-редакторе. Временное описание формата: 0x04 - Заголовок файла FORM 0x04 - размер данных файла в байтах, BIG-ENDIAN 0x04 - кол-во блоков, видимо текст ------------------------------------------------------------------------------------------------------------------------- 0x04 - индентификатор F000 0x04 - Длина до следующей секции, видимо в бинарном представлении. 0x01 - Непонятный байт, крошит изображение, есть подозрение, что это длина алфавита или какой то цепочки байт. Это не длина\ширина. Ниже объясню. 0x0? - Цвета и повторения. Формат повторений 0x01 - Код цвета 0х01 - Флаг\префикс повторений(обычно символ P, т.е. в Hex коде 50) 0х01 - промежуток повторений(через какой промежуток надо повторить этот цвет) 0х01 - кол-во раз повторений(сколько пикселей рисовать в ряд https://www.old-games.ru/forum/attachments/...mat-png.211586/ немного наглядности из примерного описания формата, файл MM9.B16 По поводу формата повторений. У него тоже есть определённые условия, а именно, описание верно только для одного условия - когда первое число после префикса равно 1. Видимо для игры это обозначает рисовать цвет сплошняком. Плюс изначально для сплошного цвета игра прибавляет в ряд толи 8, толи 10 неубираемых пикселей. Я насчитал 10. В файле присутствуют варианты, когда первый байт после префикса больше единицы. Из своих экспериментов пока только сделал вывод, что что-то двигается(из пикселей), но не понял закономерности. Иногда бывает, что в повторениях походу висят какие-то ссылки на другие места. Кстати об этом тоже по подробнее. В один момент я решил разбирать вообще сплошняком побайтово, но запутался ещё больше: https://www.old-games.ru/forum/attachments/...ble-png.215950/ красный - видимо ссылки, при изменении ломают изображение желтый - меняют цвет в нескольких местах, либо подставляют туда какой то кусок синий - одиночный пиксель голубой - нет эффекта, либо эффект незаметен бардовый - нули, непонятно чё делают, если изменить на значение, отличное от нуля, то в изображении пропадают пиксели(местами). Из переписки с -=CHE@TER=- я увидел, что стандартных данных, как у любой другой картинки, в файле нет, т.к. он нашёл указатель на этот самый пистолет в TRILOGY.EXE, где благополучно лежит длина и ширина кадра. Теперь по поводу магического числа, ломающего изображение. В MM9.B16 это 92(Hex вариант). Я пошёл ещё дальше и решил сделать "чистый" кадр. Забил всё одиночными пикселями, с цветом 01, а само число 92 поставил на нуль. Получил такую картину: https://www.old-games.ru/forum/attachments/nulls-png.216418/ Откуда то взялась лесенка. Байт, где число 92, каким то образом на неё влияет, как будто сдвигает её. Закономерности сдвигов не понял, двигает всегда на разную длину(если менять значение). Потом забил серый цвет. Лесенка уменьшилась, а само изображение увеличилось(по идее ничего не должно было подобного произойти): https://www.old-games.ru/forum/attachments/probe-png.216419/ Вопрос к знатокам - может, кто то видел подобное? Похоже на LZX, но какое то своё, хитро-мудрое. Я описывал B16 вариант, но на сайте old-games, чувак с ником ak48 видимо пробовал смотреть BND аналог и там какие то вывороты с палитрой жёсткие) |
![]() ![]() |
LexSafonov |
![]()
Сообщение
#2
|
Member ![]() ![]() Группа: Authorized Сообщений: 21 Регистрация: 29-October 20 Пользователь №: 18,034 Спасибо сказали: 1 раз(а) ![]() |
Так ребята, всем привет. Долго меня не было. Вообщем сразу по делу буду, без лишних разговоров
![]() Решил я доразобрать по сильнее файл с картой. Сначала первый заход был с так называемым "полем", отвечающим за коллизию, а именно "коллижн-блоки". На данный момент структура одного такого блока. Напомню, 1 блок - это 16 байт описание. CODE - формат одного квадрата коллизии(поле с блоками физ. движка) ------------------------------------------------------------------------------------------------------------------------- 0x04 - порядковый номер? пока не совсем ясно как это работает, некоторые номера дают стабильный вылет. Кажись это связано как то с тем, что игра некорректно определяет два одинаковых блока в разных местах. 0x02 - непонятно что это и непонятно для чего оставили. Пока просмотрел 5 разных карт и почему то везде там нули. Вполне вероятно, что там может быть что то по эффектам. 0x01 - значение есть, но не ясен эффект 0x01 - то же самое 0x01 - кажись высота рендеринга потолка блока(черный туман) 0x01 - кажись высота рендеринга пола блока(черный туман)(не точно) 0x01 - высота потолка у блока?(эти значения работают и редактируются в хекс-редакторе) 0x01 - высота пола у блока? 0x01 - непонятное значение 0x01 -хм... блок перестаёт быть неосязаемым, если туда забить простые числа. значение от 55 и ниже блочат игрока. Кажись это какая то высота для блока, только непонятно для чего оно и не совсем ясна логика работы этой высоты. 0x01 - цвет освещения в блоке? Нашёл вот такие значения: FF - окрашивает в красный цвет 64 - моргает красный цвет 128 - синий цвет 160 - желтый 192 - серый? 224 - толи оранжевый, толи красный. от 1 до 10 - в блоке яркий свет От 11 до 17 - в блоке темно? 18 - ярко красно моргает 20 - полный свет в блоке 22 - оранжево моргает 24 - моргает тёмно-оранжевым 30 - моргает с темного на белый 0x01 - походу байт, который отвечает за действия. если забить 1, то открывает стартовую дверь. значение: 1 - стартовая дверь 3 - дверь, которая открывается рубильником 9 - конец уровня Из опыта с высотами блоков на первый взгляд выяснилось, что используется система пол-потолок, как в думе\дюке. Становится понятна логика работы движка. Видимо игра действительно технически поделена на "сетку из блоков" и в качестве координат у объектов принимает позицию блока(длина-строка). Остальное "считается" уже дальше. Такая система имеет и свои изъяны, а именно, двери и свитчи можно открывать "спиной", ведь движок по факту смотрит чисто нажатие кнопки в самом блоке. Этот прикол уже проверен и неоднократно) Далее я немного дорасшиффровал заголовок файла: CODE - сначала заголовок файла: размер содержимое комментарий ------------------------------------------------------------------------------------------------------------------------- 0x04 46 4F 52 4D FORM 0x04 - размер данных файла в байтах, BIG-ENDIAN 0x04 - количество карт в файле текстом.(обычно нуль, т.к. больше одной карты в файлах не встречал) - дальше идет информация о геометрии карты и её содержании, а именно: размер содержимое комментарий ------------------------------------------------------------------------------------------------------------------------- 0x04 - Название карты, текст 0x04 - размер данных карты, BIG-ENDIAN(прямой порядок байт) 0х02 - Кол-во вершин?.LITTLE-ENDIAN(обратный порядок байт) Формула - значение этих двух байт умножить на 8 (6 байт на 3 точки + 2 байта нули) 0x02 Кол-во квадов(прямоугольников).LITTLE-ENDIAN (обратный порядок байт). Формула - значение этих 2-х байт умножить на 20 (16 байт индексы точкек и 4 байта информация) 0x02 ------------ Длина "прямоугольника" мини карты(физ. движка)(Little-Endian) 0х02 ------------ Ширина "прямоугольника" мини карты(физ. движка)(Little-Endian) Формула для этих байт = умножить длину на ширину и полученое значение умножить на 16 16 байт описывают одну ячейку. 0х02 - Стартовая позиция игрока по осиX (Здесь пишется так же ) 0х02 - Стартовая позиция игрока по осиY 0х02 - Пока не ясно что, изменения приводят к зацикливанию игры на этапе подгрузки карты, иногда к вылету. 0х02 - Поле описания монстров, которые просто спавнятся. Формула = кол-во элементов умножить на 20 (20 байт на одного монстра) 0х02 - Поле описания пикапов, формула = кол-во элементов умножить на 8 0х02 - Поле описания "коробок" и подобных объектов(свитчей, бочек) Формула = кол-во элементов умножить на 16 0x02 - Исправление, походу 2 байта это кол-во всех дверей на карте. Формула: значение умножить на 8(8 байт один элемент) Формат двери ниже. 0х02 - Пока не ясно за что отвечает. 0x02 - Похоже на стартовый угол поворота игрока, игрока на старте карты это значение крутит. 0x06 - Не ясно что это, эффект постоянно случайный от изменения. 0x04 - Неизвестное значение, каким то образом влияет на монстров на уровне. Если монстры на уровне есть и выставить нули, то у монстров отключается рендеринг спрайтов, но сами они не пропадают Теперь по порядку, я нашёл ещё 4 разных значения, а именно координаты игрока X и Y , стартовый угол игрока и поле с кол-вом и описанием дверей на карте. Формат одной двери: CODE ------------------------------------------------------------------------------------------------------------------------- 0x01 - координата X 0x01 - координата Y 0х01 - непонятный байт 0х01 - время простоя двери в открытом состоянии 0х01 - тэг двери(для использования в коллижн блоках) 0х01 - непонятный байт 0х01 - угол поворота модели двери относительно карты 0х01 - индекс модели из секции D000\1\2\3... Пока что я не совсем понял вот такие вещи, а именно: - Если трёхмерная модель карты имеет координаты, то и её коллизия тоже должна иметь какие то стартовые координаты первого блока. - Так же я не совсем понял, что за последнее поле имеется в файле карты, после поля описания дверей. Там примерно 4000 байт.... Байты каким то образом там упорядочены, но изменения делают вообще случайные вещи(отключают двери, либо наоборот вешают другие эфффекты на "коллижн-блоки". Не могу понять логику их работы... - Каким образом дверям задаётся движение и их собственная коллизия(если дверь крутить, то игрок и монстры её коллизию видят).В некоторых картах есть двери, которые, видимо, вообще крутятся чисто вокруг своей оси(вроде 4 уровень в игре, где крео-камеры, сами модули имеют походу двери, которые "открываются" крутясь). В теории если это выяснить, то возможно будет вообще делать двери, которые будут открываться в стороны, а не вверх-низ, как в думе. Ладно, пойду спать, отпишусь по результатам, если чего выйдет)) |
![]() ![]() |
Упрощённая версия | Сейчас: 30th April 2025 - 22:34 |