Outpost 2 Lêerformate · bei.pm

Die dataformate wat deur Outpost 2 gebruik word, het 'n struktuur wat herinner aan JFIF / PNG - die individuele datablokke het altyd 'n 8 Byte kop. Daarom spaar ek myself die moeite om die individuele koppe op die spesifieke plekke te dokumenteer en dokumenteer ek slegs afwykings daar.

Die formaat is altyd die volgende; die werklike nuttige data is dan daarin ingebed:

Volumes is 'n datakonteiner vir die spel, soortgelyk aan 'n argiefformaat soos byvoorbeeld Tarball. In Outpost 2 ken die formaat egter net lêers - geen vouers nie. Waarskynlik kan hierdie egter deur middel van toepaslike lêernaam gesimuleer word.

'Een Volume bestaan uit die Volume-koptekst sowel as verskeie Volume-blokke wat die spesifieke lêers verteenwoordig.

"Volumes" is die lêers met die uitbreiding 'vol' in die spelgids.

Die Volume-header bevat op sy beurt geen gebruikersdata nie.
Dit dien slegs as 'n houer.

As eerste data in die Volume-header behoort die Volume-stringe te wees; gevolg deur die Volume-inligting.

Die Volume Strings is 'n lys van lêernommers wat binne die volume ingesluit is.

Die Volume-inligting neem meer gedetailleerde inligting oor die lêers op. Dit is op 'n sekere manier 'n tipe FAT-gidsinskrywing (FAT = File Allocation Table)

Die aantal lêers spruit voort uit die blokgrootte gedeel deur die lengte van die gidsinskrywing - 14 Byte.

Die individuele gidsinskrywings het elk die volgende struktuur:

'n Volume-blok is 'n houer wat lêers opneem. Dit bevat net weer - weens die blokformaat - die lêergrootte op 'n redundante manier, en daarna volg die nutdata direk.

Die tegels is 'n Outpost-2-spesifieke bitmap-grafiekformaat. Hulle strek oor 13 tegelstelle, ""wells"" genoem (well0000.bmp tot well0012.bmp), wat binne die volume maps.vol geleë is.

Die tegelstelle / Wells bevat die volgende:

Dit is raadsaam om die teëls nie vooraf te render om dit te kas te maak nie, aangesien die data vir die dag/nag siklus nog verwerk moet word - en daar sou baie, baie data ontstaan.

Die teëls is 8bpp grafika met 'n geïndekseerde palet van 32x32 pixels resolusie, wat in 'n rooster georganiseer is. In 'n so gevormde teëls stel kan egter baie meer wees.

Die hoofhouer bestaan uit 2 afdelings: head en data.

Na hierdie inligting volg daar nog 'n paletlêer wat in die gestandaardiseerde RIFF-formaat beskikbaar is. Die presiese spesifikasie kan gevind word - aangesien die palette ook elders verskyn - onder Palet.

Uiteindelik volg die blote pixeldata, van links-bo na regs-benede in rye.
Die datavalue van die grafika, wat gewoonlik as 8bpp-bitmaps voorkom, stem ooreen met die indeks van die kleur in die kleurskaal.

Die spel-enjin teken die teëls *waarskynlik* op aanvraag.
Dit blyk onder andere te wees as gevolg van die dag-nag siklus, wat 32 gradasie van individuele teëls het. Daar word blykbaar 'n bietjie van die helderheidswaarde afgetrek. Presiese waardes kon nog nie bepaal word nie, ek werk op die berekeningsgrondslag

v *= (daylight / 48) + 0.25;

met die HSV-data van die pixels, terwyl daylight 'n waarde van 0-31 is en v 'n waarde tussen 0-1. Boonop moet daar in ag geneem word dat daar op die kaart 'n rand van 16 teëls aan die linkerkant en regterkant is (dit dien om eenhede onsigbaar te laat spawne).

Daarbenewens blyk die dag-nag siklus per speletjie-kik net een kolom van die kaart te werk.
‘n Versnelde dag-nag siklus lyk dus soos volg:

Waartoe PRT presies staan, is vir my nie bekend nie; dit sou moontlik 'Palette and Ressource Table' kan wees - aangesien hierdie lêer - gevind as op2_art.prt in die maps.vol - 'n sulke is, of dit die funksie heel goed sou beskryf.

Diese lêer bevat 'n lys van paletten, 'n tabel oor al die gebruikte bitmapte, al die animasiedefinisies en nog 'n reeks onbekende data. Dit volg die vorige houerformaat losweg, aangesien nie al die datastelle hierdie skema volg nie.

Die CPAL-seksie (waarskynlik vir palet-houer) sluit slegs die paletdata in deur aan te dui hoeveel van die gewoonlik 1052-byte groot 8-bits paletten teenwoordig is.

Die 1052-byte-aanduiding word nie as bindend beskou nie, aangesien die paletformaat potensieel verskillende paletgroottes kan hê. Dit geld slegs vir die databasis waarmee Outpost 2 afgelewer word.

Na die paletlys volg onmiddellik en sonder 'n inleidende kop, reeds die lys van bitmaps; sowel as onmiddellik daaropvolgend die animasielyste.
Albei word elk met 'n uint(32) (of weer uint24+uint8 vlae?) ingelei, wat die aantal datastelle bevat.

Die palet-inligting is baie maklik om te lees.
Hulle bestaan uit 'n kopstuk en 'n data-segment.

Die dataseksie neem die individuele paletinskrywings op. Die aantal paletinskrywings is gebaseer op die bloklengte / 4.

Die individueleinskrywings het die volgende eenvoudige struktuur;

Wat die palet aanbetref, is daar verder net te sê dat die volgende reëls van toepassing is op palet wat vir animasies gebruik word:

• Die eerste kleur is ALTYD deurskynend, maak nie saak watter waarde daar aangedui word nie.
• Die paletinskrywings 1-24 tel as spelerkleur in die palet 1-8.
  Hoe die kleure, behalwe vir speler 1, presies verkry word, is vir my onduidelik.
  Ek vermoed dat die oorblywende kleure hardcoded is.

Diese Datenstruktur der PRT-Datei geeu die hoe die vir die sprites gebruikte bitmaps gebou is. Hierdie bitmaps dien as 'n enkele komponent, waarvan verskeie saamgestel word tot 'n animasiekader van 'n sprite.

Die konkrete beelddata versteek egter in die op2_art.BMP in die speletjie-gids.
Waarom hierdie bitmaplêer 'n (meestal korrekte) RIFF-bitmapkop het, is onduidelik. Waarskynlik gebruik Outpost 2 stelsels-API's om die grafika te laai, deur hierdie kop tydelik oorgeneem te word en die ooreenstemmende, wisselende velde te oorskryf.

Die pixeldata is in die BMP-lêer op die posisie Offset + die uint32-offset, dit wat in die BMP-lêer op adres 0x000A te vind is (RIFF-bitmap-data-offset), te vind - en stem weer ooreen met die rygewys rangskikking van bo links na regs onder.

Monochrome 1bpp-grafika kan so geteken word, dat kleur 0 volle deursigtigheid is, sowel as kleur 1 'n semi-deursigtige swart/grys is, omdat die monochroom-grafika gewoonlik vir voertuig- en geboueskaduwees in die animasies gebruik word.

Dit maak dit moontlik om reeds baie grafika saam te stel.

Kom ons kom by die koninklike klas van dissiplines binne die Outpost 2 dataformate:
Die animasies.

Die animasielyste begin met 'n globale kop wat primêr vir dataverifikasie dien. Daarop volg die konkrete animasiedefinisies wat in 3 vlakke verdeel is:

1. Animatie
   'n Animatie is die hoogste instansie; dit stel 'n animasie van 'n eenheid, 'n gebou of 'n 'partikel-animasie' (kometebotsing, weer, ontploffing) in 'n bepaalde uitgangstoestand voor.
2. Raam
   'n Raam is 'n enkele beeld binne 'n animasie. 'n Animasie kan een of meer rame bevat.
3. Subraam
   'n Subraam is die inligting dat 'n bepaalde bitmap onder bepaalde kriteria op 'n bepaalde posisie van 'n raam geteken moet word. 'n Raam kan een of meer subrame bevat.

Daarna volg die individuele animasiedefinisies onmiddellik.

Die data van die boonste laag, die animasie, is hoofsaaklik bestuursdata - die Boundingbox dui die koördinate van die merk rondom die voertuig/gebou aan, as dit gekies is en dui ook terselfdertyd aan watter area klikbaar moet wees.

Die offset bepaal hoofsaaklik die "nulpunt"; die punt wat op spelinterne koördinate bygevoeg of afgetrek moet word. Mens kan ook wiskundig sê: die offset dui hier die koördinaat oorsprong aan.

Die windows is, net soos die offset, elk (per window) 4 uint(32)-waardes, wat 'n area aandui wat as bruikbaar vir individuele subframes beskou word. Buite die windows mag, sover dit vir die bitmap ooreenkomstig bedoel is, nie geteken word nie.

Hiermee kan ons nou individuele rame sowel as volledige animasies saamstel, hier een keer as 'n voorbeeld aan 'n meer komplekse animasie, die animasie met die indeks 500, demonstreer

Animasie 500 toon hoe 'n Plymouth-vragmotor, wat met gewone ertse laai, afgelaai word. Dit is een van die min animasies wat die Windowing-funksionaliteit gebruik.

En so kan die volledige animasie saamgestel word.
Helaas is daar steeds 'n probleem met die boonste laai-opening, aangesien die toepaslike bit in die grafiektipe-inligting nie gestel is nie.

Hier is nog 'n paar ander, pragtig geanimeerde sprites uit die speletjie:

Nou ontbreek nog die gebruikerskoppelvlak van die speletjie, wat in 'n geborstelde metaal-voorkoms uitgevoer is.

Maar ook hier is dit duidelik dat Dynamix nie die wiel weer moes uitvind nie; hier word nie net eenvoudig die User32- en GDI32-API's wat deur Windows verskaf word, gebruik nie - veral word ook die hulpbronnebestuur van User32 benut.

Dit kan byvoorbeeld deur programme soos die deur Angus Johnson as gratis sagteware ontwikkelde Resource Hacker of - as jy huiwer om Wine op Linux / Mac OS te gebruik - met die hulp van die in icoutils ingeslote wrestool onttrek word.