This post by MadMarioSkills
inspired me to take a closer look at how MBG's DTS format works for textures. Here's a compilation of my findings:
First of all, you can open any DTS file in a hex editor such as XVI32 to change these values. At the end of the file, you will find information on the various textures in the file. It should look something like this in the ASCII view:
This area stores information on each of the textures in the file. First, there are the names of the textures, delimited by either character 0x05 or 0x06; I don't know if there's any pattern to which one is used where. Then, after the texture names, we have four bytes for each texture, the last three of which are usually 00 00 00. These determine the settings for each texture, in the same order that the texture names appear in (the order seems somewhat random). The "default" in Blender's DTS exporter is 0x43 00 00 00.
To describe what individual bits do, I'll write the four bytes of info as:
where abcdefgh is the first byte in binary, and xx yy zz are the last three in hexadecimal.
First of all, you can open any DTS file in a hex editor such as XVI32 to change these values. At the end of the file, you will find information on the various textures in the file. It should look something like this in the ASCII view:
Code:
...|texture1|texture2-texture3|texture4|texture5C c C C W ...
This area stores information on each of the textures in the file. First, there are the names of the textures, delimited by either character 0x05 or 0x06; I don't know if there's any pattern to which one is used where. Then, after the texture names, we have four bytes for each texture, the last three of which are usually 00 00 00. These determine the settings for each texture, in the same order that the texture names appear in (the order seems somewhat random). The "default" in Blender's DTS exporter is 0x43 00 00 00.
To describe what individual bits do, I'll write the four bytes of info as:
Code:
abcdefgh xx yy zz
Bit/Byte | Function | Effect in MBG |
---|---|---|
a | Disable mipmapping | The texture will not be blurred at faraway distances like it normally is. In practice, makes the texture look badly aliased. |
b | Disable environment mapping | If this bit is 0, the texture will appear "shiny" and reflect the sky. The amount of reflection is stored elsewhere in the file (I was unable to figure out the format, but it seems to be at the very end). The environment mapping will be stronger in parts of the texture with a higher alpha value, contrary to what one would expect. (This is why base.marble.png has such a low alpha.) |
c | Use self-illumination | The texture will appear bright from all sides, independent of the sun's direction, color, or ambient light. This is why you can always see gems clearly even in a dark area of the level. |
d | Subtractive translucency | If translucency is enabled, the texture will be drawn by subtracting its colors from what's behind it, similar to the Subtract mode in Photoshop. This is not affected by the alpha channel. |
e | Additive translucency | If translucency is enabled, the texture will be drawn by adding its colors to what's behind it, similar to the Addition mode in Photoshop. This is affected by the alpha channel, with higher alpha indicating more addition. |
f | Translucency | Allows the texture to use its alpha channel as opacity. This can cause the drawing order to function improperly. |
g | Enable TWrap | Appears to prevent textures from wrapping vertically when disabled. |
h | Enable SWrap | Appears to prevent textures from wrapping horizontally when disabled. |
xx | Mipmap border | Set to 1 when the "Mipmap Zero Border" option is selected. This creates a black border that appears between textures when the texture is viewed from far away. I have no idea what this would be used for. |
yy | Unknown | This byte was never modified in my tests. I suspect it's part of either mipmap border (as above) or part of IFL animation (as below), i.e. one of those is stored in two bytes. |
zz | IFL sequence index | When nonzero, causes the texture to use an IFL animation instead (e.g. the start pad colors that change). I have no idea how this system works, but I can only assume that this byte is the index of the animation or similar information. |