OBD:TXMP: Difference between revisions

From OniGalore
mNo edit summary
(added detail on effects options and PS2 palette format; added section on pixel byte storage order; made formal subsections out of informal subsections)
 
(43 intermediate revisions by 5 users not shown)
Line 1: Line 1:
[[Main Page]] >> [[OBD:Oni Binary Data|Oni Binary Data]] >> [[OBD:File types|File types]] >> TXMP
{{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 platforms (Windows, Mac and PS2).


<CENTER>[[OBD:TXMB|<==]] <FONT SIZE=5>TXMP : Texture Map</FONT> [[OBD:TxtC|==>]]<BR>
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.
<FONT SIZE=2>[[OBD:File types/General|General]] file</FONT></CENTER>


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


http://www6.fh-eberswalde.de/user/dkriesch/onistuff/images/txmp_all.gif
==Windows/Mac implementation==
[[Image:txmp_all.gif]]




{| BORDER=1 WIDTH=100% CELLPADDING=2 CELLSPACING=0
{{Table}}
|- ALIGN=CENTER BGCOLOR="#FFDDBB"
{{OBD_Table_Header}}
| WIDTH=15% | <B>Raw hex</B>
|- ALIGN=CENTER VALIGN=TOP
| WIDTH=15% | <B>Translation</B>
{{OBDtr| 0x00 | res_id  |FF0000| 01 1F 00 00 | 31       | 00031-rl_1.TXMP }}
| WIDTH=70% | <B>Meaning</B>
{{OBDtr| 0x04 | lev_id  |FFFF00| 01 00 00 06 | 3         | level 3 }}
|- ALIGN=CENTER VALIGN=TOP BGCOLOR="#FFEEDD"
{{OBDtr2|0x08 | char[128]|FFC8C8| rl_1                   | name of the texture; unused }}
| BGCOLOR="#FF0000" | 01 1F 00 00
{{OBDtr| 0x88 | int32    |FFFFC8| 00 10 00 00 | 0x1000    | options; possible option flags (from left to right):
| 31
:0x01 - has mipmaps
| ALIGN=LEFT | 00031-rl_1.TXMP
:0x04 - U wrapping disabled
|- ALIGN=CENTER VALIGN=TOP BGCOLOR="#FFEEDD"
:0x08 - V wrapping disabled
| BGCOLOR="#FFFF00" | 01 00 00 06
:0x10 - ignored
| 3
:0x40 - animation order: play back to back (frames 0 to n then n-1 to 0)
| ALIGN=LEFT | level 3
:0x80 - animation order: play in random order
|- ALIGN=CENTER VALIGN=TOP BGCOLOR="#FFEEDD"
:0x100 - animation time: add local (particle) time (see below)
| BGCOLOR="#00FF00" COLSPAN=2 | <TT>rl_1</TT>
:0x200 - has environment map texture
| ALIGN=LEFT | name of the texture
:0x400 - additive alpha blending
|- ALIGN=CENTER VALIGN=TOP BGCOLOR="#FFEEDD"
:0x1000 - little-endian data
| BGCOLOR="#00FFFF" | 00
:0x4000 - animation time: ignore game time (see below)
| 0
:0x8000 - effect: blue shield
| ALIGN=LEFT | MIP-mapping option; the following options are possible:<P>00 - off<BR>01 - on
:0x10000 - effect: invisibility
 
:0x20000 - effect: Daodan shield}}
|- ALIGN=CENTER VALIGN=TOP BGCOLOR="#FFEEDD"
{{OBDtr| 0x8C | int16    |C8FFC8| 80 00       | 128       | width of the image in pixels }}
| BGCOLOR="#FF00FF" | 10
{{OBDtr| 0x8E | int16    |C8FFC8| 80 00       | 128       | height of the image in pixels }}
| 16
{{OBDtr| 0x90 | int32    |C8FFFF| 09 00 00 00 | 9        | texture format; see below for list of available formats.
| ALIGN=LEFT | color depth (= 16 bits)
:0 - ARGB4444, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
|- ALIGN=CENTER VALIGN=TOP BGCOLOR="#FFEEDD"
::Four 4-bit channels, with bitmasks 0x000F (Blue), 0x00F0 (Green), 0x0F00 (Red) and 0xF000 (Alpha).
| BGCOLOR="#FFC8C8" | 00 00
:1 - RGB555, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
| 0
::Three 5-bit channels, with bitmasks 0x001F (Blue), 0x03E0 (Green) and 0x7C00 (Red).
| ALIGN=LEFT | unknown
:::N.B. The high bit (0x8000) is unused, but the convention is to always set it to 1.
|- ALIGN=CENTER VALIGN=TOP BGCOLOR="#FFEEDD"
:2 - ARGB1555, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
| BGCOLOR="#FFFFC8" | 80 00
::Three 5-bit channels with bitmasks 0x001F (Blue), 0x03E0 (Green) and 0x7C00 (Red), 1-bit alpha (0x8000).
| 128
:3 (never used in vanilla TXMPs)<ref>[[TSFT]] implicitly uses I8 for storing its glyphs in the PC versions, at least in most languages (the Chinese version has its own font storage system), but TSFT doesn't use TXMP to store its pixel data so it doesn't count as a use of this TXMP format type.</ref> - I8, 8 bits/pixel, stored as a single byte. Monochrome "intensity" (256 levels of gray).
| ALIGN=LEFT | width (= 128 pixels)
:4 (never used in vanilla TXMPs) - I1, 8 pixels/byte. Pixel rows, bottom to top. Monochrome "intensity" (black-or-white).
|- ALIGN=CENTER VALIGN=TOP BGCOLOR="#FFEEDD"
:5 (never used in vanilla TXMPs) - A8, 8 bits/pixel, stored as a single byte. Standalone alpha (256 levels of opacity).
| BGCOLOR="#FFFFC8" | 80 00
:6 (never used in vanilla TXMPs) - A4I4, 8 bits/pixel, stored as a single byte. Intensity (bit mask 0x0F), alpha (0xF0).
| 128
: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)
| ALIGN=LEFT | height (= 128 pixels)
::Four 8-bit channels, with bitmasks 0x000000FF (Blue), 0x0000FF00 (Green), 0x00FF0000 (Red) and 0xFF000000 (Alpha).
|- ALIGN=CENTER VALIGN=TOP BGCOLOR="#FFEEDD"
:8 - RGB888, 32 bits/pixel (stored as a little-endian int32, swaps to big-endian at runtime on Mac)
| BGCOLOR="#C8FFC8" | 01 00 00 00
::Three 8-bit channels, with bitmasks 0x000000FF (Blue), 0x0000FF00 (Green) and 0x00FF0000 (Red).
| 1
:::N.B. The high byte (0xFF000000) is unused, but the convention is to always set it to 0x00.
| ALIGN=LEFT | store type = 1 (uncompressed, without alpha blending)
:9 - S3TC/DXT1, RGB565 compressed 4 times ([https://wikis.khronos.org/opengl/S3_Texture_Compression GL_COMPRESSED_RGB_S3TC_DXT1_EXT] OpenGL texture format)
|- ALIGN=CENTER VALIGN=TOP BGCOLOR="#FFEEDD"
:10 (never used in vanilla TXMPs) - RGB_Bytes, 24 bits/pixel, stored as 3 consecutive bytes: first Red, then Green, then Blue.
| BGCOLOR="#C8FFFF" | 00 00 00 00
::N.B. Unlike for RGB888 (type 8), the storage is compact, with no unused alpha bit.
| not used
: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.
| ALIGN=LEFT | link to a [[OBD:TXAN|TXAN]] file; only used if the texture is the first pic of a texture animation
:12 (never used in vanilla TXMPs) - RGBA5551, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
|- ALIGN=CENTER VALIGN=TOP BGCOLOR="#FFEEDD"
::Three 5-bit channels with bitmasks 0x003E (Blue), 0x07C0 (Green) and 0xF800 (Red), 1-bit alpha (0x0001).
| BGCOLOR="#FFC8FF" | 00 00 00 00
:13 (never used in vanilla TXMPs) - RGBA4444, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
| not used
::Four 4-bit channels, with bitmasks 0x00F0 (Blue), 0x0F00 (Green), 0xF000 (Red) and 0x000F (Alpha).
| ALIGN=LEFT | link to a TXMP file; only used in connection with vertex shading effects
:14 (never used in vanilla TXMPs) - RGB565, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
|- ALIGN=CENTER VALIGN=TOP BGCOLOR="#FFEEDD"
::Two 5-bit channels with bitmasks 0x001F (Blue) and 0xF800 (Red), 6-bit Green channel (0x07E0).
| BGCOLOR="#FFC800" | 20 00 00 00
:15 (never used in vanilla TXMPs) - ABGR1555, 16 bits/pixel (stored as a little-endian int16, swaps to big-endian at runtime on Mac)
| 32
::Three 5-bit channels with bitmasks 0x001F (Red), 0x03E0 (Green) and 0x7C00 (Blue), 1-bit alpha (0x8000).
| ALIGN=LEFT | address at which the texture is stored in the raw file (on PC; null on Mac and PC demo)
}}
|- ALIGN=CENTER VALIGN=TOP BGCOLOR="#FFEEDD"
{{OBDtr| 0x94 | link    |FFC8FF| 00 00 00 00 | unused    | link to a [[OBD:TXAN|TXAN]] file; used if this texture is animated }}
| BGCOLOR="#C800C8" | 00 00 00 00
{{OBDtr| 0x98 | link    |FFC800| 00 00 00 00 | unused    | link to a TXMP file that contain the environment map  }}
| 0
{{OBDtr| 0x9C | offset  |C800C8| 20 00 00 00 |00 00 00 20| offset of pixel data in the raw file (v1.0 engine only) }}
| ALIGN=LEFT | address at which the texture is stored in the sep file (on Mac and PC demo; null on PC)
{{OBDtr| 0xA0 | offset  |C87C64| 00 00 00 00 | unused    | offset of pixel data in the separate file (v1.1 engine only) }}
|- ALIGN=CENTER VALIGN=TOP BGCOLOR="#FFEEDD"
{{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):
| BGCOLOR="#C87C64" | AD DE
*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.
| dead
*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).
| ALIGN=LEFT | not used
*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.
}}
{{OBDtr| 0xB0 | char[16] |B0C3D4| AD DE       | dead     | padding bytes (not part of TXMP) }}
|}
|}
;[http://www.answers.com/topic/mipmap MIP mapping] (MIP stands for "multum in parvo")
:A texture mapping technique that uses multiple texture maps, or MIP maps. Each MIP map is half the size of the first one, providing several texture maps for various levels of depth.
;[http://www.answers.com/topic/alpha-blending?method=22 Alpha blending]
:In computer graphics, the combining of the alpha channel with other layers in an image in order to show translucency.
:The alpha channel is an additional eight bits used with each pixel in a 32-bit graphics system that can represent 256 levels of translucency.
:(here, the base color depth is 16 bits; and there are only 4 bits for the alpha channel, so only 16 levels of transparency. [[User:Geyser|geyser]])
You can edit the raw/sep file manually (although we recommend [[OBD:OUP| Oni Un/Packer]]) : there's a tutorial [http://www6.fh-eberswalde.de/user/dkriesch/onistuff/subfold/texture/texture.htm here]


===Effect options===
The "blue shield", "invisibility" and "Daodan shield" options tell the engine to vary the texture's Gouraud shading with certain preset colors that vary with time.


 
{| class="wikitable"
{| BORDER=1 WIDTH=100% CELLPADDING=2 CELLSPACING=0
!Flag name
|- BGCOLOR="#FFDDBB"
!Texture with flag
| WIDTH=15% | <B>Option</B>
!Used for
| WIDTH=15% | <B>Value</B>
|-
| WIDTH=70% | <B>Meaning</B>
|"blue shield"
|- VALIGN=TOP BGCOLOR="#FFEEDD"
|TXMPSHIELD
| ROWSPAN=4 | MIP-mapping types
|force shield
| BGCOLOR="#00FFFF" | 00
|-
| off
|"invisibility"
|- VALIGN=TOP BGCOLOR="#FFEEDD"
|TXMPINVIS
| BGCOLOR="#00FFFF" | 01
|phase cloak
| on
|-
|- VALIGN=TOP BGCOLOR="#FFEEDD"
|"Daodan shield"
| BGCOLOR="#00FFFF" | 11
|TXMPDAODAN_SHIELD
| unknown
|red boss shield and [[supershield]]
|- VALIGN=TOP BGCOLOR="#FFEEDD"
| BGCOLOR="#00FFFF" | 1C
| unknown (used for skyboxes, works with 00 too)
|- VALIGN=TOP BGCOLOR="#FFEEDD"
| ROWSPAN=4 | Color depths
| BGCOLOR="#FF00FF" | 10
| 16 bit
|- VALIGN=TOP BGCOLOR="#FFEEDD"
| BGCOLOR="#FF00FF" | 12
| 16 bit + shade vertex
|- VALIGN=TOP BGCOLOR="#FFEEDD"
| BGCOLOR="#FF00FF" | 14
| 16 bit + 4 bits for the alpha channel
|- VALIGN=TOP BGCOLOR="#FFEEDD"
| BGCOLOR="#FF00FF" | 20
| 32 bit
|- VALIGN=TOP BGCOLOR="#FFEEDD"
| ROWSPAN=8 | Store types
| BGCOLOR="#C8FFFF" | 00
| uncompressed, with alpha blending
|- VALIGN=TOP BGCOLOR="#FFEEDD"
| BGCOLOR="#C8FFFF" | 01
| uncompressed, without alpha blending
|- VALIGN=TOP BGCOLOR="#FFEEDD"
| BGCOLOR="#C8FFFF" | 02
| unknown
|- VALIGN=TOP BGCOLOR="#FFEEDD"
| BGCOLOR="#C8FFFF" | 03
| unknown
|- VALIGN=TOP BGCOLOR="#FFEEDD"
| BGCOLOR="#C8FFFF" | 08
| 32 bit uncompressed (used for skyboxes)
|- VALIGN=TOP BGCOLOR="#FFEEDD"
| BGCOLOR="#C8FFFF" | 09
| compressed
|- VALIGN=TOP BGCOLOR="#FFEEDD"
| BGCOLOR="#C8FFFF" | 0A
| unknown
|- VALIGN=TOP BGCOLOR="#FFEEDD"
| BGCOLOR="#C8FFFF" | 0B
| unknown
|}
|}


In the vanilla game data, these flags are only used by the above-named textures. The engine also calls upon these textures by hardcoded name in order to create a character's shield or phase cloak effect.


Below you can see the pictures for this example. The first picture shows how its stored in Oni, the second how you'll see it in the game.
===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 byte storage order===
As noted above under each format description, the bytes of multibyte texture formats are generally stored "backwards" compared to their names, so if a format is named "RGBA"-something then its bytes will be in ABGR order on disk. This convention was established in the Windows world where PCs were little-endian and loading the bytes AA BB GG RR into a 32-bit int in memory would place them in the correct order, 0xRRGGBBAA. Macintoshes, being big-endian at the time, expected the data to be stored in reverse order and thus Oni would perform a byte swap on most of these types when it loaded them into memory to ensure that they ended up as 0xRRGGBBAA in memory. The sole exceptions to this little-endian storage rule among Oni's supported texture formats are RGB_Bytes and RGBA_Bytes, which actually store their bytes in the stated order, RGB and RGBA respectively. However these formats were never used by any textures in Oni.


{|cellpadding=10
===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.
{|border=0
|+Pixel arrangement
|+Pixel arrangement
!how it's stored
!how it's stored
!&nbsp;
!how you'll see it
!how you'll see it
|-
|-
|http://www6.fh-eberswalde.de/user/dkriesch/onistuff/images/txmp_ex1.gif
|[[Image:txmp_ex1.gif]]
|http://www6.fh-eberswalde.de/user/dkriesch/onistuff/images/txmp_ex2.gif
|&nbsp;
|[[Image:txmp_ex2.gif]]
|}
 
==PS2 implementation==
The PS2 TXMP layout is similar to PC, with notable differences in the last few bytes due to Rockstar moving to a PS2-standard 32-bit indexed color ("CLUT") system for optimization purposes. Here are the high-level differences:
*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 pushed down to 0x94 along with everything else that follows).
*Two new pixel formats were added, and are the only formats used on PS2: type 16 for opaque textures (indexed 32-bit RGB with ignored alpha byte), and type 17 for transparent textures (indexed 32-bit RGBA).
*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).
 
Here is how the end of TXMPrl_1 looks in level3_Final.dat of the English retail PS2 version.
{{Table}}
{{OBD_Table_Header}}
|- ALIGN=CENTER VALIGN=TOP
{{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        | pixel format 16 (indexed 32-bit RGB with inactive alpha) }}
{{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 | 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 pixel data in the .raw file }}
{{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; presumably the same "material type" (set at runtime) as for Windows demo and Mac }}
{{OBDtr| 0xAC | char[4]  |B0C3D4| AD DE AD DE | dead      | presumably the same texture name pointer (set at runtime) as for Windows demo and Mac }}
{{OBDtr| 0xB0 | char[4]  |B0C3D4| AD DE AD DE | dead      | presumably 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) }}
|}
 
===Palette file format===
*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 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.
 
===Palette format===
*Valid palette indices start at 1 because of palette 0 always being empty.
*Each color in a palette entry is 4 bytes, stored on disk in RGBA order (byte 0 = red, byte 1 = green, byte 2 = blue, byte 3 = alpha). This is the same layout as RGB_Bytes (type 10) and RGBA_Bytes (type 11), not the reversed BGRA order used by most of the other texture formats.
*Each palette consists of 256 32-bit color slots and thus takes up 1024 bytes. If a palette does not use all 256 entries then the palette is closed out with a series of {0x00, 0x00, 0x00, 0x80} entries.
*Each pixel in the .raw or .sep data is stored as a 1-byte index into the image's chosen color palette.
 
===Palette CLUT swizzle===
:The PS2 Graphics Synthesizer (GS) stores CLUT entries in a scrambled order due to its hardware cache line layout. Within every 32-entry block of the palette, entries 8–15 and 16–23 are swapped relative to their logical positions. Software reading the palette must undo this before using it as a palette index.
 
===Ignored alpha byte for type 16===
:The fourth byte would represent alpha, but in RGB888 it is merely a padding byte, always set to 0x80.
 
===Alpha scaling for type 17===
:The PS2 GS uses a half-range alpha where 0x00 = fully transparent and 0x80 = fully opaque (values above 0x80 are technically possible but indicate "source alpha contribution > 1" in GS blending, which doesn't arise in Oni).
 
===Alternating 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 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).
 
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 18 types of image storage are elaborated on below in order to illustrate exactly how they work. The "Mem view" column shows the bytes in big-endian format and the "Disk view" column shows the bytes as they are actually stored in little-endian order. For example, bytes in memory shown as 0xFC00 are stored as "00 FC" on disk.
 
===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).
{|border=1 cellpadding=3 cellspacing=0
!<br>Bits
!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>
|-
!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)
!Mem view
!Disk view
|-
|Black||<code>1 1 1 1 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!F0 00!!00 F0
|-
|White||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF!!FF FF
|-
|Red||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!FF 00!!00 FF
|-
|Green||<code>1 1 1 1 0 0 0 0</code>||<code>1 1 1 1 0 0 0 0</code>
!F0 F0!!F0 F0
|-
|Blue||<code>1 1 1 1 0 0 0 0</code>||<code>0 0 0 0 1 1 1 1</code>
!F0 0F!!0F F0
|-
|Cyan||<code>1 1 1 1 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!F0 FF!!FF F0
|-
|Magenta||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 1 1 1 1</code>
!FF 0F!!0F FF
|-
|Yellow||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 0 0 0 0</code>
!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.
{|border=1 cellpadding=3 cellspacing=0
!<br>Bits
!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>
|-
!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
!Mem view
!Disk view
|-
|Black||<code>1 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!80 00!!00 80
|-
|White||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF!!FF FF
|-
|Red||<code>1 1 1 1 1 1 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!FC 00!!00 FC
|-
|Green||<code>1 0 0 0 0 0 1 1</code>||<code>1 1 1 0 0 0 0 0</code>
!83 E0!!E0 83
|-
|Blue||<code>1 0 0 0 0 0 0 0</code>||<code>0 0 0 1 1 1 1 1</code>
!80 1F!!1F 80
|-
|Cyan||<code>1 0 0 0 0 0 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!83 FF!!FF 83
|-
|Magenta||<code>1 1 1 1 1 1 0 0</code>||<code>0 0 0 1 1 1 1 1</code>
!FC 1F!!1F FC
|-
|Yellow||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 0 0 0 0 0</code>
!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.
{|border=1 cellpadding=3 cellspacing=0
!<br>Bits
!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>
|-
!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)
!Mem view
!Disk view
|-
|Black||<code>1 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!80 00!!00 80
|-
|White||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF!!FF FF
|-
|Red||<code>1 1 1 1 1 1 0 0</code>||<code>0 0 0 0 0 0 0 0</code>
!FC 00!!00 FC
|-
|Green||<code>1 0 0 0 0 0 1 1</code>||<code>1 1 1 0 0 0 0 0</code>
!83 E0!!E0 83
|-
|Blue||<code>1 0 0 0 0 0 0 0</code>||<code>0 0 0 1 1 1 1 1</code>
!80 1F!!1F 80
|-
|Cyan||<code>1 0 0 0 0 0 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!83 FF!!FF 83
|-
|Magenta||<code>1 1 1 1 1 1 0 0</code>||<code>0 0 0 1 1 1 1 1</code>
!FC 1F!!1F FC
|-
|Yellow||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 0 0 0 0 0</code>
!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.
{|border=1 cellpadding=3 cellspacing=0
!Bits
!<code>7 6 5 4 3 2 1 0</code>
|-
!Masks||<code>A A A A I I I I</code>
|-
!colspan=2|Examples of bit values
!Mem view
|-
|Black, opaque||<code>1 1 1 1 0 0 0 0</code>
!F0
|-
|White, opaque||<code>1 1 1 1 1 1 1 1</code>
!FF
|-
|Black, transparent||<code>0 0 0 0 0 0 0 0</code>
!00
|-
|White, transparent||<code>0 0 0 0 1 1 1 1</code>
!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.
{|border=1 cellpadding=3 cellspacing=0
!<br>Bits
!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 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>
|-
!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)
!Mem view
!Disk 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>
!FF 00 00 00!!00 00 00 FF
|-
|White||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF FF FF!!FF FF FF FF
|-
|Red||<code>1 1 1 1 1 1 1 1</code>||<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>
!FF FF 00 00!!00 00 FF FF
|-
|Green||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!FF 00 FF 00!!00 FF 00 FF
|-
|Blue||<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>1 1 1 1 1 1 1 1</code>
!FF 00 00 FF!!FF 00 00 FF
|-
|Cyan||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF 00 FF FF!!FF FF 00 FF
|-
|Magenta||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF 00 FF!!FF 00 FF FF
|-
|Yellow||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!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.
{|border=1 cellpadding=3 cellspacing=0
!<br>Bits
!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 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>
|-
!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
!Mem view
!Disk 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>
!00 00 00 00!!00 00 00 00
|-
|White||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!00 FF FF FF!!FF FF FF 00
|-
|Red||<code>0 0 0 0 0 0 0 0</code>||<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>
!00 FF 00 00!!00 00 FF 00
|-
|Green||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!00 00 FF 00!!00 FF 00 00
|-
|Blue||<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>1 1 1 1 1 1 1 1</code>
!00 00 00 FF!!FF 00 00 00
|-
|Cyan||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!00 00 FF FF!!FF FF 00 00
|-
|Magenta||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!00 FF 00 FF!!FF 00 FF 00
|-
|Yellow||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!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.
{|border=1 cellpadding=3 cellspacing=0
!<br>Bits
!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 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>
|-
!colspan=4|Bit values for primary colors
!Mem 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>
!00 00 00
|-
|White||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF FF
|-
|Red||<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>
!FF 00 00
|-
|Green||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!00 FF 00
|-
|Blue||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!00 00 FF
|-
|Cyan||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!00 FF FF
|-
|Magenta||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!FF 00 FF
|-
|Yellow||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>
!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.
{|border=1 cellpadding=3 cellspacing=0
!<br>Bits
!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 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>
|-
!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)
!Mem 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>1 1 1 1 1 1 1 1</code>
!00 00 00 FF
|-
|White||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF FF FF
|-
|Red||<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>1 1 1 1 1 1 1 1</code>
!FF 00 00 FF
|-
|Green||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!00 FF 00 FF
|-
|Blue||<code>0 0 0 0 0 0 0 0</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!00 00 FF FF
|-
|Cyan||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!00 FF FF FF
|-
|Magenta||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>
!FF 00 FF FF
|-
|Yellow||<code>1 1 1 1 1 1 1 1</code>||<code>1 1 1 1 1 1 1 1</code>||<code>0 0 0 0 0 0 0 0</code>||<code>1 1 1 1 1 1 1 1</code>
!FF FF 00 FF
|}


<HR>
==Notes==
<CENTER>[[OBD:TXMB|<==]] <B>TXMP : Texture Map</B> [[OBD:TxtC|==>]]</CENTER>
<references/>
<HR>


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


[[Main Page]] >> [[OBD:Oni Binary Data|Oni Binary Data]] >> [[OBD:File types|File types]] >> TXMP
{{OBD}}

Latest revision as of 19:35, 5 April 2026

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 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 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 index into a custom 256-color palette. This format is detailed under § PS2 implementation.

Windows/Mac implementation

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 - has mipmaps
0x04 - U wrapping disabled
0x08 - V wrapping disabled
0x10 - ignored
0x40 - animation order: play back to back (frames 0 to n then n-1 to 0)
0x80 - animation order: play in random order
0x100 - animation time: add local (particle) time (see below)
0x200 - has environment map texture
0x400 - additive alpha blending
0x1000 - little-endian data
0x4000 - animation time: ignore game time (see below)
0x8000 - effect: blue shield
0x10000 - effect: invisibility
0x20000 - effect: Daodan shield
0x8C int16 80 00 128 width of the image in pixels
0x8E int16 80 00 128 height of the image in pixels
0x90 int32 09 00 00 00 9 texture format; 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)[1] - 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[2]) - 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[3]) - 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 (v1.0 engine only)
0xA0 offset 00 00 00 00 unused offset of pixel data in the separate file (v1.1 engine 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 "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).

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 padding bytes (not part of TXMP)

Effect options

The "blue shield", "invisibility" and "Daodan shield" options tell the engine to vary the texture's Gouraud shading with certain preset colors that vary with time.

Flag name Texture with flag Used for
"blue shield" TXMPSHIELD force shield
"invisibility" TXMPINVIS phase cloak
"Daodan shield" TXMPDAODAN_SHIELD red boss shield and supershield

In the vanilla game data, these flags are only used by the above-named textures. The engine also calls upon these textures by hardcoded name in order to create a character's shield or phase cloak effect.

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 byte storage order

As noted above under each format description, the bytes of multibyte texture formats are generally stored "backwards" compared to their names, so if a format is named "RGBA"-something then its bytes will be in ABGR order on disk. This convention was established in the Windows world where PCs were little-endian and loading the bytes AA BB GG RR into a 32-bit int in memory would place them in the correct order, 0xRRGGBBAA. Macintoshes, being big-endian at the time, expected the data to be stored in reverse order and thus Oni would perform a byte swap on most of these types when it loaded them into memory to ensure that they ended up as 0xRRGGBBAA in memory. The sole exceptions to this little-endian storage rule among Oni's supported texture formats are RGB_Bytes and RGBA_Bytes, which actually store their bytes in the stated order, RGB and RGBA respectively. However these formats were never used by any textures in Oni.

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 PS2 TXMP layout is similar to PC, with notable differences in the last few bytes due to Rockstar moving to a PS2-standard 32-bit indexed color ("CLUT") system for optimization purposes. Here are the high-level differences:

  • 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 pushed down to 0x94 along with everything else that follows).
  • Two new pixel formats were added, and are the only formats used on PS2: type 16 for opaque textures (indexed 32-bit RGB with ignored alpha byte), and type 17 for transparent textures (indexed 32-bit RGBA).
  • 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).

Here is how the end of TXMPrl_1 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 pixel format 16 (indexed 32-bit RGB with inactive alpha)
0x98 link 00 00 00 00 0 link to a TXAN file; used if this texture is animated
0x9C link 00 00 00 00 0 link to a TXMP file that contains the environment map
0xA0 offset C0 05 00 00 00 00 05 C0 offset of pixel data in the .raw file
0xA4 offset 00 00 00 00 0 offset of pixel data in the .sep file
0xA8 int32 00 00 00 00 0 always 0; presumably the same "material type" (set at runtime) as for Windows demo and Mac
0xAC char[4] AD DE AD DE dead presumably the same texture name pointer (set at runtime) as for Windows demo and Mac
0xB0 char[4] AD DE AD DE dead presumably 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)

Palette file format

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

Palette format

  • Valid palette indices start at 1 because of palette 0 always being empty.
  • Each color in a palette entry is 4 bytes, stored on disk in RGBA order (byte 0 = red, byte 1 = green, byte 2 = blue, byte 3 = alpha). This is the same layout as RGB_Bytes (type 10) and RGBA_Bytes (type 11), not the reversed BGRA order used by most of the other texture formats.
  • Each palette consists of 256 32-bit color slots and thus takes up 1024 bytes. If a palette does not use all 256 entries then the palette is closed out with a series of {0x00, 0x00, 0x00, 0x80} entries.
  • Each pixel in the .raw or .sep data is stored as a 1-byte index into the image's chosen color palette.

Palette CLUT swizzle

The PS2 Graphics Synthesizer (GS) stores CLUT entries in a scrambled order due to its hardware cache line layout. Within every 32-entry block of the palette, entries 8–15 and 16–23 are swapped relative to their logical positions. Software reading the palette must undo this before using it as a palette index.

Ignored alpha byte for type 16

The fourth byte would represent alpha, but in RGB888 it is merely a padding byte, always set to 0x80.

Alpha scaling for type 17

The PS2 GS uses a half-range alpha where 0x00 = fully transparent and 0x80 = fully opaque (values above 0x80 are technically possible but indicate "source alpha contribution > 1" in GS blending, which doesn't arise in Oni).

Alternating 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 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 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 18 types of image storage are elaborated on below in order to illustrate exactly how they work. The "Mem view" column shows the bytes in big-endian format and the "Disk view" column shows the bytes as they are actually stored in little-endian order. For example, bytes in memory shown as 0xFC00 are stored as "00 FC" on disk.

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) 		Mem view Disk 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 		Mem view Disk 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) 		Mem view Disk 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 Mem 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) 		Mem view Disk 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 		Mem view Disk 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 Mem 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) 		Mem 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. ↑ TSFT implicitly uses I8 for storing its glyphs in the PC versions, at least in most languages (the Chinese version has its own font storage system), but TSFT doesn't use TXMP to store its pixel data so it doesn't count as a use of this TXMP format type.
  2. ↑ 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.
  3. ↑ 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=47048"