Outpost 2 Bestandsformaten · bei.pm

De door Outpost 2 gebruikte gegevensformaten hebben een structuur die doet denken aan JFIF / PNG - de afzonderlijke datablokken hebben altijd een header van 8 bytes. Daarom laat ik het achterwege om de afzonderlijke headers op de bijbehorende specifieke plaatsen te documenteren en documenteer ik daar alleen afwijkingen.

Het formaat is altijd het volgende; de eigenlijke nuttige gegevens zijn daar dan in ingebed:

Volumes zijn een gegevenscontainer voor het spel, vergelijkbaar met een archiefformaat zoals bijvoorbeeld Tarball. In ieder geval kent het formaat in Outpost 2 alleen bestanden - geen mappen. Waarschijnlijk kunnen deze echter worden gesimuleerd door middel van de juiste bestandsnamen.

Een Volume bestaat uit de Volume-header en uit meerdere Volume-blokken die overeenkomen met de specifieke bestanden.

"Volumes" zijn de bestanden met de extensie 'vol' in de spelmap.

De Volume Header bevat op zijn beurt geen nuttige gegevens.
Hij dient alleen als container.

Als eerste gegevens in de Volume Header zouden de Volume Strings moeten staan; daarop volgen vervolgens de Volume-informatie.

De Volume Strings zijn een lijst van bestandsnamen die binnen het volume bevat zijn.

De volume-informatie bevat gedetailleerdere informatie over de bestanden. Het is in zekere zin een soort FAT-directory-invoer (FAT = File Allocation Table)

Het aantal bestanden wordt berekend door de blokgrootte te delen door de lengte van de directory-invoeren - 14 byte.

De individuele directory-invoeren hebben elk de volgende structuur:

Een volume-blok is een container die bestanden opslaat. Het bevat alleen nogmaals - vanwege het blokformaat - redundante informatie over de bestandsgrootte, en daarachter volgen direct de bruikbare gegevens.

De tiles zijn een specifiek Bitmap-grafiekformaat voor Outpost-2. Ze bestaan uit 13 tilesets, "wells" genoemd (well0000.bmp tot well0012.bmp), die zich binnen de volume maps.vol bevinden.

De tilesets / wells bevatten het volgende:

Het is raadzaam voor een accurate uitvoering om de tiles niet van tevoren te renderen om deze te cachen, omdat de gegevens voor de dag/nacht-cyclus nog verwerkt moeten worden - en er zouden zeer veel gegevens ontstaan.

De tiles zijn 8bpp-afbeeldingen met een geïndexeerde palet van elk 32x32 pixels resolutie, die onder elkaar zijn gerangschikt. In een dergelijk ontstaan tileset kunnen echter veel meer

De hoofdcontainer bestaat uit 2 secties: head en data.

Na deze gegevens volgt er nog een palettend bestand in het gestandaardiseerde RIFF-formaat. De exacte specificatie is te vinden - aangezien de paletten ook op andere plaatsen voorkomen - onder Paletten.

Eindelijk volgen hier de ruwe pixeld gegevens, van linksboven regel voor regel naar rechtsonder.
De dataverdienste van de in de regel als 8bpp-bitmaps weergegeven afbeeldingen komt overeen met de index van de kleur in de kleurenpalet.

De spel-engine tekent de tegels *waarschijnlijk* on-demand.
Dit lijkt onder andere te maken te hebben met de dag-nachtcyclus, die 32 gradaties van individuele tegels kent. Daarbij wordt blijkbaar van de helderheidswaarde telkens 'een beetje' afgetrokken. Nauwkeurige waarden zijn nog niet vastgesteld, ik werk op basis van de berekening

v *= (daylight / 48) + 0.25;

met de HSV-gegevens van de pixels, waarbij daylight een waarde van 0-31 is en v een waarde tussen 0-1. Bovendien moet in overweging worden genomen dat er op de kaart aan beide zijden nog een rand van 16 tegels bestaat (die dient voor het onzichtbaar spawnen van eenheden).

Aanvullend lijkt de dag-nachtcyclus per spelcyclus telkens slechts één kolom van de kaart bij te werken.
Een versnelde dag-nachtcyclus ziet er daarom als volgt uit:

Waarvoor PRT precies staat, is mij onbekend; het zou bijvoorbeeld 'Palette and Resource Table' kunnen zijn - aangezien dit bestand, te vinden als op2_art.prt in de maps.vol, zo'n tabel betreft, of dit zou de functie goed beschrijven.

Dit bestand bevat een lijst van paletten, een tabel van alle gebruikte bitmaps, alle animatiedefinities en nog een aantal onbekende gegevens. Het volgt de bestaande containerstructuur losjes, aangezien niet alle gegevens zich aan dit schema houden.

De CPAL-sectie (waarschijnlijk staat het voor Paletten-Container) omvat alleen de palettendata, door aan te geven hoeveel van de gebruikelijke 1052 byte grote 8-bits paletten aanwezig zijn.

De vermelding van 1052 bytes geldt niet als bindend, aangezien het palettenformaat potentieel verschillende paletgroottes zou kunnen bevatten. Het geldt alleen voor de dataset die met Outpost 2 wordt meegeleverd.

Na de palettenlijsten volgt direct en zonder inleidende kop, al de lijst van bitmaps; net zo direct volgen daarop de animatielijsten.
Beiden worden elk ingeleid met een uint(32) (of weer uint24+uint8 vlaggen?) die het aantal records bevat.

De palletinformatie is zeer eenvoudig te lezen.
Deze bestaat uit een header en een datasegment.

De datasectie bevat de afzonderlijke palletinvoer. Het aantal palletinvoer wordt berekend als de bloklengte / 4.

De afzonderlijke invoeren hebben de volgende eenvoudige structuur;

Wat de paletten betreft, is verder alleen nog te zeggen dat de volgende regels gelden voor paletten die voor animaties worden gebruikt:

• De eerste kleur is ALTIJD transparant, ongeacht welke waarde daar is opgegeven.
• De paletten-items 1-24 worden in de paletten 1-8 als spelerskleur beschouwd.
  Waar de kleuren buiten speler 1 precies vandaan komen, is mij onduidelijk.
  Ik vermoed dat de overige kleuren hardcoded zijn.

Deze datastructuur van het PRT-bestand geeft aan hoe de bitmapafbeeldingen die voor de sprites worden gebruikt zijn opgebouwd. Deze bitmaps dienen als afzonderlijke onderdelen, waarvan er meerdere worden samengevoegd tot een animatieframe van een sprite.

De specifieke afbeeldingsgegevens bevinden zich daarentegen in de op2_art.BMP in de spelmap.
Waarom dit bitmapbestand beschikt over een (overwegend correcte) RIFF-bitmapheader, is onduidelijk. Waarschijnlijk gebruikt Outpost 2 systeem-API's om de graphics te laden, door deze header tijdelijk over te nemen en de bijbehorende, variërende velden te overschrijven.

De pixelgegevens zijn in het BMP-bestand te vinden op de positie Offset + de uint32-offset, die in het BMP-bestand op adres 0x000A te vinden is (RIFF-bitmapgegevensoffset), en komen overeen met de regelmatige indeling van linksboven naar rechtsonder.

Monochrome 1bpp-graphics kunnen zo worden getekend, dat kleur 0 volledige transparantie heeft, terwijl kleur 1 een semi-transparant zwart/grijs is, aangezien de monochrome graphics doorgaans worden gebruikt voor voertuig- en gebouwschaduwen in de animaties.

Dit stelt je in staat om al veel graphics samen te stellen.

Nu komen we bij de koningsklasse van de disciplines binnen de Outpost 2 dataformaten:
De animaties.

De animatielijsten worden ingeleid met een globale header, die primair dient voor dataverificatie. Vervolgens volgen de specifieke animatiedefinities, die zijn onderverdeeld in 3 niveaus:

1. Animatie
   Een animatie is de hoogste instantie; het stelt een animatie van een eenheid, een gebouw of een 'deeltjesanimatie' (kometinslag, weer, explosie) in een bepaalde beginpositie voor.
2. Frame
   Een frame is een enkel beeld binnen een animatie. Een animatie kan één of meerdere frames bevatten.
3. Subframe
   Een subframe is de informatie dat een bepaalde bitmap onder bepaalde criteria op een specifieke positie van een frame moet worden getekend. Een frame kan één of meerdere subframes bevatten.

Vervolgens volgen direct de afzonderlijke animatiedefinities.

De gegevens van de bovenste laag, de animatie, zijn voornamelijk beheergegevens - de Boundingbox geeft de coördinaten van de markering rondom het voertuig/gebouw aan, wanneer deze is geselecteerd en geeft tegelijkertijd aan welk gebied aanklikbaar moet zijn.

De offset bepaalt voornamelijk het "nulpunt"; het punt dat op de interne spelcoördinaten moet worden opgeteld of afgetrokken. Men zou ook wiskundig kunnen zeggen: de offset verwijst hier naar de coördinaten oorsprong.

De vensters bevatten, net als de offset, elk (per venster) 4 uint(32)-waarden, die een gebied aangeven dat voor individuele subframes als bruikbaar geldt. Buiten de vensters mag, voor zover dit voor de bitmap is voorzien, niet worden getekend.

Zo kunnen we nu individuele frames evenals complete animaties samenstellen, hier exemplaarmatig gedemonstreerd aan een complexere animatie, de animatie met index 500.

Animatie 500 laat zien hoe een Plymouth-vrachtwagen, die geladen is met gewone ertsen, wordt gelost. Dit is een van de weinige animaties die de vensterfunctionaliteit benut.

En zo kan de complete animatie worden samengevoegd.
Helaas is er nog een probleem met het bovenste laadluik, omdat hier de bijbehorende bit in de grafiektype-informatie niet is ingesteld.

Hier zijn nog een paar andere prachtig geanimeerde sprites uit het spel:

Nu ontbreekt alleen nog de gebruikersinterface van het spel, die in een geborsteld metaal uiterlijk is uitgevoerd.

Maar ook hier is te zien dat Dynamix het wiel niet opnieuw hoefde uit te vinden; hier worden niet alleen eenvoudig de door Windows geleverde User32- en GDI32-API's gebruikt - vooral wordt ook het resourcebeheer van User32 toegepast.

Dit kan bijvoorbeeld worden geëxtraheerd met programma's zoals de door Angus Johnson als freeware ontwikkelde Resource Hacker, of - als je onder Linux / Mac OS het gebruik van Wine vermijdt - met behulp van de in icoutils opgenomen wrestool.