Outpost 2 Filformat · bei.pm

Dataformata som vert nytta av Outpost 2 har ei struktur som minner om JFIF / PNG - dei enkelte datablocka har alltid ein 8-byte header. Derfor vel eg å ikkje dokumentere dei enkelte headera på dei spesifikke plassane, men dokumenterer berre avvik.

Formatet er alltid det same; dei eigentlege nyttedataene er så innbakt i det:

Volumene er ein datakontainer for spelet, liknande eit arkivformat som til dømes Tarball. I alle fall i Outpost 2 kjenner formatet berre til filer - ingen mapper. Det er truleg mogleg å simulere desse gjennom tilsvarande filnamn.

Eit volum består av volumoverskrifta samt fleire volumblokker som tilsvarar dei konkrete filene.

"Volumer" er filene med ending 'vol' i spelemappa.

Volume-headeret inneheld ikkje noko brukardata.
Det fungerar berre som ein container.

Det første elementet i volume-headeret bør vere volume-strengane; deretter følgjer volume-informasjonen.

Volumetekstane er ei liste over filnamn som er innehalde i volumet.

Voluminformasjonen inneheld meir detaljerte opplysningar om filene. Dette er på ein måte ein slags FAT-katalogpost (FAT = File Allocation Table).

Antalet filer kjem fram ved å dele blokkerstørrelsen med lengda på katalogpostane - 14 byte.

Dei enkelte katalogpostane har følgjande oppbygging:

Eit volumeblock er ein container som tar imot filer. Han inneheld berre ein gong - på grunn av blokkformatet - redudant filstorleiken, og deretter følgjer direkte nytteopplysningane.

Tilane er eit spesifikt Bitmap-grafikkformat for Outpost-2. Dei strekkjer seg over 13 tilesets, kalla "wells" (well0000.bmp til well0012.bmp), som ligg innanfor voluma maps.vol.

Tilane / Wells inneheld følgjande:

Det er tilrådd for ei nøyaktig gjennomføring å ikkje rendere flisene på førehand for å cache dei, då dataene for dag/natt-syklusen må bearbeidast - og det ville oppstå svært, svært mange data.

Flisene er 8bpp-grafikk med indeksert palett med ei oppløysing på 32x32 pikslar, som er ordna i rekkjer. I eit slik oppstått flisesett kan det imidlertid vere langt fleire

Hovud-containeren består av 2 seksjonar: head og data.

Etter desse opplysningane følgjer det ei palettfil i det standardiserte RIFF-formatet. Den nøyaktige spesifikasjonen finn ein - sidan palettane også dukkar opp andre stader - under Palettane.

Til slutt følger dei reine pixeldata, frå venstre-øvre hjørne radvis til høgre-nedre hjørne.
Dataverdien i grafikane som som regel er i 8bpp-bitmaps, tilsvarar indeksen til fargen i fargepaletten.

Spillmotoren teiknar brikkene *sannsynlegvis* på etterspørsel.
Dette ser ut til å vere knytt til dag-kveld-syklusen, som har 32 nivå av individuelle brikker. Det ser ut til at det vert trekt 'litt' frå lysverdien. Nøyaktige verdiar har enno ikkje blitt fastsett, eg arbeider på grunnlag av berekninga

v *= (daylight / 48) + 0.25;

med HSV-dataene til pikselane, der daylight er ein verdi frå 0-31 og v er ein verdi mellom 0-1. Det må også takast med i vurderinga at det på kartet er ein kant på 16 brikker til venstre og høgre (denne vert brukt til usynleg spawning av einingar).

I tillegg ser det ut til at dag-kveld-syklusen oppdaterer berre ein kolonne av kartet per spel-syklus.
Eit akselerert dag-kveld-syklus ser difor slik ut:

Kva PRT står for er meg ikkje kjent; det kan til dømes vere 'Palette and Resource Table' - då dette er ei fil - å finne som op2_art.prt i maps.vol - som handlar om dette, eller dette ville godt beskrive funksjonen.

Denne fila inneheld ei liste over palettar, ei tabell over alle brukte bitmap-bilete, alle animasjonsdefinisjonar og ei rekkje ukjente data. Den følgjer det tidlegare containerformatet laust, sidan ikkje alle datapostar følgjer dette skjemaet.

CPAL-seksjonen (som sannsynlegvis står for palettcontainer) omfatar berre palettdata, ved å angi kor mange av dei vanlegvis 1052 byte store 8-bit palettane som finst.

1052-byte spesifikasjonen er ikkje bindande, då palettformatet potensielt kan ha ulike palettstorleikar. Den gjeld berre for datainnhaldet som Outpost 2 blir levert med.

Etter palettlistene følgjer umiddelbart, utan innleiande header, lista over bitmap-bilete; på same måte følgjer animasjonslistene umiddelbart etter.
Begge blir innleia med ein uint(32) (eller igjen uint24+uint8 flagg?) som inneheld talet på datapostar.

Informasjonen om pallane er veldig enkel å lese.
Den består av ein header og eit datasegment.

Data-seksjonen registrerer dei enkelte palletteinlegg. Antallet av palletteinlegg kjem av blokk-lengda / 4.

Dei enkelte innlegga har ein enkel oppbygging som følgjer;

Når det gjeld palettane, er det ellers å seie at for palettar som skal brukast til animasjonar, gjeld følgjande reglar:

• Den første fargen er ALLTID transparent, uansett kva verdi som er oppgitt der.
• Palett-postane 1-24 vert rekna som spelarfarge i palettane 1-8.
  Kor fargane utanom spelar 1 kjem frå, er meg uvisst.
  Jeg mistenker at dei resterande fargane er hardkodet.

Denne datastrukturen i PRT-filen angir korleis bitmapane som vert brukte for spritane er oppbygd. Desse bitmapane fungerer som enkeltkomponentar, der fleire vert sett saman til ein animasjonsramme for ein sprite.

Dei konkrete bileta finst i op2_art.BMP i spelkatalogen.
Kvifor denne bitmapfilen har ein (for det meste korrekt) RIFF-bitmapheader, er uklart. Sannsynlegvis bruker Outpost 2 system-API-ar for å laste grafikk, ved å ta denne headeren midlertidig og overskrive dei tilsvarande, variande felta.

Pixeldata er plassert i BMP-filen på Offset + uint32-offsetet, som kan finnast i BMP-filen på adresse 0x000A (RIFF-bitmap-dataoffset), og svarar igjen til radvis ordning frå øvst til venstre til nedst til høgre.

Monokrome 1bpp-grafikk kan teiknast slik at farge 0 er fullstendig transparent, medan farge 1 er halvtransparent svart/grå, sidan monokrom-grafikk vanlegvis vert brukt til skuggar for køyretøy og bygningar i animasjonane.

Dersom ein kan sette saman mange grafikkar på denne måten.

no kjem vi til kongeklassen av disiplinar innan Outpost 2 dataformata:
Animasjonane.

Animationslistene blir innleidd med ein global header, som primært er til for dataverifikasjon. Deretter følgjer dei konkrete animasjonsdefinisjonane, som er delt inn i 3 nivå:

1. Animajon
   Ein animasjon er den øvste instansen; ho representerer animasjonen av ein eining, ein bygning eller ein 'partikkel-animasjon' (kometnedslag, vêr, eksplosjon) i ein bestemt utgangspunkt.
2. Frame
   Ein frame er eit enkelt bilete innanfor ei animasjon. Ei animasjon kan innehalde ein eller fleire frames.
3. Subframe
   Ein subframe er informasjon om at ei bestemt bitmap skal teiknast på ein bestemt posisjon i eit frame under bestemte kriterium. Eit frame kan innehalde ein eller fleire subframes.

Deretter følgjer dei enkelte animasjonsdefinisjonane direkte.

Dataene til det øvste laget, animasjonen, er først og fremst forvaltningsdata - Boundingbox refererer til koordinatane til merkedomenet rundt kjøretøyet/bygningen, når det er valt, og indikerer også samtidig kva område som skal være klikkbart.

Offsetet bestemmer først og fremst "nullpunktet"; punktet som skal leggjast til eller trekkast frå spelintern koordinatar. Man kan også seie matematisk at offsetet her refererer til koordinatorigins.

Vindauga består, akkurat som offsetet, av 4 uint(32)-verdier per vindauge, som angir eit område som er brukbart for enkelt subrammer. Utenfor vindauga skal det, så lenge det er tiltenkt for bitmapen, ikkje teiknast.

Med dette kan vi no sette saman enkeltbilde og heile animasjonar i samsvar, her demonstrert med eit meir komplisert eksempel, animasjonen med indeks 500.

Animasjon 500 viser korleis ein Plymouth-transportar, lasta med vanleg malm, blir lossa. Dette er ein av dei få animasjonane som nyttar vindusfunksjonaliteten.

Og slik kan heile animasjonen setjast saman.
Dessverre er det eit problem med den øvste lasteluka, sidan det aktuelle bitet i grafikktypa-informasjonen ikkje er sett.

Her er nokre fleire, vakkert animerte sprites frå spelet:

Når brukergrensesnittet til spelet manglar, er det halde i ein børsta metall-look.

Men også her er det tydeleg at Dynamix ikkje måtte oppfinne hjulet på nytt; her blir ikkje berre dei enkle funksjonane frå Windows sine User32- og GDI32-APIar nytta - spesielt blir også ressursforvaltninga frå User32 brukt.

Desse kan ein for eksempel hente ut ved hjelp av program som det frie programmet Resource Hacker, utvikla av Angus Johnson, eller - dersom ein er skeptisk til å bruke Wine under Linux / Mac OS - ved hjelp av wrestool som er inkludert i icoutils.