This might actually be a precision problem. Are you using low-color-resolution rendertargets/backbuffer/textures (8 bit per channel) ?

This might actually be a precision problem. Are you using low-color-resolution rendertargets/backbuffer/textures (8 bit per channel) ?

I'm using 32-bit color for the backbuffer (R8G8B8A8) but 32 bit float for the texture render target. I didn't know your backbuffer could go higher than 32bit (8 bit per channel) color... When I try R32G32B32A32_FLOAT for the back buffer I get a failure in trying to set up the swap chain.

Maybe I need to accumulate in a second texture render target instead of the back buffer?


-- Edit --

I forgot to mention I've changed my blending a bit. I'm using a blend factor now instead of straight alpha blend, but I'm still having the same effect with not getting it to fade completely to zero.

Here are my current settings:

rtbd.BlendEnable = true;
rtbd.SrcBlend = D3D11_BLEND_SRC_COLOR;
rtbd.DestBlend = D3D11_BLEND_BLEND_FACTOR;
rtbd.BlendOp = D3D11_BLEND_OP_ADD;
rtbd.SrcBlendAlpha = D3D11_BLEND_ONE;
rtbd.DestBlendAlpha = D3D11_BLEND_ONE;
rtbd.BlendOpAlpha = D3D11_BLEND_OP_ADD;
rtbd.RenderTargetWriteMask = D3D11_COLOR_WRITE_ENABLE_ALL;

/* .... */
float blendFactors[] = {.99, .97, .9, 0};
g_pImmediateContext->OMSetBlendState(g_pTexBlendState, blendFactors, 0xFFFFFFFF);


If I understand this correctly, it should eventually fade to completely black, since the blend factor will make it slightly darker every frame, yet I'm still left with the not-quite-black trail.

Why do you have this? float blendFactors[] = {.99, .97, .9, 0};
shouldn't it be something like:
float blendFactors[] = {.9, .9, .9, .9};
And no, it will never fade completely(theoretically), but it should get really close.

Did you try CryZe's blend mode, AKA "alpha blending"?
[quote name='Such1' timestamp='1354585556' post='5006898']it will never fade completely(theoretically), but it should get really close.

You've got to keep the 8-bit quantization in mind with regards to this.
If the background is 1/255, then when you multiply by 0.99, you still end up with 1/255 -- e.g. [font=courier new,courier,monospace]intOutput = round( 255 * ((intInput/255)*0.99) )[/font]

Instead of directly blending the previous contents and the current image, there's other approaches you could try.
e.g. you could render the previous contents into a new buffer using a shader that subtracts a value from it, and then add the current image into that buffer. This way you'll definitely reach zero, even in theory
[/quote]

Yes I tried Cryze's recommendation, however it didn't look right either. I like how color blending looks over pure alpha better anyway, since I can fade the individual channels separately and get a "warmer" looking fade that looks even more like a CRT. I see your point about the dynamic range, and I agree that subtracting would be best, except when you subtract 1 from 0 you still clamp at zero, so the accumulation buffer's dark bits would block out where the "new" accumulated yellow bits should go.

I think I'll try and get around the dynamic range issue by rendering into a second texture, one that's 32-bit float, instead of using the backbuffer. This is how it'd be used in practice anyway, so using the backbuffer for this test is probably not a real representation of the technique. Hopefully the greater dynamic range will let the accumulation eventually settle on zero.

Here's what I mean by the "warmer" look of using color blending instead of alpha, it looks a lot more phosphor-like: