Jump to content

OBD:TXMP: Difference between revisions

m
wording
m (clearer representation of bitset values)
m (wording)
 
Line 3: Line 3:
TXMP is the only known instance type that is interpreted differently by the three kinds of Oni engines on the three platforms (Windows, Mac and PS2).
TXMP is the only known instance type that is interpreted differently by the three kinds of Oni engines on the three platforms (Windows, Mac and PS2).


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 this merely amounts to using different fields within the same 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 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.
Line 66: Line 66:
{{OBDtr| 0x94 | link    |FFC8FF| 00 00 00 00 | unused    | link to a [[OBD:TXAN|TXAN]] file; used if this texture is animated }}
{{OBDtr| 0x94 | link    |FFC8FF| 00 00 00 00 | unused    | link to a [[OBD:TXAN|TXAN]] file; used if this texture is animated }}
{{OBDtr| 0x98 | link    |FFC800| 00 00 00 00 | unused    | link to a TXMP file that contain the environment map  }}
{{OBDtr| 0x98 | link    |FFC800| 00 00 00 00 | unused    | link to a TXMP file that contain the environment map  }}
{{OBDtr| 0x9C | offset  |C800C8| 20 00 00 00 |00 00 00 20| offset of pixel data in the raw file (Windows retail only) }}
{{OBDtr| 0x9C | offset  |C800C8| 20 00 00 00 |00 00 00 20| offset of pixel data in the raw file (v1.0 engine only) }}
{{OBDtr| 0xA0 | offset  |C87C64| 00 00 00 00 | unused    | offset of pixel data in the separate file (Windows demo and Mac only) }}
{{OBDtr| 0xA0 | offset  |C87C64| 00 00 00 00 | unused    | offset of pixel data in the separate file (v1.1 engine only) }}
{{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.