Assuming your destination surface actually has an alpha channel (i.e. it's format name has an 'A' in it, e.g D3DFMT_A8R8G8B8 rather than an 'X', e.g. D3DFMT_X8R8G8B8), then some other things to look at:

- The D3DRS_COLORWRITEENABLE render state determines which channels get written to the frame buffer; the default includes D3DCOLORWRITEENABLE_ALPHA, but I tend not to trust 'defaults'.

- D3DRS_SEPARATEALPHABLENDENABLE should be FALSE (which is also its 'default') unless you want to do anything special (also assuming you have driver/hardware support).

- if you have D3DRS_ALPHABLENDENABLE set to TRUE, ensure the currently set blend operation does something meaningful with respect to the destination alpha channel; the default ONE:ZERO does, but others might not.

- if alpha testing is enabled (D3DRS_ALPHATESTENABLE is TRUE), ensure the reference value and comparison mode are sensible for the alpha values your shader outputs. If a pixel fails alpha test, it won't be written to the Z buffer or the frame buffer.

Quote:Original post by Xmon
The thing is (if I have'nt done anything stupid in my coding) that I got a value for the 4th component in the ps shader. But then when I look up the surface in photoshop the alpha channel is all black. So I was thinking do I have to do something more?

Just a thought: how are you saving the surface out to file, and which file format are you using?

If there were a problem with the retrieving/saving/format handling (your own or the library you use - ISTR an older version of D3DX had an issue with the alpha channel handling of either PNG or TGA, can't remember the details) or the file format simply not supporting an alpha channel. I suppose it could also be possible that the alpha has been saved in 'premultiplied' form.


IMO it would be very worthwhile to visualise the alpha channel interactively rather than saving it out to file, something like the following:

1) Render the scene as you are already, with the shader writing the alpha channel of the render target.

2) Render a fullscreen, white quad with a colour of 0x00FFFFFF and:
a. D3DRS_SRCBLEND = D3DBLEND_DESTALPHA (FB = 1*DestA + 0)
b. D3DRS_DESTBLEND = D3DBLEND_ZERO
c. D3DRS_ALPHABLENDENABLE = TRUE
d. D3DRS_ALPHATESTENABLE = FALSE (to prevent any pixels being rejected)
e. D3DRS_ZENABLE = FALSE (to blat the quad over the top of everything)

That should get you a greyscale representation of what's in your alpha channel, and at least provide some clue as to where the problem is (if indeed there is one - it could just be a wild goose chase related to the alpha channel not making it through into the file/Photoshop).

Quote:Original post by Xmon

D3DXCreateTexture(pd3dDevice, desc.Width, desc.Height, 1, desc.Usage & D3DUSAGE_RENDERTARGET, D3DFMT_A8R8G8B8, desc.Pool, &g_pGlowTexture);

Something that does jump out at me that could be correct (depending on what your intention is there), but could also be the cause of some problems is:

"desc.Usage & D3DUSAGE_RENDERTARGET"

Is the & intentional? Shouldn't that be
"desc.Usage | D3DUSAGE_RENDERTARGET" ?

Quote:Original post by Xmon
Does anybody know some sample that wrights alpha value to the rendertarget?

The DepthOfField sample in the Feb 2006 DirectX SDK writes to the alpha channel of a render target; the alpha value gets used to decide how much blur to apply to a pixel.

While not the simplest sample, you should be able to check the core use of the API against what your code is doing.