OBD:TXMP
|
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 PS2 implementation is significantly different from the other two. It is
Windows and Mac TXMP
Offset | Type | Raw Hex | Value | Description |
---|---|---|---|---|
0x00 | res_id | 01 1F 00 00 | 31 | 00031-rl_1.TXMP |
0x04 | lev_id | 01 00 00 06 | 3 | level 3 |
0x08 | char[128] | rl_1 | name of the texture; unused | |
0x88 | int32 | 00 10 00 00 | 0x1000 | options; possible option flags (from left to right):
|
0x8C | int16 | 80 00 | 128 | width of the image in pixels |
0x8E | int16 | 80 00 | 128 | height of the image in pixels |
0x90 | int32 | 01 00 00 00 | 1 | texture format #1 (RGB555); see below for list of available formats.
|
0x94 | link | 00 00 00 00 | unused | link to a TXAN file; used if this texture is animated |
0x98 | link | 00 00 00 00 | unused | link to a TXMP file that contain the environment map |
0x9C | offset | 20 00 00 00 | 00 00 00 20 | at this position starts the texture part in the raw file (Windows retail only) |
0xA0 | offset | 00 00 00 00 | unused | at this position starts the texture part in the separate file (Windows demo and Mac only) |
0xA4 | char[12] | AD DE | dead | The layout of these 12 bytes is different for the "PC" and "Mac" versions (i.e. Windows retail vs. Windows demo and Mac):
Since runtime fields are grouped at the end, PC and Mac TXMPs are treated by OniSplit under the same template, merely switching between the .raw and .sep links, and blanking out everything past 0xA4. |
0xB0 | char[16] | AD DE | dead | completely unused bytes (not part of the PC or Mac TXMP template) |
- Effect options
- "Shield", "Invisibility" and "Daodan shield" options do not affect the texture reading/drawing in any way. The texture data is still RGB555 or whatever format the texture format field says it is. The effect of these flags is that the engine uses vertex shading with a colour that varies with time.
- Animation time
When using animated textures the image to display is selected using the game time and animation speed. For textures that are used by particles the local (particle) time can be used either to replace or offset the game time.
- Pixel storage order
- Pixels are stored in row-major order, meaning that all the pixels forming a scanline (image row) are grouped together (stored in left-to right order); the rows are stored in bottom-to-top order (see illustration below).
- In the case of the DXT1 storage format, the row-major, left-to-right, bottom-to-top order applies to the 4x4 blocks composing the image, and also inside each 4x4 block for the storage of 2-bit pixels.
- In the case of the I1 format (several pixels per byte), the row-major, left-to-right, bottom-to-top order applies to the 1-bit pixels composing the image.
how it's stored | how you'll see it | |
---|---|---|
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.
- 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).
- 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.
- 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
Here is how the end of the rl_1 TXMP looks in level3_Final.dat of the English retail PS2 version.
Offset | Type | Raw Hex | Value | Description |
---|---|---|---|---|
0x90 | int32 | 56 00 | 86 | index of the 256-color palette used by this texture (starts at 0x15800 in level3_palette.pal) |
0x94 | int32 | 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 |
0x98 | link | 00 00 00 00 | unused | link to a TXAN file; used if this texture is animated |
0x9C | link | 00 00 00 00 | unused | link to a TXMP file that contain the environment map |
0xA0 | offset | C0 05 00 00 | 00 00 05 C0 | position of the pixel data in the .raw file |
0xA4 | offset | 00 00 00 00 | unused | position of the pixel data in the .sep file (unused) |
0xA8 | int32 | 00 00 00 00 | 0 | "material type" (supposedly); same runtime usage as for Windows demo and Mac |
0xAC | char[4] | AD DE AD DE | dead | actually probably a runtime field used as a pointer to the texture name |
0xB0 | char[4] | AD DE AD DE | dead | actually more runtime fields (flags) used for rendering optimization |
0xB4 | char[12] | AD DE | dead | completely unused bytes (not part of the template) |
Notes
- ↑ Storage format 7 was jointly used by OniSplit, Daodan DLL and the Intel Mac build to allow for 32-bit textures with transparency - most importantly experimental lightmaps, see HERE. However, the actual storage format used in this case was RGBA_Bytes (type 11), and type 7 was used by mistake.
- ↑ Storage format 11 (RGBA_Bytes) was effectively implemented by OniSplit to allow for 32-bit textures with transparency - most importantly experimental lightmaps, see HERE. However, it was mislabeled as type 7 (ARGB8888) by OniSplit, Daodan DLL and the Intel Mac build, which resulted in byte swapping and the requirement of authoring PC and Mac versions of TXMPs.
ONI BINARY DATA |
---|
TXMB << Other file types >> TxtC |
TXMP : Texture Map |
Generic file |