[SDL] Delta time?

Paul Lowe paul_subscribed at tetravista.net
Sat Oct 13 09:37:55 PDT 2007


Hey everyone, I'd strongly encourage y'all to listen to what David has
to say here since based on my knowledge and experience working with him
-- he is the  fixed logic / framerate "pimp". :)

Cheers,

~Paul Lowe

David Olofson wrote:
> 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
>   



More information about the SDL mailing list