20,500
edits
OBD:TXMP: Difference between revisions
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
(added detail on effects options and PS2 palette format; added section on pixel byte storage order; made formal subsections out of informal subsections) |
(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) |
||
| 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 | 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. | ||
==PS2 implementation== | ==PS2 implementation== | ||