Final Fantasy Hacktics

Quote from: Leonarth on November 14, 2021, 01:46:33 pmAnyway, I put together some notes on maps, I'd like to know if there's any part of it that people feel needs further explanation.

Code Select Expand

Map table starts at: $569104
Number of entries: 0xA3
Size of an entry: 0x58

When accessing this table map ID is decreased by 1, so map ID 1 is the first entry, map ID 0 has no entry and instead produces a completely black map.

Map table:
0x00 Word Tileset graphics, relative offset (these are loaded to 0x06000000)
0x04 Word Tile arrangement for both layers, relative offset
0x08 Word Top layer behavior, relative offset
0x0C Short Relative offset to map palette for LCD A
0x0E Short pad?
0x10 Word Terrain map, relative offset
0x14 Word Main tile animations, relative offset
0x18 Word Main tile animation graphics, relative offset
0x1C Word Target VRAM offset for Main tile animations
0x20 Word Extra tile animations 1, relative offset
0x24 Word Extra tile animations 2, relative offset
0x28 Word Extra tile animations 3, relative offset
0x2C Word Extra tile animations 4, relative offset
0x30 Word Extra tile animation 1 graphics, relative offset
0x34 Word Extra tile animation 2 graphics, relative offset
0x38 Word Extra tile animation 3 graphics, relative offset
0x3C Word Extra tile animation 4 graphics, relative offset
0x40 Word Target VRAM offset for Extra tile animations 1
0x44 Word Target VRAM offset for Extra tile animations 2
0x48 Word Target VRAM offset for Extra tile animations 3
0x4C Word Target VRAM offset for Extra tile animations 4
0x50 Word pad?
0x54 Byte Sky palette id for LCD A
0x55 Byte Sky palette id for LCD B and TV
0x56 Byte Map palette id for LCD B and TV
0x57 Byte pad?

Relative offsets in Tile animations are added to their corresponding Tile animation graphics.

A map palette table entry is a short, relative offset to the start of that color mode's table.
Map palette tables start at:
LCD B: $42CC80
TV: $427A04
There is no LCD A table, as the LCD A map palettes are referenced through relative offsets.

All other relative offsets are always relative to the start of the table, $569104

Sky palettes do not work in the same way, I haven't really looked much into them, though.

Data accessed through relative offsets has a compression header.
Not all data can use every mode, for example, Tile arrangement only checks for modes 0x01, 0x10 and 0x11.

Palettes accessed through palette ID are always lzss compressed, with no compression header.

The compression header looks like this:
0x00 Byte Mode

if Mode is 0x00 or 0x02 (raw):
0x01 3Bytes Uncompressed data length
The rest of bytes are raw, uncompressed data

if Mode is 0x01 (raw, fixed size):
0x01 3Bytes Unused
The rest of bytes are raw, uncompressed data, Uncompressed data length is 0x4000 bytes

if Mode is 0x10 (lz77):
0x01 3Bytes Uncompressed data length
The rest of bytes are lz77 compressed data

if Mode is 0x11:
0x01 3Bytes Offset

if Offset is 0xFFFFFF:
Call the decompress routine again, passing the offset + 4 as the argument. For some reason.
I have only ever seen the mode on the new decompress call be 0x10, not sure what the point is.
else:
Get the word at Offset, and divide it by 256 (or >> 8), call this NewID.
Call decompress for Tile arrangement of map NewID (without substracting 1 from NewID).

if Mode is 0x12 (lz77):
0x01 Word Unused
0x05 3Bytes Uncompressed data length
The rest of bytes are lz77 compressed data

if Mode is 0x20 (lzss):
0x01 3Bytes Unused
0x04 Word Uncompressed data length
The rest of bytes are lzss compressed data

if Mode is 0x21:
??? Seems to never be used.
If modes 0x01 and 0x11 are anything to go by, this could be a map specific lzss mode.
That would simply mean the Uncompressed data length is fixed.
As it is never used, I never really bothered checking.

if Mode is 0x22 (lzss):
0x01 7Bytes Unused
0x08 Word Uncompressed data length
The rest of bytes are lzss compressed data

Data is decompressed before it can be accessed, the structures explained here are for the decompressed data.

Tile arrangement:
2 layers of:
64 rows of:
64 columns of:
0x00 Short Tile

The Bottom layer is first, the Top layer is second.
These tiles are stored in WRAM and then copied to VRAM as needed, so their format is just that of a regular GBA tile.
Layers are simply what the map looks like, they technically have no impact on gameplay.

The Bottom layer goes below the units, it contains most of what the map looks like.
Stuff on the Top layer goes above the Bototm layer. It goes below the units as well, unless specified otherwise by the Top layer behavior data.
The Top layer can easily be used as a way to add more detail to maps, which is something vanilla doesn't take advantage of.

Terrain map structure:
16 rows of:
16 columns of:
0x00 Byte Height of the terrain
0x01 Byte Type of the terrain
Positions start with the top left one, going right and down, as if reading.

Type of the terrain is actually a bitfield (not heavily tested):
0b0000 0000: No bits set, regular terrain
0b0000 0001: Can look at but can't walk on, however, can fly over
0b0000 0010: Water (can jump over, can stand on)
0b0000 0100: Can look at but can't even fly over
0b0000 1000: Can't look at and can't walk on
0b0001 0000: Nothing special?
0b0010 0000: Nothing special?
0b0100 0000: Nothing special?
0b1000 0000: Nothing special?

Top layer behavior:
64 rows of:
32 columns of:
0x00 Short Behavior
As you may have guessed, each column in the Top layer behaviour data affects two tiles of the Top layer in the Tile arrangement data.
Behavior is a packed struct that looks like this:
0b--YY YYHH HHH- XXXX
- denotes unused bits.

For example, if we had an X of 8, a Y of 12 and a H of 5:
X: 0b---- ---- ---- 1000
H: 0b---- --00 101- ----
Y: 0b--11 00-- ---- ----
Putting it all together:
0b0011 0000 1010 1000
Or, as a Short:
0x30A8

The purpose of this data is to determine when something in the Top layer goes in front of units, and when it goes behind them.
The X and Y components should correspond with the Terrain map tile this Top layer "object" would be "standing" on.
H should correspond with the height of that same Terrain Map tile.
I have not actually looked into how the game handles this data and what the actual checks look like, but going by these rules works fine enough.

Tile animations:
0x00 Short Length of graphics for each frame
0x02 Short Number of entries in the list
Then, for each entry:
0x00 Short Duration
0x02 Short Graphics relative offset (this gets multiplied by 0x20 after being read, which is the size of a tile)


Quote from: Leonarth on November 13, 2021, 01:11:50 pmEither way, what is wrong with your move descriptions? "broken" is very undescriptive.