Jump to content
  • Advertisement
Sign in to follow this  
X5-Programmer

FPS lock.

This topic is 4970 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
Advertisement
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
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!