Stoplaughin

I was working on updating my UI and I ran into a rather annoying issue. Many of my textures have strange artifacts in EQ. It seem like its caused by a horrendous stretching algorithm. It seems like this should be a common issue unless I'm doing something wrong, but I wasn't able to find any threads similar to my issue.

One example is when I tried to make the main window border one pixel black. I made it 64 pixels long so that the texture wouldn't have to be tiled as much for larger windows. Sure enough I had a one pixel border, but about 15% from the left side and about 20% long was a darker color but noticeably far from black on the bottom of all the windows with borders. The lighter bar followed those proportions no matter the size. I filled those 64 pixels with black several times to be sure. Checked the alpha channel several times. Neither of those fixed it. Then I shrank it to 16 pixels long and problem solved.

I have had other artifacts with other textures. It seems common with textures with hard edges. Usually changing the size of the texture only makes it worse. Another example is a button texture. Even when the button is the same size as the texture there are artifacts. On the left is a screen shot in EQ and the right is from the texture file.



Anyone else experienced this issue? Tips on how to minimize it? The only thing I have found is to soften the edges. Or am I missing something?

Haliken

When EQ sends your UI textures to the video card (or at least into RAM), it compesses them first. The artifacts you're seeing are due to the lossless TGA images being converted into DDS.

The only way around it is to play with the image, adding buffers beyond the edges of your graphics (put an extra row of pixels around your hard edges of the same color) or shifting the location of the graphics to use within the image for example, to try and work around the compression artifacts.

Enok

Stoplaughin

Thanks for the info. I used the DirectX Texture Tool to convert my TGA images to DDS and problem solved. No compression or at least its not visible.

Haliken

When you use DDS files instead, those images are fed directly to your video card/RAM without compressing or changing them. The DDS files themselves do typically present some compression artifacts, but much less than EQ converting the TGA files for you. Also, with DDS files, what you see is what you get in game.

So... good call. Be sure to keep non-DDS versions of your images for editing, since DDS files can be quite lossy. Edit your originals then reconvert to DDS when making changes. At least that's my advice.

Enok

Stoplaughin

I did some research and it looks like all TGA files are compressed in the D3DFMT_DXT3 format. That format has 4-bits per pixel alpha channel. Each 4x4 block of pixels, or texel as its called has two 16-bit (R5G6B5) colors associated with it. For each of the 16 pixels in a texel they have two bits which represent the linear interpolation of between the two colors. So it leaves artifacts if you have three or more different colors in a texel.

The advantage of DDS files is EQ does not change the format from the way they are stored in the file. So you can pick just about any uncompressed color-bit combination you can imagine, or you can pick any of the 5 DXT compressed formats.

And if anyone is wondering EQ uses A4R4G4B4 for text.

Haliken

Have you determined a ''best'' DDS format for use with the EQ UI? I'd only ever tried the DXT ones and been disappointed with the artifacting (not like using TGA was any better, but still). Had just assumed the other formats wouldn't work.

Don't get me wrong, I do plan to do more testing now, but was just interested in more of what you found.

Enok

Stoplaughin

A8R8G8B8 the same format as the video buffer so its basically as good as you can get. A4R4G4B4 isn't bad. Also if you don't need the alpha channel you can choose a format without alpha R5G6B5 is a good format that doesn't have alpha. Any format that doesn't match the video buffer has to be converted before its displayed, but it saves on memory storage and memory bandwidth.

Haliken

At the very least, an A8R8G8B8 DDS file is lossless and interchangeable with TGA files (if named .tga, EQ will still load it correctly). This wasn't always true, and may still not be, at least with the compressed DXT versions; if the file wasn't loaded explicitly as a DDS file by EQ, it would cause an error.

Anyhow, I have converted my UIs over to 8888 and gotten a drastic increase in sharpness. Thanks for asking questions as you got me fiddling around with DDS files again as well.

Enok

shillingworth

Those surface formats you guys are talking about are different per computer, most will default to A8R8G8B8, but in the case of it not being supported the devices moves down a list of formats until it finds one for the screen and back buffer that match.

The artifacts your seeing aren't related to surface formats, it's due to texture co-ordinate systems. EQ has to convert the X and Y values of location to floating point numbers between 0 and 1, considering the complexity of the scene, they are most likely using the HLSL half(16 bits) structure instead of the float(32 bits) structure for those texture co-ordinates. The resulting image is also rasterized, which can sometimes place as many as 12 pixels on top of each other.

Compression artifacts show as a sort of blotchy effect across an entire surface.

While DDS are nice because then you gain the advantage of a floating point format for pixel values, you also gain a huge amount of memory usage with them because Direct X will load every detail level from the size specified all the way down to 1x1, the flags in the DX LoadTextureFromFile function only specifies which detail levels are sent to the graphics cards, so system memory still gets eaten up.

__________________

Haliken

Regardless of the details, the artifacts we see are clearly caused by the texture format. Use TGA and get incredibly obvious artifacts in-game; use DDS saved as A8R8G8B8 and get pristine, pixel-perfect colors.

Enok

P.S. - I've been saving the DDS files without mip-maps, so unless EQ is generating them (which it would be with TGA too since it seems to convert TGAs into DXT5 DDS format when it loads them), the only extra memory overhead would be from using A8R8G8B8 instead of DXT5. Memory usage by EQ has not lead me to believe there's a noticeable difference in memory usage, and UI load time is significantly faster (60 TGAs for item icons alone being converted to DDS meant 60 less 256x256 TGAs that EQ needed to convert to DXT5 upon loading).

Stoplaughin

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)).

Haliken

I was trying to profile EQ's UI memory usage, but there's a glaring flaw with EQ's loading of the UI: every time I did a /loadskin, memory usage simply increased. Each successive /load default increased memory used by roughly 16 MB. Each successive /load dds_ui increased memory use by roughly 22 MB.

I've been doing all this testing on a relatively old and weak computer: 1.3 GHz Athlon, 512 MB SDR RAM, Radeon 9550. Page file is a fixed 2GB, not fragmented. There is no appreciable framerate difference between using DDS versus TGA, load times are drastically faster with DDS (the UI loads in roughly 10 seconds for DDS compared to roughly 30 seconds for TGA); again, this is an old computer and I imagine CPU power has a large bearing on the load time for TGAs as they're converted to DDS.

- Idle memory usage is at ~180 MB.
- Once EQ is loaded and at character select: ~800 MB (arbitrary amount of Luclin models on versus off).
- Once logged in with the default UI: ~890 MB (old world zone, no other players).
- Once logged in with a largely DDS UI: ~933 MB (old world zone, no other players).

These memory usage numbers were consistent across multiple sessions. Obviously, much of this memory usage winds up in my paging file since this machine only has 512 MB of physical RAM.

At first it looks damning, but remember the default UI loads for character select. It's unclear if the default is reloaded when you log in to a character (if that character is set to use the default). If not, that would explain the higher than expected difference.

At the extreme end, if a fully DDS UI consumes 50 more MB, it's a drop in the bucket compared to EQ's over-all RAM usage, and provides DRASTIC (theorhetically up to nearly 16 times the quality, texel accuracy versus pixel accuracy) image quality improvements, faster load times and an unmeasurable (with my tools) affect on performance.

Enok

Stoplaughin

I found an interesting fact. EQ doesn't load textures until the first time it needs to draw them. So when you load your UI it doesn't necessarily load all 200-400 textures depending on the UI and whether or not it includes the default as a no break method.

I definitely noticed the memory leak when reloading your UI, while I was updating my UI. I'm not sure what memory isn't being freed. When I looked the only textures I saw that are allocated in DX buffers and not deleted are the con indicators. Which seems a little small considering the size of the memory leak.

I just took the default UI and converted all the TGAs to DDS A8RG8B8 and did a simple 10 frame average on render times. The tests were on an Athlon 1800+ 1.5Ghz, 1.5GB RAM, Geforce FX 5700LE 128MB. The results surprised me. I tested in Everfrost and the DDS version was 3% faster than the TGA version. I tested in Blightfire and the TGA version was 5% faster than the DDS version. Given the simplicity of the test at most DDS could potentially cause a very small increase in render time on average. Probably unnoticeable for most people. For the people with 64MB video cards and less RAM the increase may be more significant but still probably not noticeable.