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

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

Формат завжди такий; фактичні корисні дані в ньому вбудовані:

Обсяги - це контейнери даних для гри, схожі на архівний формат, наприклад, Tarball. Принаймні в Outpost 2 цей формат містить лише файли - без папок. Напевно, їх можна було б симулювати за допомогою відповідних імен файлів.

Обсяг складається з заголовка обсягу та кількох блоків обсягу, які відповідають конкретним файлам.

"Обсяги" - це файли з розширенням 'vol' у директорії гри.

Обсяг заголовка не містить жодних корисних даних.
Він слугує лише як контейнер.

Першими даними в обсязі заголовка повинні бути рядки обсягу; далі слідують інформація про обсяг.

Обсягові рядки є списком імен файлів, які містяться в обсязі.

Інформація про том містить більш детальні відомості про файли. Це, певним чином, є своєрідним записом у FAT-довіднику (FAT = таблиця розподілу файлів).

Кількість файлів визначається шляхом ділення розміру блоку на довжину записів у довіднику - 14 байт.

Окремі записи в довіднику мають наступну структуру:

Об'ємний блок - це контейнер, який містить файли. Він містить лише ще раз - через формат блоку - редундантний розмір файлу, а потім безпосередньо слідують корисні дані.

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

При цьому тайлсети / колодязі містять наступне:

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

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

Головний контейнер складається з 2 секцій: head та data.

Після цих даних буде надано ще файл палітри у стандартизованому форматі RIFF. Точну специфікацію можна знайти - оскільки палітри з'являються і в інших місцях - за посиланням Палітри.

Нарешті йдуть чисті піксельні дані, зліва зверху рядками донизу справа.
Значення даних у графіках, які зазвичай представлені у форматі 8bpp-бітмапи, відповідає індексу кольору в палітрі кольорів.

Ігровий движок, ймовірно, малює тайли *на вимогу*.
Це, зокрема, пов'язано з циклом день-ніч, який має 32 ступені окремих тайлів. При цьому, очевидно, від значення яскравості 'трохи' віднімається. Точні значення ще не вдалося визначити, я працюю на основі розрахунків

v *= (daylight / 48) + 0.25;

з HSV-даними пікселів, де daylight – це значення від 0 до 31, а v – це значення між 0 і 1. Крім того, слід врахувати, що на карті є ще край з 16 тайлів зліва і справа (він служить для невидимого спавну одиниць).

Додатково, здається, що цикл день-ніч оновлює лише один стовпець карти за кожен ігровий цикл.
Прискорений цикл день-ніч виглядає наступним чином:

Що саме означає PRT мені невідомо; можливо, це може бути 'Таблиця палітри та ресурсів' - оскільки цей файл, який можна знайти як 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 позначає координати мітки навколо транспортного засобу/будівлі, коли вона вибрана, і також вказує, яка область має бути активною для кліку.

Зміщення (offset) в основному визначає "нулеву точку"; точку, яку потрібно враховувати або віднімати для внутрішніх координат гри. Можна також сказати більш математично: зміщення тут позначає координатний початок.

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

Тепер ми можемо складати окремі кадри, а також цілі анімації відповідно, на прикладі більш складної анімації з індексом 500, продемонстровано

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

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

Ось ще кілька інших, чудово анімованих спрайтів з гри:

Тепер залишилося ще інтерфейс користувача гри, який виконаний у стилі шліфованого металу.

Але й тут видно, що Dynamix не потрібно було винаходити велосипед заново; тут використовуються не лише прості функції, надані API User32 та GDI32 від Windows - зокрема, також використовується управління ресурсами User32.

Ці ресурси можна, наприклад, витягнути за допомогою програм, таких як Resource Hacker, що розроблений Angus Johnson як безкоштовне програмне забезпечення, або - якщо ви уникаєте використання Wine під Linux / Mac OS - за допомогою wrestool, що входить до складу icoutils.