Outpost 2 Filformat · bei.pm

Dataformat som används av Outpost 2 har en struktur som påminner om JFIF / PNG - de enskilda datablocken har alltid en 8-byte header. Därför hoppar jag över att dokumentera de enskilda headerna på de aktuella specifika ställena och dokumenterar endast avvikelser där.

Formatet är alltid följande; de verkliga nyttolastdata är sedan inbäddade däri:

Volymer är en databehållare för spelet, liknande ett arkivformat som till exempel Tarball. Åtminstone i Outpost 2 känner formatet endast till filer - inga mappar. Det är troligt att dessa ändå skulle kunna simuleras genom motsvarande filnamn.

Ett volym består av volymhuvudet samt flera volymblock som motsvarar de konkreta filerna.

"Volymer" är filerna med ändelsen 'vol' i spelmappen.

Volymhuvudet innehåller i sin tur inga användardata.
Det fungerar bara som en behållare.

Det första datumet i volymhuvudet bör vara volymsträngarna; följt av volyminformationen.

Volume-strängarna är en lista med filnamn som ingår i volymen.

Volyminformationerna tar detaljerad information om filerna. Det handlar på ett sätt om en slags FAT-katalogpost (FAT = File Allocation Table).

Antalet filer beräknas genom blockstorleken dividerat med längden på katalogposterna - 14 byte.

De enskilda katalogposterna har följande struktur:

En volymblock är en behållare som tar emot filer. Den innehåller ytterligare en gång - på grund av blockformatet - redundant filstorleken och därefter följer direkt användardata.

Tiles handlar om ett Outpost-2-specifikt bitmap-grafikformat. De sträcker sig över 13 tilesets, ""wells" kallade (well0000.bmp till well0012.bmp), som finns inom volymen maps.vol.

Tilesets / Wells innehåller följande:

Det är rekommenderat för en noggrann implementering att inte rendera tiles i förväg för att cacha dem, eftersom datan för dag/natt-cykeln fortfarande måste bearbetas - och det skulle genereras väldigt mycket data.

Tiles är 8bpp-grafik med indexerad palett på 32x32 pixlar, som är ordnade i ett rutnät. I ett så skapat tileset kan dock mycket fler

Huvudcontainern består av 2 sektioner: head och data.

En palettfil i standardiserat RIFF-format kommer att följa dessa uppgifter. Den exakta specifikationen finns - eftersom paletterna också förekommer på andra ställen - under Paletter.

Till slut följer de rena pixeldatan, rad för rad från vänster-övre till höger-nedre.
Datastrukturen för de grafiker som vanligtvis presenteras som 8bpp-bitmaps motsvarar färgindexet i färgpaletten.

Spelmotorn ritar tiles *troligen* på begäran.
Detta verkar bland annat bero på dag-natt-cykeln som har 32 olika nivåer av enskilda tiles. Det verkar som om ljusstyrkevärdet minskas 'lite' varje gång. Exakta värden har ännu inte kunnat fastställas, jag arbetar utifrån beräkningsgrunden

v *= (daylight / 48) + 0.25;

med HSV-data för pixlarna, där daylight är ett värde mellan 0-31 och v är ett värde mellan 0-1. Dessutom är det viktigt att beakta att det på kartan finns en kant av 16 tiles till vänster och höger (som används för osynligt spawnande av enheter).

Det verkar också som att dag-natt-cykeln uppdaterar endast en kolumn av kartan per spelcykel.
En accelererad dag-natt-cykel ser därför ut som följande:

Vad PRT exakt står för är mig okänt; en möjlighet skulle kunna vara 'Palette and Resource Table' - eftersom denna fil - som finns som op2_art.prt i maps.vol - handlar om just detta, vilket skulle beskriva funktionen ganska bra.

Denna fil innehåller en lista över paletter, en tabell över alla använda bitmaps, alla animationsdefinitioner och en mängd okända data. Den följer det tidigare containerformatet löst, eftersom inte alla poster följer detta schema.

CPAL-sektionen (som troligen står för Palettcontainer) omfattar endast palettdata genom att ange hur många av de vanligen 1052 byte stora 8-bitars paletterna som finns.

Angivelsen av 1052 byte ska inte ses som bindande, eftersom palettformatet potentiellt kan föreskriva olika palettstorlekar. Den gäller endast för den datamängd som Outpost 2 levereras med.

Efter palettlistorna följer omedelbart och utan inledande rubrik, redan listan över bitmaps; precis som omedelbart följer animationslistorna.
Båda inleds med en uint(32) (eller kanske igen uint24+uint8 flaggor?) som innehåller antalet poster.

Palettinformationerna är mycket enkla att läsa.
De består av en header och ett datasegment.

Dataavsnittet tar upp de enskilda pallinläggen. Antalet pallinlägg beräknas utifrån blocklängden / 4.

De enskilda inläggen har följande, enkla struktur;

Angående paletterna är det enda att säga att följande regler gäller för paletter som används för animationer:

• Den första färgen är ALLTID transparent, oavsett vilket värde som anges där.
• Palettposterna 1-24 räknas som spelarfärg i paletter 1-8.
  Var färgerna utöver spelare 1 kommer ifrån är oklart för mig.
  Jag misstänker att de övriga färgerna är hårdkodade.

Datastrukturen för PRT-filen anger hur de bitmappar som används för spriter är uppbyggda. Dessa bitmappar fungerar som enskilda komponenter, varav flera sätts samman till en animationsram för en sprite.

De konkreta bilddata finns istället i op2_art.BMP i spelkatalogen.
Varför denna bitmapfil har en (övervägande korrekt) RIFF-bitmapheader är oklart. Troligtvis använder Outpost 2 system-API:er för att ladda grafik genom att temporärt ta över denna header och överskriva de motsvarande, varierande fälten.

Pixeldatan finns i BMP-filen på position Offset + uint32-offsetet, som finns i BMP-filen vid adress 0x000A (RIFF-bitmapdataoffset), och följer återigen den radvisa arrangemanget från övre vänstra till nedre högra hörnet.

Monokroma 1bpp-grafiker kan ritas på så sätt att färg 0 representerar fullständig transparens, medan färg 1 är en halvtransparent svart/grå ton, eftersom monokromgrafiker vanligtvis används för fordon och byggnadsskuggor i animationerna.

Därmed kan man redan sätta ihop många grafik.

Nu kommer vi till kungaklassen bland disciplinerna inom Outpost 2 dataformat:
Animationerna.

Animationslistorna inleds med en global header som främst används för dataverifikation. Därefter följer de konkreta animationsdefinitionerna, som är indelade i 3 nivåer:

1. Animation
   En animation är den högsta instansen; den representerar en animation av en enhet, en byggnad eller en 'partikel-animation' (kometnedslag, väder, explosion) i en viss utgångssituation.
2. Frame
   En frame är en enskild bild inom en animation. En animation kan innehålla en eller flera frames.
3. Subframe
   En subframe är informationen om att en viss bitmap under vissa kriterier ska ritas på en viss position av en frame. En frame kan innehålla en eller flera subframes.

Därefter följer direkt de enskilda animationsdefinitionerna.

Datana från det översta lagret, animationen, är främst administrationsdata - Boundingbox anger koordinaterna för markeringen runt fordonet/byggnaden när det har valts och indikerar samtidigt vilket område som ska vara klickbart.

Offsetet bestämmer främst "nollpunkten"; den punkt som ska läggas till eller subtraheras från spelinternt koordinatsystem. Man kan också säga mer matematiskt: offsetet anger här koordinatursprunget.

Fönstren består, precis som offsetet, av 4 uint(32)-värden per fönster som anger ett område som är användbart för individuella subframes. Utanför fönstren får, om det är avsett för bitmapen, inte ritas.

Med detta kan vi nu sätta ihop enskilda ramar såväl som kompletta animationer, här demonstrerat med en mer komplex animation, animationen med index 500.

Animation 500 visar hur en Plymouth-transportör, som är lastad med vanligt malm, lastas ur. Detta är en av de få animationerna som utnyttjar fönsterfunktionaliteten.

Och så kan hela animationen sättas ihop.
Tyvärr finns det fortfarande ett problem med den övre lastluckan, eftersom det aktuella biten i grafiktyp-informationen inte är inställt.

Här är några fler vackert animerade sprites från spelet:

Nu saknas användargränssnittet för spelet, som har en borstad metall-look.

Men här är det också tydligt att Dynamix inte behövde uppfinna hjulet på nytt; här används inte bara enkelt de User32- och GDI32-API:er som tillhandahålls av Windows - särskilt används också resursförvaltningen från User32.

Dessa kan exempelvis extraheras med program som Angus Johnson utvecklat som freeware, Resource Hacker, eller - om man avstår från att använda Wine på Linux / Mac OS - med hjälp av wrestool som ingår i icoutils.