For a long time I''ve been looking for some kind of timing function to regulate the frames per second in an OpenGL program. As in something that I could give an exact number value to instead of just using a counter to only draw one frame every 10 times the program looped. There was a series of functions I found that didn''t work. Any ideas? Anybody know of a good method to do this?

Enabling V-sync would be the easist awnser.

You could manually slow it with sleep() calls after each frame is done (so each fram takes a minimum of so much time).

Don''t try to make the program run at a certain fps number.
Instead you could try to automaticly adjust the speed of how fast things are moving.

The easiest way of doing this is to multiply every motion with the time it took to render the last frame(1 second = 1.0f).
This way your animations will run at the same speed regardless of the computer you use

---------------------------------
For an overdose of l33tness, flashbang.nu

quote:

---

Original post by skow
Enabling V-sync would be the easist awnser.

You could manually slow it with sleep() calls after each frame is done (so each fram takes a minimum of so much time).

---

vsync means sync to the refresh rate of the monitor. so this solution wouldn't work at all because different monitors have different refresh rates. So though it might run at 60FPS on your machine, it would run at 70/75/90/100/120 FPS on other people's monitors.

sleep is also a horrible idea because sleep means sleep for AT LEAST this long. that means that the OS can decide to sleep your program for MUCH longer. sleep is a really bad way to try and time things.

either go with the no FPS limits and use time based movement:
s(t) = 1/2 * a * t^2 + v0 * t + s0;
s(t) = position at time t
a = acceleration
v0 = velocity last frame
s0 = position last frame
t = time since last frame

or clamp your main loop at some number like 60FPS or something. you do this also with timers. just calculate the time since the last frame was drawn, if it hasn't yet been 1/60th of a second, don't excecute the loop:

//replace the 60 with whatever you want the framerate to beconst float TIME_PER_FRAME = 1/60;while(1){    static float timeLast = myGetTimeFunction();    float timeNow = myGetTimeFunction();    if (timeNow - timeLast >= TIME_PER_FRAME)    {        timeLast = timeNow;        //execute my game logic    }} 

use QueryPerformanceTimer and whatever the name of the function is that gets the frequency of the timer to calculate the time since last frame. the normal gettime function isn't accurate enough for game timing (though you should provide it as a fallback case b/c not all machines have access to QueryPerformanceTimer).

I believe that there are tutorials on both frame clamping and time based movement in the articles & resources section of this site.

-me

[edited by - Palidine on February 26, 2004 1:13:24 PM]

I should point out that the danger with a program locked at 30FPS or 60FPS or whatever, and using constant movement is that you''d better be damn sure that it ALWAYS can run at least that fast on even your slowest target machine. if the framerate starts to drop below your target number everything in the game will have the apperance of moving in slow motion. as a system, it does, however make some things easier because you know you are always dealing with a constant update frequency.

time based movement has more complexity in the move routines and everything has to be updated by passing down a time since last frame variable. it handles slow framerates a bit more elegantly though because things don''t move in slow motion. the screen will just update chunkily but things will be where they are supposed to be.

both solutions offer different challenges and different benefits. both are used widely in the professional games industry. it''s more a personal decision for you. i happen to really like physics and find time based movement more sensible. but i''ve worked on games that have both systems. so just use whichever makes more sense to you at the moment.

-me

I assumed he was having problems with geting insainly high fps (600+) where there is a rippling effect on the screen. Either of my solutions work for that case.

Never use frame based movement! Time based is your friend.