20,500
edits
m (wording) |
(Claude helped me finish REing the PS2 format; I've arranged the existing information better and integrated Claude's suggested corrections) |
||
| Line 100: | Line 100: | ||
==PS2 implementation== | ==PS2 implementation== | ||
The PS2 TXMP layout is similar to PC, with notable differences in the last few bytes due to Rockstar moving to 32-bit indexed color | The PS2 TXMP layout is similar to PC, with notable differences in the last few bytes due to Rockstar moving to a PS2-standard 32-bit indexed color ("CLUT") system for optimization purposes. Here are the high-level differences: | ||
*There are 4 extra bytes of storage as compared to a v1.1 TXMP (which is already 4 bytes larger than a v1.0 TXMP). | *There are 4 extra bytes of storage as compared to a v1.1 TXMP (which is already 4 bytes larger than a v1.0 TXMP). | ||
*The extra 4 bytes come from a palette index (int32) inserted at 0x90 before the pixel format (which is pushed down to 0x94 along with everything else that follows). | *The extra 4 bytes come from a palette index (int32) inserted at 0x90 before the pixel format (which is pushed down to 0x94 along with everything else that follows). | ||
*Two new pixel formats were added, and are the only formats used on PS2: type 16 for opaque textures (indexed 32-bit RGB with ignored alpha byte), and type 17 for transparent textures (indexed 32-bit RGBA). | |||
*Two new pixel formats were added, and are the only formats used on PS2: type 16 for opaque textures | |||
*The pixel data (color indices) can be stored either in the .raw file (pointer field at 0xA0) or in the .sep file (pointer at 0xA4). | *The pixel data (color indices) can be stored either in the .raw file (pointer field at 0xA0) or in the .sep file (pointer at 0xA4). | ||
Here is how the end of TXMPrl_1 looks in level3_Final.dat of the English retail PS2 version. | Here is how the end of TXMPrl_1 looks in level3_Final.dat of the English retail PS2 version. | ||
| Line 125: | Line 122: | ||
|} | |} | ||
;Palette file format | |||
*Palettes are stored per-level in level#_palette.pal files in a pal/ subdirectory of GameDataFolder, corresponding to how .raw and .sep files are stored in raw/ and sep/ subdirectories. | |||
*Each level#_palette.pal file contains between 85 and 179 palettes, not counting the first palette (index 0) at the start of each .pal file which is always blank. | |||
;Palette format | |||
*Valid palette indices start at 1. Each palette consists of 256 32-bit colors and takes up 1024 bytes. | |||
*Each 4-byte palette entry is stored as R, G, B, A in memory order (byte 0 = red, byte 1 = green, byte 2 = blue, byte 3 = alpha). This is the same layout as RGBA_Bytes (type 11), not the reversed BGRA order used by most of the other texture formats. | |||
*Each pixel in the .raw or .sep data is stored as a 1-byte index into the image's chosen color palette. | |||
;Palette CLUT swizzle | |||
:The PS2 Graphics Synthesizer (GS) stores CLUT entries in a scrambled order due to its hardware cache line layout. Within every 32-entry block of the palette, entries 8–15 and 16–23 are swapped relative to their logical positions. Software reading the palette must undo this before using it as a palette index. | |||
;Ignored alpha byte for type 16 | |||
:The fourth byte would represent alpha, but in RGB888 it is merely a padding byte, always set to 0x80. | |||
;Alpha scaling for type 17 | |||
:The PS2 GS uses a half-range alpha where 0x00 = fully transparent and 0x80 = fully opaque (values above 0x80 are technically possible but indicate "source alpha contribution > 1" in GS blending, which doesn't arise in Oni). | |||
;Alternating use of .raw or .sep storage | ;Alternating use of .raw or .sep storage | ||