Author Topic: Framerate and movement  (Read 1187 times)

Offline Kaiidyn

  • long
  • ***
  • Posts: 103
    • View Profile
Framerate and movement
« on: February 07, 2011, 09:25:10 pm »
When moving an object in the render loop.. lets say.. rotateX(0.01f); it will rotate faster with higher framerate and rotates slower with lower framerate..
If i remember correctly, some other sdk i once used had a function or something called AccurateTimeElapsed..
I'm not sure what it does but when calling eg, rotateX(0.001f * AccurateTimeElapsed); it would rotate at the same speed on any framerate..
is there some similar method or whatever in jPCT?
Or if someone knows how it works so that I can implement it myself ?

Kind regards,
Kaiidyn.
Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control. - Grady Booch

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11745
    • View Profile
    • http://www.jpct.net
Re: Framerate and movement
« Reply #1 on: February 08, 2011, 07:54:34 am »
I prefer to think in ticks, which basically is a simplified way to measure time. It's less accurate then taking the actual time itself, but makes game states easier predictable and reproducable IMHO. You can find a simple example in the source code for the advanced example. Or have a look at Robombs' source code that contains a more complex Ticker class.
If you want to use elapsed time between frames instead, just measure it using whatever seems to be appropriate...System.currentTimeMillis() or System.nanotime() or whatever.
One thing to keep in mind is that some operations that are based on elapsed time increase in runtime for higher times. Collision detection is a good example of this. If you increase the movement vector based on time elapsed since the last frame to get equals movement speeds, collision detection will take longer resulting in even more elapsed time until the next call, which results in even slower collision detection and so on. It's a good idea to introduce an upper bound to the time taken. If a system is so slow that this is reached, the game itself will slow down (not just the frame rate), which isn't nice but it's better than bringing the whole thing to a complete halt.