I stole code for loading .tga from the ATI demo I used ealier. But it still took quite a while to implement, so I really regret that I didn't try PIX earlier.

I didn't know PIX and I guess I shied away because of that. Too bad.

Once I got it up and running, I must say that Im impressed. I can easily see myself getting addicted to it

It does not look like there is anything wrong with the D3DX-loading of the .tga. My ATI-imported code didn't solve the problem either, so I expected that. But what can it be then?

I made a collage of the PIX session I ran. If you are interested in something not shown, let me know. I am also uploading my .PixRun file, if anyone is interested. It is created by the latest DX-SDK (june 2010 - had to download it especially for this, as the DX I run on had an ancient version (DX SDK June 2005).

Here is the PIXRun-file (zipped):

http://www.samtalebasen.dk/Run7.PIXRun.zip

Here is the PIX-collage (BIG!):

Do you render the alpha tested geometry before or after you render opaque geometry?

If you render it first, it'll still write the depth values for pixels with alpha < 1.0. The terrain would then fail the depth comparison for those pixels and your clearcolor would become visible.

This is only true for alpha blending. For alpha testing each pixel is either opaque or clipped. Of course its possible to enable both in which case your point is valid.

Yes you're right, i should've mentioned that.

It looks like blending is disabled in that Pix screenshot, so that doesn't seem to be the problem.

I figured it out, and it was not an easy one:

My rendertarget was in the format of ARGB and cleared to black. The alpha values of the plants then changed the alpha value of the rendertarget. This rendertarget was then rendered onto another rendertarget (in order to support multiple viewports), also cleared black, but with XRGB format. And then the black hits through the alpha values.

I changed the rendertarget to XRGB and the problem was solved. I was experimenting once with antialias and at some point set the rendertarget to ARGB and never changed it back, and then it hit me now like a landmine

I thank you all for your patience and incredible will to help. Even when we did not get close to the actual problem here, I learned alot:

- Not taking anything for granted, not even a D3DX-file-loader

- Both editors and loaders can play funny tricks to save space, like storing RGB-layer of pixels with alpha 0 as black (0).

- I learned that good alpha textures needs similar RGB color across the border, or filtering will create an unwanted result (since I have only used other ppl's textures, this was new to me)

- When I go into details on mipmaps, I have to be careful with the same borders on these as well

- I learned to use PIX!

Thank you all for your help. I wouldn't know what to do without the incredible amount of expertise on this forum.

EDIT:

phil_t:

It was actually the same scenario as before, I had just disabled rendering skybox, terrain and non-alphatested objects, so I wouldn't get an ungodly amount of textures and surfaces in the test.

It looks a lot like you're not setting the blend mode correctly.

The black borders is a sign that your texture is stored with pre-multiplied alpha. (Since you're not handling alpha blending correctly, it'll look black because the color is being pre-multiplied by an alpha close to 0) This is most likely fine.

With pre=multiplied alphas, you probably want to set your blend mode to something like: S + D(1-Sa)

Hope this helps.

- Both editors and loaders can play funny tricks to save space, like storing RGB-layer of pixels with alpha 0 as black (0).

Again, this is a sign of pre-multiplied alpha... meaning that something with color: (R, G, B, A) = (1.0, 1.0, 1.0, 0.5) will be stored in a way that the color is multiplied by the alpha channel: (0.5, 0.5, 0.5, 0.5).

This doesn't require the alpha to be 0.0.

The reason why this is done is not to save memory, but instead to save processing in the pixel shader during the blend operation.

The "typical" alpha blend operation is: Source * (Source_Alpha) + Destination * (1 - Source_Alpha), which is done once per pixel per frame that the texture is drawn.

If you pre-multiply your texture, the equivalent blend operation becomes: Source + Destination * (1-Source_Alpha), meaning that you get to save the computation by skipping the multiplication by Source_Alpha (because it's already multiplied in!)

Hope this explains things a bit more.