# OpenGL Limiting update rate

This topic is 3763 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I have written a simple game using OpenGL and Glut. The game runs fine on my laptop which I developed it on, the problem is when I move it to my more powerful computer, the game runs far too quickly, the FPS is more than 10x faster. Is there anyway of slowing it down. I don't know if this is a problem is the way I have done things, for example the player can jump. The players velocity the Y axis is reduced each frame, I played with the fiqures to get the jumping right on my laptop as about 60fps but then at 600fps on my pc the jump is way to fast. I hope that I have explained my problem correctly. Thanks.

##### Share on other sites
You need to query the time passed in order to correctly move your character. Computers have a very accurate time clock.
If you are on Windows, look for QueryPerformanceFrequency().

##### Share on other sites
You could do this one of three ways (that I'm aware of, at least).

A) You can limit the number of frames you render, forcing the game never to render more than, say, 60 frames. This is the easiest, but least flexible way. It is a definite option, however, especially for smaller games.

B) You can let the game run as fast as it can/wants, but check each frame for how many millaseconds has passed since the last frame, using that time that passed to move your player. Say your player moves 100 units a second, and your game is currently running at 50 frames per second, then your player would move 2 units each of those frames. On a slower computer running at 25 frames per second, the player would still move just as 'fast', by moving 4 units per frame. This is a very common way. I would recommend doing it like this.

C) The third way, I stumbled upon recently and thought was interesting. I've never heard of it before, but I want to integrate it into my next project just for fun. It's a bit more messy, though. You basicly mix the above two methods, by limiting your 'Update' frames to say, 60 FPS, while letting your drawing happen as fast as possible. The article I read is here.

##### Share on other sites
I use this, is uses SDL_GetTicks() but window's GetTickCount() or w/e you want works also.

bool LockFramesPerSecond(int framerate)
{
static float lastTime = 0.0f;
float currentTime = SDL_GetTicks() * 0.001f;
if((currentTime - lastTime) > (1.0f / framerate))
{
lastTime = currentTime;
return true;
}
return false;
}

and in your main loop, do this to lock the framerate at 60....

if(LockFramesPerSecond(60))
{
//main drawing and stuff
}

##### Share on other sites
Thanks for your help everyone, I haven't tried it yet but I didn't know about the GetTickCount function so that will help. Will play around with it tomorrow but I think I understand how to get this working.

Thanks again.

##### Share on other sites
This is how I do it with SDL.net:

protected virtual void Tick(object sender, TickEventArgs e)        {                 if ((timeToNextUpdate_ -= e.TicksElapsed) < 0)            {                Update(sender, e);                // Set the next update time; we plus the difference to account for overflow                timeToNextUpdate_ = updatePerSecond_ + timeToNextUpdate_;            }                        // Draw as frequently as possible            Draw(sender, e);                              }

It's not C or C++ but I think the concept is the same.

PS. timeToNextUpdate is set to 0f at the beginning. updatePerSecond is how many time the update frame is being called, and is equal to:

1000 milliseconds / number of updates per seconds

Hope this helps!

##### Share on other sites
you could group all your render functions in an if statement

say you want all of your logic to happen as much as possible, but limit the rendering to the refresh rate or something (lets just say 60htz)

//pseudocode

//pre frame code

//logic code

if(1/60th of a second has passed)
{
//reset timer
//rendering code
}

##### Share on other sites
Quote:
 Original post by Servant of the LordC) The third way, I stumbled upon recently and thought was interesting. I've never heard of it before, but I want to integrate it into my next project just for fun. It's a bit more messy, though. You basicly mix the above two methods, by limiting your 'Update' frames to say, 60 FPS, while letting your drawing happen as fast as possible. The article I read is here.

This is the one many AAA games use (Doom 3, for example), since the delta-time (B) method will become more and more inaccurate as time goes by because of the floating-point inaccuracy. Note, however, that it will not become an issue with most small-games and games lasting a couple of hours or less, especially not if you use better integration methods than Euler (4th order Runge-Kutta, for example).

The C is clearly the winner in most, if not all, aspects, since it will ensure stability and allow the rendering to go on as fast as possible, although you will need to interpolate between update samples in each frame to avoid jerkiness.

##### Share on other sites
I've done some playing and I seem to have Servant of the Lord's method C working. The logic is updating at 60 fps while the game is rendering as fast as it can. There isn't much in there yet so on my main PC that's over 1000fps.

Thanks for all your help everyone.

##### Share on other sites
Quote:
 Original post by nife87although you will need to interpolate between update samples in each frame to avoid jerkiness.

1. 1
Rutin
29
2. 2
3. 3
4. 4
5. 5

• 13
• 13
• 11
• 10
• 14
• ### Forum Statistics

• Total Topics
632961
• Total Posts
3009487
• ### Who's Online (See full list)

There are no registered users currently online

×