Outpost 2 Dateiformater · bei.pm
déi Dateiformater, déi op dëser Säit beschriwwe sinn, baséieren op der technescher Analyse vum geistegen Eegentum vun Dynamix, Inc. an Sierra Entertainment.
D'geistegt Eegentum ass Haut Deel vun der Activision Publishing, Inc.- / Activision Blizzard, Inc.-Masse an ass zur Zäit am Besëtz vun Microsoft Corp..
D'Informatioune goufen duerch Reverse Engineering an Datenanalyse fir d'Archivéierung an d'Interoperabilitéit mat historesche Date gesammelt.
Et goufen keng proprietär oder vertrauléch Spezifikatiounen benotzt.
D'Spill kann zur Zäit op gog.com als Download kaaft ginn.
Konschtwierk vum Spill
déi folgend Artikel-Reihe dokumentéiert meng Erkenntnisser zu den Dateiformater am Echtzäit-Strategie-Spill "Outpost 2: Divided Destiny", dat 1997 vun Sierra verëffentlecht an vun Dynamix entwéckelt gouf.
Ich hunn mech vum 01. November 2015 bis den 14. November 2015 haaptsächlech mat der Analyse vun den Daten vum Spill - an wat een domat ufangen kann - beschäftegt.
Den Informatiounen, déi ech bis elo konnt sammelen, no huet Dynamix - wéi esou vill kommerziell Entreprisen - e puer Dateiformater net speziell fir Outpost 2 entwéckelt, mee och an aneren Entwécklungen wéi zum Beispill der Mechwarrior-Serie (ofgewandelt) benotzt.
Ouni dat ze vergiessen, kann een och feststellen, dass d'Innovatiouns-Kraaft vun de Dateiformater praktesch an Grenzen hält an dacks op méi laang bestehend Konzepter aus übleche Formater wéi JFIF an RIFF opgebaut gëtt.
Fir d'Interpretatioun vun den Tabellen a Dateiformater sinn weider Informatiounen ënner Wat ass wat? verfügbar.
Die hei ugebueden Daten sinn allgemeng als Little Endian ze verstoen.
Zum Schluss kann een soen, dass d'Reverse Engineering vill Spaass gemaach huet, och wann et net komplett ass.
Natierlech kann ech och nëmmen recommandéieren, d’Spill selwer ze spillen, well et interessant Spillmechaniken bitt.
Aféierung
déi von Outpost 2 benotzten Datenformate hunn eng Struktur, déi un JFIF / PNG erënnert - d'eenzel Datenblocken hunn ëmmer eng 8 Byte Header. Dofir spueren ech mir d'Dokumentatioun vun den eenzelne Headeren an de entspriechende spezifesche Plazen an dokumentéieren do just d'Ausnam.
D'Format ass ëmmer dat folgend; d'echent Nutzdaten sinn dann doran agebett:
| Adr | x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | xA | xB | xC | xD | xE | xF | char | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x0000 | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| Offset | Datentyp | Bezeechnung | Erklärung |
|---|---|---|---|
| 0x0000 | uint(32) | Magic Bytes | Enthält d'Informatiounen, wat am nächste Datenblock ze erwaarden ass. Bekannt Wäerter:
|
| 0x0004 | uint(24) | Block-Längt | Enthält d'Informatioun wéi grouss (an Byte) de folgende Datenblock ass. D'reine Nutzdaten sinn hei gemengt - déi 8 Header-Byte sinn doran net enthalen. |
| 0x0007 | uint(8) | Fändel? | Et ass onbekannt, fir wat dësen Block genau gedéngt. An de Volumen ass dëse Wäert oft 0x80, an aneren Dateien oft 0x00. Dat léisst d'Schlëssel ze, datt et sech ëm e Flag-Set handelt. |
Volume
Bei den Volumen handelt et sich ëm e Datencontainer fir d'Spill, ähnlech wéi e Archivformat wéi z.B. Tarball. Zumindest an Outpost 2 kann dat Format just Dateien - keng Fieder - erkennen. Wahrscheinlech kéinten dës awer iwwer entspriechend Dateinimmere simuléiert ginn.
E Volume besteet aus dem Volume-Header souwéi aus verschiddene Volume Blokker, déi den konkret Dateien entspriechen.
"Volumes" sinn d'Dateien mat der Endung 'vol' am Spillverzeechnes.
| Adr | x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | xA | xB | xC | xD | xE | xF | char | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x0000 | 56 | 4f | 4c | 20 | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | V | O | L | . | . | . | . | . | . | . | . | . | . | . | . | |
| Offset | Datentyp | Bezeechnung | Erklärung |
|---|---|---|---|
| 0x0000 | uint(32) | Magic Bytes | |
| 0x0004 | uint(24) | Block-Längt | |
| 0x0007 | uint(8) | Fändelen |
Volume Header
| Adr | x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | xA | xB | xC | xD | xE | xF | char | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x0000 | 76 | 6f | 6c | 68 | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | v | o | l | h | . | . | . | . | . | . | . | . | . | . | . | . |
| Offset | Datentyp | Bezeechnung | Erklärung |
|---|---|---|---|
| 0x0000 | uint(32) | Magic Bytes | |
| 0x0004 | uint(24) | Block-Längt | |
| 0x0007 | uint(8) | Fändelen |
De Volume Header enthält selwer keng Nutzdaten.
Hien déngt nëmmen als Container.
Als éischt Datum am Volume Header sollten déi Volume Strings sinn; dorop follegen dann d'Volume-Informatiounen.
Volumensträng
| Adr | x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | xA | xB | xC | xD | xE | xF | char | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x0000 | 76 | 6f | 6c | 69 | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | v | o | l | i | . | . | . | . | . | . | . | . | . | . | . | . |
| Offset | Datentyp | Bezeechnung | Erklärung |
|---|---|---|---|
| 0x0000 | uint(32) | Magic Bytes | |
| 0x0004 | uint(24) | Block-Längt | |
| 0x0007 | uint(8) | Fändelen |
| Adr | x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | xA | xB | xC | xD | xE | xF | char | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x0000 | 76 | 6f | 6c | 73 | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | v | o | l | s | . | . | . | . | . | . | . | . | . | . | . | . |
| Offset | Datentyp | Bezeechnung | Erklärung |
|---|---|---|---|
| 0x0000 | uint(32) | Magic Bytes | |
| 0x0004 | uint(24) | Block-Längt | |
| 0x0007 | uint(8) | Fändelen | |
| 0x0008 | uint(32) | Payload-Längt | Gitt un, wéi vill Bytes vun de folgende Daten tatsächlech Nutzdaten sinn. D'rescht, déi verbléift Daten an der Volume-Strings-Lëscht sinn offenbar als garbage z'ënnerstëtzen. An Dateien mat méi spéit Datum sinn dës 'verbleibend Daten' 0x00, wat op Mängel mat der Toolchain während der Entwécklung vum Spill hinweisen kéint, mengt, datt sich éischter ganz spéit eent Entwéckler ëm d'korrekt Initialiséierung vun de Buffer gekëmmert huet, well et keen Afloss op d'Spill huet, ob d'Daten initialiséiert sinn oder net. |
| 0x000c | uint(8)[] | Dateinumm-Lëscht | Hei ass et eng 0-Byte-terminéiert Lëscht vu Dateinimm, déi - op d'mannst am presenteierte Datenbestand - just ASCII-Zeichen erwaart. Et ass net néideg, beim Parsen vun den Daten dësen Datenblock méi genee ze bewäerten, well an den Volume-Informatiounen de facto d'Offsets vun den Dateinimm direkt referenzéiert ginn. |
Bei de Volume Strings ass et eng Lëscht vun Dateinimm déi am Volume enthalen sinn.
Volumen Informatiounen
| Adr | x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | xA | xB | xC | xD | xE | xF | char | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x0000 | 76 | 6f | 6c | 69 | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | v | o | l | i | . | . | . | . | . | . | . | . | . | . | . | . |
| Offset | Datentyp | Bezeechnung | Erklärung |
|---|---|---|---|
| 0x0000 | uint(32) | Magic Bytes | |
| 0x0004 | uint(24) | Block-Längt | |
| 0x0007 | uint(8) | Fändelen |
déi Volumen-Informatiounen enthalen méi detailléiert Informatiounen iwwer d'Dateien. Et ass esou eng Aart FAT-Verzeechnesäintrag (FAT = File Allocation Table).
Die Zuel vun den Dateien ergëtt sech aus der Blockgréisst dividéiert duerch d'Längt vun de Verzeechnesäinträgen - 14 Byte.
Die eenzelne Verzeechnesäinträgen hunn all folgend Struktur:
| Adr | x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | xA | xB | xC | xD | xE | xF | char | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x0000 | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| Offset | Datentyp | Bezeechnung | Erklärung |
|---|---|---|---|
| 0x0000 | uint(32) | Dateinumm-Offset | Gëtt un, an wéi engem Offset (!) an der Dateinummelëscht (Volume-Strings) de Numm vun der Datei fonnt gëtt. Hëlt Bezug op de Start vum Nutzdatenblock. |
| 0x0004 | uint(32) | Datei-Offset | Gitt un, op wéi engem Offset bannent der ganzer Volume-Datei d'Datei sech befënnt. |
| 0x0008 | uint(32) | Dateigréisst | Gëtt an, wéi grouss d'Datei an Byte ass. |
| 0x000c | uint(16) | Fändel? | Gëtt anscheinend zousätzlech Informatiounen iwwer d'Dateikodéierung un.
|
Volume Block
| Adr | x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | xA | xB | xC | xD | xE | xF | char | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x0000 | 56 | 42 | 4c | 48 | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | V | B | L | H | . | . | . | . | . | . | . | . | . | . | . | . |
| Offset | Datentyp | Bezeechnung | Erklärung |
|---|---|---|---|
| 0x0000 | uint(32) | Magic Bytes | |
| 0x0004 | uint(24) | Block-Längt | |
| 0x0007 | uint(8) | Fändelen |
Eng Volume-Block ass e Container, deen Dateien opnimmt. Hien enthält nëmmen eng kierz - wéinst dem Blockformat - redundant d'Dateigréisst an nom de folgend direkt d'Nutzdaten.
Kachelen
| Adr | x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | xA | xB | xC | xD | xE | xF | char | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x0000 | 50 | 42 | 4d | 50 | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | P | B | M | P | . | . | . | . | . | . | . | . | . | . | . | . |
| Offset | Datentyp | Bezeechnung | Erklärung |
|---|---|---|---|
| 0x0000 | uint(32) | Zauber Bytes | |
| 0x0004 | uint(24) | Block-Längt | |
| 0x0007 | uint(8) | Fändelen |
D'Tiles sinn e spezifesch Bitmap-Grafikformat fir Outpost-2. Si dehnen sech iwwer 13 Tilesets, genannt "wells" (well0000.bmp bis well0012.bmp), déi am Volume maps.vol sinn.
Déi Tilesets / Wells enthalen folgendes:
| Dateiname | Inhalt |
|---|---|
| well0000.bmp | Eng 32x32px grouss, blo Grafik - idéal als Test, ob de perséinleche Image-Loader funktionéiert |
| well0001.bmp | Enthält hell Gestein, Gebirgszich op hellem Gestein an onzuelbar Variantë vun Einschlagskrateren am helle Gestein |
| well0002.bmp | Enthält hell-Gestein-'Doodads' - also Elemente, déi zur Auflockerung (oder bewosst als Struktur, wéi z.B. Maueren) op hellem Gestein placéiert kënne ginn, dorënner och Vegetatioun |
| well0003.bmp | Enthält eng krustenaart Struktur op hellem Gestein |
| well0004.bmp | Enthält dunkles Gestein, Gebirgszich op dunklem Gestein an onzuelbar Variantë vun Einschlagskrateren am dunkle Gestein |
| well0005.bmp | Enthält dunkles-Gestein-'Doodads' - also Elemente, déi zur Auflockerung (oder bewosst als Struktur, wéi z.B. Maueren) op dunklem Gestein placéiert kënne ginn |
| well0006.bmp | Enthält eng krustenaart Struktur op dunklem Gestein, souwéi Iwwergäng tëscht hellem a dunklem Gestein |
| well0007.bmp | Enthält Lava inklusiv jee 4-5 Frames Animatioun dovun |
| well0008.bmp | Enthält Sand an onzuelbar Variantë vun Einschlagskrateren am Sand |
| well0009.bmp | Enthält Sand-'Doodads' - also Elemente, déi zur Auflockerung (oder bewosst als Struktur, wéi z.B. Maueren) op Sand placéiert kënne ginn |
| well0010.bmp | Enthält jee 48 Iwwergäng vum Sand zu hellem a dunklem Gestein |
| well0011.bmp | Enthält d'Polarkappen vun der Map, mat dunklem Gestein als Ënnergrond |
| well0012.bmp | Enthält d'Polarkappen vun der Map, mat hellem Gestein als Ënnergrond |
Ech recommandéieren, fir eng präzis Umsetzung, d'Tiles net am Viraus ze renderen fir se ze cachen, well d'Daten fir den Dag/Nuecht-Zyklus nach veraarbecht mussen ginn - an et géif vill vill Daten entstoen.
D'Tiles sinn 8bpp-Grafiken mat indexéierter Palette vun 32x32 Pixel Rescht, déi an engem Raster ugestallt sinn. An engem esou entstane Tileset kënnen awer vill méi
D'Haupt-Container besteet aus 2 Sektiounen: head an data.
Placke Kapp
| Adr | x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | xA | xB | xC | xD | xE | xF | char | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x0000 | 68 | 65 | 61 | 64 | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | h | e | a | d | . | . | . | . | . | . | . | . | . | . | . | . |
| 0x0010 | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| Offset | Datentyp | Bezeechnung | Erklärung |
|---|---|---|---|
| 0x0000 | uint(32) | Zauber Bytes | |
| 0x0004 | uint(24) | Block-Längt | |
| 0x0007 | uint(8) | Fändelen | |
| 0x0008 | uint(32) | Versioun / Fändel? | Hei kéint et sech ëm eng Versiounsangabe vum Dateiformat handelen; an allen Dateien, déi mir zur Verfügung stinn, war hei de Wäert |
| 0x000c | uint(32) | Breit (Horisontale Resolutioun) | Gitt un, wéi breet d'Bilddatei ass (an Pixel). Bei allen Wells vum Outpost 2 wäert hei den Wäert |
| 0x0010 | uint(32) | Héicht (Vertikaler Resolutioun) | Gitt un, wéi héich d'Bilddatei ass (an Pixel). Bei allen Wells vum Outpost 2 wäert hei den Wäert |
| 0x0014 | uint(32) | Faarftiefe? | De Bedeitung vun dësem Wäert ass onbekannt. Well en an allen getesteten Dateien den Wäert |
| 0x0018 | uint(32) | Farbtiefe 2? | Die Bedeitung vun dësem Wäert ass onbekannt. Et kéint sech ëm eng 'Zil'-Faarfdeif sinn. |
Nach dësen Informatioune gëtt et nach eng Palettendatei am standardiséierte RIFF-Format. D'genau Spezifikatioun fannt dir - well d'Paletten och an anere Plazen ervirkommen - ënner Paletten.
Fliesen Daten
| Adr | x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | xA | xB | xC | xD | xE | xF | char | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x0000 | 64 | 61 | 74 | 61 | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | d | a | t | a | . | . | . | . | . | . | . | . | . | . | . | . |
| Offset | Datentyp | Bezeechnung | Erklärung |
|---|---|---|---|
| 0x0000 | uint(32) | Zauber Bytes | |
| 0x0004 | uint(24) | Block-Längt | |
| 0x0007 | uint(8) | Fändelen |
Schlussendlech follegen déi blanke Pixeldaten, vun lénks-uewen ze reihenweis no riets-unten.
Den Datenwert bei den normalerweis als 8bpp-Bitmaps virgelueden Grafiken entsprécht dem Index vun der Faarf an der Faarfpalette.
Pixeldaten fänken uewen lénks un an enden unten riets.
Die Spill-Engine weist d'Tiles *wäret * op der Demande aus.
Dëst schéngt ënner anerem dem Dag-Nuecht-Zyklus geschuldet ze sinn, dee 32 Abstufungen vun eenzelne Tiles kennt. Hei gëtt anscheinend vum Helligkeitswert jee 'e bëssi' ofgezunn. Genau Wäerter konnten nach net ermittelt ginn, ech schaffen op der Berechnungsbasis
v *= (daylight / 48) + 0.25;
mat de HSV-Daten vun de Pixel, woubei daylight e Wäert vun 0-31 ass an v e Wäert tëscht 0-1. Zousätzlech ass ze berücksichtegen, datt op der Map jeweils nach e Rand vun 16 Tiles no lénks a riets existent ass (dat déngt dem onsichtbare Spawnen vun Unitéiten).
Zousätzlech schéngt de Dag-Nuecht-Zyklus pro Gamecycle jeweils nëmmen eng Spalte vun der Map ze aktualiséieren.
E beschleunegten Dag-Nuecht-Zyklus gesäit dofir esou aus:
Visualiséierung vum Dag-Nuecht-Zyklus
PRT
| Adr | x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | xA | xB | xC | xD | xE | xF | char | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x0000 | 43 | 50 | 41 | 4c | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | C | P | A | L | . | . | . | . | . | . | . | . | . | . | . | . |
| Offset | Datentyp | Bezeechnung | Erklärung |
|---|---|---|---|
| 0x0000 | uint(32) | Magesch Bytes | |
| 0x0004 | uint(24) | Palettenlängt | Gëtt, am Géigesaz zum normalem Blockformat, d'Zuel vun den an dëser Datei ze fannen Paletteen u - net d'Längt vum Block an Byte. |
| 0x0007 | uint(8) | Fändelen | Wahrscheinlech, wéi üblech, Flags. Mir sinn awer keng Flags bekannt; well all meng bekannt Wäerter |
Fir wat genau PRT steet, ass mir net bekannt; et kéint zum Beispill 'Palette an Ressource Tabelle' sinn - well et sech bei dëser Datei - ze fannen als op2_art.prt an der maps.vol - ëm esou eng handelt, respektiv dëst d'Funktion ganz gutt beschreiwen géif.
Dës Datei enthält eng Lëscht vun Palette, eng Tabelle iwwer all ugewannt Bitmapen, all Animatiounsdefinitiounen an nach eng Rei vun onbekannten Daten. Si follegt dem bis elo gebrauchten Containerformat nëmmen los, well net all Datensätz dësem Schema follegen.
Die CPAL-Sektioun (steet wahrscheinlech fir Palette-Container) ëmfaasst nëmmen d'Palette-Daten, andeems et ugéint, wéivill vun de gewéinlecherweis 1052 Byte groussen 8-Bit-Palette present sinn.
Die 1052-Byte-Angab gëtt net als verbindlech ugesi, well d'Paletteformat potenziell ënnerschiddlech Palettegréissten virgesäit. Si gëllt nëmmen fir den Datenbestand, mat deem Outpost 2 ausgelëft gëtt.
Nach den Palette-Listen follegt direkt an ouni e véierfäerdegen Header, déi Lëscht vun de Bitmapen; genee sou direkt folgen dorop d'Animatiounslisten.
béid ginn jeeweils mat engem uint(32) (oder zréck uint24+uint8 flags?) ageléit, deen d'Zuel vun den Datensätz enthält.
Paletten
| Adr | x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | xA | xB | xC | xD | xE | xF | char | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x0000 | 50 | 50 | 41 | 4c | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | P | P | A | L | . | . | . | . | . | . | . | . | . | . | . | . |
| Offset | Datentyp | Bezeechnung | Erklärung |
|---|---|---|---|
| 0x0000 | uint(32) | Magie Bytes | |
| 0x0004 | uint(24) | Palettenlängt | Gëtt, am Géigendeel zum normale Blockformat, d'Zuel vun den doheem an dëser Datei ze fannen Palette ugegraff - net d'Längt vum Block an Byte. |
| 0x0007 | uint(8) | Fändelen | Wahrscheinlech, wéi üblech, Flags. Mir sinn awer keng Flags bekannt; well all mir bekannt Wäerter |
Die Paletteninformatiounen sinn ganz einfach ze liesen.
Sie besteet aus engem Header an engem Data-Segment.
Paletten-Header
| Adr | x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | xA | xB | xC | xD | xE | xF | char | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x0000 | 68 | 65 | 61 | 64 | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | h | e | a | d | . | . | . | . | . | . | . | . | . | . | . | . |
| Offset | Datentyp | Bezeechnung | Erklärung |
|---|---|---|---|
| 0x0000 | uint(32) | Magie Bytes | |
| 0x0004 | uint(24) | Palettenlängt | Gëtt, am Géigendeel zum normale Blockformat, d'Zuel vun den doheem an dëser Datei ze fannen Palette ugegraff - net d'Längt vum Block an Byte. |
| 0x0007 | uint(8) | Fändelen | Wahrscheinlech, wéi üblech, Flags. Mir sinn awer keng Flags bekannt; well all mir bekannt Wäerter |
| 0x0008 | uint(32) | Palettenformat-Versioun? | Definéiert wahrscheinlech, wéi eng Palettenformat-Versioun d'Palette follegt. All Outpost2-Paletten scheine Version |
Paletten-Daten
| Adr | x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | xA | xB | xC | xD | xE | xF | char | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x0000 | 64 | 61 | 74 | 61 | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | d | a | t | a | . | . | . | . | . | . | . | . | . | . | . | . |
| Offset | Datentyp | Bezeechnung | Erklärung |
|---|---|---|---|
| 0x0000 | uint(32) | Magie Bytes | |
| 0x0004 | uint(24) | Block-Längt | |
| 0x0007 | uint(8) | Fändelen |
Die Datensektioun hëlt d'eenzel Paletten-Einträg op. Die Zuel vun den Paletten-Einträg resultéiert aus der Block-Längt / 4.
Die eenzel Einträeg hunn dabei folgend, einfachen Opbau;
| Adr | x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | xA | xB | xC | xD | xE | xF | char | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x0000 | -- | -- | -- | 04 | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| Offset | Datentyp | Bezeechnung | Erklärung |
|---|---|---|---|
| 0x0000 | uint(8) | Rout-Komponente | Gëtt den Rot-Anteil vun der Faarf aan |
| 0x0001 | uint(8) | Gréng-Komponent | Gëtt den Gréng-Anteil vun der Faarf ugewisen |
| 0x0002 | uint(8) | Blau-Komponenter | Gëtt de Blou-Anteil vun der Faarf ugewisen |
| 0x0003 | uint(8) | Onbekannt - Fändel? | Et ass onkloer, wat dësen Wäert bedeit, well hien anscheinend grundsätzlech |
Zu de Paletten ass et nach ze soen, dass fir Animationen ze benotzen Paletten folgend Regelen gëllen:
- Déi éischt Faarf ass IMMER transparent, egal wéi eng Wäert do angegeben ass.
-
Die Paletten-Einträcht 1-24 sinn an den Paletten 1-8 als Spillerfaarf ze werten.
Wo d’Faarwen ausserhalb vum Spiller 1 genee hierkommen, ass mir net kloer.
Ech vermuten, dass d’reschtlech Faarwen hardcoded sinn.
Paletten-Referenz
Bitmaps
| Adr | x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | xA | xB | xC | xD | xE | xF | char | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x0000 | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| 0x0010 | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| Offset | Datentyp | Bezeechnung | Erklärung |
|---|---|---|---|
| 0x0000 | uint(32) | Ausrichte Breede | Gëtt d'Breite vun de Pixeldatenzeilen an Byte ugebueden - well dës un d'4-Byte-Grenzen ausgeriicht sinn. Firwat dësen Wert separat gespäichert gëtt, obwuel hien berechent kéint ginn, ass onkloer. |
| 0x0004 | uint(32) | Offset | Gëtt den Offset vun der éischter Zeil an der Bitmap ugewisen |
| 0x0008 | uint(32) | Héicht | Gitt d'Héicht vum Bild an Pixel u |
| 0x000c | uint(32) | Breede | Gëtt d'Breite vum Bild an Pixel ugeduecht |
| 0x0010 | uint(16) | Typ | Gitt d'Art vum Bild un. Hei schéngt et eng Bitmask ze sinn:
|
| 0x0012 | uint(16) | Palette | Definéiert, wéi eng Palette aus der PRT-Datei soll benotzt ginn |
Dës Dateistruktur vun der PRT-Datei weist d'Zesummesetzung vun de Bitmaps, déi fir d'Sprites benotzt ginn. Dës Bitmaps déngen als eenzel Bestanddeel, vun deenen méi e puer zu engem Animatiounsframe vun engem Sprite zesummegesat ginn.
déi konkret Bilddaten sinn an der
op2_art.BMP am Spillverzeechnes verstoppt.
Firwat dës Bitmapdatei e (haaptsächlech korrekten) RIFF-Bitmapheader huet, ass onkloer. Wahrscheinlech benotzt Outpost 2 System-APIs fir d'Grafiken ze lueden, andeems dësen Header temporär iwwerholl gëtt an d'entspriechend, variéierend Felder iwwerholl ginn.
déi Pixeldaten sinn an der BMP-Datei un der Positioun Offset + dem uint32-Offset, das an der BMP-Datei um Adress 0x000A ze fannen ass (RIFF-Bitmap-Datenoffset), ze fannen - an entspriechen erëm der zeilenweiser Uerdnung vu lénks uewen no riets uewen.
Monochrom 1bpp-Grafiken kënnen esou gezeechent ginn, dass Faarf 0 komplett Transparenz ass, souwéi Faarf 1 een halbschwaarze/groussen ass, well d'Monochrom-Grafiken üblech fir Fahrzeug- a Gebaiedeschiet an den Animatiounen benotzt ginn.
Dofir kann ee schonn eng ganz Partie Grafiken zesummesetzen.
Geschütztes Wunnmodul (Plymouth)
Animatiounen
Nun kommen mir zur Kéierklassen vun den Disziplinen am Outpost 2 Datenformat:
Den Animationen.
Die Animatiounslisten ginn mat engem globalen Header, deen primär der Dateverifikatioun déngt, ageleitet. Darophin kommen d'konkreten Animatiounsdefinitiounen, déi an 3 Stufen ënnerdeelt sinn:
-
Animatioun
Ei Animatioun ass d'oberste Instanz; si stellt eng Animatioun vun enger Eenheet, engem Gebai oder enger 'Partikel-Animatioun' (Kometenschlag, Wieder, Explosioun) an enger bestëmmter Ausgangslage duer. -
Frame
E Frame ass eeen eenzegt Bild an engem Animatioun. Eng Animatioun kann een oder méi Frames enthalen. -
Subframe
E Subframe ass d'Informatioun dor iwwer, datt eng bestëmmte Bitmap ënner bestëmmten Kriterien op eng bestëmmte Positioun vun engem Frame gezeechent soll ginn. E Frame kann een oder méi Subframes enthalen.
>Anschléissend kommen schonn direkt d'eenzeg Animatiounsdefinitiounen.
| Adr | x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | xA | xB | xC | xD | xE | xF | char | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x0000 | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| Offset | Datentyp | Bezeechnung | Erklärung |
|---|---|---|---|
| 0x0000 | uint(32) | Zuel vun Animatiounen | Wéi vill Animatiounsdatensätz sinn et? |
| 0x0004 | uint(32) | Zuel vu Frame | Wéi vill Frames insgesamt sollten et sinn |
| 0x0008 | uint(32) | Zuel vun Subframes | Wéi vill Subframes insgesamt sollt et ginn |
| 0x000c | uint(32) | Zuel vun optionalen Entréeën | Wéi vill "optional Entréeën" sinn esou verfügbar. |
Animatioun
| Adr | x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | xA | xB | xC | xD | xE | xF | char | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x0000 | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| 0x0010 | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| 0x0020 | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| Offset | Datentyp | Bezeechnung | Erklärung |
|---|---|---|---|
| 0x0000 | uint(32) | Onbekannt 1 | Onbekannt Informatiounen |
| 0x0004 | uint(32) | Bounding Box: Lénks | Gëtt de lénksen Ufank (an Pixel) vun der Bounding Box uginn. |
| 0x0008 | uint(32) | Bounding Box: Uewen | Gëtt de fäerdegen Ufang (an Pixel) vun der Bounding Box ugesot. |
| 0x000c | uint(32) | Bounding Box: Breet | Gitt d'Breit (an Pixel) vun der Bounding Box un. |
| 0x0010 | uint(32) | Bounding Box: Héicht | Gitt d'Héicht (an Pixel) vun der Bounding Box u. |
| 0x0014 | uint(32) | Offset: X | Gëtt de horizontalen Mënschpunkt vun der Animatioun u |
| 0x0018 | uint(32) | Offset: Y | Gitt de vertikale Mënschenpunkt vun der Animatioun un |
| 0x001c | uint(32) | Onbekannt 2 | Onbekannt Informatioun |
| 0x0020 | uint(32) | Zuel vu Frame | Gëtt un, wéi vill Animatiounsframe an dëser Animatioun enthalen sinn |
| 0x0024 | uint(32) | Zuel vun den Fënsteren | Gitt an, wéi vill Fënsteren beim Zéien anzewenden sinn |
Die Date vun der oberster Schicht, der Animation, sinn do vorrangig Verwaltungsdaten - déi Boundingbox bezeechent déi Koordinaten vun der Markéierung ronderëm d'Fuerzeug/Gebai, wann dat gewielt ass an gëtt och gläichzäiteg un, wéi eng Zone klickbar soll sinn.
D'Shift bestëmmt vorrangig den "Nullpunkt"; den Punkt, deen op d'Spillintern Koordinaten ze addéieren beziehungsweise ofzéien ass. Een kéint och mathematesch soen: d'Shift bezeechent hei den Koordinatenurspronk.
Bei den Windows handelt et sech, genee wéi beim Shift, ëm jeeweils (pro Window) 4 uint(32)-Wäerter, déi eng Zone uginn, déi fir eenzel Subframes als benotzbar gëllt. D'Ausserhalb vun den Windows darf, esou wäit et fir d'Bitmap entspriechend virgesin ass, net gezeechent ginn.
Frame
| Adr | x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | xA | xB | xC | xD | xE | xF | char | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x0000 | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| Offset | Datentyp | Bezeechnung | Erklärung |
|---|---|---|---|
| 0x0000 | uint(8) | Subframe-Zuel an Toggle fir Optional 1, 2 | Dëse Wäert enthält:
|
| 0x0001 | uint(8) | Onbekannt 1 an Toggle fir Optional 3, 4 | Disen Wert enthält:
|
| 0x0002 | uint(8) | Optional 1 | Onbekannt |
| 0x0003 | uint(8) | Optional 2 | Onbekannt |
| 0x0004 | uint(8) | Optional 3 | Onbekannt |
| 0x0005 | uint(8) | Optional 4 | Onbekannt |
Subframe
| Adr | x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 | xA | xB | xC | xD | xE | xF | char | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x0000 | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . | . |
| Offset | Datentyp | Bezeechnung | Erklärung |
|---|---|---|---|
| 0x0000 | uint(16) | Bitmap-ID | Gitt un, wéi eng Bitmap fir dësen Subframe soll benotzt ginn |
| 0x0002 | uint(8) | Onbekannt 1 | Et ass ongewosst - ech vermuten awer staark, datt et sech hei ëm eng Render-Prioritéit (Z-Layer) handelt. |
| 0x0003 | uint(8) | Subframe-ID | Gitt un, an welchem Subframe mir sinn |
| 0x0004 | sint(16) | Offset - Horizontal | Gëtt an, wou am Frame d'Subframe plazéiert soll ginn, respektiv ëm wéi vill Pixel d'Bitmap horizontal verschobbe soll ginn |
| 0x0006 | sint(16) | Offset - Vertikal | Gëtt ugewisen, wou innerhalb vum Frame d'Unterframe placéiert soll ginn, respektiv wéi vill Pixel d'Bitmap vertikal verschoben soll ginn |
Daduerch kënne mir elo eenzel Frames, souwéi komplett Animatioune entspriechend zesummesetzen, hei als Beispill un enger méi komplexer Animation, der Animation mat dem Index 500, demonstréiert.
Animation 500
Animatioun 500 weist, wéi e Plymouth-Transporter, deen mat gewéinlechem Erz belueden ass, entluede gëtt. Dëst ass eng vun de wenigen Animatiounen, déi d'Windowing-Funktionalitéit benotzt.
An esou kann d'komplet Animatioun zesummegestallt ginn.
Leider ass et nach e Problem mat der uupper Ladeluke, well hei d'äquivalente Bit an der Grafiktyp-Informatioun net gesat ass.
Hir sinn nach e puer weider, schéin animéiert Sprites aus dem Spill:
Rendering vun Animatioun 500 illustriert
Animatioun 500 fäerdeg zesummegestallt
Plymouth Gebai-Fabréck
Eden Weltraumhafen
Eden medizinescht Zentrum
SCAT
Plymouth Weltraumhafen
Easteregg:
Weihnachtsmann
Easteregg:
Dans Hund
Benotzer-Interface
Nun feiert nach nach dem User-Interface vum Spill, dat an engem gebürsteten Metall-Look gehaalen ass.
Aber och hei ass et erkennbar, dass Dynamix d'Rad net nei erfannen huet; hei ginn net nëmmen d'User32- an GDI32-APIs benotzt, déi vun Windows zur Verfügung gestallt ginn - besonnesch gëtt och d'Ressourcen-Management vum User32 benotzt.
D'Secher kann een beispillsweis duerch Programer wéi dat vun Angus Johnson als Freeware entwéckelt Resource Hacker extrahéieren, oder - wann een ënner Linux / Mac OS de Gebrauch vun Wine scheitert - mat Hëllef vum wrestool, dat an icoutils enthalen ass.
| Dateinumm | Inhalt |
|---|---|
| Outpost2.exe | Enthält nëmmen d'Icon vum Spill, dat d'Weltallstatioun vir New Terra weist |
| op2shres.dll | Enthält neben Grafiken fir Bedienelementer wéi Ëmrandungen, Knäppercher, Radio-Knäppercher an Checkboxen och Dialog-Hintergrënn, déi Begleed-Biller fir d'Story-Missionstexter an d'Hauptmenü-Hintergrond-Grafik |
| out2res.dll | Enthält d'Ingame-Fënsterdekoratioun, Icons fir gewéinlecht an speziellt Metall, den Lade-Bildschirm, Grafiken fir Dialoger souwéi weider Cursor-Grafiken, zousätzlech zu den animéiert an der Spillverzeechnung |