Outpost 2 Filformater · bei.pm

Dataformatene som brukes av Outpost 2 har en struktur som minner om JFIF / PNG - de enkelte datablokkene har alltid en 8 Byte header. Dermed velger jeg å unngå å dokumentere de enkelte headerne på de spesifikke stedene, og dokumenterer bare avvikene der.

Formatet er alltid det følgende; de faktiske nyttedataene er deretter innebygd i det:

Volumer er en databeholder for spillet, lignende et arkivformat som for eksempel Tarball. I hvert fall i Outpost 2 kjenner formatet kun filer - ingen mapper. Det er sannsynlig at disse imidlertid kan simuleres gjennom passende filnavn.

Ett volum består av volumheaderen samt flere volumblokker som tilsvarer de konkrete filene.

"Volumer" er filene med filendelsen 'vol' i spillkatalogen.

Volumenkoppen inneholder ingen nyttedata.
Den fungerer kun som en beholder.

Som den første datoen i volumkappen skal volumstrenger være; deretter følger voluminformasjonen.

Volumetekstene er en liste over filnavn som finnes innenfor volumet.

Voluminformasjonen inneholder mer detaljerte opplysninger om filene. Dette er på en måte en slags FAT-katalogoppføring (FAT = File Allocation Table).

Antall filer beregnes ved å dele blokkstørrelsen på lengden av katalogoppføringene - 14 byte.

Hver enkelt katalogoppføring har følgende oppbygning:

En volumeblok er en beholder som tar opp filer. Den inneholder bare en gang til - på grunn av blokkformatet - redundant filstørrelsen, og deretter følger bruksdataene direkte.

Tiles er et spesifikt bitmapgrafikkformat for Outpost-2. De strekker seg over 13 tilesett, kalt "wells" (well0000.bmp til well0012.bmp), som finnes innenfor volumet maps.vol.

Tilesett / Wells inneholder følgende:

Det anbefales å ikke rendre flisene på forhånd for å cache dem, da dataene for dag/natt-syklusen fortsatt må bearbeides - og det ville genereres veldig mange data.

Flisene er 8bpp-grafikk med indeksert palett, hver med en oppløsning på 32x32 piksler, og de er ordnet i rader. I et slik flisesett kan det imidlertid være betydelig flere

Hovedbeholderen består av 2 seksjoner: head og data.

I henhold til disse opplysningene vil det også bli presentert en palettfil i standardisert RIFF-format. Den nøyaktige spesifikasjonen finnes - siden palettene også dukker opp andre steder - under Paletter.

Til slutt følger de rå pikseldataene, fra øverst til venstre radvis mot nederst til høyre.
Datastrengen for grafikkene, som vanligvis foreligger som 8bpp-bitmaper, tilsvarer indeksen til fargen i fargepaletten.

Spillmotoren tegner sannsynligvis *tiles* etter behov.
Dette ser ut til å skyldes dag- og natt-syklusen, som har 32 nyanser av individuelle tiles. Det ser ut til at det trekkes 'litt' fra lysverdi. Nøyaktige verdier har ennå ikke blitt fastslått, jeg jobber med beregningsgrunnlaget

v *= (daylight / 48) + 0.25;

med HSV-dataene til pikslene, der daylight er en verdi fra 0-31 og v er en verdi mellom 0-1. I tillegg må det tas hensyn til at det på kartet er en rand på 16 tiles til venstre og høyre (som tjener til usynlig spawne av enheter).

I tillegg ser det ut til at dag- og natt-syklusen oppdaterer kun én kolonne av kartet per spillsyklus.
En akselerert dag- og natt-syklus ser derfor slik ut:

Hva PRT står for er meg ukjent; det kan for eksempel være 'Palette and Resource Table' - siden denne filen - som finnes som op2_art.prt i maps.vol - faktisk er en slik fil, eller dette ville beskrive funksjonen ganske bra.

Denne filen inneholder en liste over paletter, en tabell over alle brukte bitmap-er, alle animasjonsdefinisjoner og en rekke ukjente data. Den følger den tidligere containerformatet løst, da ikke alle datasett følger dette skjemaet.

CPAL-seksjonen (som sannsynligvis står for palettcontainer) omfatter bare palettdataene, ved å angi hvor mange av de vanligvis 1052 byte store 8-bit paletter som er til stede.

1052-byte-angivelsen anses ikke som bindende, da palettformatet potensielt kan ha forskjellige palettstørrelser. Den gjelder bare for datamaterialet som Outpost 2 leveres med.

Etter palettlistene følger umiddelbart, uten innledende overskrift, listen over bitmap-er; deretter følger animasjonslistene umiddelbart.
Begge innledes med en uint(32) (eller igjen uint24+uint8 flagg?) som inneholder antall datasett.

Paletteinformasjonen er veldig enkel å lese.
Den består alltid av en header og et datasegment.

Datasetet inneholder de enkelte palloppføringene. Antallet palloppføringer er basert på blokkens lengde / 4.

De enkelte oppføringene har en enkel struktur som følger;

Når det gjelder palettene, er det ellers bare å si at følgende regler gjelder for paletter som skal brukes til animasjoner:

• Den første fargen er ALLTID transparent, uansett hvilken verdi som angis der.
• Palettoppføringene 1-24 regnes som spillerfarge i palett 1-8.
  Hvor fargene utenom spiller 1 egentlig kommer fra, er uklart for meg.
  Jeg antar at de resterende fargene er hardkodet.

Denne datastrukturen i PRT-filen angir hvordan bitmapene som brukes for sprites er bygget opp. Disse bitmapene fungerer som enkeltkomponenter, hvor flere settes sammen til et animasjonsramme for en sprite.

De konkrete bildedataene finnes derimot i op2_art.BMP i spillmappen.
Hvorfor denne bitmapfilen har en (for det meste korrekt) RIFF-bitmapheader, er uklart. Sannsynligvis bruker Outpost 2 system-API-er for å laste grafikken, ved midlertidig å overta denne headeren og overskrive de relevante, varierende feltene.

Pixeldatas er plassert i BMP-filen på Offset + uint32-offset, som kan finnes i BMP-filen på adresse 0x000A (RIFF-bitmap-dataoffset), og dette tilsvarer igjen radvis oppstilling fra øverste venstre til nederste høyre.

Monokrome 1bpp-grafikker kan tegnes slik at farge 0 er fullstendig gjennomsiktig, mens farge 1 er et halvtransparent svart/grått, da monokromgrafikk vanligvis brukes for skygger av kjøretøy og bygninger i animasjonene.

Dette gjør at man allerede kan sette sammen mange grafikker.

Nå kommer vi til toppen av disiplinene innen Outpost 2 dataformater:
Animasjonene.

Animasjonslistene innledes med en global header, som primært tjener til dataverifisering. Deretter følger de konkrete animasjonsdefinisjonene, som deles inn i 3 nivåer:

1. Animasjon
   En animasjon er den øverste instansen; den representerer en animasjon av en enhet, en bygning eller en 'partikkel-animasjon' (kometnedslag, vær, eksplosjon) i en bestemt startposisjon.
2. Bilde
   Et bilde er et enkelt bilde innen en animasjon. En animasjon kan inneholde ett eller flere bilder.
3. Underbilde
   Et underbilde er informasjonen om at et bestemt bitmap skal tegnes på en bestemt plassering av et bilde under visse kriterier. Et bilde kan inneholde ett eller flere underbilder.

Deretter følger de individuelle animasjonsdefinisjonene.

Dataene til det øverste laget, animasjonen, er primært administrasjonsdata - Boundingbox refererer til koordinatene til markeringen rundt kjøretøyet/bygningen, når det er valgt, og indikerer samtidig hvilket område som skal være klikkbart.

Offsetet bestemmer primært "nullpunktet"; punktet som skal legges til eller trekkes fra i henhold til interne spillkoordinater. Man kan også si mer matematisk: offsetet betegner her koordinatsystemets opprinnelse.

Når det gjelder vinduene, er de, akkurat som offsetet, hver av dem (per vindu) 4 uint(32)-verdier, som angir et område som anses som brukbart for individuelle subrammer. Utenfor vinduene skal man ikke tegne, med mindre det er spesifisert for bitmapen.

Med dette kan vi nå sette sammen enkeltstående rammer, så vel som komplette animasjoner. Her demonstreres det med et eksempel på en mer kompleks animasjon, animasjonen med indeksen 500.

Animasjon 500 viser hvordan en Plymouth-fraktbil, som er lastet med vanlig malm, blir losset. Dette er en av de få animasjonene som bruker vindusfunksjonaliteten.

Og slik kan den komplette animasjonen settes sammen.
Dessverre er det fortsatt et problem med den øverste lasteluken, da det aktuelle bitet i grafikktypens informasjon ikke er satt.

Her er noen flere, vakkert animerte sprites fra spillet:

Nå mangler vi bare brukergrensesnittet til spillet, som har et børstet metall-utseende.

Men også her er det tydelig at Dynamix ikke måtte finne opp hjulet på nytt; her brukes ikke bare de enkle funksjonene fra User32- og GDI32-APIene som tilbys av Windows - spesielt benyttes også ressursstyringen fra User32.

Disse kan for eksempel ekstraheres ved hjelp av programmer som Resource Hacker, utviklet som freeware av Angus Johnson, eller - hvis man unngår å bruke Wine på Linux / Mac OS - ved hjelp av wrestool som er inkludert i icoutils.