Outpost 2 Filformater · bei.pm

De dataformater, der bruges af Outpost 2, har en struktur, der minder om JFIF / PNG - de enkelte datablokke har altid en 8 bytes header. Derfor undlader jeg at dokumentere de enkelte headere på de relevante specifikke steder og dokumenterer kun afvigelserne der.

Formatet er altid det følgende; de egentlige nyttedata er derefter indlejret i det:

Volumener er en databeholder til spillet, svarende til et arkivformat som f.eks. Tarball. I det mindste i Outpost 2 kender formatet kun filer - ingen mapper. Det er sandsynligt, at disse dog kan simuleres gennem passende filnavne.

Et volume består af volume-headeren samt flere volume blokke, der svarer til de konkrete filer.

"Volumes" er filerne med endelsen 'vol' i spilmappen.

Volume-headeret indeholder i sig selv ingen nyttedata.
Det fungerer kun som en container.

Som det første element i volume-headeret skal der findes volume-strenge; derefter følger volume-oplysningerne.

Volume Strings er en liste over filnavne, der er indeholdt i volumenet.

Volume-oplysningerne indeholder mere detaljerede oplysninger om filerne. Det drejer sig på en måde om en slags FAT-katalogpost (FAT = File Allocation Table)

Antallet af filer beregnes ved at dividere blokstørrelsen med længden af katalogposterne - 14 byte.

De enkelte katalogposter har følgende opbygning:

En volume-block er en beholder, der indeholder filer. Den indeholder blot endnu en gang - på grund af blokformatet - redundant filstørrelsen, og derefter følger direkte brugerdataene.

Tiles er et Outpost-2-specifikt Bitmap-grafikformat. De strækker sig over 13 tilesets, "wells" kaldet (well0000.bmp til well0012.bmp), som findes inden for volumen maps.vol.

De indeholder følgende i tilesets / wells:

Det er stærkt anbefalet for en præcis implementering ikke at forudrenderere tiles for at cache dem, da dataene til dag/nat-cyklussen stadig skal behandles - og der ville opstå meget, meget store datamængder.

Tiles er 8bpp-grafik med en indekseret palette med en opløsning på 32x32 pixels, som er arrangeret i et gitter. I et sådan tileset kan der dog være langt flere

Hovedcontaineren består af 2 sektioner: head og data.

Efter disse oplysninger følger der en palettedat fil i det standardiserede RIFF-format. Den præcise specifikation findes - da paletterne også optræder andre steder - under Paletter.

Endelig følger de rå pixeldata, fra venstre-øverst række for række mod højre-nederst.
Data værdien for de grafikker, der som regel findes som 8bpp-bitmap, svarer til farveindekset i farvepaletten.

Spil-motoren tegner fliserne *sandsynligvis* on-demand.
Dette ser blandt andet ud til at skyldes dag-nat cyklussen, som har 32 nuancer af enkelte fliser. Her bliver der åbenbart trukket 'lidt' fra lysstyrken. Nøjagtige værdier er endnu ikke blevet fastslået, jeg arbejder på beregningsgrundlaget

v *= (daylight / 48) + 0.25;

med HSV-dataene fra pixel, hvor daylight er en værdi fra 0-31 og v en værdi mellem 0-1. Derudover skal det tages i betragtning, at der på kortet er en kant på 16 fliser til venstre og højre (den tjener til usynligt at spawn enheder).

Derudover ser det ud til, at dag-nat cyklussen kun opdaterer én søjle af kortet pr. spilcyklus.
En accelereret dag-nat cyklus ser derfor sådan ud:

Hvad PRT præcist står for, er mig ikke bekendt; det kunne for eksempel være 'Palette and Resource Table' - da denne fil - som findes som op2_art.prt i maps.vol - netop handler om dette, eller det ville i hvert fald beskrive funktionen ret godt.

Denne fil indeholder en liste over paletter, en tabel over alle anvendte bitmapper, alle animationsdefinitioner samt en række ukendte data. Den følger det hidtidige containerformat løst, idet ikke alle datasæt følger dette schema.

CPAL-sektionen (som sandsynligvis står for palette-container) omfatter kun palettedataene, ved at angive hvor mange af de typisk 1052 byte store 8-bit paletter der er til stede.

Angivelsen af 1052 byte betragtes ikke som bindende, da paletteformatet potentielt kunne have forskellige paletstørrelser. Den gælder kun for det datasæt, som Outpost 2 leveres med.

Efter paletlisten følger straks, uden en indledende header, listen over bitmapper; ligeledes følger animationslisterne umiddelbart efter.
Disse indledes hver især med en uint(32) (eller måske uint24+uint8 flags?), som indeholder antallet af datasæt.

Paletteinformationerne er meget enkle at læse.
De består hver især af en header og et datasegment.

Dataafsnittet indeholder de enkelte paletindgange. Antallet af paletindgange er baseret på bloklængden / 4.

De enkelte indgange har følgende enkle opbygning;

Om paletterne er der ellers kun at sige, at der gælder følgende regler for paletter, der bruges til animationer:

• Den første farve er ALDRIG transparent, uanset hvilken værdi der angives.
• Paletternes indgange 1-24 betragtes som spillerfarver i paletterne 1-8.
  Hvor farverne uden for spiller 1 præcist kommer fra, er mig uklart.
  Jeg formoder, at de resterende farver er hardcoded.

Denne datastruktur i PRT-filen angiver, hvordan de bitmaps, der bruges til sprites, er opbygget. Disse bitmaps fungerer som individuelle komponenter, hvor flere sammensættes til en animationsramme for et sprite.

De konkrete billeddata findes derimod i op2_art.BMP i spillets mappe.
Hvorfor denne bitmapfil har en (overvejende korrekt) RIFF-bitmapheader, er uklart. Sandsynligvis bruger Outpost 2 system-API'er til at indlæse grafikken, ved midlertidigt at overtage denne header og overskrive de relevante, varierede felter.

Pixeldatarne findes i BMP-filen ved positionen Offset + det uint32-offset, der kan findes i BMP-filen på adresse 0x000A (RIFF-bitmap-dataoffset), og svarer igen til den linjemæssige opstilling fra øverste venstre til nederste højre.

Monokrome 1bpp-grafikker kan tegnes sådan, at farve 0 er fuldstændig gennemsigtig, mens farve 1 er et halvtransparent sort/grå, da monokrom-grafikker typisk bruges til skygger af køretøjer og bygninger i animationerne.

Derfor kan man allerede sammensætte mange grafikker.

Nu kommer vi til kongeklassen af discipliner inden for Outpost 2 dataformater:
Animationerne.

Animationslisterne indledes med en global header, der primært tjener til dataverifikation. Herefter følger de konkrete animationsdefinitioner, der er opdelt i 3 niveauer:

1. Animation
   En animation er den øverste instans; den repræsenterer en animation af en enhed, en bygning eller en 'partikel-animation' (kometnedslag, vejr, eksplosion) i en bestemt udgangssituation.
2. Frame
   Et frame er et enkelt billede inden for en animation. En animation kan indeholde et eller flere frames.
3. Subframe
   Et subframe er informationen om, at et bestemt bitmap skal tegnes på en bestemt position i et frame under bestemte kriterier. Et frame kan indeholde et eller flere subframes.

Herefter følger de enkelte animationsdefinitioner.

Dataene fra det øverste lag, animationen, er primært administrationsdata - Boundingbox angiver koordinaterne for markeringen omkring køretøjet/bygningen, når det er valgt, og angiver samtidig, hvilket område der skal være klikbart.

Offsettet bestemmer primært "nulpunktet"; det punkt, der skal lægges til eller trækkes fra de interne koordinater. Man kunne også sige mere matematisk, at offsettet her angiver koordinatursprunget.

Windowsene består, ligesom offsettet, af 4 uint(32)-værdier pr. vindue, der angiver et område, der betragtes som anvendeligt for enkelte subframes. Uden for vinduerne må der, hvis det er relevant for bitmap'en, ikke tegnes.

Med dette kan vi nu samle individuelle rammer såvel som komplette animationer, her vist som eksempel med en mere kompleks animation, animationen med indeks 500.

Animation 500 viser, hvordan en Plymouth-transportør, der er lastet med almindeligt mineral, bliver tømt. Dette er en af de få animationer, der bruger vinduesfunktionaliteten.

Og sådan kan den komplette animation samles.
Desværre er der stadig et problem med den øverste lastelem, da det relevante bit i grafiktypen-informationen ikke er sat.

Her er nogle flere, smukt animerede sprites fra spillet:

Nu mangler vi kun brugergrænsefladen til spillet, som har et børstet metal-look.

Men her er det også tydeligt, at Dynamix ikke behøvede at genopfinde hjulet; her bruges ikke blot de funktioner, der leveres af Windows’ User32- og GDI32-API'er - især anvendes også ressourcestyringen fra User32.

Disse kan for eksempel udtrækkes ved hjælp af programmer som den freeware, der er udviklet af Angus Johnson, Resource Hacker, eller - hvis man undgår at bruge Wine på Linux / Mac OS - ved hjælp af wrestool, som er inkluderet i icoutils.