Jump to content
  • Advertisement
Sign in to follow this  
Android07

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.

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by Servant of the Lord
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.


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 this post


Link to post
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 this post


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


Only if your set ndt is greater than about 16ms (60 fps). And if your ndt is that large then set it smaller and that'll fix the problem no worrie. I use a set update time of 16ms on most of my stuff and I never bothred interpolating. Its true that on a decent machine running 120 fps half the renders are pointless as they're exactly the same as the last time frame but unless your doing an AA title the effort required to impliment interpolation of your entire game isn't worth the effort in my oppinion. If your making crysis then definatly worth it ... however if your making tetris, raiden or megaman clones then your much better off putting your time into adding a menu system or more levels.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!