Tilesetdaten PKMN GSK
aus RHWiki, der freien Romhacking-Enzyklopädie
| Inhaltsverzeichnis |
Alle Aspekte eines Tilesets sind in den jeweiligen Tilesetheadern eingetragen. Lediglich die verwendeten Paletten werden im Mapheader der jeweiligen Map festgelegt.
| Offset der Pointertabelle | Vorhandene Tilesets | Offset der Animationsroutine | |
| Gold/Silber | 0x156D3 | 0x1D | 0xFC003 |
| Kristall | 0x4D5A5 | 0x25 | 0xFC000 |
Die Anzahl der Tilesets ist im Original im Code nicht eingeschränkt. Die Tileset-Nr. ist jedoch nur ein Byte, d.h. es gibt maximal 256 verschiedene Tilesets im Spiel.
Struktur des Tilesetheaders
Die Struktur sieht wie folgt aus:
[3byte-Pointer auf die Bilddaten][3byte-Pointer auf die Blockdaten][3byte-Pointer auf die Kollisionsdaten][2byte-Pointer auf die Animationsdaten][00][00][2byte-Pointer auf die Palettenzuordnung]
Die Daten des Tilesetheaders
3byte-Pointer auf die Bilddaten
- Pointet auf die komprimierten Bilddaten des Tilesets.
- In Gold und Silber ist das Tileset auf maximal 0x60 Tiles, in Kristall auf 0xC0 Tiles beschränkt. In Kristall wird die "zweite Hälfte" bestehend aus 0x60 Tiles in den VRAM1 geladen. Das erste Tile wird in allen Versionen als Tile 0x00 referenziert. Das erste Tile der "zweiten Hälfte" des Tilesets wird in Kristall mit 0x80 referenziert. Welches der Tiles im Block vorkommt, wird noch zusätzlich über die Palettenzuordnung bestimmt.
3byte-Pointer auf die Blockdaten
- Die Blockdaten sind in Gold, Silber und Kristall identisch aufgebaut. Es gibt maximal 0x80 Blocks für jedes Tileset.
- Aufbau der Blockdaten:
0x10 Bytes um den Block folgendermaßen zu bilden:
[0][1][2][3]
[4][5][6][7]
[8][9][A][B]
[C][D][E][F]
Beispiel: Block 04 aus Tileset 01
[05][05][05][05]
[05][03][05][03] =>
[03][05][03][05] =>
[05][05][05][05]
- Die Blockdaten haben kein Ende, d.h. sie werden nicht durch Byte 0xFF oder sonstiges abgeschlossen. Die Blockdaten starten mit Block 0x00. Auf Maps wird Block 0x00 in den Mapdaten standardmäßig mit dem Füller-Block ersetzt. Sollte dieser auch 0x00 sein, so wird wirklich Block 0x00 genommen. Block 0x00 hat immer die Kollisionsdaten 0xFF, ist also nicht begehbar.
3byte-Pointer auf die Kollisionsdaten
- Die Kollisionsdaten sind in Gold, Silber und Kristall identisch aufgebaut. Es gibt maximal 0x100 Blöcke, die mit Kollisionsdaten abgedeckt werden können (obwohl es bloß maximal 0x80 Blocks pro Tileset gibt).
- Aufbau der Kollisionsdaten:
| 0x04 Bytes um den Block folgendermaßen zu bilden: | Die Abschnitte über die Blockdaten gelegt (im Wechsel fett markiert): |
| [links-oben ][rechts-oben ] [links-unten][rechts-unten] |
|[0][1]|[2][3]| |
Kollisionsdaten über Block 04 aus Tileset 01 gelegt.
- Für eine Liste möglicher Kollisionsdaten siehe Liste der Kollisionsdaten in Pokémon Gold, Silber und Kristall.
2byte-Pointer auf die Animationsdaten
- Der Pointer pointet in Gold, Silber und Kristall auf den Tabellenanfang einer Ablauftabelle in Rombank 0x3F (bzw. in der Rombank in der auch die Animationsroutine ist, siehe oben).
- Aufbau der Ablauftabelle:
[Übergebener 2byte-Wert][2byte-Pointer auf auszuführende Routine]...
- Der gesamte Animationsablauf fängt von vorn an, wenn die entsprechende Routine innerhalb der Ablauftabelle den Ablauf zurück setzt. Es kann maximal 0x100 verschiedene Tabelleneinträge geben bevor diese automatisch von vorn wieder abgearbeitet wird.
- Die übergebenen Werte sind meist VRAM-Offset von Tiles, die animiert werden sollen, oder aber 0x0000, wenn kein Wert übergeben wird.
- Für eine Liste der möglichen Routinen siehe Liste der Routinen für die Tileset-Animation in Pokémon Gold, Silber und Kristall.
[00][00]
- Diese Bytes sind beabsichtigt frei und werden nirgends im Rom abgefragt. Wahrscheinlich wurden sie zu einem früheren Zeitpunkt in der Entwicklung verwendet.
2byte-Pointer auf die Palettenzuordnung
- Die Palettenzuordnung ist in Gold, Silber und Kristall grundlegend gleich. Jedoch wird in Kristall in ihr noch einmal genau festgelegt, welches Tile in einem Block verwendet werden soll. Der Pointer pointet auf Palettendaten in Rombank 0x02 in Gold und Silber und in Rombank 0x13 in Kristall (bzw. in den Rombänken der entsprechenden Routinen).
- Aufbau der Palettendaten:
[Palette für Tile 0x01 (4bit)|Palette für Tile 0x00 (4bit)][Paletten für Tile 0x03 (4bit)|Palette für Tiles 0x02 (4bit)]...
- In Gold und Silber wird für alle 4bit-Werte über 0x07 statt des Wertes anhand der aktuellen Mapbank ein anderer Wert aus Tabelle 02:45D7, die mit Mapbank 0x01 startet, genommen. Somit können mapbank-spezifisch die Paletten für einige Tiles gewechselt werden. Im finalen Spiel wird dieser Mechanismus, der wohl für den Wechsel der Dachfarben gedacht war (alle Tabellenwerte sind 0x06, die Palette mit den Dachfarben), nicht genutzt, wohl deswegen, weil die Dachfarben durch eine andere Routine festgelegt werden.
- In Kristall hingegen wird wie folgt weiter verfahren: 4bit-Werte über 0x07 stellen Tiles im VRAM1 dar, d.h. Tiles aus der "zweiten Hälfte" des Tilesets (oben angesprochen). Die Paletten-Nr. ist 4bit-Wert AND 0x07.
- Da die Tiles der "zweiten Tilesethälfte" erst ab Tile 0x80 kommen, muss die "Lücke" zwischen dem letzten Tile der ersten Tilesethälfte, Tile 0x5F, und dem ersten Tile der zweiten Tilesethälfte, Tile 0x80, mit Dummy-Daten, im Original mit "F" für jedes Tile, aufgefüllt werden.
Beispiel: Die Palettenzuordnung für die erste Zeile von Tileset 01 in Kristall:
[5|0][1|5][2|2][1|0][1|1][6|6][6|6][6|6]...
Es sind außerdem die Tiles in der "Lücke" zwischen den beiden Tilesethälften enthalten (Tiles 0x60 bis 0x7F).
