OBD talk:TXMP
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
- probably an index
- MIP mapping
- not sure
- maybe they are not only MIP mapping options
- (in that case almost certainly a set of flags)
- Color depth
- It's not just the color depth
- (actually, quite little to do with color depth)
- so almost certainly a bitset.
MIP mapping
- 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
- Enabled for skyboxes (anything special about the format?)
- 0x08
- unknown
- 0x10
- This one is enabled for env-mapped textures and env maps themselves.
- Also enabled for skyboxes?
- 0x20
- if you use this bit, you get always a white image; never used in Oni (IIRC)
- 0x40
- unknown
- 0x80
- unknown
- 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)
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
- 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.
- 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)
- 1
- (5,5,5) RGB and 1 bit extra, or (5,6,5) RGB?
- 2
- (5,5,5) RGB, 1 bit extra
- 8
- (8,8,8) RGB?
- 9
- compressed (four times) (algorithm detailed elsewhere)
- Anything else?
- No. Ssg 10:52, 13 February 2007 (CET)