I have not heard of this programming model where you do not have a game loop that draws everything every frame between d3dDevice.Present calls. I''m not saying it''s totally invalid, but certainly not very popular...

I guess if you''re not rerendering the scene each frame, you''re going to have accuracy problems. It boils down to that fact that the pixels we see each frame represent an instantaneous sampling of the game world. To further sample those samples (and then those samples...) is going to be difficult to implement with any cross CPU consistency for ANY type of effects. Pixels are just our once-per-frame window into the world!

Why can''t you wait until the fade is finished to stop rendering?

> Why can''t I just lock the back buffer; copy the data to a vertex buffer; and manipulate the vertices? Does anyone have sample code for this?

The back buffer should just contain pixel data, not vertices. However, you could lock the back buffer and push the data into a texture (or several textures). Basically taking a snapshot of the scene. In my own experience, locking the backbuffer on a hardware device and reading the pixel data can be slow, so it depends on whether you mind a slight delay before the fade process begins (certainly no more than a second, I''d estimate, and you only need to do it once).

Or, if your device supports it, you can render straight to texture(s).

In either case, once you have some textures that represent the current scene that you want to fade over, you could:

a. draw the "screenshot" in ortho mode
b. draw the alpha-blended quad on top of it
c. render

and repeat these steps, darkening the alpha blend in step (b) each time.

Just one approach, and not at all elegant, but allows you to use the rendered back buffer data while maintaining some level of hardware acceleration.

Would it be possible to keep rendering your game scene every frame then popping an alpha-blended quad on top of it? Seems like you could avoid some headache this way. Unless you''re rendering something on top of the alpha-fade that''s going to eat up more cycles, like a complex menu or something???? In that case, this approach (or another) *may* be worthwhile, but I''d check it on different GPU''s/hardware to avoid the types of problems mentioned in MasterWorks_Software''s last post.

Why not use the gammacontrol to do a fade?