I’m wondering what the best way to do a time based movement is.
Well, I’d say “not at all”, but that’s not quite accurate. What I mean
is that I prefer to run the game logic at a fixed, hardwired
"virtual" frame rate, to make sure long frames don’t cause collision
detection to fail and stuff like that.
Indeed, this method causes interference between the logic frame rate
and the rendering frame rate (you need to resample all “cordinate
streams” from the logic frame rate to the rendering frame rate), but
some simple interpolation deals with that very nicely.
Of course, the most accurate method is to always use the delta time in
logic calculations, but that means you have to explicitly deal with
long frames and stuff, so you don’t have players running through
walls and stuff when the rendering frame rate drops too low.
Also note that if you store recorded demos as just player control
data, relying on the game logic to replay demos accurately, the
"accurate" method becomes virtually impossible to implement reliably.
Rounding errors and deviations caused by approximations (such as not
reporting the exact time of every collision event) easilly build up
cause demos to play differently on different machines, or even from
time to time.
With a fixed logic frame rate, this is not a problem, as the game
logic will be doing the exact same calculations every time you play
Use a sleep method in the main loop.
(This method calculates how long the application should sleep
(Then mine would be the third method, or something.)
Anyway, I don’t like this approach at all, since it’s heavily
dependent on the OS scheduler, and generally doesn’t provide much
Besides, it requires that you have thread safe communication between
the logic thread and the rendering thread. …unless you actually
throttle the frame rate of the whole game. Do not do that!
A fixed logic frame rate with coordinate interpolation lets you do
everything in one thread, and ensures that there is always one
properly calculated set of data for each rendered frame. Works
anywhere, and it’s simple and totally accurate within the limits of
the chosen logic frame rate. (Could be 10 Hz or 1 kHz; lower rates
just mean higher control latency and lower “maximum event rate”.)
I’m using this method in Kobo Deluxe, BTW. Seemed natural, given that
the original game was hardwired to 30 ms/frame, and I wanted to make
use of the maximum possible rendering frame rate, without entirely
rewriting the game logic.
It’s not exactly a simple example to look at, though. Maybe I should
hack a small SDL example?
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Monday 19 January 2004 19.33, Alexander Bussman wrote: