OniGalore

OBD:TXMP: Difference between revisions

OBD Discussion

OBD:TXMP (view source)

Revision as of 01:58, 8 December 2023

1,830 bytes added ,  8 December 2023
m
changed family
m (changed family)
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{OBD_File_Header | type=TXMP | prev=TXMB | next=TxtC | name=Texture Map | family=Generic | align=center}}
{{OBD_File_Header | type=TXMP | prev=TXMB | next=TxtC | name=Texture Map | family=General | align=center}}


TXMP is the only known instance type that is interpreted differently by the three kinds of Oni engines on the three plaftorms (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 plaftorms (Windows, Mac and PS2).


The difference between "PC" (Windows retail) and "Mac" (Windows demo and Mac proper) is minor, even though the checksums are different, and can One stores pixel data in the .raw file, and the other in a .sep file. Apart from that the data format is common (even though the template checksums are different), and is described in the first section below.
The difference between "PC" (Windows retail) and "Mac" (Windows demo and Mac proper) 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 "PC" TXMPs store their pixel data in the .raw file, and "Mac" TXMPs use the .sep file, but this merely amounts to using different fields within the same structure. Thus, even though the template checksums for "Mac" and "PC" are different, both formats can easily be described in common.


The PS2 implementation is significantly different from the other two. It is  
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.


==Windows and Mac TXMP==
==Windows and Mac TXMP==
Line 105: Line 105:
*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 shifted 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. 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).  
*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.  
*The pixel format (shifted to 0x94) is typically 0x10, sometimes 0x11. The pixel data is stored in the .raw file at the address
*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.
*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 the rl_1 TXMP looks in level3_Final.dat of the English retail PS2 version.
Line 112: Line 113:
{{OBD_Table_Header}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
|- ALIGN=CENTER VALIGN=TOP
{{OBDtr| 0x90 | int32    |C8FFC8| 56 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        | texture format #16 (8-bit indexed); #17 also occurs (the difference is not yet documented); other values not yet observed }}
{{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 | unused    | 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 contain the environment map  }}
{{OBDtr| 0x9C | link    |FFC800| 00 00 00 00 | unused    | link to a TXMP file that contains the environment map  }}
{{OBDtr| 0xA0 | offset  |C800C8| C0 05 00 00 |00 00 05 C0| position of the pixel data in the .raw file }}
{{OBDtr| 0xA0 | offset  |C800C8| C0 05 00 00 |00 00 05 C0| position of the pixel data in the .raw file }}
{{OBDtr| 0xA4 | offset  |C87C64| 00 00 00 00 | unused    | position of the pixel data in the .sep file (unused) }}
{{OBDtr| 0xA4 | offset  |C87C64| 00 00 00 00 | unused    | position of the pixel data in the .sep file (unused) }}
{{OBDtr| 0xA8 | int32    |B0C3D4| 00 00 00 00 | 0        | "material type" (supposedly); same runtime usage 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      | actually probably a runtime field used as a pointer to the texture name }}
{{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| 0xB0 | char[4]  |B0C3D4| AD DE AD DE | dead      | actually more runtime fields (flags) used for rendering optimization }}
{{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
Unlike for PC or 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).
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).
Environment/character/particle TXMPs seem to be using .raw storage consistently (not checked beyond level1_Final). As a notable anomaly, .sep storage is used for the following three textures (console screens) in level0_Final: _CON_SAVEGAME (main TXMP only; the animation frames use .raw storage), _CON_SAVEGAME_USED, _CON_USED.
<!--
<!--
;Oni's internal storage types
;Oni's internal storage types
Line 475: Line 483:
<references/>
<references/>


{{OBD_File_Footer | type=TXMP | prev=TXMB | next=TxtC | name=Texture Map | family=Generic}}
{{OBD_File_Footer | type=TXMP | prev=TXMB | next=TxtC | name=Texture Map | family=General}}


{{OBD}}
{{OBD}}
ValBot
Bots
2,112

edits

Retrieved from "https://wiki.oni2.net/Special:MobileDiff/38728...41907"