Jump to content

  • Log In with Google      Sign In   
  • Create Account


How to handle update-rate?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
2 replies to this topic

#1 Deprecated   Members   -  Reputation: 107

Like
0Likes
Like

Posted 03 January 2012 - 03:19 PM

Have been working a little on a tile-based game/simulator to test and display different AI behaviour on my laptop. When running the simulator on my regular computer an uncapped framerate will obviously make the simulation go much faster.

The most obvious solution to the problem with too fast framerate was time.sleep(0.5) which made it run at (about) 2 FPS.

The second, also obvious, solution was to get the time it took to iterate one step, then subtract that from 1000 / 60 which made it run at (almost exactly) 60 FPS.

But what happends the other way around? Assume that I have two computers and tell them both at exactly the same time to move from A to B (without either of them being connected to the other, ultimatly controlled by a server). The first computer runs at 2 FPS and the second runs at 2000 FPS. How can I calculate the relative speed per update if I want them both to arrive at B, at the same time?

Writing this, I'm assuming that I'd have to multiply the time it took for each update with a distance per second value. But as it's tile-based both the minimum and maximum movement is 1. It would of course be possible to increase dx, dy until they were greater than 1, but that doesn't seem good enough as it could still differ as much as 1 / FPS seconds between the results.


As my above thoughs might seem a little messy, how can I normalize update-rate between different hardwares?
Those who can do, do; those who can't do, do teach.

Sponsor:

#2 colinhect   Members   -  Reputation: 193

Like
2Likes
Like

Posted 03 January 2012 - 05:30 PM

Use a fixed timestep. Explained here: http://gafferongames.com/game-physics/fix-your-timestep/

This will decouple rendering framerate from the logic update rate.

#3 Deprecated   Members   -  Reputation: 107

Like
0Likes
Like

Posted 03 January 2012 - 10:49 PM

Thanks!

As it is tile-based and I'm only working with integers for positions and angles I figure each entity should have internal "countdowns" for the amount of updates needed before moving or communicating with other entities (assuming it takes more than 1 timestep)?
Those who can do, do; those who can't do, do teach.

#4 thok   Members   -  Reputation: 657

Like
0Likes
Like

Posted 05 January 2012 - 06:57 AM

Use a fixed timestep. Explained here: http://gafferongames...-your-timestep/

This will decouple rendering framerate from the logic update rate.


+1 for the mention of this article. I found it very helpful myself.

In my first game prototype, I had coupled the frame rate and update rate. It worked okay for a prototype, but it's not correct. So when I rebooted my project (threw away a lot of the prototype code), decoupling the render and update timers was the first thing I did, thanks to this article. As a side effect, it also forced me to correctly model my physics simulations (making every movement _time_ dependent, instead of _tick_ dependent).




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS