Outpost 2 Dateiformate · bei.pm

Die von Outpost 2 verwendeten Datenformate haben einen an JFIF / PNG erinnernden Aufbau - die einzelnen Datenblöcke verfügen dabei immer über einen 8 Byte Header. Daher spare ich es mir, die einzelnen Header an den entsprechenden spezifischen Stellen zu dokumentieren und dokumentiere dort nur Abweichungen.

Das Format ist immer das folgende; die eigentlichen Nutzdaten sind dann darin eingebettet:

Bei den Volumes handelt es sich um einen Datencontainer für das Spiel, ähnlich zu einem Archivformat wie z.B. Tarball. Zumindest in Outpost 2 kennt das Format dabei lediglich Dateien - keine Ordner. Wahrscheinlich ließen sich diese allerdings über entsprechende Dateinamen simulieren.

Ein Volume besteht dabei aus dem Volume-Header sowie aus mehreren Volume Blöcken, die den konkreten Dateien entsprechen.

"Volumes" sind die Dateien mit der Endung 'vol' im Spielverzeichnis.

Der Volume Header enthält seinerseits keinerlei Nutzdaten.
Er dient lediglich als Container.

Als erstes Datum im Volume Header sollten sich die Volume Strings finden; darauf folgen dann die Volume-Informationen.

Bei den Volume Strings handelt es sich um eine Liste von Dateinamen, die innerhalb des Volumes enthalten sind.

Die Volume-Informationen nehmen detailliertere Informationen zu den Dateien auf. Dabei handelt es sich in gewisser Weise um eine Art FAT-Verzeichniseintrag (FAT = File Allocation Table)

Die Anzahl an Dateien ergibt sich aus der Blockgröße geteilt durch die Länge der Verzeichniseinträge - 14 Byte.

Die einzelnen Verzeichniseinträge haben dabei jeweils folgenden Aufbau:

Bei einem Volume-Block handelt es sich um einen Container, der Dateien aufnimmt. Er enthält lediglich noch einmal - aufgrund des Blockformates - redundant die Dateigröße und anschließend folgen direkt die Nutzdaten.

Bei den Tiles handelt es sich um ein Outpost-2-Spezifisches Bitmap-Grafikformat. Sie erstrecken sich über 13 Tilesets, "wells" genannt (well0000.bmp bis well0012.bmp), die sich innerhalb des Volumes maps.vol befinden.

Dabei enthalten die Tilesets / Wells folgendes:

Es erschreit ratsam für eine akkurate Umsetzung, die Tiles nicht im Vorraus zu rendern um diese zu cachen, da die Daten für den Tag/Nacht-Zyklus noch bearbeitet werden müssen - und sehr sehr viele Daten anfallen würden.

Die Tiles sind 8bpp-Grafiken mit indexierter Palette zu je 32x32 Pixel Auflösung, welche untereinander angeordnet sind. In einem so entstandenen Tileset können allerdings weitaus mehr

Der Haupt-Container besteht aus 2 Sektionen: head und data.

Nach diesen Angaben erfolgt noch eine im standardisierten RIFF-Format vorliegende Palettendatei. Die genaue Spezifikation findet sich - da die Paletten auch anderswo auftauchen - unter Paletten.

Schließlich folgen bereits die blanken Pixeldaten, von links-oben zeilenweise nach rechtsunten.
Der Datenwert bei den in aller Regel als 8bpp-Bitmaps vorliegenden Grafiken entspricht dabei dem Index der Farbe in der Farbpalette.

Die Spiel-Engine zeichnet die Tiles dabei *wahrscheinlich* on-demand.
Dies scheint unter anderem dem Tag-Nacht-Zyklus geschuldet zu sein, der 32 Abstufungen einzelner Tiles kennt. Dabei wird offenbar vom Helligkeitswert jeweils 'ein wenig' abgezogen. Genaue Werte ließen sich noch nicht ermitteln, ich arbeite auf der Berechnungsgrundlage

v *= (daylight / 48) + 0.25;

mit den HSV-Daten der Pixel, wobei daylight ein Wert von 0-31 ist und v ein Wert zwischen 0-1. Darüber hinaus ist zu berücksichtigen, dass auf der Map jeweils noch ein Rand von 16 Tiles nach links und rechts (der dient dem unsichtbaren Spawnen von Einheiten) existiert.

Zusätzlich scheint der Tag-Nacht-Zyklus pro Gamecycle jeweils nur eine Spalte der Map zu aktualisieren.
Ein beschleunigter Tag-Nacht-Zyklus sieht daher wie folgt aus:

Wofür PRT genau steht ist mir nicht bekannt; denkbar wäre beispielsweise 'Palette and Ressource Table' - da es sich bei dieser Datei - zu finden als op2_art.prt in der maps.vol - um eine solche handelt, bzw dies die Funktion ganz gut beschreiben würde.

Diese Datei enthält dabei eine Liste von Paletten, eine Tabelle über alle verwendeten Bitmaps, alle Animationsdefinitionen und noch eine Reihe von unbekannten Daten. Sie folgt dem bisherigen Containerformat lose, da nicht alle Datensätze diesem Schema folgen.

Die CPAL-Sektion (steht wahrscheinlich für Paletten-Container) umschließt dabei lediglich die Palettendaten, indem es angibt, wieviele der jeweils üblicherweise 1052 Byte großen 8-Bit-Paletten vorhanden sind.

Die 1052-Byte-Angabe gilt dabei nicht als verbindlich, da das Palettenformat potentiell unterschiedliche Palettengrößen vorsähe. Sie gilt lediglich für den Datenbestand, mit dem Outpost 2 ausgeliefert wird.

Nach den Paletten-Listen folgt unmittelbar und ohne einleitenden Header, bereits die Liste der Bitmaps; genauso unmittelbar folgen darauf die Animationslisten.
Beide werden dabei jeweils mit einem uint(32) (oder wieder uint24+uint8 flags?) eingeleitet, der die Anzahl an Datensätzen enthält.

Die Paletten-Informationen sind sehr einfach einzulesen.
Sie bestehen jeweils aus einem Header und einem Data-Segment.

Die Datensektion nimmt die einzelnen Paletten-Einträge auf. Die Anzahl an Paletten-Einträge ergibt sich aus der Block-Länge / 4.

Die einzelnen Einträge haben dabei folgenden, schlichten Aufbau;

Zu den Paletten ist ansonsten nur noch zu sagen, dass bei für Animationen zu verwendende Paletten folgende Regeln gelten:

• Die erste Farbe ist IMMER transparent, egal was für ein Wert dort angegeben ist.
• Die Paletten-Einträge 1-24 sind in den Paletten 1-8 als Spielerfarbe zu werten.
  Wo die Farben abseits von Spieler 1 genau herkommen, ist mir unklar.
  ich vermute, dass die restlichen Farben hardcoded sind

Diese Datenstruktur der PRT-Datei gibt an, wie die für die Sprites verwendeten Bitmaps aufgebaut sind. Diese Bitmaps dienen dabei als einzelner Bestandteil, von dem mehrere zu einem Animationsframe eines Sprites zusammengebaut werden.

Die konkreten Bilddaten verbergen sich dagegen in der op2_art.BMP im Spielverzeichnis.
Warum diese Bitmapdatei über einen (überwiegend korrekten) RIFF-Bitmapheader verfügt, ist unklar. Wahrscheinlich verwendet Outpost 2 System-APIs zum Laden der Grafiken, indem dieser Header temporär übernommen wird und die entsprechenden, variierenden Felder überschrieben werden.

Die Pixeldaten sind dabei in der BMP-Datei an der Position Offset + dem uint32-Offset, das in der BMP-Datei an Adresse 0x000A zu finden ist (RIFF-Bitmap-Datenoffset), zu finden - und entsprechen wieder der zeilenweisen Anordnung von oben links nach rechts unten.

Monochrome 1bpp-Grafiken können dabei so gezeichnet werden, dass Farbe 0 vollständiger Transparenz, sowie Farbe 1 ein halbtransparentes schwarz/grau ist, da die Monochrom-Grafiken üblicherweise für Fahrzeug- und Gebäudeschatten in den Animationen verwendet werden.

Damit kann man bereits viele Grafiken zusammensetzen.

Nun kommen wir zur Königsklasse der Disziplinen innerhalb der Outpost 2 Datenformate:
Den Animationen.

Die Animationslisten werden mit einem globalen Header, der primär der Datenverifikation dient, eingeleitet. Daraufhin folgen die konkreten Animationsedefinitionen, die sich in 3 Stufen gliedern:

1. Animation
   Eine Animation ist die oberste Instanz; sie stellt eine Animation einer Einheit, eines Gebäudes oder einer 'Partikel-Animation' (Kometenschlag, Wetter, Explosion) in einem bestimmten Ausgangslage dar.
2. Frame
   Ein Frame ist ein einzelnes Bild innerhalb einer Animation. Eine Animation kann ein oder mehrere Frames beinhalten.
3. Subframe
   Ein Subframe ist die Information darüber, dass eine bestimmte Bitmap unter bestimmten Kriterien an eine bestimmte Position eines Frames gezeichnet werden soll. Ein Frame kann ein oder mehrere Subframes beinhalten.

Anschließend folgen schon direkt die einzelnen Animationsdefinitionen.

Die Daten der obersten Schicht, der Animation, sind dabei vorrangig Verwaltungsdaten - die Boundingbox bezeichnet dabei die Koordinaten der Markierung um das Fahrzeug/Gebäude, wenn das selbige ausgewählt ist und gibt auch gleichzeitig an, welcher Bereich anklickbar sein soll.

Das Offset bestimmt vorrangig den "Nullpunkt"; den Punkt, der auf spielinterne Koordinaten aufzurechnen beziehungsweise abzuziehen ist. Man könnte auch mathematischer sagen: das Offset bezeichnet hier den Koordinatenursprung.

Bei den Windows handelt es sich, genauso wie beim Offset, um jeweils (pro Window) 4 uint(32)-Werte, die einen Bereich angeben, der für einzelne Subframes als verwendbar gilt. Ausserhalb der Windows darf, sofern es für die Bitmap entsprechend vorgesehene ist, nicht gezeichnet werden.

Damit können wir nun einzelne Frames, als auch komplette Animationen entsprechend zusammensetzen, hier einmal exemplarisch an einer komplexeren Animation, der Animation mit dem Index 500, demonstriert

Animation 500 zeigt, wie ein Plymouth-Transporter, der mit gewöhnlichem Erz beladen ist, entladen wird. Dabei handelt es sich um eine der wenigen Animationen, die die Windowing-Funktionalität nutzt.

Und so lässt sich die komplette Animation zusammenfügen.
Leider gibt es noch ein Problem mit der oberen Ladeluke, da hier das entsprechende Bit in der Grafiktyp-Information nicht gesetzt ist.

Hier noch ein paar weitere, wunderschön animierte Sprites aus dem Spiel:

Nun fehlt noch das User-Interface des Spieles, welches in einem gebürstetem Metall-Look gehalten ist.

Aber auch hier ist erkennbar, dass Dynamix das Rad nicht neu erfinden musste; hier werden nicht nur schlicht die durch die von Windows bereitgestellten User32- und GDI32-APIs genutzt - insbesondere wird auch das Ressourcen-Management von User32 verwendet.

Diese lassen sich beispielsweise durch Programme wie das von Angus Johnson als Freeware entwickelte Resource Hacker, oder - falls man unter Linux / Mac OS den Einsatz von Wine scheut - mithilfe des in icoutils enthaltenen wrestool extrahieren.