[SDL] Delta time?

[Alan Wolfe]

To add to the good fight I'm tossing in my 2 cents here...

I did a game based on delta time and had nothing but problems at both low
and high fps... at low fps you could go through walls and at high fps, due
to precision issues you couldn't even walk across the ground.

It sucked :P

I'm now working on a game that has a game loop that doesn't rely on delta
time at all, but just does "1 iteration" of game logic, and that main loop
is called once every 30 miliseconds and if more time has elapsed between
frames, we could run the main loop more than once to do "frame skipping" and
try to catch up (but we don't do this, we just let the game run slower)

It works wonderfully

" You don't have to test the game logic at various rendering frame rates, as
the logic behaves *exactly* the same way everywhere, every time, whether the

frame rate is 10 or 1000 fps."

Wise words there, heed them or make the same mistakes we have!!! (said in a
ghostly haunting voice)


-----Original Message-----
From: sdl-bounces at lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On
Behalf Of David Olofson
Sent: Friday, October 12, 2007 6:56 PM
To: necronology at cox.net
Cc: A list for developers using the SDL library. (includes SDL-announce)
Subject: Re: [SDL] Delta time?

On Saturday 13 October 2007, necronology at cox.net wrote:
> Wow that paper is something. My opinion is that he easy answer is as
> follows>
[...the usual delta time solution...]

I think you're completely missing the point, actually.

In the simple case of your example, there is indeed no difference. 
However, any real game will have collision detection, time 
driven "AI" and other stuff that is not directly related to user 
input or video frame rate.

For example, collision detection: As soon as an object is moving more 
than one pixel per frame, collisions will frequently happen *between* 
frames. That is, first there is no collision, and next, the collision 
already happened some "random" (frame rate dependent) time ago - and 
you might even fail to detect it at all, if you're relying on 
naïve "Do we have an intersection right now?" tests.

Another example; time driven "AI": We have this enemy firing ten 
bullets a second at the player. Ideally, this would produce a nice 
spiral of evenly spaced bullets as the player circles around the 
enemy - but unless the rendering frame rate happens to be exactly N * 
10 fps, the spiral will have a sawtooth like distortion to it, caused 
by interference between the nominal firing rate and the rendering 
frame rate. And if the rendering frame rate should ever drop below 
the firing rate, the firing rate will drop with it!

Considering all math and logic needed to deal with these problems 
properly (and this without *really* getting it right anyway!), I 
strongly suggest that it's easier and safer to just run the game 
logic at a fixed frame rate. This way, you can safely use simple 
iterative methods (ie vx+=ax; vy+=ay; x+=vx; y+=vy; if(collision) 
die(); if(!count--) ax=-ax; etc) like it was often done back in the 
days of constant frame rates throughout the games. You don't have to 
test the game logic at various rendering frame rates, as the logic 
behaves *exactly* the same way everywhere, every time, whether the 
frame rate is 10 or 1000 fps.


//David Olofson - Programmer, Composer, Open Source Advocate

.-------  http://olofson.net - Games, SDL examples  -------.
|        http://zeespace.net - 2.5D rendering engine       |
|       http://audiality.org - Music/audio engine          |
|     http://eel.olofson.net - Real time scripting         |
'--  http://www.reologica.se - Rheology instrumentation  --'
_______________________________________________
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org