OBD talk:TXMP

From OniGalore
Revision as of 14:22, 6 March 2007 by Geyser (talk | contribs) (→‎0x88: @ alloc: besser so?)
Jump to navigation Jump to search
Complete and accurate knowledge on the TXMP format is badly needed.
For one thing, incomplete/inaccurate knowledge may be a reason why repacking (with OUP) fails.
Also, import and export lack a few features (alpha, env maps) and may get colors slightly wrong.
Basically, the incomplete/inaccurate information is related to the three bytes below, and to the associated RAW/SEP formats.
One not-too-comfortable aspect is that apparently contradictory settings for the 3 bytes are somehow interpreted by Oni.
geyser 21:09, 3 February 2007 (CET)
Option Value Meaning
MIP-mapping types 00 off
01 on
11 unknown
1C unknown (used for skyboxes, works with 00 too)
Color depths 10 16 bit
12 16 bit + shade vertex
14 16 bit + 4 bits for the alpha channel
20 32 bit
Store types 00 uncompressed, with alpha blending
01 uncompressed, without alpha blending
02 unknown
03 unknown
08 32 bit uncompressed (used for skyboxes)
09 compressed
0A unknown
0B unknown

Bitsets or indices

Store type (0x90)
probably an index
MIP mapping (0x88)
not sure
maybe they are not only MIP mapping options
(in that case almost certainly a set of flags)
Color depth (0x89)
It's not just the color depth
(actually, quite little to do with color depth)
so almost certainly a bitset.

MIP mapping (0x88)

Bitset

0x01
This one "just" turns mip mapping on and off.
For uncompressed pictures, resampling is trivial. ==> They are "pre-resampled". It's not done at runtime.
what about compressed ones.
0x02
unknown
0x04
Disable wrapping for the U coordinate of the texture.
Enabled for skyboxes, animations and pretty much anything else that does not need texture wrapping.
0x08
Disable wrapping for the V coordinate of the texture. See above.
0x10
This one is enabled for env-mapped textures and env maps themselves.
Also enabled for skyboxes?
0x20
used a runtime (marks if a texture name has been allocate for this TXMP or not)
0x40
unknown - animation related
0x80
unknown - animation related, only used by an "electric arc" texture, could mean to play frames of the animation in random order
Anything else?
There aren't so many values: 0, 1, 17, 28. It's hard to decide against an ID.
A bitset does make some sense because both 1 and 17 use MIP mapping...
Well, IMO they're bitsets. I fixed that a long time ago. Ssg 10:59, 13 February 2007 (CET)
You "fixed that" where? I can't see it detailed on OS... geyser 04:05, 6 March 2007 (CET)
Here? Ssg 12:19, 6 March 2007 (CET)
Not that it matters now, but IIRC you had not uploaded that update as of 2007/02/13... geyser 13:41, 6 March 2007 (CET)

Color depth

Actually, the colors are parsed according to the store type.
This one only sets the depth for miscellaneous extras (alpha, env map, etc)
0x01
Used when again?
0x02
Reads the high byte as env map (0x00 is "little", 0xFF is "much")
Sometimes used in conjunction with 5x5x5 textures, i.e. if it really
reads the whole byte, the 3 lower bits will be garbage. Not sure...
0x04
Reads the high byte as alpha (0x00 is transparent, 0xFF is opaque)
0x08
Used when again?
0x10
On if there are 16 bits per uncompressed pixel (color depth etc may vary) ==> no changes ==> Oni reads it directly from the raw file
It appears to me that this bit means that the byte order of texture raw data must be swaped, it does not have anything to do with the number of bits which is encoded in the texture format anyway. Neo
0x20
On if there are 32 bits per uncompressed pixel (color depth etc may vary) (or may they?)
IIRC, that bit is never used in Oni. If you use it, Oni chrashes.
This one appears to be used only at runtime to mark if the texture has been loaded or not (loading basically means to convert the offset to texture data in the raw file to a memory address, that's why Oni crashes if you set this bit, it thinks that the texture is already loaded and it uses the file offset as a memory pointer which is not valid) Neo
0x40
Looks like TXAN looping ON/OFF. Somebody please check somehow ^^
0x80
16 bit blue (?) - only SHIELD use it

The first two bits of the next bitset are used too:

0x01
16 bit alpha (?) - only INVIS use it
0x02
16 bit red (?) - only DAODAN_SHIELD use it Ssg 11:06, 13 February 2007 (CET)

Store type

Data per pixel, uncompressed unless mentioned otherwise

0
(4,4,4) RGB, 4 bits extra (interpreted as alpha or env map blending), equivalent to GL_RGBA4 OpenGL image format
1
(5,5,5) RGB and 1 bit extra, the extra bit is simply ignored, equivalent to GL_RGB5 OpenGL image format
2
(5,5,5) RGB, 1 bit extra (interpreted as alpha or env map blending), equivalent to GL_RGB5_A1 OpenGL image format
8
(8,8,8) RGB, 8 bits extra that are ignored, equivalent to GL_RGB OpenGL image format
9
compressed (four times) (algorithm detailed elsewhere), equivalent to GL_COMPRESSED_RGB_S3TC_DXT1_EXT OpenGL compressed image format
Anything else?
No. Uups... I mean, yes.
The "mac exe" contains the following stuff in the image section (image.c or somthing like that):
rgb555, rgb565, rgba5551, argb1555, argb4444, rgba4444, rgba8888, s3, compressed, i8, i1, i4a4
(r=red, g=green, b=blue, a=alpha, i=intensity; see http://www.cg.tuwien.ac.at/~wimmer/view3dx/TEXUS.html too)




Reloaded

Woohoo, nice clean list for accurate knowledge! Over here!!!

0x88

Bitset (rather large: 18 bits at least) bytes are listed in Little Endian

0x 01 00 00 00
MIP mapping enabled (generations stored in RAW/SEP, used at runtime)
Q: Anything special about MIP mapping of DXT1-compressed pixels?
0x 02 00 00 00
Q: (sorry) ever used? effect? ^^ geyser
0x 04 00 00 00
U wrapping disabled
0x 08 00 00 00
V wrapping disabled
0x 10 00 00 00
Enabled for env-mapped textures and env maps themselves.
Q: Also enabled for skyboxes? Exact effect? geyser
0x 20 00 00 00
used a runtime (marks if a texture name has been allocated for this TXMP or not) Neo
Q: same question as below for 0x00200000: does the whole bitset get copied "elsewhere" at runtime? geyser
0x 40 00 00 00
unknown - animation related Neo
Q: (sorry) exact effect? ^^ geyser
0x 80 00 00 00
unknown - animation related, only used by an "electric arc" texture, could mean to play frames of the animation in random order Neo
0x 00 01 00 00
Q: Ever used? Effect? ^^ geyser
0x 00 02 00 00
Reads the high byte as env map (0x00 is "little", 0xFF is "much")
Q: Sometimes used in conjunction with store type 1 or 2. 5x5x5 color, 1 bit extra, i.e., if it really reads the whole high byte, the 3 lower bits are garbage then?
0x 00 04 00 00
Reads the high byte as alpha (0x00 is transparent, 0xFF is opaque)
Q: Same as above: what if the store type is 1 or 2?
0x 00 08 00 00
Q: Ever used? Effect? ^^ geyser
0x 00 10 00 00
On if there are 16 bits per uncompressed pixel (color depth etc may vary) ==> no changes ==> Oni reads it directly from the raw file Ssg 11:06, 13 February 2007 (CET)
It appears to me that this bit means that the byte order of texture raw data must be swapped, it does not have anything to do with the number of bits which is encoded in the texture format anyway. Neo
Q: Whom is the swapped data relevant to, then? "Texture format" = "store type"? "Number of bits" = RGB color depth = "store type"? geyser
0x 00 20 00 00
IIRC, that bit is never used in Oni. If you use it, Oni chrashes. Ssg 11:06, 13 February 2007 (CET)
This one appears to be used only at runtime to mark if the texture has been loaded or not (loading basically means to convert the offset to texture data in the raw file to a memory address, that's why Oni crashes if you set this bit, it thinks that the texture is already loaded and it uses the file offset as a memory pointer which is not valid) Neo
Q: Neo, are you saying Oni writes to the memory-mapped DAT-part of every loaded TXMP? Or is that particular bitset copied "elsewhere"? geyser
0x 00 40 00 00
Looks like TXAN looping ON/OFF. Somebody please check somehow ^^ geyser
Q: (sorry) did anybody "please check somehow"? ^^ geyser
0x 00 80 00 00
16 bit blue (?) - only SHIELD uses it Ssg 11:06, 13 February 2007 (CET)
Q: ??? geyser
0x 00 00 01 00
16 bit alpha (?) - only INVIS uses it Ssg 11:06, 13 February 2007 (CET)
Q: ??? geyser
0x 00 00 02 00
16 bit red (?) - only DAODAN_SHIELD uses it Ssg 11:06, 13 February 2007 (CET)
Q: ??? geyser
To the last 3 entries: F.e. the SHIELD in ONI is blue. If you disable the "blue bit" and enable the "red bit" you'll get a red shield. If you disable the "blue bit" and enable no other "colour bit", you'll get a white shield, because IIRC, the hex data of the texture is fully FFFF. Ssg 12:35, 6 March 2007 (CET)
Neo, what say you? Ssg: thanks a lot, but... no "green" bit? geyser 13:44, 6 March 2007 (CET)

0x90

Integer ID. Defines the RGB color depth of texels (is that correct? geyser)

0
(4,4,4) RGB, 4 bits extra (interpreted as alpha or env map blending)
equivalent to GL_RGBA4 OpenGL image format Neo
Q: Does the interpretation of the high bits depend on the 0x88 settings? geyser
1
(5,5,5) RGB and 1 bit extra
the extra bit is simply ignored, equivalent to GL_RGB5 OpenGL image format Neo
Q: Is the extra bit always ignored, regardless of the 0x88 settings? geyser
2
(5,5,5) RGB, 1 bit extra (interpreted as alpha or env map blending)
equivalent to GL_RGB5_A1 OpenGL image format Neo
Q: Does the interpretation of the high bits depend on the 0x88 settings? geyser
8
(8,8,8) RGB, 8 bits extra
extra bits are ignored, equivalent to GL_RGB OpenGL image format Neo
Q: (sorry) are the extra bit always ignored, regardless of the 0x88 settings? geyser
9
compressed (four times) (algorithm detailed elsewhere)
equivalent to GL_COMPRESSED_RGB_S3TC_DXT1_EXT OpenGL compressed image format Neo
(note: ARB stands for Architecture Review Board, not Alpha Red Blue ^^ geyser)
Q: Aha, "dxt1". Any more ideas looking at THESE? geyser
Anything else?
Q: (sorry) nothing else, ever ever? ^^ geyser