Dateiformate von Siedler II

BBM - Palettendateien
LBM - Bilddateien
LST - Archive
IDX - DAT-Index-Dateien
DAT - Archive
BOB - Archive
GER - Textdateien
ENG - Textdateien
WLD - Kartendateien (Szenario)
SWD - Kartendateien (Eigene)
RTX - Missionsbeschreibungen
SNG - Musikformat
BobTypes (Archivdatentypen)


Zurück - Index - Weiter

BBM - Palettendateien

BBM-Dateien sind die am einfachsten strukturierten Dateien von Siedler II, sie enthalten nur die reinen Farbdaten.

Anzahl Größe Daten
1 48 Bytes Header der Bilddatei, irrelevant
256 3 Bytes RGB (Farbdaten)


Nach oben

LBM - Bilddateien

In den LBM-Dateien sind ausschliesslich die Splash-Screens gespeichert
LBM ist ein "chunked"-Dateiformat,
d.h die Dateien sind in Stücke gegliedert,
die jede eine andere Funktion erfüllen


Anzahl Größe Daten
1 4 Bytes "FORM" (File-Identifier)
4 1 Byte Unbekannte Daten
1 4 Bytes "PBM " (Header-Identifier)


ab hier dann die einzelnen "chunk"-Typen, können mehrmals auftreten:

Anzahl Größe Daten
1 4 Bytes "BHMD" (Chunk-Identifier)
1 4 Bytes length (Chunk-Length, bei ungerader Zahl aufrunden)
1 2 Bytes width (Breite des Bildes)
1 2 Bytes height (Höhe des Bildes)
4 1 Byte Unbekannte Daten
1 2 Bytes depth (Farbtiefe des Bildes)
1 2 Bytes compression_flag (Kompressionsflag des Bildes)
length - 20 1 Byte Unbekannte Daten


Anzahl Größe Daten
1 4 Bytes "CMAP" (Chunk-Identifier)
1 4 Bytes length (Chunk-Length, muss 768 sein)
256 3 Bytes RGB (Farbdaten)


Anzahl Größe Daten
1 4 Bytes "BODY" (Chunk-Identifier)
1 4 Bytes length (Chunk-Length, bei ungerader Zahl aufrunden)

Hier gibt es eine Unterscheidung, falls "compression_flag" 0 ist,
also unkomprimiert, liegen die Farbdaten so:
length 1 Byte color (Farbindex aus "CMAP"-Palette, Alpha-Wert immer 0xFF)

für "compression_flag" 1 ist das Bild komprimiert,
da liegen die Farbdaten so:
Folgende 3 Teile werden abgearbeitet bis man "length"-Bytes
oder "width" und "height" des Bildes erreicht hat.
1 1 Byte ctype (Komprimierungstyp)

für "ctype" >= 0
1 1 Byte count (Anzahl nachfolgender Farbpixel)
count 1 Byte color (Farbindex aus "CMAP"-Palette, Alpha-Wert immer 0xFF)

für "ctype" < 0 ( bzw > 127 )
1 1 Byte color (Farbindex aus "CMAP"-Palette, Alpha-Wert immer 0xFF)

ergibt (ctype < 0 ? (-ctype + 1) : ctype) Bytes Farbpixel im Bild
(erst x bis width auffüllen, dann nächste Zeile)

Sonstige "chunk"-Typen sind uninteressant bzw unbekannt,
diese muss man überspringen:
Anzahl Größe Daten
1 4 Bytes "????" (Chunk-Identifier)
1 4 Bytes length (Chunk-Length, bei ungerader Zahl aufrunden)
length 1 Byte Unbekannte Daten


Nach oben

LST - Archive

In den LST-Archiven stehen meist die ganzen Missionsobjekte, aber auch z.b die Sounds

Anzahl Größe Daten
2 1 Byte id (Datei-Identifier)
1 4 Byte count (Anzahl Einträge)

ab hier kommen nun die ganzen Einträge:
1 2 Byte type

Falls type == 0x0000, dann ist der Eintrag leer und unbenutzt,
d.h direkt darauf wieder auf type testen
Wenn type == 0x0001, dann ist der Eintrag benutzt und die nächsten
2 Bytes sind der Bobtype:
1 2 Byte bobtype
x 1 Byte data (je nach BobType verschieden)

data ist je nach BobType verschieden (vgl. BobTypes)

Nach oben

IDX - DAT-Index-Dateien

Die IDX-Dateien sind die Indexdateien für die jeweiligen DAT-Dateien:

Anzahl Größe Daten
1 16 Bytes name (Datensatzname)
1 4 Bytes offset (Startadresse der Daten in der DAT)
6 1 Byte Unbekannte Daten
1 2 Byte bobtype (Typ des Eintrags)


Nach oben

DAT - Archive

Die DAT-Archive sind indizierte Dateiarchive,
welche immer eine IDX-Datei dabeihaben.
Sie enthalten soviele Datensätze wie ihre IDX-Datei.
Man nimmt einen Datensatz aus der IDX,
das offset ergibt die Startadresse des Eintrags:

Anzahl Größe Daten
1 2 Bytes Wiederholung Bobtype
bobtype-size 1 Byte Daten des Bobtypes

Je nach Bobtype werden die Daten dann ausgewertet (vgl. BobTypes)

Nach oben

BOB - Archive

In den BOB-Archiven werden die ganzen Männchen inkl Animationen gespeichert.
Jedes der Bilder wird auf 32x32px "gemappt"
Anzahl Größe Daten
4 1 Byte Unbekannte Daten
1 4 Bytes size (Größe des Grundfarbblocks)
size 1 Byte rawbase (Daten des Grundfarbblocks)

Nun folgen 96 "Körper"-Blöcke:
1 1 Byte height (Höhe des Körpers)
height 2 Bytes starts (Startadressen des Körpers)
1 1 Byte ny (Nullpunkt Y)

Die Grundkörper-Bilder werden aus dem rawbase-Block und den 96-Körperblöcken generiert.

Nun kommen die 6 Farbblöcke für die Animationsrichtungen, also folgendes 6 mal:
2 1 Byte Unbekannte Daten
1 1 Byte height (Höhe des Körpers)
1 4 Byte size (Größe des Farbblocks)
size 1 Byte raw (Daten des Farbblocks)

Nun kommen die ganzen Warenbilder:
1 4 Byte count (Anzahl der Bilder)

Dann folgender Block count mal:
2 1 Byte Unbekannte Daten
1 1 Byte waren_height (Höhe des Bildes)
height 2 Bytes waren_starts (Startadressen des Bildes)
1 1 Byte waren_ny (Nullpunkt Y)

Jetzt kommen nun die wirklichen Animationsbildchen:
1 4 Byte count (Anzahl der Bilder)

Jetzt folgender Block count mal:
1 2 Byte id (ID des Blocks)
2 1 Byte Unbekannte Daten

Mit Hilfe der ID kann man nun aus dem aktuellen Bild (i)
den jeweiligen raw-Block ermitteln (raw[i%6])

Die zugehörigen Startadressen sind dann waren_starts[id],
die Höhe waren_height[id] und der Y-Nullpunkt waren_ny[id].

Daraus lassen sich die Animationsoverlays erstellen.

Man nimmt dann nur noch ein gewünschtes Körperbild
und die gewünschte Ware/Animation, und blittet diese übereinander.

Die Y-Nullpunkte korrigieren die vertikale Position

Für die Bilddaten wird der BobType 04 benutzt (vgl. BobTypes)

Nach oben

GER/ENG - Textdateien

Es gibt 2 Arten von Textdateien, Dateien, welche Archive sind
und die, die nur einen einzigen Eintrag enthalten.

Die Unterscheidung ist ziemlich einfach, man muss sich nur die
ersten 2 Bytes ansehen.

Wenn die ersten 2 Bytes 0xE7FD ergeben, ist es ein Archiv.

Wenn dies nicht der Fall ist, ist das Auslesen einfach:
Die komplette Datei ist der Text.

Falls es ein Archiv ist, ists komplizierter:
Anzahl Größe Daten
2 1 Byte 0xE7FD (File-Identifier)
1 2 Bytes count (Anzahl der Texte)
2 1 Byte Unbekannte Daten
1 2 Bytes size (Größe der Daten ohne Header)

Nun kommen erstmal die Startoffsets der Texte:
Anzahl Größe Daten
count 2 Bytes offset (Start-Offsets)

Nun folgen die Texte, falls das Offset 0 ist, ist der Texteintrag unbenutzt.

Man geht am besten alle Offsets durch, addiert 10 zum Offset dazu und
man erhält die Startadresse des Textes.
Diesen liest man bis zur terminierenden '\0' ein.

Wichtig: Die Texte sind mit dem OEM-Zeichensatz kodiert,
also ggf. in ANSI oder UTF-8 Zeichensatz umwandeln.

Nach oben

WLD/SWD - Kartendateien

Nach oben

RTX - Missionsbeschreibungen

Nach oben

SNG - Musikformat

In den SNG-Dateien ist die Hintergrundmusik von Siedler2 gespeichert.
Das Format ist sogenanntes XMIDI.

Anzahl Größe Daten
1 4 Bytes "FORM" (File-Identifier)
1 4 Bytes length (Data-Length)
1 4 Byte "XMID" oder "XDIR" (Inhalts-Identifier)

Für "XMID" gilt: nur 1 Track (track_count = 1),
falls id "XDIR" ist kommt folgendes:
1 4 Bytes "????" (Chunk-Identifier)
1 4 Bytes length (Chunk-Length, bei ungerader Zahl aufrunden)
length 1 Byte data (Chunk-Data)

Es gibt folgende Chunk's beim "XDIR":
"INFO" 2 Bytes track_count (MIDI-Track-Count)
"CAT " 4 Bytes "XMID" (wenn das nicht "XMID" ist, ists kein normales XMIDI-Format)

Das war nun der XMIDI-Header, nun kommen die Trackdaten dran
(solang einlesen bis track_nr == track_count):
1 4 Bytes "????" (Chunk-Identifier)

Es gibt folgende Chunks, manche haben unbekannte Daten:
"FORM" 4 Bytes unbekannte Daten
"XMID" ? Bytes unbekannte Daten
"TIMB" 4 Bytes length + length Bytes data unbekannte Daten
"EVNT" 4 Bytes length + length Bytes data die eigentlichen Trackdaten, nach jedem EVNT-Block track_nr um 1 erhöhen


Das Auswerten der MIDI-Trackdaten kann nach der
Veröffentlichung des Quellcodes im Quellcode nachgelesen werden.

Nach oben

BobTypes

Bobtypes sind die Dateitypbezeichner in den Archiven

Bobtype 01 (WAVs, MIDIs)
Bobtype 02 (RLE komprimiertes Bitmap)
Bobtype 03 (Font)
Bobtype 04 (Bitmap mit spezifischer Spielerfarbe)
Bobtype 05 (Palette)
Bobtype 07 (Schatten)
Bobtype 14 (unkomprimiertes Bitmap)

Bobtype 01 (WAVs, MIDIs)



Anzahl Größe Daten
1 4 Bytes length (Größe des Datenblocks)
length 1 Byte data (Daten)


Die WAV-Daten sind 8-Bit 11025Hz Mono PCM-Dateien (ohne WAV-Header),
Die MIDI-Daten kann man am beginnenden "FORM" erkennen,
diese sind im XMIDI-Format

Nach oben zu BobTypes

Bobtype 02 (RLE komprimiertes Bitmap)



Anzahl Größe Daten
1 2 Bytes nx (Nullpunkt X)
1 2 Bytes ny (Nullpunkt Y)
4 1 Byte Unbekannte Daten (immer 00 00 00 00 ???)
1 2 Bytes width (Breite des Bildes)
1 2 Bytes height (Höhe des Bildes)
1 2 Byte Unbekannte Daten (immer 01 00 ???)
1 4 Byte length (Länge des Datenblockes)
height 2 Byte starts (Startadressen der einzelnen Bildzeilen)
length-height*2 1 Byte data
1 1 Byte 0xFF (Block-End-Marker)


Wir ignorieren den length und starts,
dafür lesen wir sie folgendermaßen ein:

bis Zeile voll:
Anzahl Größe Daten
1 1 Byte count (Anzahl farbiger Pixel)
count 1 Byte color (Farbindex des Pixels)
1 1 Byte count (Anzahl transparenter Pixel)

dann folgendes einmal einlesen, und wieder bis zeile voll obigen block
1 1 Byte 0xFF (Zeilen-End-Marker)


Nach oben zu BobTypes

Bobtype 03 (Font)



Anzahl Größe Daten
1 1 Byte dx (X-Spacing)
1 1 Byte dy (Y-Spacing)

dann 224 Bilder des Bobtypes 04 für jeden Buchstaben (224: ASCII-Tabelle 32-256)

Nach oben zu BobTypes

Bobtype 04 (Bitmap mit spezifischer Spielerfarbe)



Anzahl Größe Daten
1 2 Bytes nx (Nullpunkt X)
1 2 Bytes ny (Nullpunkt Y)
4 1 Byte Unbekannte Daten (immer 00 00 00 00 ???)
1 2 Bytes width (Breite des Bildes)
1 2 Bytes height (Höhe des Bildes)
1 2 Byte Unbekannte Daten (immer 01 00 ???)
1 4 Byte length (Länge des Datenblockes)
height 2 Byte starts (Startadressen der einzelnen Bildzeilen)
length-height*2 1 Byte data


Wir ignorieren den length und starts,
dafür lesen wir sie folgendermaßen ein:

bis Zeile voll:
Anzahl Größe Daten
1 1 Byte shift ("Schalter")

für shift < 0x40, transparent
count = shift
count-pixel transparent

für shift > 0x40 und < 0x80, unkomprimiert
count = shift - 0x40
count 1 Byte color (Farbindex des Pixels)


für shift > 0x80 und < 0xC0, spielerfarbe
count = shift - 0x80
count 1 Byte color (Spielerfarbeindex des Pixels)


für shift > 0xC0, komprimiert
count = shift - 0xC0
1 1 Byte color (Farbindex des Pixels)

erzeugt count-mal color-Pixel

Nach oben zu BobTypes

Bobtype 05 (Palette)



Anzahl Größe Daten
1 2 Byte Unbekannte Daten (immer 01 00 ???)
256 3 Bytes RGB (RGB-Daten)


Nach oben zu BobTypes

Bobtype 07 (Schatten)



Anzahl Größe Daten
1 2 Bytes nx (Nullpunkt X)
1 2 Bytes ny (Nullpunkt Y)
4 1 Byte Unbekannte Daten (immer 00 00 00 00 ???)
1 2 Bytes width (Breite des Bildes)
1 2 Bytes height (Höhe des Bildes)
1 2 Byte Unbekannte Daten (immer 01 00 ???)
1 4 Byte length (Länge des Datenblockes)
height 2 Byte starts (Startadressen der einzelnen Bildzeilen)
length-height*2 1 Byte data
1 1 Byte 0xFF (Block-End-Marker)


Wir ignorieren den length und starts,
dafür lesen wir sie folgendermaßen ein:

bis Zeile voll:
Anzahl Größe Daten
1 1 Byte count (Anzahl halbtransparenter schwarzer Pixel, Alpha-Wert 0x40)
1 1 Byte count (Anzahl transparenter Pixel)

dann folgendes einmal einlesen, und wieder bis Zeile voll obigen Block
1 1 Byte 0xFF (Zeilen-End-Marker)


Nach oben zu BobTypes

Bobtype 14 (unkomprimiertes Bitmap)



Anzahl Größe Daten
2 1 Byte Unbekannte Daten (immer 01 00 ???)
1 4 Bytes length (Größe der Daten)
length 1 Byte data (Daten)
1 2 Byte nx (Nullpunkt X)
1 2 Byte ny (Nullpunkt Y)
1 2 Bytes width (Breite des Bildes)
1 2 Bytes height (Höhe des Bildes)
8 1 Byte Unbekannte Daten (immer 00 00 02 01 F4 06 70 00???)

Die Daten sind Zeile für Zeile reine, nicht transparente Farbindezes.

Nach oben zu BobTypes

Zurück - Index - Weiter


Copyright © 2005-2006 Settlers Freaks