EQInterface Forums - View Single Post

The artifacts are caused by the DX texture compression. When I use a DDS file saved in A8R8G8B8 and take a screen shot the pixel colors are are exactly the same as specified in the DDS file for an unstretched texture.

The DXT3 compression format is a bit different than most other lossy compressions. It goes through the texture 4x4 pixels at a shot and picks two colors. Then all the pixels in that block are either (color1), (color2), (color1*(1/3)+color2*(2/3)), or (color1*(2/3)+color2*(1/3)). So if you have three or more very distinct colors in that block you're going to end up with weird results. Like a one pixel black line all the sudden changing colors half way through because on your texture file there is something directly below it thats white. With the knowledge of how the compression works you could do things to help minimize the artifacting. Make sure there is a 4 pixel space between UI elements with different colors. Try to align each UI element on your texture so that any sudden changes in color are compressed in separate blocks. Stuff like that.

The D3DXCreateTextureFromFileEx function, which is used to load DDS images should only create as many mip levels as the caller asks for. However it looks like EQ passes D3DX_DEFAULT for all DDS files, which means that a full mip chain is created. For TGA files EQ calls D3DXCreateTextureFromFileInMemoryEx and only requests one mip level. Kind of strange that EQ uses the FileInMemory function. I wonder if EQ does something strange like converts the TGA file to a bitmap before it asks DX to convert it?

You are right though all DDS files have an extra one third memory overhead for the mip chain. It also means that because TGA files are always compressed, a A8R8G8B8 DDS file will eat up a little over 5 times as much memory. But you still have to put that number into perspective. A 256x256 TGA file will take 64kB and the A8R8G8B8 DDS file will take 341.33KB. So for every 256x256 your talking an increase of 277.33KB. If you were to convert all 69 spell, gemicon, and dragitem textures to DDS you would gain 18.69MB. That is probably an unacceptable increase for some people. Especially those running less powerful systems. If you were to just convert your 8 equivalent window_pieces textures you only gain 2.17MB. Many UIs tend to shrink things from the default UI so many pieces could be shrunk and could also be packed tighter. You might be able to reduce that down to as few as 4 files. Upping your textures to 512x512 could help reduce the wasted pixels. You could also combine all your UI pieces that don't need alpha and save them in DDS R8G8B8 to save about 85KB per 256x256 texture.

There is also another point that Haliken brought up. Speed of loading. If you take your TGA files and convert them to DDS DXT3 they will take one third more memory but load very fast. Since DX wants mip maps anyways if they are included in the file it will load even faster. Actually DXT3 takes 16 bytes per block whereas DXT1 only takes 8 bytes per block to store. So if DXT1 is acceptable you are best off using DDS DXT1 and including the mip maps in the file. It will load much faster than a TGA file or an uncompressed DDS file and even though it includes mip maps it will take 1.5 times less memory even after the TGA is compressed to DXT3! The difference between DXT3 and DXT1 is that DXT3 has a 4-bit alpha channel and DXT1 is only 1-bit. So alpha is all or nothing with DXT1, and DXT3 can have 15 different levels of transparency. The way the alpha information is encoded in DXT1 also means there is one less possible color per block. So for DXT1 the possible colors are (color1), (color2), or (color1*(1/2)+color2*(1/2)).

09-13-2008, 05:53 AM	#11
Stoplaughin A Tundra Mammoth Join Date: Mar 2004 Posts: 60	The artifacts are caused by the DX texture compression. When I use a DDS file saved in A8R8G8B8 and take a screen shot the pixel colors are are exactly the same as specified in the DDS file for an unstretched texture. The DXT3 compression format is a bit different than most other lossy compressions. It goes through the texture 4x4 pixels at a shot and picks two colors. Then all the pixels in that block are either (color1), (color2), (color1(1/3)+color2(2/3)), or (color1(2/3)+color2(1/3)). So if you have three or more very distinct colors in that block you're going to end up with weird results. Like a one pixel black line all the sudden changing colors half way through because on your texture file there is something directly below it thats white. With the knowledge of how the compression works you could do things to help minimize the artifacting. Make sure there is a 4 pixel space between UI elements with different colors. Try to align each UI element on your texture so that any sudden changes in color are compressed in separate blocks. Stuff like that. The D3DXCreateTextureFromFileEx function, which is used to load DDS images should only create as many mip levels as the caller asks for. However it looks like EQ passes D3DX_DEFAULT for all DDS files, which means that a full mip chain is created. For TGA files EQ calls D3DXCreateTextureFromFileInMemoryEx and only requests one mip level. Kind of strange that EQ uses the FileInMemory function. I wonder if EQ does something strange like converts the TGA file to a bitmap before it asks DX to convert it? You are right though all DDS files have an extra one third memory overhead for the mip chain. It also means that because TGA files are always compressed, a A8R8G8B8 DDS file will eat up a little over 5 times as much memory. But you still have to put that number into perspective. A 256x256 TGA file will take 64kB and the A8R8G8B8 DDS file will take 341.33KB. So for every 256x256 your talking an increase of 277.33KB. If you were to convert all 69 spell, gemicon, and dragitem textures to DDS you would gain 18.69MB. That is probably an unacceptable increase for some people. Especially those running less powerful systems. If you were to just convert your 8 equivalent window_pieces textures you only gain 2.17MB. Many UIs tend to shrink things from the default UI so many pieces could be shrunk and could also be packed tighter. You might be able to reduce that down to as few as 4 files. Upping your textures to 512x512 could help reduce the wasted pixels. You could also combine all your UI pieces that don't need alpha and save them in DDS R8G8B8 to save about 85KB per 256x256 texture. There is also another point that Haliken brought up. Speed of loading. If you take your TGA files and convert them to DDS DXT3 they will take one third more memory but load very fast. Since DX wants mip maps anyways if they are included in the file it will load even faster. Actually DXT3 takes 16 bytes per block whereas DXT1 only takes 8 bytes per block to store. So if DXT1 is acceptable you are best off using DDS DXT1 and including the mip maps in the file. It will load much faster than a TGA file or an uncompressed DDS file and even though it includes mip maps it will take 1.5 times less memory even after the TGA is compressed to DXT3! The difference between DXT3 and DXT1 is that DXT3 has a 4-bit alpha channel and DXT1 is only 1-bit. So alpha is all or nothing with DXT1, and DXT3 can have 15 different levels of transparency. The way the alpha information is encoded in DXT1 also means there is one less possible color per block. So for DXT1 the possible colors are (color1), (color2), or (color1(1/2)+color2(1/2)).