Sign in to follow this  

FPS lock.

This topic is 4666 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

Hi, I have an problem to get my game to flow good.. I mean now I got all movements and things bounded to the elapsed timer ( fps based ).. but the problem is my fps changes alot between 150-300 so the movements on the units are like hack forward when the fps change.. so cant I lock the fps to let say 100 all the time or something to avoid this? if so give me an example on how to do this.. thx.

Share this post


Link to post
Share on other sites
you should use the time since last game loop to adjust the movement..
instead of:

position += direction * speed;

you should do:

position += direction * speed * t;

where t is the time since last frame (for instance in seconds, and the speed will be in units per seconds)...
this way the object will move the same length independent of the frame rate..

Share this post


Link to post
Share on other sites
There are multiple ways to do this. Here's what I know of...

1) Lock your frame rate to a specific FPS. The advantage is that it's very easy to do. Disadvantage is that A) you waste a lot of processor time that could be spent on something else, and B) Your game will slow down if the FPS drops below what you locked it to.

2) Use the time it took to complete the previous frame (or an average of previous frames) to compute a factor by which all movements are multiplied. Advantage is that it's still pretty easy, you don't waste CPU cycles, and your game won't slow down. Disadvantages are that gameplay results are non-deterministic which can mess up physics, some kinds of multiplayer games, and lots of other stuff...

3) Make your game logic update rate independant of the frame rate, and then interpolate between logical frames to draw the graphics. Advantages are that it keeps your results deterministic, your graphics are as silky-smooth as method 2, and that you aren't wasting any CPU cycles. Disadvantages are that it's easily the most complicated to implement and that the graphics will lag behind up to one logical frame behind the game logic (though this isn't really a problem with a reasonbly-high logical update rate). Also, if you implement it right, your game logic won't slow down if your FPS drops below the update rate.

The third method is my personal favorite.

- Fuzz

Share this post


Link to post
Share on other sites

This topic is 4666 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this