Outpost 2 Формати на датотеки · bei.pm

Податочните формати користени во Outpost 2 имаат структура која наликува на JFIF / PNG - поединечните блокови на податоци секогаш имаат хедер од 8 бајти. Затоа, ќе избегнам да ги документирам поединечните хедери на соодветните специфични места и таму ќе документирам само отстапувања.

Форматот секогаш е следниот; самите корисни податоци се вградени во него:

Обемите се податоци контејнер за играта, слично на архивски формат како на пример Tarball. Најмалку во Outpost 2, форматот познава само фајлови - без папки. Веројатно би можеле да се симулираат преку соодветни имиња на фајлови.

Едно Volume се состои од Volume-Header и неколку Volume блокови, кои одговараат на конкретните фајлови.

"Volumes" се фајловите со завршеток 'vol' во директориумот на играта.

Хедерот на волуменот не содржи никакви корисни податоци.
Тој служи само како контејнер.

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

Во Volume Strings се работи за листата на имиња на датотеки што се вклучени во волуменот.

Информациите за волуменот содржат подетални информации за фајловите. Станува збор за вид на FAT-ен запис во директориумот (FAT = Табела за распределба на фајлови)

Бројот на фајлови се добива од големината на блокот поделена со должината на записите во директориумот - 14 байтови.

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

Волумен-блокот е контејнер кој собира фајлови. Тој само повторно - поради форматот на блокот - содржи редундантно големина на фајлот и потоа следат директно корисните податоци.

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

При тоа, сетовите на тилови / Води содржат следново:

Препорачливо е за точна имплементација, да не се рендерираат плочките однапред за да се кешираат, бидејќи податоците за ден/ноќниот циклус мора да се обработат - и ќе се генерираат многу, многу податоци.

Плочките се 8bpp графики со индексирана палета со резолуција од 32x32 пиксели, кои се распоредени една под друга. Во така создаден сет на плочки, сепак може да има многу повеќе

Главниот контејнер се состои од 2 секции: head и data.

По овие информации следува и една палетна датотека во стандардизираниот RIFF формат. Точната спецификација се наоѓа - бидејќи палетите се појавуваат и на други места - под Палети.

Конечно, следуваат чистите пиксел податоци, од лево-горе по редови до десно-долу.
Вредноста на податоците кај графиките кои обично се во формат 8bpp-Bitmap одговара на индексот на бојата во палетата на бои.

Играчката механика ги црта плочките *веројатно* на побарувачка.
Ова изгледа, меѓу другото, да се должи на циклусот на денот и ноќта, кој има 32 степени на поединечни плочки. Очигледно, се одзема 'малку' од вредноста на осветленоста. Точните вредности сè уште не можат да се утврдат, работам на основа на пресметката

v *= (daylight / 48) + 0.25;

со HSV податоците на пикселите, при што daylight е вредност од 0-31, а v е вредност помеѓу 0-1. Понатаму, треба да се земе во предвид дека на мапата постои по 16 плочки од левата и десната страна (кои служат за невидливо појавување на единици).

Дополнително, изгледа дека циклусот на денот и ноќта по играчкиот циклус обновува само еден столб од мапата.
Затоа, забрзаниот циклус на денот и ноќта изгледа следново:

За што точно значи PRT не ми е познато; возможно е, на пример, 'Табела на палети и ресурси' - бидејќи оваа датотека - може да се најде како op2_art.prt во maps.vol - е таква, односно тоа добро би ја опишало функцијата.

Oваа датотека содржи листа на палети, табела за сите користени битмапи, сите дефиниции на анимации и уште еден број на непознати податоци. Таа следи досегашниот формат на контејнерот лабаво, бидејќи не сите записи го следат овој шем.

Секцијата CPAL (веројатно значи контејнер на палети) опфаќа само податоците за палетите, наведувајќи колку од секоја обично присутна палета од 1052 байта постојат.

Подавањето на 1052 байта не се смета за обврзувачко, бидејќи форматот на палетите потенцијално предвидува различни големини на палети. Тоа важи само за податоците со кои се испорачува Outpost 2.

По листите на палети веднаш, без воведна хедер, следи листата на битмапи; исто така веднаш следат и листите на анимации.
Двете се воведуваат со uint(32) (или повторно uint24+uint8 флагови?) кој ја содржи бројот на записи.

Информациите за палетите се многу лесни за читање.
Tие се составени од хедер и сегмент на податоци.

Податоците во секцијата ги содржат поединечните записи за палетите. Bројот на записи за палетите произлегува од должината на блокот / 4.

Поединечните записи имаат следна, едноставна структура;

За палетите, инаку, може да се каже само дека за палетите што се користат за анимации важат следните правила:

• Првата боја ЕВЕГА е секогаш транспарентна, без оглед на тоа каква вредност е наведена таму.
• Записите на палетата 1-24 се сметаат за боја на играч во палетите 1-8.
  Каде точно доаѓаат боите, освен од играч 1, ми е непознато.
  Сметам дека преостанатите бои се тврдо кодирани.

Структурата на податоците од PRT-файлот укажува на тоа како се изградени BITMAP-ите користени за спритовите. Овие BITMAP-и служат како единствена компонента, од која неколку се собираат во анимациска рамка на спритот.

Конкретните сликарски податоци се наоѓаат во op2_art.BMP во директориумот на играта.
Зошто овој битмап-фајл има (претежно точен) RIFF битмап хедер, не е јасно. Веројатно Outpost 2 користи системски API за вчитување на графики, применувајќи го овој хедер времено и променувајќи ги соодветните, варијабилни полиња.

Пикселските податоци се наоѓаат во BMP-фајлот на позиција Офсет + uint32-Офсет, кој може да се најде во BMP-фајлот на адреса 0x000A (RIFF битмап податоци офсет), и повторно одговара на редоследот на редовите од горе лево надесно.

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

На тој начин може да се состават многу графики.

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

Листите на анимациите започнуваат со глобален хедер, кој служи главно за верификација на податоците. По тоа следат конкретните дефиниции на анимациите, кои се делат на 3 нивоа:

1. Анимација
   Анимацијата е највисоката инстанца; таа претставува анимација на единица, зграда или 'партилска анимација' (удар на комета, време, експлозија) во одредена почетна позиција.
2. Фрејм
   Фрејмот е едно единствено слика во рамките на анимацијата. Анимацијата може да содржи еден или повеќе фрејмови.
3. Субфрејм
   Субфрејмот е информација дека одреден битмап треба да се нацрта на одредена позиција на фрејмот под одредени критериуми. Еден фрејм може да содржи еден или повеќе субфрејмови.

Потоа следат директно индивидуалните дефиниции на анимациите.

Податоците од најгорниот слој, анимацијата, се првенствено управни податоци - Boundingbox означува координати на ознаката околу возилото/зграда, кога истото е избрано и истовремено укажува на тоа кој дел треба да биде кликабилен.

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

Во прозорците, како и кај офсетот, има по 4 uint(32) вредности за секој прозорец, кои означуваат област која важи за поединечни субфреймови. Надвор од прозорците не смее да се црта, освен ако не е предвидено за битмапа.

На тој начин можеме да составиме поединечни фрејмови, како и целосни анимации, тука ќе покажеме на пример на една покомплексна анимација, анимацијата со индексот 500.

Анимација 500 прикажува како се празни Plymouth-товарникот, кој е натоварен со обично руда. Станува збор за една од малкуте анимации кои ја користат функционалноста на прозорците.

И така, целата анимација може да се состави.
За жал, постои уште еден проблем со горната товарна врата, бидејќи соодветниот бит во информациите за типот на графиката не е поставен.

Еве уште неколку, прекрасно анимирани спрајтови од играта:

Сега останува уште корисничкиот интерфејс на играта, кој е во избрусен метал-изглед.

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

Овие можат да се извлечат, на пример, преку програми како што е Resource Hacker, развиен од Angus Johnson како freeware, или - ако не сакате да користите Wine под Linux / Mac OS - со помош на wrestool вклучен во icoutils.