OniGalore

OBD:TXMP: Difference between revisions

OBD Discussion

OBD:TXMP (view source)

Revision as of 23:56, 4 April 2026

103 bytes added ,  4 April
m
wording
m (added note to clarify that I8 is used and yet is not used by TSFT)
m (wording)
Line 5: Line 5:
The difference between the format used in v1.0 of the engine (Windows retail) and v1.1 (Windows demo, Mac, [[OniX]]) is minor, at least from the point of view of disk storage (the structural difference is limited to runtime fields grouped at the end of the instance, which is why they haven't been documented or implemented in OniSplit). A more obvious difference is that v1.0 TXMPs store their pixel data in the .raw file and v1.1 TXMPs use the .sep file, but as far as the .dat is concerned this merely amounts to using a different data pointer field within the TXMP structure. Thus, even though the template checksums for v1.0 and v1.1 are different, both formats can easily be described together.
The difference between the format used in v1.0 of the engine (Windows retail) and v1.1 (Windows demo, Mac, [[OniX]]) is minor, at least from the point of view of disk storage (the structural difference is limited to runtime fields grouped at the end of the instance, which is why they haven't been documented or implemented in OniSplit). A more obvious difference is that v1.0 TXMPs store their pixel data in the .raw file and v1.1 TXMPs use the .sep file, but as far as the .dat is concerned this merely amounts to using a different data pointer field within the TXMP structure. Thus, even though the template checksums for v1.0 and v1.1 are different, both formats can easily be described together.


The PS2 implementation is significantly different from the other two, in that it systematically uses indexed colors: instead of color being stored in the pixel data itself, each pixel is merely an 8-bit index into a 256-color palette (palettes are stored per-level, in files named level0_palette.pal etc). This difference is detailed in a separate section at the bottom of the page.
The PS2 implementation is significantly different from the other two, in that it systematically uses indexed colors: instead of color being stored in the pixel data itself, each pixel is merely an index into a custom 256-color palette. This format is detailed under {{SectionLink||PS2 implementation}}.


==Windows and Mac TXMP==
==Windows/Mac implementation==
[[Image:txmp_all.gif]]
[[Image:txmp_all.gif]]


Line 70: Line 70:
{{OBDtr| 0xA4 | char[12] |B0C3D4| AD DE      | dead      | The layout of these 12 bytes is different for the v1.0 and v1.1 versions (i.e. Windows retail vs. Windows demo and Mac):
{{OBDtr| 0xA4 | char[12] |B0C3D4| AD DE      | dead      | The layout of these 12 bytes is different for the v1.0 and v1.1 versions (i.e. Windows retail vs. Windows demo and Mac):
*For a v1.1 TXMP, the four bytes at 0xA4-A7 are "00 00 00 00" instead of "AD DE AD DE", and correspond to a "material type" attributed at runtime (from [[TMBD]]), which is then used for impact/breakability lookup. The Windows retail TXMPs apparently have no such "material type" field.
*For a v1.1 TXMP, the four bytes at 0xA4-A7 are "00 00 00 00" instead of "AD DE AD DE", and correspond to a "material type" attributed at runtime (from [[TMBD]]), which is then used for impact/breakability lookup. The Windows retail TXMPs apparently have no such "material type" field.
*The fields at 0xA8-AF (for v1.1) or 0xA4-AB (for v1.0) are used only at runtime (and somehow obfuscated by "DEAD" when written to disk). Judging by the Windows demo and Mac engine, we can assume they are the same in both engines, and serve for rendering optimization (there is a texture name pointer, a "dirty" flag stored as a byte and 3 extra bytes used as flags).
*The fields at 0xA8-AF (for v1.1) or 0xA4-AB (for v1.0) are used only at runtime (and somehow obfuscated by "0xDEAD" when written to disk). Judging by the Windows demo and Mac engine, we can assume they are the same in both engines, and serve for rendering optimization (there is a texture name pointer, a "dirty" flag stored as a byte and 3 extra bytes used as flags).
*For Windows retail, the four bytes at 0xAC-AF are completely unused (not part of the template).
*For Windows retail, the four bytes at 0xAC-AF are completely unused (not part of the template).
Since runtime fields are grouped at the end, v1.0 and v1.1 TXMPs are treated by OniSplit under the same template, merely switching between the .raw and .sep links and blanking out everything past 0xA4.
Since runtime fields are grouped at the end, v1.0 and v1.1 TXMPs are treated by OniSplit under the same template, merely switching between the .raw and .sep links and blanking out everything past 0xA4.
Line 100: Line 100:


==PS2 implementation==
==PS2 implementation==
The TXMP layout is mostly the same on the PS2 platform as on the other two, with differences only in the last few bytes.
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, presumably to save memory on a very RAM-limited system:
*There are 4 extra bytes of storage as compared to a Windows demo and Mac TXMP (which is already 4 bytes larger than a Windows retail 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 shifted 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).
*Valid palette indices start at 1. Palettes are stored per-level in level#_palette.pal files. Each palette consists of 256 32-bit colors and takes up 1024 bytes.
*Valid palette indices start at 1. 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 palette consists of 256 32-bit colors and takes up 1024 bytes.
*The level#_palette.pal files have between 85 and 179 palettes, not counting the first palette (index 0) at the start of each .pal file, which is always blank.  
*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.
*The pixel format (shifted to 0x94) has only two variants: 0x10 for opaque textures, meaning 32-bit RGB with ignored alpha, or 0x11 for transparent textures.
*Two new pixel formats were added, and are the only formats used on PS2: type 16 for opaque textures, meaning 32-bit RGB with ignored alpha, and type 17 for transparent 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). See below for an overview.
*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). See below for an overview.


Here is how the end of the rl_1 TXMP 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.
{{Table}}
{{Table}}
{{OBD_Table_Header}}
{{OBD_Table_Header}}
Line 114: Line 114:
{{OBDtr| 0x90 | int32    |C8FFC8| 56 00 00 00 | 86        | index of the 256-color palette used by this texture (starts at 0x15800 in level3_palette.pal) }}
{{OBDtr| 0x90 | int32    |C8FFC8| 56 00 00 00 | 86        | index of the 256-color palette used by this texture (starts at 0x15800 in level3_palette.pal) }}
{{OBDtr| 0x94 | int32    |C8FFFF| 10 00 00 00 | 16        | palette pixel format #16 (32-bit RGB, with inactive alpha); the other recurrent format is #17 (32-bit RGBA) }}
{{OBDtr| 0x94 | int32    |C8FFFF| 10 00 00 00 | 16        | palette pixel format #16 (32-bit RGB, with inactive alpha); the other recurrent format is #17 (32-bit RGBA) }}
{{OBDtr| 0x98 | link    |FFC8FF| 00 00 00 00 | unused    | link to a [[OBD:TXAN|TXAN]] file; used if this texture is animated }}
{{OBDtr| 0x98 | link    |FFC8FF| 00 00 00 00 | 0        | link to a [[OBD:TXAN|TXAN]] file; used if this texture is animated }}
{{OBDtr| 0x9C | link    |FFC800| 00 00 00 00 | unused    | link to a TXMP file that contains the environment map  }}
{{OBDtr| 0x9C | link    |FFC800| 00 00 00 00 | 0        | link to a TXMP file that contains the environment map  }}
{{OBDtr| 0xA0 | offset  |C800C8| C0 05 00 00 |00 00 05 C0| offset of the pixel data in the .raw file }}
{{OBDtr| 0xA0 | offset  |C800C8| C0 05 00 00 |00 00 05 C0| offset of the pixel data in the .raw file }}
{{OBDtr| 0xA4 | offset  |C87C64| 00 00 00 00 | unused    | offset of pixel data in the .sep file (unused) }}
{{OBDtr| 0xA4 | offset  |C87C64| 00 00 00 00 | 0        | offset of pixel data in the .sep file }}
{{OBDtr| 0xA8 | int32    |B0C3D4| 00 00 00 00 | 0        | always 0; supposedly the same "material type" (set at runtime) as for Windows demo and Mac }}
{{OBDtr| 0xA8 | int32    |B0C3D4| 00 00 00 00 | 0        | always 0; supposedly the same "material type" (set at runtime) as for Windows demo and Mac }}
{{OBDtr| 0xAC | char[4]  |B0C3D4| AD DE AD DE | dead      | supposedly the same texture name pointer (used at runtime) as for Windows demo and Mac }}
{{OBDtr| 0xAC | char[4]  |B0C3D4| AD DE AD DE | dead      | supposedly the same texture name pointer (set at runtime) as for Windows demo and Mac }}
{{OBDtr| 0xB0 | char[4]  |B0C3D4| AD DE AD DE | dead      | supposedly the same rendering optimization flags (runtime) as for Windows demo and Mac }}
{{OBDtr| 0xB0 | char[4]  |B0C3D4| AD DE AD DE | dead      | supposedly the same rendering optimization flags (runtime) as for Windows demo and Mac }}
{{OBDtr| 0xB4 | char[12] |B0C3D4| AD DE      | dead      | completely unused bytes (not part of the template) }}
{{OBDtr| 0xB4 | char[12] |B0C3D4| AD DE      | dead      | completely unused bytes (not part of the template) }}
|}
|}


;Alternative use of .raw or .sep storage
;Alternative use of .raw or .sep storage
Unlike the Win/Mac game data (where pixel data is stored exclusively in .raw or exclusively in .sep for all TXMPs), PS2 TXMPs use .raw and .sep storage alternatively, depending on the TXMP. The engine apparently uses the .sep pointer only if there is no .raw pointer (or vice versa).
Unlike the Win/Mac game data (where pixel data is stored exclusively in .raw or exclusively in .sep for all TXMPs), PS2 TXMPs use .raw and .sep storage alternatingly, depending on the TXMP. The engine apparently uses the .sep pointer if there is no .raw pointer (or vice versa).


Examples of textures using .sep storage are: all [[:Category:Fly-in_portraits|fly-in portraits]]; all [[:Category:Splashscreens|splashscreen]] components; some illustrations in Konoko's [[Data Comlink]] (namely, [[:File:TXMPLevel02move.png|combat move illustrations]] and [[:File:TXMPhypo.png|item illustrations]]; objectives and weapon illustrations use .raw storage).
Examples of textures using .sep storage are: all [[:Category:Fly-in_portraits|fly-in portraits]]; all [[:Category:Splashscreens|splashscreen]] components; some illustrations in Konoko's [[Data Comlink]] (namely, [[:File:TXMPLevel02move.png|combat move illustrations]] and [[:File:TXMPhypo.png|item illustrations]]; objectives and weapon illustrations use .raw storage).
Retrieved from "https://wiki.oni2.net/Special:MobileDiff/47032"