Phantasy Star Generation 2:Notes
CUE found out the coding algorithm. It's a Lempel-Ziv related one, called Lempel-Ziv Renau.
Structure of files :
- Bytes $0000 to $000a : header
- 2 bytes : signature, always "CM"
- 4 bytes: decoded data length, low endian
- 4 bytes: encoded data length, low endian
- From $000a : ENCODED_DATA
- Then FLAGS. Flags are read bit per bit :
- if bit = 0, then put one byte from ENCODED_DATA and put into DECODED_STREAM
- if bit = 1, then the corresponding half-word in ENCODED_DATA is of the form lllloooooooooooo, where l = length and o = offset. Copy then 'length + 3' bytes from DECODED_STREAM[current_position - offset + 1] to DECODED_STREAM[curent_position].
- Fill the file with $00, up to have a file size dividible by $800.
Graphics files (SGGG)
They are just 256 colors palette indexed bitmap files.
- bytes $0 to $3 : 'SGGG' (identifier)
- bytes $4 to $7 : always 1, usage unknown
- bytes $8 to $9 : width (Little Endian)
- bytes $a to $b : height (LE)
- bytes $c to $f : unknown
- bytes $10 to $410 : palette. Each color is 32b RGBA. Alpha max seems to be $80 (and most colors are alpha max). Colors are stored in a weird way though :
- colors $0 to $7
- colors $10 to $17
- colors $8 to $f
- colors $18 to 1f
- and so on...
- from bytes $410 : bitmap. The picture seems cut in 512×512 blocks in scan order, each of which described row per row, from top to bottom.
For example, a 640×448 bitmap is cut in 2 rects, one with pixels (0 - 511, 0 - 447) and the other (512 - 639, 0 - 447). No bitmap actually need more than 2 rects.
- some files may contain other palettes after the bitmap.
The font file is file 0002 in MAPDATA.DAT archive. It's a SGGG file (see above) with the following characteristics :
- its size is 512×512
- its palette contains 64 times the 4 same colors : $FFFFFF00, $FFFFFF3A, $FFFFFF5F, $FFFFFF7F. They are all white colors, with varying alpha, for antialiasing purposes when drawing the character
- the bitmap file is actually made of 4 512×512 layers ; each byte in the bitmap part of the SGGG codes 4 pixels, one for each layer :
- bits 0-1 code a 4 colour pixel in layer 0
- bits 2-3 code a 4 colour pixel in layer 1
- bits 4-5 code a 4 colour pixel in layer 2
- bits 6-7 code a 4 colour pixel in layer 3
We can thus obtain those 4 characters sheets :
(todo : insert them)
They are all located in MAPDATA.DAT archive file.
A map is made of several layers, from top to bottom. The layer is made of tiles (always 32×32), found in SGGG files. To know which tileset is used for a given layer can be found in the SLPM_625.53 file.
The last layer is the collision map. The tileset file associated is always MAPDATA.DAT\0112.
Map file specification
- 4 bytes : number of planes, excluding the collision map plane
- 4 bytes : width (in tiles)
- 4 bytes : height (in tiles)
- 4 bytes : unknown (always 07000000)
- 16 bytes : unknown (always 01000000 00000000 00000000 00000000)
- from pos 32 : layers info
- 1 byte : tileset id (a same tileset can be shared between several layers)
- 1 byte : blend mode
Usually 0 (classical blend with a unique alpha value for the entire layer). When set to 1, blend multiplying RGB value by the alpha value, then add RGB values with the bottom layer.
- 1 byte : alpha (on a base 100)
- 1 byte : unknown. Generally 100, can be greater (e.g. in file 0176)
- 12 bytes : unknown (generally 0s)
- layer data
Layer is parsed from top row to bottom row, each row from left to right. Two bytes per tile, the two most significant bits code flipping.
- just before the collision layer : Treasure boxes data
- 4 bytes : number of boxes, then for each box :
- 4 bytes : unknown (8 for boxes)
- 4 bytes : x position (in pixels, not tiles)
- 4 bytes : y position
- 2 bytes : unknown (0 or 1)
- 2 bytes : unknown. likely event id (each box in a map has a different number, starting from 0)
- 12 bytes : unknown (generally 0s)
- after collision layer : lift data
- 4 bytes : number of lifts, then for each
- 4 bytes : id ?
- 2 bytes : x position (in pixels)
- 2 bytes : y position
- 2 bytes : width
- 2 bytes : height