OBD talk:TXMP

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

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)

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)