Хочу в этой теме начать обсуждение не торопясь, "за чаем". По форуму разбросаны различные описания, но все они неструктурированы и, зачастую, сложны для понимания. В одной теме вскользь обсуждается звук, в другой графика, применительно к конкретной ситуации. Вот и захотелось весь этот "бардак" оформить. Уверен, что многие новички (как я) не знают даже как подступиться к незнакомым символам. Всем это будет полезно. Файлы, в которые запиханы различные ресурсы, пока рассматривать не будем. Т.к. продолжил "пилить" свою софтину, для написания алгоритма нужны конкретные данные. Начну с того, что понял я.
Рассмотрим отдельно:
Файл IMAG
Пусто
Файл CEL
Начинается с CCB заголовка (различного размера?). После него Могут встречаться XTRA, PLUT(палитра?). Данные непосредственно картинки - после PDAT. CEL //*** CCB structure for CEL FLAGS: integer; /// 4 bytes /Assorted 1-bit flags. This is the first word read. NEXTPTR: integer;/// 3 bytes / Address of next CCB to process. SOURCEPTR: integer; /// 3 bytes / Address of image data to be rendered. PLUTPTR: integer; ///3 bytes / Address of PLUT to be loaded. XPOS: integer;/// 4 bytes / Horizontal source position of cel in bitmap (in 16.16 or 17.15 format) YPOS: integer;/// 4 bytes / Vertical source position of cel in bitmap (in 16.16 or 17.15 format) ///// Ниже приведены опциональные (необязательные) параметры CCB HDX: integer; /// 4 bytes / Starting horizontal offset X value (in 12.20 format) HDY: integer; /// 4 bytes / Starting horizontal offset Y value (in 12.20 format) VDX: integer; /// 4 bytes / Vertical offset x value (in 16.16 format) VDY: integer; /// 4 bytes / Vertical offset y value (in 16.16 format) HDDX: integer; /// 4 bytes / Change in HDX offset value (in 12.20 format) HDDY: integer; /// 4 bytes / Change in HDY offset value (in 12.20 format) PIXC: integer; /// 4 bytes / Pixel processor control word. PRE0: integer; /// 4 bytes / Possible first preamble word PRE1: integer; /// 4 bytes / Possible second preamble word
Файл ANIM.
Заголовок ANIM, далее (через определенное количество байт? Каких?) идет CCB заголовок. Явно, что он неодинаков для всех файлов (из чего он состоит?). После него Могут встречаться XTRA, PLUT (палитра?) и, собственно, PDAT (данные непосредственно самого изображения). Далее CCB и прочее не повторяется, то есть, можно взять данные от CCB (включительно) и до первого PDAT и приписать в начале перед каждой секцией PDAT. Мы получим из ANIM файла столько картинок, сколько вхождений PDAT имеем.
Файл??? Добавляйте свои мысли, описания, наработки. Только прошу, пишите понятным языком. Буду обновлять первый пост. По мере возможностей буду копаться сам.
Последний раз редактировалось Versus 31 июл 2014, 10:32, всего редактировалось 1 раз.
AIFF - музыка AIFC - звуковые эффекты На приставке 3DO у многих файлов вообще нет расширений и это может быть всё что угодно. Чаще всего это исполняемые файлы или видео (поправьте если ошибаюсь, но по-моему у видео действительно на ставят расширения) В CEL заголовок CCB всегда 80 байт (0x50). С PLUT непонятка - почти везде размер 76 байт (0x4C), но изредка встречаются исключения. Точно не скажу. PDAT - данные, размер всегда разный.
//*** CCB structure for CEL FLAGS: integer; /// 4 bytes /Assorted 1-bit flags. This is the first word read. NEXTPTR: integer;/// 3 bytes / Address of next CCB to process. SOURCEPTR: integer; /// 3 bytes / Address of image data to be rendered. PLUTPTR: integer; ///3 bytes / Address of PLUT to be loaded. XPOS: integer;/// 4 bytes / Horizontal source position of cel in bitmap (in 16.16 or 17.15 format) YPOS: integer;/// 4 bytes / Vertical source position of cel in bitmap (in 16.16 or 17.15 format) ///// Ниже приведены опциональные (необязательные) параметры CCB HDX: integer; /// 4 bytes / Starting horizontal offset X value (in 12.20 format) HDY: integer; /// 4 bytes / Starting horizontal offset Y value (in 12.20 format) VDX: integer; /// 4 bytes / Vertical offset x value (in 16.16 format) VDY: integer; /// 4 bytes / Vertical offset y value (in 16.16 format) HDDX: integer; /// 4 bytes / Change in HDX offset value (in 12.20 format) HDDY: integer; /// 4 bytes / Change in HDY offset value (in 12.20 format) PIXC: integer; /// 4 bytes / Pixel processor control word. PRE0: integer; /// 4 bytes / Possible first preamble word PRE1: integer; /// 4 bytes / Possible second preamble word
///---------- ПЕРЕМЕННЫЕ ДЛЯ СУБ-ЧАНКА SHDR ------------------------------- /// - все поля размером 4 байта version: integer; numbuffers: integer; //// для плейера - сколько буферов надо разместить -- игнорируем initAmplitude: integer; ///// начальная амплитуда -- 0 = min, 7fff -- max initPan: integer; //// начальный баланс (лево\право) dataFormat: string[5];/// формат данных [4] байта, не используется sampleSize: integer; //// размер каждого сэмпла в битах sampleRate: integer; /// частота сэмплов numChannels: integer; /// сколько каналов (1 == моно\2 == стерео) CompressionType: string[5]; /// тип компрессии [4] байта CompressionRatio: integer; /// во сколько раз сжато SampleCount: integer; //// количество сэмплов ////
///------------ ПЕРЕМЕННЫЕ ДЛЯ СУБ-ЧАНКА SSMP ----------------------------- //// actSampleSize: integer; - размер сэмпла аудио data: word; - непосредственно данные ////
CTRL - для потрошения ресурсов мне не пригодился, назначение не знаю, встречается вместе с графическими и аудио данными; SYNC - используется для синхронизации видео потока и аудио с действиями игрока;
typedef struct CinePakHeader { //SUBS_CHUNK_COMMON; long chunkType; /* chunk type */ long chunkSize; /* chunk size including header */ long time; /* position in stream time */ long channel; /* logical channel number */ long subChunkType; /* data sub-type */ long version; /* 0 for this version */ long cType; /* video compression type*/ long height; /* Height of each frame */ long width; /* Width of each frame */ long scale; /* Timescale of Film*/ long count; /* Number of frames*/ } CinePakHeader
long version; /*0 for this version */ long cType; /*video compression type*/ long height; /*Height of each frame */ long width; /*Width of each frame */ long scale; /*Timescale of Film*/ long count; /*Number of frames*/ }ShortCinePakHeader ///////////////////////////////////////
typedef struct CinePakFrame { //SUBS_CHUNK_COMMON; long chunkType; /* chunk type */ long chunkSize; /* chunk size including header */ long time; /* position in stream time */ long channel; /* logical channel number */ long subChunkType; /* data sub-type */ long duration; /*Duration of this sample*/ long frameSize; /*Number of bytes in frame*/ char frameData[4]; /*compressed frame data...*/ } CinePakFrame
//////////////////////
SNDS - блок аудио данных, соседствует с SSMP
Давно этим всем не занимался, мог что-то упустить и забыть. Когда-то копался в ресурсах Road Rash, там вообще одни нестандартные чанки данных.
NEXTPTR: integer;/// 3 bytes / Address of next CCB to process.
Это что? Это как раз и есть та самая шляпа из Killing Time, когда на текстуру стены накладывается текстура трещин. И этот NEXTPTR есть указатель на структуру CCB этой трещины. Если накладывать ничего не нужно, то NEXTPTR = NULL. Но как это всё используется?!
Добавлено спустя 5 минут 51 секунду:
Author писал(а):
SOURCEPTR: integer; /// 3 bytes / Указатель на секцию PDAT PLUTPTR: integer; ///3 bytes / Указатель на секцию PLUT
Я понимаю так, сначала нужно разобрать секцию FLAGS (описана в 3DO SDK), ориентируясь по ней мы узнаем, должны ли читать только NEXTPTR и SOURCEPTR или за ними ещё расположен указатель на PLUT (хотя подозреваю он есть всегда только может быть NULL, как ты заметил). В зависимости от флагов могут добавляться опциональные (необязательные) параметры CCB, которые либо прописаны, либо отстутствуют. Как всё это используется не знаю.
В 3DO SDK (файл MovieToSream.c одноимённой утилиты) нашёл зачем точно нужен FILL.
"Write out a chunk of type 'FILL' for the remaining block data. This is done when no other block is small enough to fit in the remaining space." Т.е. как и предполагалось - для забивания пустот, которые должны быть для обработчиков даных, но их нечем заполнять. В данном случае, нет подходящего размера блока с видео данными в оставшемся пространстве (видимо есть некий "шаг"/обязательный размер данных/ у декодера видео).
Файлы ARY Массив из нескольких CEL-картинок с текстурами с порезанными заголовками CCB, PDAT, PLUT. typedef struct ARY { string CARY; //сигнатура файла CelARraY int32 start_offset; //смещение к началу первого файла int32 file_size; //размер файла ARY минус 4 байта int32 zero1; //нули int32 offset1; //смещение к началу первой текстуры int32 offset2; //смещение к началу второй текстуры ... int32 offsetN; //смещение к началу N-ой (последней) текстуры int32 zero2; //нули - обозначают конец таблицы оффсетов };
Далее идёт секция CCB первой картинки, но заголовок CCB обрезан, нужно восстановить его самим написав вначале: 43 43 42 20 00 00 00 50 00 00 00 00 Здесь 43 43 42 20 = "CCB " 00 00 00 50 = неизменный размер секции в 80 байт (0x50) 00 00 00 00 = нули Далее идут 68 байт (0x44) из файла ARY, начиная со смещения offset1 до offset2 (должно быть offset2 - offset1 = 0x44) Секция CCB имеет следующий вид (для дальнейшей распаковки нам понадобятся offset_PDAT и offset_PLUT): typedef struct CCB { string CCB ; //сигнатура секции "CCB " (с пробелом в конце) int32 CCB_size; //размер секции, всегда равен 0x50 int32 zero1; //нули int32 flags; //спец. флаги (за подробностями читаем 3DO SDK, а пока просто копируем данные из ARY) int32 zero2; //нули int32 offset_PDAT //смещение к секции PDAT применительно к файлу ARY int32 offset_PLUT //смещение к секции PLUT применительно к файлу ARY ... //дальше лень расписывать, просто копируем данные }; Сразу после секции CCB идёт секция PDAT, заголовок тоже обычно обрезан. Восстанавливается дописыванием байт: 50 44 41 54 размер_секции_PDAT Здесь 50 44 41 54 = "PDAT" размер_секции_PDAT = размер секции PDAT = смещение_к_следующей_секции_PDAT - смещение_к_предыдущей_секции_PDAT Далее копируем данные из ARY, начиная со смещения offset_PDAT и до смещения offset_PDAT из заголовка CCB следующего файла. Ну и по аналогии восстанавливаем секцию PLUT, дописав вначале секции: 50 4C 55 54 00 00 00 4C 00 00 00 20 Здесь 50 4C 55 54 = "PLUT" 00 00 00 4C = размер секции PLUT, всегда 0x4C 00 00 00 20 = неизвестный байт 0x20. Скорее всего он всегда равен 0x20 во всех картинках Копируем данные из ARY, начиная со смещения offset_PLUT и до смещения offset_PLUT из заголовка CCB следующего файла.
Собственно, мне не понятно как размер CARY может быть 61B4, если размер JOIN'a = 1FB8??? Только за счёт вырезанных заголовков? Куда прицеплять заголовок CCB? Перед "7FE6C220"?
Собственно, мне не понятно как размер CARY может быть 61B4, если размер JOIN'a = 1FB8???
Давно это было. Там получается так, что файлы внтури ZSеream как бы дефраментированы - кусок здесь, кусок там. Если размер JOIN не совпадает с размером файла, значит где-то дальше в ZStream должно быть продолжение файла, сопровождаемая сигнатурой JARYJDAT, т.е. JARYJHDR это начало файла, а JARYJDAT это продолжение. Причём совсем не обязательно это продолжение будет в следующем JOIN, оно может быть и через 2-3 джоина.
Добавлено спустя 3 минуты 59 секунд:
Author писал(а):
Куда прицеплять заголовок CCB? Перед "7FE6C220"?
Ну да. Но тут я не до конца понял - в одном ARY находится несколько CEL. Причём там так хитро сделано - текстура стены одна и та же, а на неё накладываются лианы, трещины, орнамент. Получается что все эти лианы и трещины существуют отдельными текстурами, а гладкая стена - отдельно от них. Как это всё правильно распаковать не очень понятно.
aliast, спасибо за пояснение. Весьма запутано, я уже столкнулся с JDAT'ами при вытаскивании звуков. Пока получается фигово, хотя содержимое JOIN'ов анализирую.
GOTO - работает как называется. Переход на заданную позицию после чанка. STOP - ?? PAUS - ?? ALRM - alarm
Streamed cels (потоковые Cel'ы, видимо видео на основе картинок) CHAR4LITERAL('S','C','E','L') // any SCEL chunk CHAR4LITERAL('H','E','A','D') // SCEL header chunk CHAR4LITERAL('C','L','S','T') // SCEL cel-list chunk (список Cel)
Типы cel списков в SCEL чанке CHAR4LITERAL('C','L','S','T') // regular cel list (обычный CEL список) CHAR4LITERAL('D','B','L','V') // Double-Vision cel list
