Here is the exact way that i do it for a screen2screen "swap fade" (topmost picture here under "transitions"):

First let me explain that i have a layered object processor. You can insert objects for updating onto any of the layers (background, sprite, foreground, GUI, etc). One of the layers is a dedicated "transition layer". All of the layers can be "frozen" (they treat the frame delta-time as zero).

So:
- we are on the title screen
- user presses enter to start "action mode"
- on the next game loop start, the state manager changes states, deletes all objects associated with the previous state. We are now in action mode, technically. The world is created as well as the player.
- all layers are frozen except the "transition layer"
- a new TransitionEffect object is created and given to the object procesor
- The TransitionEffect object grabs the backbuffer (a rendering of the previous Title Screen - we still haven't started rendering the first frame of Action Mode yet) and creates a texture out of it.
- each trip though the game loop, the only active object is the TransitionEffect which renders the screenshot on top of the new world and object contained by it, created by the Action Mode. ALthough all the other objects are frozen, they still render.
- When the TransitionEffect draws the old screenshot at 100% transparency (you can't see it and only the new screen is visible now), it gets removed from the list of update objects and all the normal layers are thawed.
- Action continues.

Somewhere in there you also want to block player input as well. You could hit the "fire" button several times before the new screen fades in and you fire several shots as soon as player control resumes.

I implemented a fade-between-screens effect in a previous incarnation of my previous project, and you can see it (albeit on momentarily) in these video clips:

Clip 1
Clip 2

The way I implemented it is pretty much what everyone else has suggested and that was I had one function that would be called, accepting a float that indicated the duration of the fade in seconds. It would then copy the framebuffer into a number of textures, this number of course depending on the maximum size texture of the user's hardware. At that point the video subssytem kept an internal timer on how long it had been since the fade was invoked and every subsequent frame was automatically rendered with an appropriate alpha setting while the stored frame data was rendered with a complementary alpha value. When the time ran out the fade counter was reset, the textures (or rather, their contents) were discarded and everything proceeded normally.

The fade effect occurs in the first video between the main menu and the "new game" menu, and when the big white flash occurs; in the second it just occurs between the "new game" menu and the main menu.

Your effects look pretty good. Off topic: how did you record it? "Camera aimed at the screen" or is there really some software way to do it?

Quote:Original post by leiavoia
Your effects look pretty good. Off topic: how did you record it? "Camera aimed at the screen" or is there really some software way to do it?

I used the exceedingly useful program FRAPS. I only have version 1, version 2 allows sound recording (I dubbed the explosion sound effect back into the video before compressing it, tricky tricky!) but of course it costs money.

Also if you look at this clip you hear that there's actually a sound effect leading into the main explosion, although the one in this video has since been replaced.

But of course that entire version of the program has been replaced too, so oh well; although the effects will probably remain very similar since they worked so well.

Looking at the aritcles here called 'Enginuity' gave me a pretty good idea of what an engine layout should be.