OniGalore

OBD:TXMP: Difference between revisions

OBD Discussion

OBD:TXMP (view source)

Revision as of 22:33, 30 November 2025

1,455 bytes removed ,  Yesterday at 22:33
discovered this huge section commented out – I have restored it, tried to correct the broken parts, deleted the incomplete parts, and removed any mention of Macs being big-endian since that hasn't been true since two architecture migrations ago; the table markup is still pretty busted but it's functional
m (link fix; grammar tweaks)
(discovered this huge section commented out – I have restored it, tried to correct the broken parts, deleted the incomplete parts, and removed any mention of Macs being big-endian since that hasn't been true since two architecture migrations ago; the table markup is still pretty busted but it's functional)
 
(One intermediate revision by the same user not shown)
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 plaftorms (Windows, Mac and PS2).
TXMP is the only known instance type that is interpreted differently by the three kinds of Oni engines on the three plaftorms (Windows, Mac and PS2).


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


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


==Windows and Mac TXMP==
==Windows and Mac TXMP==
 
[[Image:txmp_all.gif]]
[[image:txmp_all.gif]]




Line 67: 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| at this position starts the texture part in the raw file (Windows retail only) }}
{{OBDtr| 0x9C | offset  |C800C8| 20 00 00 00 |00 00 00 20| offset of pixel data in the raw file (Windows retail only) }}
{{OBDtr| 0xA0 | offset  |C87C64| 00 00 00 00 | unused    | at this position starts the texture part in the separate file (Windows demo and Mac only) }}
{{OBDtr| 0xA0 | offset  |C87C64| 00 00 00 00 | unused    | offset of pixel data in the separate file (Windows demo and Mac only) }}
{{OBDtr| 0xA4 | char[12] |B0C3D4| AD DE      | dead      | The layout of these 12 bytes is different for the "PC" and "Mac" versions (i.e. Windows retail vs. Windows demo and Mac):
{{OBDtr| 0xA4 | char[12] |B0C3D4| AD DE      | dead      | The layout of these 12 bytes is different for the v1.0 and v1.1 versions (i.e. Windows retail vs. Windows demo and Mac):
*For a Mac or Windows demo TXMP, the four bytes at 0xA4-A7 are "00 00 00 00" instead of "AD DE AD DE", and correspond to a "material type" attributed at runtime (from [[TMBD]]), which is then used for impact/breakability lookup. The Windows retail TXMPs apparently have no such "material type" field.
*For a v1.1 TXMP, the four bytes at 0xA4-A7 are "00 00 00 00" instead of "AD DE AD DE", and correspond to a "material type" attributed at runtime (from [[TMBD]]), which is then used for impact/breakability lookup. The Windows retail TXMPs apparently have no such "material type" field.
*The fields at 0xA8-AF (for Windows demo and Mac) or 0xA4-AB (for Windows retail) are used only at runtime (and somehow obfuscated by "DEAD" when written to disk). Judging by the Windows demo and Mac engine, we can assume they are the same in both engines, and serve for rendering optimization (there is a texture name pointer, a "dirty" flag stored as a byte and 3 extra bytes used as flags).
*The fields at 0xA8-AF (for v1.1) or 0xA4-AB (for v1.0) are used only at runtime (and somehow obfuscated by "DEAD" when written to disk). Judging by the Windows demo and Mac engine, we can assume they are the same in both engines, and serve for rendering optimization (there is a texture name pointer, a "dirty" flag stored as a byte and 3 extra bytes used as flags).
*For Windows retail, the four bytes at 0xAC-AF are completely unused (not part of the template).
*For Windows retail, the four bytes at 0xAC-AF are completely unused (not part of the template).
Since runtime fields are grouped at the end, PC and Mac TXMPs are treated by OniSplit under the same template, merely switching between the .raw and .sep links, and blanking out everything past 0xA4.
Since runtime fields are grouped at the end, v1.0 and v1.1 TXMPs are treated by OniSplit under the same template, merely switching between the .raw and .sep links and blanking out everything past 0xA4.
}}
}}
{{OBDtr| 0xB0 | char[16] |B0C3D4| AD DE      | dead      | completely unused bytes (not part of the PC or Mac TXMP template) }}
{{OBDtr| 0xB0 | char[16] |B0C3D4| AD DE      | dead      | completely unused bytes (not part of the v1.0 or v1.1 TXMP template) }}
|}
|}


Line 117: Line 116:
{{OBDtr| 0x98 | link    |FFC8FF| 00 00 00 00 | unused    | link to a [[OBD:TXAN|TXAN]] file; used if this texture is animated }}
{{OBDtr| 0x98 | link    |FFC8FF| 00 00 00 00 | unused    | link to a [[OBD:TXAN|TXAN]] file; used if this texture is animated }}
{{OBDtr| 0x9C | link    |FFC800| 00 00 00 00 | unused    | link to a TXMP file that contains the environment map  }}
{{OBDtr| 0x9C | link    |FFC800| 00 00 00 00 | unused    | link to a TXMP file that contains the environment map  }}
{{OBDtr| 0xA0 | offset  |C800C8| C0 05 00 00 |00 00 05 C0| position of the pixel data in the .raw file }}
{{OBDtr| 0xA0 | offset  |C800C8| C0 05 00 00 |00 00 05 C0| offset of the pixel data in the .raw file }}
{{OBDtr| 0xA4 | offset  |C87C64| 00 00 00 00 | unused    | position of the pixel data in the .sep file (unused) }}
{{OBDtr| 0xA4 | offset  |C87C64| 00 00 00 00 | unused    | offset of pixel data in the .sep file (unused) }}
{{OBDtr| 0xA8 | int32    |B0C3D4| 00 00 00 00 | 0        | 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 (used at runtime) as for Windows demo and Mac }}
Line 124: Line 123:
{{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 for PC or Mac game data (where pixel data is stored exclusively in .raw or exclusively in .sep for all TXMPs), PS2 TXMPs use .raw and .sep storage alternatively, depending on the TXMP. The engine apparently uses the .sep pointer only if there is no .raw pointer (or vice-versa).
Unlike the Win/Mac game data (where pixel data is stored exclusively in .raw or exclusively in .sep for all TXMPs), PS2 TXMPs use .raw and .sep storage alternatively, depending on the TXMP. The engine apparently uses the .sep pointer only if there is no .raw pointer (or vice versa).


Examples of textures using .sep storage are: all [[: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).
Line 131: Line 131:
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.
Environment/character/particle TXMPs seem to be using .raw storage consistently (not checked beyond level1_Final). As a notable anomaly, .sep storage is used for the following three textures (console screens) in level0_Final: _CON_SAVEGAME (main TXMP only; the animation frames use .raw storage), _CON_SAVEGAME_USED, _CON_USED.


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


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


==Notes==
==Notes==
Retrieved from "https://wiki.oni2.net/Special:MobileDiff/45715...45989"