Outpost 2 Форматы файлов · bei.pm

Форматы данных, используемые в Outpost 2, имеют структуру, напоминающую JFIF / PNG - каждый блок данных всегда имеет заголовок размером 8 байт. Поэтому я не буду документировать отдельные заголовки в соответствующих специфических местах, а буду фиксировать только отклонения.

Формат всегда следующий; фактические полезные данные встроены в него:

Объемы представляют собой контейнеры данных для игры, аналогичные архивным форматам, таким как Tarball. По крайней мере в Outpost 2 формат знает только файлы - папок нет. Вероятно, их можно смоделировать с помощью соответствующих имен файлов.

Объем состоит из заголовка объема и нескольких блоков объема, которые соответствуют конкретным файлам.

"Объемы" - это файлы с расширением 'vol' в игровом каталоге.

Заголовок объема сам по себе не содержит никаких пользовательских данных.
Он служит лишь контейнером.

В качестве первой записи в заголовке объема должны находиться строки объема; за ними следуют данные о объеме.

Объемные строки представляют собой список имен файлов, которые находятся в объеме.

Информация о томах содержит более подробные данные о файлах. Это своего рода запись в каталоге FAT (FAT = таблица размещения файлов).

Количество файлов вычисляется как размер блока, делённый на длину записей каталога - 14 байт.

Каждая отдельная запись каталога имеет следующую структуру:

Объемный блок представляет собой контейнер, который содержит файлы. Он включает в себя только еще раз - из-за формата блока - избыточный размер файла, и затем сразу же следуют полезные данные.

Тайлы представляют собой специфический для Outpost-2 формат графики в битмапе. Они охватывают 13 тайлсетов, называемых "колодцами" (well0000.bmp до well0012.bmp), которые находятся внутри объема maps.vol.

При этом тайлсеты / колодцы содержат следующее:

Рекомендуется для точного выполнения не рендерить тайлы заранее для кэширования, так как данные для цикла день/ночь еще должны быть обработаны - и возникло бы слишком много данных.

Тайлы представляют собой графики с глубиной цвета 8 бит на пиксель с индексированной палитрой размером 32x32 пикселя, которые расположены друг под другом. Однако в таком созданном тайлсете может быть значительно больше

Главный контейнер состоит из 2 секций: head и data.

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

В конце концов, следуют чистые пиксельные данные, начиная с верхнего левого угла и движущиеся по строкам к нижнему правому углу.
Значение данных для графиков, которые обычно представлены в формате 8bpp-битмап, соответствует индексу цвета в цветовой палитре.

Игровой движок, вероятно, рисует тайлы по запросу.
Это, среди прочего, связано с циклом дня и ночи, который имеет 32 градации отдельных тайлов. При этом, судя по всему, от значения яркости отнимается 'немного'. Точные значения пока не удалось определить, я работаю на основе расчётов

v *= (daylight / 48) + 0.25;

с данными HSV пикселей, где daylight — это значение от 0 до 31, а v — значение от 0 до 1. Кроме того, следует учитывать, что на карте по бокам есть граница из 16 тайлов (она служит для невидимого появления юнитов).

Кроме того, цикл дня и ночи, похоже, обновляет только одну колонку карты за игровой цикл.
Ускоренный цикл дня и ночи выглядит следующим образом:

Что именно обозначает PRT, мне неизвестно; возможно, это 'Palette and Resource Table' - поскольку этот файл, который можно найти как op2_art.prt в maps.vol, является именно таким, или это довольно хорошо описывает его функцию.

Этот файл содержит список палитр, таблицу всех используемых битмапов, все определения анимации и еще ряд неизвестных данных. Он слабо следует предыдущему формату контейнера, поскольку не все записи соответствуют этой схеме.

Секция CPAL (вероятно, обозначающая контейнер палитр) охватывает лишь данные палитр, указывая, сколько из обычно имеющихся 1052 байтных 8-битных палитр присутствуют.

Указание на 1052 байта не является обязательным, так как формат палитр потенциально может предусматривать различные размеры палитр. Это относится только к набору данных, с которым поставляется Outpost 2.

После списков палитр сразу, без вводного заголовка, следует список битмапов; точно так же сразу следуют списки анимаций.
Оба из них начинаются с uint(32) (или снова uint24+uint8 флаги?), который содержит количество записей.

Информация о паллетах очень проста для восприятия.
Она состоит из заголовка и сегмента данных.

Раздел данных включает в себя отдельные записи палет. Количество записей палет определяется как длина блока / 4.

Каждая из записей имеет следующий простой формат;

Что касается палитр, то следует отметить, что для палитр, используемых в анимациях, действуют следующие правила:

• Первый цвет ВСЕГДА прозрачный, независимо от указанного значения.
• Записи палитры с 1 по 24 считаются цветами игрока в палитрах с 1 по 8.
  Откуда берутся цвета, отличные от цвета игрока 1, мне неясно.
  Я предполагаю, что остальные цвета закодированы.

Эта структура данных файла PRT указывает, как устроены битмапы, используемые для спрайтов. Эти битмапы служат отдельным компонентом, из которого собираются несколько кадров анимации спрайта.

Конкретные данные изображения скрываются в op2_art.BMP в игровом каталоге.
Почему этот файл битмапа имеет (в основном корректный) заголовок RIFF-битмапа, остается неясным. Возможно, Outpost 2 использует системные API для загрузки графики, временно заимствуя этот заголовок и перезаписывая соответствующие изменяющиеся поля.

Данные пикселей находятся в BMP-файле по позиции Offset + uint32-Offset, который можно найти в BMP-файле по адресу 0x000A (RIFF-данные смещения битмапа) и снова соответствуют построчной организации сверху слева направо вниз.

Монохромные графики 1bpp могут быть нарисованы так, что цвет 0 представляет полную прозрачность, а цвет 1 является полупрозрачным черным/серым, так как монохромные графики обычно используются для теней автомобилей и зданий в анимациях.

Таким образом, можно собрать множество графиков.

Теперь мы переходим к королевскому классу дисциплин внутри форматов данных Outpost 2:
К анимациям.

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

1. Анимация
   Анимация является верхней инстанцией; она представляет собой анимацию юнита, здания или 'частичной анимации' (удар кометы, погода, взрыв) в определенной начальной позиции.
2. Кадр
   Кадр — это одно изображение в рамках анимации. Анимация может содержать один или несколько кадров.
3. Субкадр
   Субкадр — это информация о том, что определенная битмап должна быть нарисована в определенном месте кадра по определенным критериям. Один кадр может содержать один или несколько субкадров.

После этого сразу следуют отдельные определения анимаций.

Данные верхнего уровня, анимации, в основном представляют собой административные данные - Boundingbox обозначает координаты метки вокруг транспортного средства/здания, когда оно выбрано, и одновременно указывает, какая область должна быть кликабельной.

Смещение в первую очередь определяет "нулевую точку"; точку, к которой нужно прибавить или вычесть игровые координаты. Можно также сказать математически: смещение здесь обозначает начало координат.

В окнах, так же как и в случае со смещением, содержится по 4 значения uint(32) для каждого окна, которые указывают область, пригодную для отдельных подрамок. За пределами окон не должно быть рисования, если это не предусмотрено для битовой карты.

Теперь мы можем собирать отдельные кадры, а также целые анимации, как это демонстрируется на более сложной анимации с индексом 500

Анимация 500 показывает, как грузовик Plymouth, загруженный обычным рудами, разгружается. Это одна из немногих анимаций, использующих функцию окон.

Таким образом, можно собрать всю анимацию вместе.
К сожалению, есть еще одна проблема с верхним люком, так как соответствующий бит в информации о типе графики не установлен.

Вот еще несколько прекрасно анимированных спрайтов из игры:

Теперь осталось только пользовательское интерфейс игры, выполненное в матовом металле.

Но и здесь видно, что Dynamix не пришлось изобретать велосипед; здесь не просто используются стандартные API User32 и GDI32, предоставленные Windows — также используется управление ресурсами от User32.

Их можно, например, извлечь с помощью программы Resource Hacker, разработанной Ангусом Джонсоном в качестве бесплатного ПО, или - если вы избегаете использования Wine под Linux / Mac OS - с помощью wrestool, входящего в состав icoutils.