OBD:TXMP: Difference between revisions

From OniGalore
(discovered this huge section commented out – I have restored it, tried to correct the broken parts, deleted the incomplete parts, and removed any mention of Macs being big-endian since that hasn't been true since two architecture migrations ago; the table markup is still pretty busted but it's functional)
 
(9 intermediate revisions by 3 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 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 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==
 
[[Image:txmp_all.gif]]
[[image:txmp_all.gif]]




Line 36: Line 35:
{{OBDtr| 0x8E | int16    |C8FFC8| 80 00      | 128      | height of the image in pixels }}
{{OBDtr| 0x8E | int16    |C8FFC8| 80 00      | 128      | height of the image in pixels }}
{{OBDtr| 0x90 | int32    |C8FFFF| 01 00 00 00 | 1        | texture format #1 (RGB555); see below for list of available formats.
{{OBDtr| 0x90 | int32    |C8FFFF| 01 00 00 00 | 1        | texture format #1 (RGB555); see below for list of available formats.
:0 - ARGB4444, 16 bits/pixel (stored as a little-Endian int16, swaps to big Endian at runtime on Mac)
:0 - ARGB4444, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Four 4-bit channels, with bitmasks 0x000F (Blue), 0x00F0 (Green), 0x0F00 (Red) and 0xF000 (Alpha).
::Four 4-bit channels, with bitmasks 0x000F (Blue), 0x00F0 (Green), 0x0F00 (Red) and 0xF000 (Alpha).
:1 - RGB555, 16 bits/pixel (stored as a little-Endian int16, swaps to big Endian at runtime on Mac)
:1 - RGB555, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Three 5-bit channels, with bitmasks 0x001F (Blue), 0x03E0 (Green) and 0x7C00 (Red).
::Three 5-bit channels, with bitmasks 0x001F (Blue), 0x03E0 (Green) and 0x7C00 (Red).
:::N.B. The high bit (0x8000) is unused, but the convention is to always set it to 1.
:::N.B. The high bit (0x8000) is unused, but the convention is to always set it to 1.
:2 - ARGB1555, 16 bits/pixel (stored as a little-Endian int16, swaps to big Endian at runtime on Mac)
:2 - ARGB1555, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Three 5-bit channels with bitmasks 0x001F (Blue), 0x03E0 (Green) and 0x7C00 (Red), 1-bit alpha (0x8000).
::Three 5-bit channels with bitmasks 0x001F (Blue), 0x03E0 (Green) and 0x7C00 (Red), 1-bit alpha (0x8000).
:3 (never used in Vanilla TXMPs) - I8, 8 bits/pixel, stored as a single byte. Monochrome "intensity" (256 levels of gray).
:3 (never used in vanilla TXMPs) - I8, 8 bits/pixel, stored as a single byte. Monochrome "intensity" (256 levels of gray).
:4 (never used in Vanilla TXMPs) - I1, 8 pixels/byte. Pixel rows, bottom to top. Monochrome "intensity" (black-or-white).
:4 (never used in vanilla TXMPs) - I1, 8 pixels/byte. Pixel rows, bottom to top. Monochrome "intensity" (black-or-white).
:5 (never used in Vanilla TXMPs) - A8, 8 bits/pixel, stored as a single byte. Standalone alpha (256 levels of opacity).
:5 (never used in vanilla TXMPs) - A8, 8 bits/pixel, stored as a single byte. Standalone alpha (256 levels of opacity).
:6 (never used in Vanilla TXMPs) - A4I4, 8 bits/pixel, stored as a single byte. Intensity (bit mask 0x0F), alpha (0xF0).
:6 (never used in vanilla TXMPs) - A4I4, 8 bits/pixel, stored as a single byte. Intensity (bit mask 0x0F), alpha (0xF0).
:7 (never used in Vanilla TXMPs<ref>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 [[Lightmapping_levels|HERE]]. However, the actual storage format used in this case was RGBA_Bytes (type 11), and type 7 was used by mistake.</ref>) - ARGB8888, 32 bits/pixel (stored as a little-Endian int32, swaps to big Endian at runtime on a PowerPC Mac)
:7 (never used in vanilla TXMPs<ref>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 [[Lightmapping_levels|HERE]]. However, the actual storage format used in this case was RGBA_Bytes (type 11), and type 7 was used by mistake.</ref>) - ARGB8888, 32 bits/pixel (stored as a little-endian int32, swaps to big-endian at runtime on a PowerPC Mac)
::Four 8-bit channels, with bitmasks 0x000000FF (Blue), 0x0000FF00 (Green), 0x00FF0000 (Red) and 0xFF000000 (Alpha).
::Four 8-bit channels, with bitmasks 0x000000FF (Blue), 0x0000FF00 (Green), 0x00FF0000 (Red) and 0xFF000000 (Alpha).
:8 - RGB888, 32 bits/pixel (stored as a little-Endian int32, swaps to big Endian at runtime on Mac)
:8 - RGB888, 32 bits/pixel (stored as a little-endian int32, swaps to big-endian at runtime on Mac)
::Three 8-bit channels, with bitmasks 0x000000FF (Blue), 0x0000FF00 (Green) and 0x00FF0000 (Red).
::Three 8-bit channels, with bitmasks 0x000000FF (Blue), 0x0000FF00 (Green) and 0x00FF0000 (Red).
:::N.B. The high byte (0xFF000000) is unused, but the convention is to always set it to 0x00.
:::N.B. The high byte (0xFF000000) is unused, but the convention is to always set it to 0x00.
:9 - S3TC/DXT1, RGB565 compressed 4 times ([https://www.khronos.org/opengl/wiki/S3_Texture_Compression GL_COMPRESSED_RGB_S3TC_DXT1_EXT] OpenGL texture format)
:9 - S3TC/DXT1, RGB565 compressed 4 times ([https://wikis.khronos.org/opengl/S3_Texture_Compression GL_COMPRESSED_RGB_S3TC_DXT1_EXT] OpenGL texture format)
:10 (never used in Vanilla TXMPs) - RGB_Bytes, 24 bits/pixel, stored as 3 consecutive bytes: first Red, then Green, then Blue.
:10 (never used in vanilla TXMPs) - RGB_Bytes, 24 bits/pixel, stored as 3 consecutive bytes: first Red, then Green, then Blue.
::N.B. Unlike for RGB888 (type 8), the storage is compact, with no unused alpha bit.
::N.B. Unlike for RGB888 (type 8), the storage is compact, with no unused alpha bit.
:11 (never used in Vanilla TXMPs<ref>Storage format 11 (RGBA_Bytes) was effectively implemented by OniSplit to allow for 32-bit textures with transparency - most importantly experimental lightmaps, see [[Lightmapping_levels|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.</ref>) - RGBA_Bytes, 32 bits/pixel, stored as 4 consecutive bytes: first Red, then Green, then Blue, then Alpha.
:11 (never used in vanilla TXMPs<ref>Storage format 11 (RGBA_Bytes) was effectively implemented by OniSplit to allow for 32-bit textures with transparency - most importantly experimental lightmaps, see [[Lightmapping levels|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 Windows and Mac versions of TXMPs.</ref>) - RGBA_Bytes, 32 bits/pixel, stored as 4 consecutive bytes: first Red, then Green, then Blue, then Alpha.
:12 (never used in Vanilla TXMPs) - RGBA5551, 16 bits/pixel (stored as a little-Endian int16, swaps to big Endian at runtime on Mac)
:12 (never used in vanilla TXMPs) - RGBA5551, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Three 5-bit channels with bitmasks 0x003E (Blue), 0x07C0 (Green) and 0xF800 (Red), 1-bit alpha (0x0001).
::Three 5-bit channels with bitmasks 0x003E (Blue), 0x07C0 (Green) and 0xF800 (Red), 1-bit alpha (0x0001).
:13 (never used in Vanilla TXMPs) - RGBA4444, 16 bits/pixel (stored as a little-Endian int16, swaps to big Endian at runtime on Mac)
:13 (never used in vanilla TXMPs) - RGBA4444, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Four 4-bit channels, with bitmasks 0x00F0 (Blue), 0x0F00 (Green), 0xF000 (Red) and 0x000F (Alpha).
::Four 4-bit channels, with bitmasks 0x00F0 (Blue), 0x0F00 (Green), 0xF000 (Red) and 0x000F (Alpha).
:14 (never used in Vanilla TXMPs) - RGB565, 16 bits/pixel (stored as a little-Endian int16, swaps to big Endian at runtime on Mac)
:14 (never used in vanilla TXMPs) - RGB565, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Two 5-bit channels with bitmasks 0x001F (Blue) and 0xF800 (Red), 6-bit Green channel (0x07E0).
::Two 5-bit channels with bitmasks 0x001F (Blue) and 0xF800 (Red), 6-bit Green channel (0x07E0).
:15 (never used in Vanilla TXMPs) - ABGR1555, 16 bits/pixel (stored as a little-Endian int16, swaps to big Endian at runtime on Mac)
:15 (never used in vanilla TXMPs) - ABGR1555, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
::Three 5-bit channels with bitmasks 0x001F (Red), 0x03E0 (Green) and 0x7C00 (Blue), 1-bit alpha (0x8000).
::Three 5-bit channels with bitmasks 0x001F (Red), 0x03E0 (Green) and 0x7C00 (Blue), 1-bit alpha (0x8000).
}}
}}
{{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| at this position starts the texture part 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 (Windows retail only) }}
{{OBDtr| 0xA0 | offset  |C87C64| 00 00 00 00 | unused    | at this position starts the texture part 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 (Windows demo and Mac only) }}
{{OBDtr| 0xA4 | char[12] |B0C3D4| 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):
{{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 Mac or Windows demo 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 Windows demo and Mac) or 0xA4-AB (for Windows retail) 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 "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).
*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, 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.
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.
}}
}}
{{OBDtr| 0xB0 | char[16] |B0C3D4| AD DE      | dead      | completely unused bytes (not part of the PC or Mac TXMP template) }}
{{OBDtr| 0xB0 | char[16] |B0C3D4| AD DE      | dead      | completely unused bytes (not part of the v1.0 or v1.1 TXMP template) }}
|}
|}


Line 105: Line 104:
*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 112:
{{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| offset 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    | offset of 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) }}
|}
|}
<!--
 
;Oni's internal storage types
;Alternative use of .raw or .sep storage
There are 16 types of image storage in Oni:
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).
*The first 9 types are stored as integers (little Endian in PC memory and in TXMP, big Endian in Mac memory)
 
The
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).
{|border=1 cellspacing=0 cellpadding=3
 
!N°
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.
!ID
 
!Examples for colors
==Oni's internal storage types==
!Notes
Some of Oni's 16 types of image storage are elaborated on below in order to illustrate exactly how they work. The RAM view assumes little-endianness, which is true for Windows and for Macs since 2006.
|-
 
|0
===ARGB4444 (type 0)===
|ARGB4444
|0x00 0xFC
|
|Treated as 16-bit integer: stored as big-endian in TXMP (first the AAAARRRR byte, then the GGGGBBBB byte), but byte-swapped to little-endian on Mac platforms.
|-
|1
|RGB555
|16-bit integer, unused high bit set to 1
|Red: 0xStored in little-endian order in TXMP, unused high bit is set to 1. #FF0000
|-
|}
Bits (low-to-high) of storage bytes as in TXMP (little-endian)
----
;ARGB4444 (format N°0)
*A 16-bit field is used to store 4 color channels (4 bits each, values from 0 to 15).
*A 16-bit field is used to store 4 color channels (4 bits each, values from 0 to 15).
*Bit masks are 0x000F for Blue, 0x00F0 for Green, 0x0F00 for Red, 0xF000 for Alpha.
*Bit masks are 0x000F for Blue, 0x00F0 for Green, 0x0F00 for Red, 0xF000 for Alpha.
*In Mac RAM the two bytes appear in big Endian order (high byte first).
*Stored as big-endian in TXMP (first the AAAARRRR byte, then the GGGGBBBB byte).
*In PC RAM and in TXMP files the two bytes appear in little Endian order.
{|border=1 cellpadding=3 cellspacing=0
{|border=1 cellpadding=3 cellspacing=0
!<br/>Bits
!<br>Bits
!Byte 1 (high)<br/><code>7 6 5 4 3 2 1 0</code>
!Byte 1 (high)<br><code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low)<br/><code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low)<br><code>7 6 5 4 3 2 1 0</code>
|-
|-
!Masks||<code>A A A A R R R R</code>||<code>G G G G B B B B</code>
!Masks||<code>A A A A R R R R</code>||<code>G G G G B B B B</code>
|-
|-
!colspan=3|<br/>Bit values for primary colors (fully opaque)
!colspan=3|<br>Bit values for primary colors (fully opaque)
!Hex view<br/>(Mac RAM)
!Hex view
!(TXMP and <br/>PC RAM)
!RAM view
|-
|-
|Black||<code>1 1 1 1 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
|Black||<code>1 1 1 1 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
Line 188: Line 173:
!FF F0!!F0 FF
!FF F0!!F0 FF
|}
|}
----
 
;RGB555 (format N°1)
===RGB555 (type 1)===
*A 16-bit field is used to store 3 color channels (5 bits each, values from 0 to 31).
*A 16-bit field is used to store 3 color channels (5 bits each, values from 0 to 31).
*Bit masks are 0x001F for Blue, 0x03E0 for Green, 0x7C00 for Red.
*Bit masks are 0x001F for Blue, 0x03E0 for Green, 0x7C00 for Red.
*The high bit (0x8000) is unused, but is always set to 1 by convention.   
*The high bit (0x8000) is unused, but is always set to 1 by convention.   
*In Mac RAM the two bytes appear in big Endian order (high byte first).
*Stored in little-endian order in TXMP.
*In PC RAM and in TXMP files the two bytes appear in little Endian order.
{|border=1 cellpadding=3 cellspacing=0
{|border=1 cellpadding=3 cellspacing=0
!<br/>Bits
!<br>Bits
!Byte 1 (high)<br/><code>7 6 5 4 3 2 1 0</code>
!Byte 1 (high)<br><code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low)<br/><code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low)<br><code>7 6 5 4 3 2 1 0</code>
|-
|-
!Masks||<code>X R R R R R G G</code>||<code>G G G B B B B B</code>
!Masks||<code>X R R R R R G G</code>||<code>G G G B B B B B</code>
|-
|-
!colspan=3|<br/>Bit values for primary colors
!colspan=3|<br>Bit values for primary colors
!Hex view<br/>(Mac RAM)
!Hex view
!(TXMP and <br/>PC RAM)
!RAM view
|-
|-
|Black||<code>1 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
|Black||<code>1 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
Line 230: Line 214:
!FF E0!!E0 FF
!FF E0!!E0 FF
|}
|}
----
 
;ARGB1555 (format N°2)
===ARGB1555 (type 2)===
*A 16-bit field is used to store 3 color channels (5 bits each, values from 0 to 31) and one 1-bit channel.
*A 16-bit field is used to store 3 color channels (5 bits each, values from 0 to 31) and one 1-bit channel.
*Bit masks are 0x001F for Blue, 0x03E0 for Green, 0x7C00 for Red, and 0x8000 for Alpha.
*Bit masks are 0x001F for Blue, 0x03E0 for Green, 0x7C00 for Red, and 0x8000 for Alpha.
*In Mac RAM the two bytes appear in big Endian order (high byte first).
*In PC RAM and in TXMP files the two bytes appear in little Endian order.
{|border=1 cellpadding=3 cellspacing=0
{|border=1 cellpadding=3 cellspacing=0
!<br/>Bits
!<br>Bits
!Byte 1 (high)<br/><code>7 6 5 4 3 2 1 0</code>
!Byte 1 (high)<br><code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low)<br/><code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low)<br><code>7 6 5 4 3 2 1 0</code>
|-
|-
!Masks||<code>A R R R R R G G</code>||<code>G G G B B B B B</code>
!Masks||<code>A R R R R R G G</code>||<code>G G G B B B B B</code>
|-
|-
!colspan=3|<br/>Bit values for primary colors (opaque)
!colspan=3|<br>Bit values for primary colors (opaque)
!Hex view<br/>(Mac RAM)
!Hex view
!(TXMP and <br/>PC RAM)
!RAM view
|-
|-
|Black||<code>1 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
|Black||<code>1 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
Line 271: Line 253:
!FF E0!!E0 FF
!FF E0!!E0 FF
|}
|}
----
 
;A4I4 (format N°6)
===A4I4 (type 6)===
*An 8-bit field is used to store an intensity and an alpha (4 bits each, values from 0 to 15).
*An 8-bit field is used to store an intensity and an alpha (4 bits each, values from 0 to 15).
*Bit masks are 0x0F for Intensity, 0xF0 for Alpha.
*Bit masks are 0x0F for Intensity, 0xF0 for Alpha.
Line 298: Line 280:
|}
|}


----
===ARGB8888 (type 7)===
;ARGB8888 (format N°7)
*A 32-bit field is used to store 4 color channels (8 bits each, values from 0 to 255).
*A 32-bit field is used to store 4 color channels (8 bits each, values from 0 to 255).
*Bit masks are 0x000000FF for Blue, 0x0000FF00 for Green, 0x00FF0000 for Red, 0xFF000000 for Alpha.
*Bit masks are 0x000000FF for Blue, 0x0000FF00 for Green, 0x00FF0000 for Red, 0xFF000000 for Alpha.
*In Mac RAM the four bytes appear in big Endian order (high byte first).
*In PC RAM and in TXMP files the four bytes appear in little Endian order.
{|border=1 cellpadding=3 cellspacing=0
{|border=1 cellpadding=3 cellspacing=0
!<br/>Bits
!<br>Bits
!Byte 3 (highest)<br/><code>7 6 5 4 3 2 1 0</code>
!Byte 3 (highest)<br><code>7 6 5 4 3 2 1 0</code>
!Byte 2 (higher)<br/><code>7 6 5 4 3 2 1 0</code>
!Byte 2 (higher)<br><code>7 6 5 4 3 2 1 0</code>
!Byte 1 (high)<br/><code>7 6 5 4 3 2 1 0</code>
!Byte 1 (high)<br><code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low)<br/><code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low)<br><code>7 6 5 4 3 2 1 0</code>
|-
|-
!Masks||<code>A A A A A A A A</code>||<code>R R R R R R R R</code>||<code>G G G G G G G G</code>||<code>B B B B B B B B</code>
!Masks||<code>A A A A A A A A</code>||<code>R R R R R R R R</code>||<code>G G G G G G G G</code>||<code>B B B B B B B B</code>
|-
|-
!colspan=5|<br/>Bit values for primary colors (fully opaque)
!colspan=5|<br>Bit values for primary colors (fully opaque)
!Hex view<br/>(Mac RAM)
!Hex view
!(TXMP and <br/>PC RAM)
!RAM view
|-
|-
|Black||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
|Black||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
Line 341: Line 320:
!FF FF FF 00!!00 FF FF FF
!FF FF FF 00!!00 FF FF FF
|}
|}
----
 
;RGB888 (format N°8)
===RGB888 (type 8)===
*A 32-bit field is used to store 3 color channels (8 bits each, values from 0 to 255).
*A 32-bit field is used to store 3 color channels (8 bits each, values from 0 to 255).
*Bit masks are 0x000000FF for Blue, 0x0000FF00 for Green, 0x00FF0000 for Red.
*Bit masks are 0x000000FF for Blue, 0x0000FF00 for Green, 0x00FF0000 for Red.
*The high byte (0xFF000000) is unused, but is always set to 00 by convention.
*The high byte (0xFF000000) is unused, but is always set to 00 by convention.
*In Mac RAM the four bytes appear in big Endian order (high byte first).
*In PC RAM and in TXMP files the four bytes appear in little Endian order.
{|border=1 cellpadding=3 cellspacing=0
{|border=1 cellpadding=3 cellspacing=0
!<br/>Bits
!<br>Bits
!Byte 3 (highest)<br/><code>7 6 5 4 3 2 1 0</code>
!Byte 3 (highest)<br><code>7 6 5 4 3 2 1 0</code>
!Byte 2 (higher)<br/><code>7 6 5 4 3 2 1 0</code>
!Byte 2 (higher)<br><code>7 6 5 4 3 2 1 0</code>
!Byte 1 (high)<br/><code>7 6 5 4 3 2 1 0</code>
!Byte 1 (high)<br><code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low)<br/><code>7 6 5 4 3 2 1 0</code>
!Byte 0 (low)<br><code>7 6 5 4 3 2 1 0</code>
|-
|-
!Masks||<code>X X X X X X X X</code>||<code>R R R R R R R R</code>||<code>G G G G G G G G</code>||<code>B B B B B B B B</code>
!Masks||<code>X X X X X X X X</code>||<code>R R R R R R R R</code>||<code>G G G G G G G G</code>||<code>B B B B B B B B</code>
|-
|-
!colspan=5|<br/>Bit values for primary colors
!colspan=5|<br>Bit values for primary colors
!Hex view<br/>(Mac RAM)
!Hex view
!(TXMP and <br/>PC RAM)
!RAM view
|-
|-
|Black||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
|Black||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
Line 385: Line 362:
!00 FF FF 00!!00 FF FF 00
!00 FF FF 00!!00 FF FF 00
|}
|}
----
 
;RGB_Bytes (format N°10)
===RGB_Bytes (type 10)===
*Three consecutive 8-bit fields are used to store 3 color channels (8 bits each, values from 0 to 255).
*Three consecutive 8-bit fields are used to store 3 color channels (8 bits each, values from 0 to 255).
*Each channel has its own byte, and there is no "unused" byte (the bytes are packed 3 by 3).
*Each channel has its own byte, and there is no "unused" byte (the bytes are packed 3 by 3).
*Endianness is irrelevant when storing as a sequence of bytes.
*Endianness is irrelevant when storing as a sequence of bytes.
{|border=1 cellpadding=3 cellspacing=0
{|border=1 cellpadding=3 cellspacing=0
!<br/>Bits
!<br>Bits
!Byte 0 (red)<br/><code>7 6 5 4 3 2 1 0</code>
!Byte 0 (red)<br><code>7 6 5 4 3 2 1 0</code>
!Byte 1 (green)<br/><code>7 6 5 4 3 2 1 0</code>
!Byte 1 (green)<br><code>7 6 5 4 3 2 1 0</code>
!Byte 2 (blue)<br/><code>7 6 5 4 3 2 1 0</code>
!Byte 2 (blue)<br><code>7 6 5 4 3 2 1 0</code>
|-
|-
!Masks||<code>R R R R R R R R</code>||<code>G G G G G G G G</code>||<code>B B B B B B B B</code>
!Masks||<code>R R R R R R R R</code>||<code>G G G G G G G G</code>||<code>B B B B B B B B</code>
Line 425: Line 402:
!FF FF 00
!FF FF 00
|}
|}
----
 
;RGBA_Bytes (format N°11)
===RGBA_Bytes (type 11)===
*Four consecutive 8-bit fields are used to store 4 color channels (8 bits each, values from 0 to 255).
*Four consecutive 8-bit fields are used to store 4 color channels (8 bits each, values from 0 to 255).
*Each channel has its own byte. Endianness is irrelevant when storing as a sequence of bytes.
*Each channel has its own byte. Endianness is irrelevant when storing as a sequence of bytes.
{|border=1 cellpadding=3 cellspacing=0
{|border=1 cellpadding=3 cellspacing=0
!<br/>Bits
!<br>Bits
!Byte 0 (red)<br/><code>7 6 5 4 3 2 1 0</code>
!Byte 0 (red)<br><code>7 6 5 4 3 2 1 0</code>
!Byte 1 (green)<br/><code>7 6 5 4 3 2 1 0</code>
!Byte 1 (green)<br><code>7 6 5 4 3 2 1 0</code>
!Byte 2 (blue)<br/><code>7 6 5 4 3 2 1 0</code>
!Byte 2 (blue)<br><code>7 6 5 4 3 2 1 0</code>
!Byte 3 (alpha)<br/><code>7 6 5 4 3 2 1 0</code>
!Byte 3 (alpha)<br><code>7 6 5 4 3 2 1 0</code>
|-
|-
!Masks||<code>R R R R R R R R</code>||<code>G G G G G G G G</code>||<code>B B B B B B B B</code>||<code>A A A A A A A A</code>
!Masks||<code>R R R R R R R R</code>||<code>G G G G G G G G</code>||<code>B B B B B B B B</code>||<code>A A A A A A A A</code>
|-
|-
!colspan=5|<br/>Bit values for primary colors (fully opaque)
!colspan=5|<br>Bit values for primary colors (fully opaque)
!Hex view
!Hex view
|-
|-
Line 465: Line 442:
!FF FF 00 FF
!FF FF 00 FF
|}
|}
(GL_RGBA4 OpenGL texture format)
(GL_RGB5 OpenGL texture format)
(GL_RGB5_A1 OpenGL texture format)
(GL_RGB OpenGL texture format) RGB888
-->


==Notes==
==Notes==
<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}}

Latest revision as of 22:33, 30 November 2025

ONI BINARY DATA
TXMB << Other file types >> TxtC
TXMP : Texture Map
switch to XML:TXMP page
Overview @ Oni Stuff
OBD.png

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 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 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

Txmp all.gif


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):
0x01 00 00 00 - has mipmaps
0x04 00 00 00 - U wrapping disabled
0x08 00 00 00 - V wrapping disabled
0x10 00 00 00 - ignored
0x40 00 00 00 - animation order: play back to back (frames 0 to n then n-1 to 0)
0x80 00 00 00 - animation order: play in random order
0x00 01 00 00 - animation time: add local (particle) time (see below)
0x00 02 00 00 - has environment map texture
0x00 04 00 00 - additive alpha blending
0x00 10 00 00 - little endian data
0x00 40 00 00 - animation time: ignore game time (see below)
0x00 80 00 00 - effect: shield (blue)
0x00 00 01 00 - effect: invisibility
0x00 00 02 00 - effect: daodan shield (red)
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.
0 - ARGB4444, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
Four 4-bit channels, with bitmasks 0x000F (Blue), 0x00F0 (Green), 0x0F00 (Red) and 0xF000 (Alpha).
1 - RGB555, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
Three 5-bit channels, with bitmasks 0x001F (Blue), 0x03E0 (Green) and 0x7C00 (Red).
N.B. The high bit (0x8000) is unused, but the convention is to always set it to 1.
2 - ARGB1555, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
Three 5-bit channels with bitmasks 0x001F (Blue), 0x03E0 (Green) and 0x7C00 (Red), 1-bit alpha (0x8000).
3 (never used in vanilla TXMPs) - I8, 8 bits/pixel, stored as a single byte. Monochrome "intensity" (256 levels of gray).
4 (never used in vanilla TXMPs) - I1, 8 pixels/byte. Pixel rows, bottom to top. Monochrome "intensity" (black-or-white).
5 (never used in vanilla TXMPs) - A8, 8 bits/pixel, stored as a single byte. Standalone alpha (256 levels of opacity).
6 (never used in vanilla TXMPs) - A4I4, 8 bits/pixel, stored as a single byte. Intensity (bit mask 0x0F), alpha (0xF0).
7 (never used in vanilla TXMPs[1]) - ARGB8888, 32 bits/pixel (stored as a little-endian int32, swaps to big-endian at runtime on a PowerPC Mac)
Four 8-bit channels, with bitmasks 0x000000FF (Blue), 0x0000FF00 (Green), 0x00FF0000 (Red) and 0xFF000000 (Alpha).
8 - RGB888, 32 bits/pixel (stored as a little-endian int32, swaps to big-endian at runtime on Mac)
Three 8-bit channels, with bitmasks 0x000000FF (Blue), 0x0000FF00 (Green) and 0x00FF0000 (Red).
N.B. The high byte (0xFF000000) is unused, but the convention is to always set it to 0x00.
9 - S3TC/DXT1, RGB565 compressed 4 times (GL_COMPRESSED_RGB_S3TC_DXT1_EXT OpenGL texture format)
10 (never used in vanilla TXMPs) - RGB_Bytes, 24 bits/pixel, stored as 3 consecutive bytes: first Red, then Green, then Blue.
N.B. Unlike for RGB888 (type 8), the storage is compact, with no unused alpha bit.
11 (never used in vanilla TXMPs[2]) - RGBA_Bytes, 32 bits/pixel, stored as 4 consecutive bytes: first Red, then Green, then Blue, then Alpha.
12 (never used in vanilla TXMPs) - RGBA5551, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
Three 5-bit channels with bitmasks 0x003E (Blue), 0x07C0 (Green) and 0xF800 (Red), 1-bit alpha (0x0001).
13 (never used in vanilla TXMPs) - RGBA4444, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
Four 4-bit channels, with bitmasks 0x00F0 (Blue), 0x0F00 (Green), 0xF000 (Red) and 0x000F (Alpha).
14 (never used in vanilla TXMPs) - RGB565, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
Two 5-bit channels with bitmasks 0x001F (Blue) and 0xF800 (Red), 6-bit Green channel (0x07E0).
15 (never used in vanilla TXMPs) - ABGR1555, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
Three 5-bit channels with bitmasks 0x001F (Red), 0x03E0 (Green) and 0x7C00 (Blue), 1-bit alpha (0x8000).
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 offset of pixel data in the raw file (Windows retail only)
0xA0 offset 00 00 00 00 unused offset of pixel data 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 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.
  • 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).
  • 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.

0xB0 char[16] AD DE dead completely unused bytes (not part of the v1.0 or v1.1 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.
Pixel arrangement
how it's stored   how you'll see it
Txmp ex1.gif   Txmp ex2.gif

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) 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.

Offset Type Raw Hex Value Description
0x90 int32 56 00 00 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 palette pixel format #16 (32-bit RGB, with inactive alpha); the other recurrent format is #17 (32-bit RGBA)
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 contains the environment map
0xA0 offset C0 05 00 00 00 00 05 C0 offset of the pixel data in the .raw file
0xA4 offset 00 00 00 00 unused offset of pixel data in the .sep file (unused)
0xA8 int32 00 00 00 00 0 always 0; supposedly the same "material type" (set at runtime) as for Windows demo and Mac
0xAC char[4] AD DE AD DE dead supposedly the same texture name pointer (used at runtime) as for Windows demo and Mac
0xB0 char[4] AD DE AD DE dead supposedly the same rendering optimization flags (runtime) as for Windows demo and Mac
0xB4 char[12] AD DE dead completely unused bytes (not part of the template)
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).

Examples of textures using .sep storage are: all fly-in portraits; all splashscreen components; some illustrations in Konoko's Data Comlink (namely, combat move illustrations and 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

Some of Oni's 16 types of image storage are elaborated on below in order to illustrate exactly how they work. The RAM view assumes little-endianness, which is true for Windows and for Macs since 2006.

ARGB4444 (type 0)

  • A 16-bit field is used to store 4 color channels (4 bits each, values from 0 to 15).
  • Bit masks are 0x000F for Blue, 0x00F0 for Green, 0x0F00 for Red, 0xF000 for Alpha.
  • Stored as big-endian in TXMP (first the AAAARRRR byte, then the GGGGBBBB byte).

Bits 		Byte 1 (high)
7 6 5 4 3 2 1 0 		Byte 0 (low)
7 6 5 4 3 2 1 0
Masks A A A A R R R R G G G G B B B B

Bit values for primary colors (fully opaque) 		Hex view RAM view
Black 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 F0 00 00 F0
White 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 FF FF FF FF
Red 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 FF 00 00 FF
Green 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0 F0 F0 F0 F0
Blue 1 1 1 1 0 0 0 0 0 0 0 0 1 1 1 1 F0 0F 0F F0
Cyan 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 F0 FF FF F0
Magenta 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 FF 0F 0F FF
Yellow 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 FF F0 F0 FF

RGB555 (type 1)

  • A 16-bit field is used to store 3 color channels (5 bits each, values from 0 to 31).
  • Bit masks are 0x001F for Blue, 0x03E0 for Green, 0x7C00 for Red.
  • The high bit (0x8000) is unused, but is always set to 1 by convention.
  • Stored in little-endian order in TXMP.

Bits 		Byte 1 (high)
7 6 5 4 3 2 1 0 		Byte 0 (low)
7 6 5 4 3 2 1 0
Masks X R R R R R G G G G G B B B B B

Bit values for primary colors 		Hex view RAM view
Black 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 80 00 00 80
White 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 FF FF FF FF
Red 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 FC 00 00 FC
Green 1 0 0 0 0 0 1 1 1 1 1 0 0 0 0 0 83 E0 E0 83
Blue 1 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 80 1F 1F 80
Cyan 1 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 83 FF FF 83
Magenta 1 1 1 1 1 1 0 0 0 0 0 1 1 1 1 1 FC 1F 1F FC
Yellow 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 FF E0 E0 FF

ARGB1555 (type 2)

  • A 16-bit field is used to store 3 color channels (5 bits each, values from 0 to 31) and one 1-bit channel.
  • Bit masks are 0x001F for Blue, 0x03E0 for Green, 0x7C00 for Red, and 0x8000 for Alpha.

Bits 		Byte 1 (high)
7 6 5 4 3 2 1 0 		Byte 0 (low)
7 6 5 4 3 2 1 0
Masks A R R R R R G G G G G B B B B B

Bit values for primary colors (opaque) 		Hex view RAM view
Black 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 80 00 00 80
White 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 FF FF FF FF
Red 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 FC 00 00 FC
Green 1 0 0 0 0 0 1 1 1 1 1 0 0 0 0 0 83 E0 E0 83
Blue 1 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 80 1F 1F 80
Cyan 1 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 83 FF FF 83
Magenta 1 1 1 1 1 1 0 0 0 0 0 1 1 1 1 1 FC 1F 1F FC
Yellow 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 FF E0 E0 FF

A4I4 (type 6)

  • An 8-bit field is used to store an intensity and an alpha (4 bits each, values from 0 to 15).
  • Bit masks are 0x0F for Intensity, 0xF0 for Alpha.
  • Endianness is irrelevant for single-byte storage.
Bits 7 6 5 4 3 2 1 0
Masks A A A A I I I I
Examples of bit values Hex view
Black, opaque 1 1 1 1 0 0 0 0 F0
White, opaque 1 1 1 1 1 1 1 1 FF
Black, transparent 0 0 0 0 0 0 0 0 00
White, transparent 0 0 0 0 1 1 1 1 0F

ARGB8888 (type 7)

  • A 32-bit field is used to store 4 color channels (8 bits each, values from 0 to 255).
  • Bit masks are 0x000000FF for Blue, 0x0000FF00 for Green, 0x00FF0000 for Red, 0xFF000000 for Alpha.

Bits 		Byte 3 (highest)
7 6 5 4 3 2 1 0 		Byte 2 (higher)
7 6 5 4 3 2 1 0 		Byte 1 (high)
7 6 5 4 3 2 1 0 		Byte 0 (low)
7 6 5 4 3 2 1 0
Masks A A A A A A A A R R R R R R R R G G G G G G G G B B B B B B B B

Bit values for primary colors (fully opaque) 		Hex view RAM view
Black 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 FF 00 00 00 00 00 00 FF
White 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 FF FF FF FF FF FF FF FF
Red 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 FF FF 00 00 00 00 FF FF
Green 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 FF 00 FF 00 00 FF 00 FF
Blue 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 FF 00 00 FF FF 00 00 FF
Cyan 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 FF 00 FF FF FF FF 00 FF
Magenta 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 FF FF 00 FF FF 00 FF FF
Yellow 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 FF FF FF 00 00 FF FF FF

RGB888 (type 8)

  • A 32-bit field is used to store 3 color channels (8 bits each, values from 0 to 255).
  • Bit masks are 0x000000FF for Blue, 0x0000FF00 for Green, 0x00FF0000 for Red.
  • The high byte (0xFF000000) is unused, but is always set to 00 by convention.

Bits 		Byte 3 (highest)
7 6 5 4 3 2 1 0 		Byte 2 (higher)
7 6 5 4 3 2 1 0 		Byte 1 (high)
7 6 5 4 3 2 1 0 		Byte 0 (low)
7 6 5 4 3 2 1 0
Masks X X X X X X X X R R R R R R R R G G G G G G G G B B B B B B B B

Bit values for primary colors 		Hex view RAM view
Black 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 00 00 00 00 00 00 00
White 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 00 FF FF FF FF FF FF 00
Red 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 FF 00 00 00 00 FF 00
Green 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 00 00 FF 00 00 FF 00 00
Blue 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 00 00 00 FF FF 00 00 00
Cyan 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 00 00 FF FF FF FF 00 00
Magenta 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 00 FF 00 FF FF 00 FF 00
Yellow 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 00 FF FF 00 00 FF FF 00

RGB_Bytes (type 10)

  • Three consecutive 8-bit fields are used to store 3 color channels (8 bits each, values from 0 to 255).
  • Each channel has its own byte, and there is no "unused" byte (the bytes are packed 3 by 3).
  • Endianness is irrelevant when storing as a sequence of bytes.

Bits 		Byte 0 (red)
7 6 5 4 3 2 1 0 		Byte 1 (green)
7 6 5 4 3 2 1 0 		Byte 2 (blue)
7 6 5 4 3 2 1 0
Masks R R R R R R R R G G G G G G G G B B B B B B B B
Bit values for primary colors Hex view
Black 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 00 00
White 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 FF FF FF
Red 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 FF 00 00
Green 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 00 FF 00
Blue 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 00 00 FF
Cyan 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 00 FF FF
Magenta 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 FF 00 FF
Yellow 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 FF FF 00

RGBA_Bytes (type 11)

  • Four consecutive 8-bit fields are used to store 4 color channels (8 bits each, values from 0 to 255).
  • Each channel has its own byte. Endianness is irrelevant when storing as a sequence of bytes.

Bits 		Byte 0 (red)
7 6 5 4 3 2 1 0 		Byte 1 (green)
7 6 5 4 3 2 1 0 		Byte 2 (blue)
7 6 5 4 3 2 1 0 		Byte 3 (alpha)
7 6 5 4 3 2 1 0
Masks R R R R R R R R G G G G G G G G B B B B B B B B A A A A A A A A

Bit values for primary colors (fully opaque) 		Hex view
Black 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 00 00 00 FF
White 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 FF FF FF FF
Red 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 FF 00 00 FF
Green 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 00 FF 00 FF
Blue 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 00 00 FF FF
Cyan 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 00 FF FF FF
Magenta 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 FF 00 FF FF
Yellow 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 FF FF 00 FF

Notes

  1. ↑ 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.
  2. ↑ 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 Windows and Mac versions of TXMPs.
ONI BINARY DATA
TXMB << Other file types >> TxtC
TXMP : Texture Map
General file
Retrieved from "https://wiki.oni2.net/w/index.php?title=OBD:TXMP&oldid=45989"