[ACCEPTED]-What's the usual way of controlling frame rate?-graphics

There are two "usual" ways of 31 "controlling" framerate, and neither 30 is quite that simple.

The first and more 29 controlling of the two, and something that 28 is usually optional, is VSync. This forces 27 the video card to only push out a new frame 26 when the monitor is done refreshing. Many 25 monitors refresh at 60 Hz, so you tend to 24 get 60 FPS.

This works quite well to cap framerate 23 to monitor refresh rate, but when framerate 22 drops below refresh, it's forced to the 21 next multiple. Thus, as the framerate starts 20 to drop a bit, you lose quite a bit of potential 19 rendering time, because it's forced to 60, then 18 30, then 20, etc.

(a bit of info about vsync 17 in DirectX and OpenGL)

The second method, commonly used 16 (with vsync optionally added on) is not 15 to limit framerate. Instead, adjust your 14 code to handle differences. This is far 13 more flexible in the long run and generally 12 better coding, IMO, and much simpler than 11 trying to force a particular FPS count.

Assuming 10 you have a simple render loop, it starts 9 out looking something like:

while ( gameloop )
{
    float framedelta = ( timeNow - timeLast )
    timeLast = timeNow;

    for each ( GameObject object in World )
    {
        object->Animate(framedelta);
        object->Move(speed * framedelta)
    }

    render();
}

You want to look 8 at the time difference/time passed/delta, and 7 work from there. Allow the framerate to 6 scale based on hardware and settings (there 5 are too many variations for you to predict 4 or handle even half), and make your game 3 work with that instead of controlling it. Much 2 easier for you and more flexible and stable 1 in practice.

The typical way to yield a predictable (if not constant) frame 14 rate (with video or 3D graphics) is described 13 in the following pseudo-code.

Algorithm

1. Prepare the next frame (render in back-buffer);
2. Sleep for the remainder of the time slice;
3. Ask the frame to be displayed (swap front and back buffers).

Note the position of the sleep operation. It's sandwiched between the preparation and display of the same frame. This is the principal key to a constant frame rate! You want the preparation of the frame to count in the total time slice for displaying the frame.

There are 12 a number of variants on how to implement 11 each of these steps (choice of sleep operation 10 based on it's resolution, reliability, etc.), but 9 the core is there.

Tips for extra reliability

• Don't invoke your sleep function once for the entire interval. Define some constant with the maximum error you're ready to accept and repeatedly sleep for periods of this interval until the time remaining is smaller or equal to this amount.
• Don't be scared to occasionally drop a frame when you know you won't be able to prepare the next frame in time. It's visually more appealing to skip a frame than it is to produce a variable frame rate.
• If you can avoid background threads on a single-processor system, avoid them. Using worker threads will really mess up the reliability of your sleep function. The best approach is to split your background work into small chunks and have this work executed instead of sleeping.

The 1st is easy to implement 8 and can be hidden away in a helper function. The 7 2nd is a little more touchy as it requires 6 you to keep statistics of average rendering 5 speed, among other things. The 3rd is hard 4 to implement as it's often difficult to 3 predict how much time different tasks will 2 take. It's only usually implemented in 1 real-time systems with hard constraints.