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

Данните формати, използвани от Outpost 2, имат структура, напомняща на JFIF / PNG - отделните блокове данни винаги разполагат с 8-байтов заглавен блок. Затова ще спестя усилията си да документирам отделните заглавия на съответните специфични места и ще документирам само отклоненията там.

Форматът винаги е следният; действителните полезни данни са вградени в него:

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

Едно обемче се състои от заглавката на обема, както и от няколко обемни блока, които съответстват на конкретни файлове.

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

Обемният хедър от своя страна не съдържа никакви данни за употреба.
Той служи единствено като контейнер.

Като първи данни в обемния хедър трябва да се намират обемните низове; след това следват информацията за обема.

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

Информацията за обема съдържа по-подробни данни за файловете. По някакъв начин това представлява вид запис в директорията на FAT (FAT = File Allocation Table)

Броят на файловете се определя от размера на блока, разделен на дължината на записите в директорията - 14 байта.

Отделните записи в директорията имат следната структура:

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

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

Наборите от тилове / well съдържат следното:

Препоръчително е за точна реализация да не се рендират тайловете предварително, за да се кешират, тъй като данните за цикъла ден/нощ все още трябва да бъдат обработени - и биха възникнали много, много данни.

Тайловете са 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, който може да бъде намерен на адрес 0x000A в BMP файла (RIFF-Bитмап данни offset), и отново отговарят на редовното подреждане от горе ляво надясно надолу.

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

Така може да се сглобят много графики.

Сега преминаваме към кралския клас на дисциплините в данните на Outpost 2:
Анимациите.

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

1. Анимация
   Анимацията е най-висшата инстанция; тя представлява анимация на единица, сграда или "частична анимация" (кометен удар, време, взрив) в определена изходна ситуация.
2. Кадър
   Кадърът е едно единствено изображение в рамките на анимацията. Анимацията може да включва един или повече кадри.
3. Подкадър
   Подкадрите съдържат информация за това, че определена битмап трябва да бъде нарисувана на определена позиция на кадъра при определени критерии. Един кадър може да включва един или повече подкадри.

След това следват самите определения на анимацията.

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

Офсетът определя предимно "нулевата точка"; точката, която трябва да се изчисли спрямо вътрешните координати на играта или да се извади. Може да се каже и математически: офсетът тук обозначава координатния произход.

При прозорците става въпрос, както и при офсета, за по 4 uint(32)-стойности за всяко прозорче, които определят област, която е валидна за отделни субфреймове. Извън прозорците не трябва, освен ако не е предвидено за битовата карта, да се рисува.

С това можем да комбинираме отделни рамки, както и цели анимации, тук ще демонстрираме на примера на една по-сложна анимация, анимацията с индекс 500

Анимация 500 показва как един Plymouth транспортен автомобил, натоварен с обикновен рудник, се разтоварва. Това е една от малкото анимации, които използват функционалността на прозорците.

И така, можем да съберем цялата анимация заедно.
За съжаление, все още има проблем с горния товарен люк, тъй като съответният бит в информацията за графичния тип не е зададен.

Ето и няколко допълнителни, прекрасно анимирани спрайта от играта:

Сега остава само потребителският интерфейс на играта, който е в обработен метал стил.

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

Те могат да бъдат извлечени например с програми като разработения от Angus Johnson безплатен Resource Hacker, или - ако избягвате използването на Wine под Linux / Mac OS - с помощта на wrestool, включен в icoutils.