OBD:TXMP - Revision history

Iritscen: removed one last reference to wrong row order

2026-04-16T18:29:45Z

removed one last reference to wrong row order

← Older revision		Revision as of 18:29, 16 April 2026
Line 43:		Line 43:
	::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)<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).		: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).
	: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''. 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).

Iritscen: how is it possible that the wiki was wrong about this major fact, accompanied by a wrong illustration, for twenty years? I don't know, but I'm fixing it now

2026-04-16T18:27:53Z

how is it possible that the wiki was wrong about this major fact, accompanied by a wrong illustration, for twenty years? I don't know, but I'm fixing it now

← Older revision		Revision as of 18:27, 16 April 2026
Line 106:		Line 106:
	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.		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===		===Pixel scanline 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.		Pixels are stored in row-major order, meaning that the pixels are stored in rows and then columns, as opposed to the other way around. These rows are stored in ''top-to-bottom'' order, contrary to what was documented on this wiki for a long time. In the case of the DXT1 storage format, the row-major, left-to-right, top-to-bottom 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 (multiple pixels per byte), the row-major, left-to-right, top-to-bottom order applies to the 1-bit pixels composing the image.
	~~{\|border=0~~
	~~\|+Pixel arrangement~~
	~~!how it's stored~~
	~~! ~~
	~~!how you'll see it~~
	\|-
	~~\|[[Image:txmp_ex1.gif]]~~
	~~\| ~~
	~~\|[[Image:txmp_ex2.gif]]~~
	\|}

	==PS2 implementation==		==PS2 implementation==

Iritscen: added detail on effects options and PS2 palette format; added section on pixel byte storage order; made formal subsections out of informal subsections

2026-04-05T19:35:04Z

added detail on effects options and PS2 palette format; added section on pixel byte storage order; made formal subsections out of informal subsections

← Older revision		Revision as of 19:35, 5 April 2026
Line 27:		Line 27:
	:0x200 - has environment map texture		:0x200 - has environment map texture
	:0x400 - additive alpha blending		:0x400 - additive alpha blending
	:0x1000 - little endian data		:0x1000 - little-endian data
	:0x4000 - animation time: ignore game time (see below)		:0x4000 - animation time: ignore game time (see below)
	:0x8000 - effect: ~~phase~~ shield ~~(blue)~~		:0x8000 - effect: blue shield
	:0x10000 - effect: invisibility		:0x10000 - effect: invisibility
	:0x20000 - effect: ~~boss~~ shield ~~(red)~~ }}		:0x20000 - effect: Daodan shield}}
	{{OBDtr\| 0x8C \| int16 \|C8FFC8\| 80 00 \| 128 \| width of the image in pixels }}		{{OBDtr\| 0x8C \| int16 \|C8FFC8\| 80 00 \| 128 \| width of the image in pixels }}
	{{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 }}
Line 77:		Line 77:
	\|}		\|}

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

	~~;Effect options~~		{\| class="wikitable"
	:"~~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.		!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]]
			\|}

	;Animation time		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.		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		===Pixel byte 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).		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.
	: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 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		{\|border=0
	\|+Pixel arrangement		\|+Pixel arrangement
Line 122:		Line 142:
	\|}		\|}

			===Palette file format===
	;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.		*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.		*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		===Palette format===
	*Valid palette indices start at 1~~. Each~~ palette ~~consists of 256 32-bit colors and takes up 1024 bytes~~.		*Valid palette indices start at 1 because of palette 0 always being empty.
	*Each ~~4-byte~~ palette entry is stored ~~as R, G, B, A~~ in ~~memory~~ order (byte 0 = red, byte 1 = green, byte 2 = blue, byte 3 = alpha). This is the same layout as RGBA_Bytes (type 11), not the reversed BGRA order used by most of the other texture formats.		*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.		*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		===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.		: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		===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.		:The fourth byte would represent alpha, but in RGB888 it is merely a padding byte, always set to 0x80.

	;Alpha scaling for type 17		===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).		: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		===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).		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).

Line 149:		Line 169:

	==Oni's internal storage types==		==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 "Mem view" column shows the bytes in ~~memory as~~ big-endian and the "Disk view" column shows the bytes as they are stored in little-endian order. For example ~~the~~ bytes in memory shown as 0xFC00 are stored as "00 FC" on disk.		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)===		===ARGB4444 (type 0)===

Iritscen: Claude helped me finish REing the PS2 format; I've arranged the existing information better and integrated Claude's suggested corrections

2026-04-05T04:42:44Z

Claude helped me finish REing the PS2 format; I've arranged the existing information better and integrated Claude's suggested corrections

← Older revision		Revision as of 04:42, 5 April 2026
Line 100:		Line 100:

	==PS2 implementation==		==PS2 implementation==
	The PS2 TXMP layout is similar to PC, with notable differences in the last few bytes due to Rockstar moving to 32-bit indexed color~~, presumably to save memory on a very RAM~~-~~limited system~~:		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).		*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).		*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).
	*Valid palette indices start at 1. 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 palette consists of 256 32-bit colors and takes up 1024 bytes.		*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).
	*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.
	*Two new pixel formats were added, and are the only formats used on PS2: type 16 for opaque textures~~, meaning~~ 32-bit RGB with ignored alpha byte ~~(always set to 0x80~~), and type 17 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).		*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).
	*Each pixel is stored as a 1-byte index into the image's chosen color palette.

	Here is how the end of TXMPrl_1 looks in level3_Final.dat of the English retail PS2 version.		Here is how the end of TXMPrl_1 looks in level3_Final.dat of the English retail PS2 version.
Line 125:		Line 122:
	\|}		\|}


			;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. Each palette consists of 256 32-bit colors and takes up 1024 bytes.
			*Each 4-byte palette entry is stored as R, G, B, A in memory order (byte 0 = red, byte 1 = green, byte 2 = blue, byte 3 = alpha). This is the same layout as RGBA_Bytes (type 11), not the reversed BGRA order used by most of the other texture formats.
			*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		;Alternating use of .raw or .sep storage

Iritscen: wording

2026-04-05T01:13:08Z

wording

Iritscen: wording

2026-04-04T23:58:08Z

wording

← Older revision		Revision as of 23:58, 4 April 2026
Line 116:		Line 116:
	{{OBDtr\| 0x98 \| link \|FFC8FF\| 00 00 00 00 \| 0 \| link to a [[OBD:TXAN\|TXAN]] file; used if this texture is animated }}		{{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\| 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 ~~the~~ pixel data in the .raw file }}		{{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\| 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; supposedly the same "material type" (set at runtime) 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 }}
Line 125:		Line 125:


	;~~Alternative~~ use of .raw or .sep storage		;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).		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).

Iritscen: wording

2026-04-04T23:56:12Z

wording

Iritscen: added note to clarify that I8 is used and yet is not used by TSFT

2026-04-03T04:09:55Z

added note to clarify that I8 is used and yet is not used by TSFT

← Older revision		Revision as of 04:09, 3 April 2026
Line 42:		Line 42:
	: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)<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).
	: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)

Iritscen: changed "X view" column labels in geyser's "internal storage types" tables to hopefully be more accurate and clear

2026-04-03T00:46:21Z

changed "X view" column labels in geyser's "internal storage types" tables to hopefully be more accurate and clear

← Older revision		Revision as of 00:46, 3 April 2026
Line 132:		Line 132:

	==Oni's internal storage types==		==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~~.		Some of Oni's 16 types of image storage are elaborated on below in order to illustrate exactly how they work. The "Mem view" column shows the bytes in memory as big-endian and the "Disk view" column shows the bytes as they are stored in little-endian order. For example the bytes in memory shown as 0xFC00 are stored as "00 FC" on disk.

	===ARGB4444 (type 0)===		===ARGB4444 (type 0)===
Line 146:		Line 146:
	\|-		\|-
	!colspan=3\|<br>Bit values for primary colors (fully opaque)		!colspan=3\|<br>Bit values for primary colors (fully opaque)
	!~~Hex~~ view		!Mem view
	!~~RAM~~ view		!Disk 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 187:		Line 187:
	\|-		\|-
	!colspan=3\|<br>Bit values for primary colors		!colspan=3\|<br>Bit values for primary colors
	!~~Hex~~ view		!Mem view
	!~~RAM~~ view		!Disk 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 226:		Line 226:
	\|-		\|-
	!colspan=3\|<br>Bit values for primary colors (opaque)		!colspan=3\|<br>Bit values for primary colors (opaque)
	!~~Hex~~ view		!Mem view
	!~~RAM~~ view		!Disk 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 265:		Line 265:
	\|-		\|-
	!colspan=2\|Examples of bit values		!colspan=2\|Examples of bit values
	!~~Hex~~ view		!Mem view
	\|-		\|-
	\|Black, opaque\|\|<code>1 1 1 1 0 0 0 0</code>		\|Black, opaque\|\|<code>1 1 1 1 0 0 0 0</code>
Line 293:		Line 293:
	\|-		\|-
	!colspan=5\|<br>Bit values for primary colors (fully opaque)		!colspan=5\|<br>Bit values for primary colors (fully opaque)
	!~~Hex~~ view		!Mem view
	!~~RAM~~ 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>		\|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 335:		Line 335:
	\|-		\|-
	!colspan=5\|<br>Bit values for primary colors		!colspan=5\|<br>Bit values for primary colors
	!~~Hex~~ view		!Mem view
	!~~RAM~~ 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>		\|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 376:		Line 376:
	\|-		\|-
	!colspan=4\|Bit values for primary colors		!colspan=4\|Bit values for primary colors
	!~~Hex~~ view		!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>		\|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>
Line 416:		Line 416:
	\|-		\|-
	!colspan=5\|<br>Bit values for primary colors (fully opaque)		!colspan=5\|<br>Bit values for primary colors (fully opaque)
	!~~Hex~~ view		!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>		\|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>

Iritscen: wording

2026-02-23T22:28:36Z

wording

← Older revision		Revision as of 22:28, 23 February 2026
Line 3:		Line 3:
	TXMP is the only known instance type that is interpreted differently by the three kinds of Oni engines on the three platforms (Windows, Mac and PS2).		TXMP is the only known instance type that is interpreted differently by the three kinds of Oni engines on the three platforms (Windows, Mac and PS2).

	The difference between the format used in v1.0 of the engine (Windows retail) and v1.1 (Windows demo, Mac, [[OniX]]) is minor, at least from the point of view of disk storage (the structural difference is limited to runtime fields grouped at the end of the instance, which is why they haven't been documented or implemented in OniSplit). A more obvious difference is that v1.0 TXMPs store their pixel data in the .raw file and v1.1 TXMPs use the .sep file, but this merely amounts to using different ~~fields~~ within the ~~same~~ structure. Thus, even though the template checksums for v1.0 and v1.1 are different, both formats can easily be described together.		The difference between the format used in v1.0 of the engine (Windows retail) and v1.1 (Windows demo, Mac, [[OniX]]) is minor, at least from the point of view of disk storage (the structural difference is limited to runtime fields grouped at the end of the instance, which is why they haven't been documented or implemented in OniSplit). A more obvious difference is that v1.0 TXMPs store their pixel data in the .raw file and v1.1 TXMPs use the .sep file, but as far as the .dat is concerned this merely amounts to using a different data pointer field within the TXMP structure. Thus, even though the template checksums for v1.0 and v1.1 are different, both formats can easily be described together.

	The PS2 implementation is significantly different from the other two, in that it systematically uses indexed colors: instead of color being stored in the pixel data itself, each pixel is merely an 8-bit index into a 256-color palette (palettes are stored per-level, in files named level0_palette.pal etc). This difference is detailed in a separate section at the bottom of the page.		The PS2 implementation is significantly different from the other two, in that it systematically uses indexed colors: instead of color being stored in the pixel data itself, each pixel is merely an 8-bit index into a 256-color palette (palettes are stored per-level, in files named level0_palette.pal etc). This difference is detailed in a separate section at the bottom of the page.
Line 66:		Line 66:
	{{OBDtr\| 0x94 \| link \|FFC8FF\| 00 00 00 00 \| unused \| link to a [[OBD:TXAN\|TXAN]] file; used if this texture is animated }}		{{OBDtr\| 0x94 \| link \|FFC8FF\| 00 00 00 00 \| unused \| link to a [[OBD:TXAN\|TXAN]] file; used if this texture is animated }}
	{{OBDtr\| 0x98 \| link \|FFC800\| 00 00 00 00 \| unused \| link to a TXMP file that contain the environment map }}		{{OBDtr\| 0x98 \| link \|FFC800\| 00 00 00 00 \| unused \| link to a TXMP file that contain the environment map }}
	{{OBDtr\| 0x9C \| offset \|C800C8\| 20 00 00 00 \|00 00 00 20\| offset of pixel data in the raw file (~~Windows retail~~ only) }}		{{OBDtr\| 0x9C \| offset \|C800C8\| 20 00 00 00 \|00 00 00 20\| offset of pixel data in the raw file (v1.0 engine only) }}
	{{OBDtr\| 0xA0 \| offset \|C87C64\| 00 00 00 00 \| unused \| offset of pixel data in the separate file (~~Windows demo and Mac~~ only) }}		{{OBDtr\| 0xA0 \| offset \|C87C64\| 00 00 00 00 \| unused \| offset of pixel data in the separate file (v1.1 engine only) }}
	{{OBDtr\| 0xA4 \| char[12] \|B0C3D4\| AD DE \| dead \| The layout of these 12 bytes is different for the v1.0 and v1.1 versions (i.e. Windows retail vs. Windows demo and Mac):		{{OBDtr\| 0xA4 \| char[12] \|B0C3D4\| AD DE \| dead \| The layout of these 12 bytes is different for the v1.0 and v1.1 versions (i.e. Windows retail vs. Windows demo and Mac):
	*For a v1.1 TXMP, the four bytes at 0xA4-A7 are "00 00 00 00" instead of "AD DE AD DE", and correspond to a "material type" attributed at runtime (from [[TMBD]]), which is then used for impact/breakability lookup. The Windows retail TXMPs apparently have no such "material type" field.		*For a v1.1 TXMP, the four bytes at 0xA4-A7 are "00 00 00 00" instead of "AD DE AD DE", and correspond to a "material type" attributed at runtime (from [[TMBD]]), which is then used for impact/breakability lookup. The Windows retail TXMPs apparently have no such "material type" field.

← Older revision		Revision as of 01:13, 5 April 2026
Line 105:		Line 105:
	*Valid palette indices start at 1. 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 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 in a pal/ subdirectory of GameDataFolder, corresponding to how .raw and .sep files are stored in raw/ and sep/ subdirectories. Each palette consists of 256 32-bit colors and takes up 1024 bytes.
	*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.		*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.
	*Two new pixel formats were added, and are the only formats used on PS2: type 16 for opaque textures, meaning 32-bit RGB with ignored alpha, and type 17 for transparent textures.		*Two new pixel formats were added, and are the only formats used on PS2: type 16 for opaque textures, meaning 32-bit RGB with ignored alpha byte (always set to 0x80), and type 17 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~~.		*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).
			*Each pixel is stored as a 1-byte index into the image's chosen color palette.

	Here is how the end of TXMPrl_1 looks in level3_Final.dat of the English retail PS2 version.		Here is how the end of TXMPrl_1 looks in level3_Final.dat of the English retail PS2 version.
Line 113:		Line 114:
	\|- ALIGN=CENTER VALIGN=TOP		\|- 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\| 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 \| ~~palette~~ pixel format #16 (32-bit RGB, with inactive alpha~~); the other recurrent format is #17 (32-bit RGBA~~) }}		{{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\| 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\| 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\| 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\| 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; ~~supposedly~~ the same "material type" (set at runtime) as for Windows demo and Mac }}		{{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 \| ~~supposedly~~ the same texture name pointer (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 \| ~~supposedly~~ the same rendering optimization flags (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) }}		{{OBDtr\| 0xB4 \| char[12] \|B0C3D4\| AD DE \| dead \| completely unused bytes (not part of the template) }}
	\|}		\|}

← Older revision		Revision as of 23:56, 4 April 2026
Line 5:		Line 5:
	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 difference between the format used in v1.0 of the engine (Windows retail) and v1.1 (Windows demo, Mac, [[OniX]]) is minor, at least from the point of view of disk storage (the structural difference is limited to runtime fields grouped at the end of the instance, which is why they haven't been documented or implemented in OniSplit). A more obvious difference is that v1.0 TXMPs store their pixel data in the .raw file and v1.1 TXMPs use the .sep file, but as far as the .dat is concerned this merely amounts to using a different data pointer field within the TXMP structure. Thus, even though the template checksums for v1.0 and v1.1 are different, both formats can easily be described together.

	The PS2 implementation is significantly different from the other two, in that it systematically uses indexed colors: instead of color being stored in the pixel data itself, each pixel is merely an ~~8-bit~~ index into a 256-color palette ~~(palettes are stored per-level, in files named level0_palette.pal etc)~~. This ~~difference~~ is detailed ~~in a separate section at the bottom of the page~~.		The PS2 implementation is significantly different from the other two, in that it systematically uses indexed colors: instead of color being stored in the pixel data itself, each pixel is merely an index into a custom 256-color palette. This format is detailed under {{SectionLink\|\|PS2 implementation}}.

	==Windows ~~and~~ Mac ~~TXMP~~==		==Windows/Mac implementation==
	[[Image:txmp_all.gif]]		[[Image:txmp_all.gif]]

Line 70:		Line 70:
	{{OBDtr\| 0xA4 \| char[12] \|B0C3D4\| AD DE \| dead \| The layout of these 12 bytes is different for the v1.0 and v1.1 versions (i.e. Windows retail vs. Windows demo and Mac):		{{OBDtr\| 0xA4 \| char[12] \|B0C3D4\| AD DE \| dead \| The layout of these 12 bytes is different for the v1.0 and v1.1 versions (i.e. Windows retail vs. Windows demo and Mac):
	*For a v1.1 TXMP, the four bytes at 0xA4-A7 are "00 00 00 00" instead of "AD DE AD DE", and correspond to a "material type" attributed at runtime (from [[TMBD]]), which is then used for impact/breakability lookup. The Windows retail TXMPs apparently have no such "material type" field.		*For a v1.1 TXMP, the four bytes at 0xA4-A7 are "00 00 00 00" instead of "AD DE AD DE", and correspond to a "material type" attributed at runtime (from [[TMBD]]), which is then used for impact/breakability lookup. The Windows retail TXMPs apparently have no such "material type" field.
	*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).		*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).		*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.		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.
Line 100:		Line 100:

	==PS2 implementation==		==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.		The PS2 TXMP layout is similar to PC, with notable differences in the last few bytes due to Rockstar moving to 32-bit indexed color, presumably to save memory on a very RAM-limited system:
	*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).		*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 ~~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 pushed down 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 in a pal/ subdirectory of GameDataFolder, corresponding to how .raw and .sep files are stored in raw/ and sep/ subdirectories. 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.		*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.
	*~~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.		*Two new pixel formats were added, and are the only formats used on PS2: type 16 for opaque textures, meaning 32-bit RGB with ignored alpha, and type 17 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.		*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 TXMPrl_1 looks in level3_Final.dat of the English retail PS2 version.
	{{Table}}		{{Table}}
	{{OBD_Table_Header}}		{{OBD_Table_Header}}
Line 114:		Line 114:
	{{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\| 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 \| palette pixel format #16 (32-bit RGB, with inactive alpha); the other recurrent format is #17 (32-bit RGBA) }}		{{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 \| 0 \| 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 contains the environment map }}		{{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 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~~ \| offset of pixel data in the .sep file ~~(unused)~~ }}		{{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; supposedly the same "material type" (set at runtime) 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 \| supposedly the same texture name pointer (~~used~~ at runtime) as for Windows demo and Mac }}		{{OBDtr\| 0xAC \| char[4] \|B0C3D4\| AD DE AD DE \| dead \| supposedly the same texture name pointer (set at runtime) as for Windows demo and Mac }}
	{{OBDtr\| 0xB0 \| char[4] \|B0C3D4\| AD DE AD DE \| dead \| supposedly the same rendering optimization flags (runtime) as for Windows demo and Mac }}		{{OBDtr\| 0xB0 \| char[4] \|B0C3D4\| AD DE AD DE \| dead \| supposedly the same rendering optimization flags (runtime) as for Windows demo and Mac }}
	{{OBDtr\| 0xB4 \| char[12] \|B0C3D4\| AD DE \| dead \| completely unused bytes (not part of the template) }}		{{OBDtr\| 0xB4 \| char[12] \|B0C3D4\| AD DE \| dead \| completely unused bytes (not part of the template) }}
	\|}		\|}


	;Alternative use of .raw or .sep storage		;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).		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).		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).