[SDL] Delta time?

[necronology at cox.net]

LoL, I was just answering a question. In reality game logic seems to work best when frame rate independant. Things like advanced motion planning and interpolated ray casting are the the children of the answer I gave. Making a game is a vast enterprise. I don't think you can put any concept in a box and say it's wrong. I say make it simple and get it done. After that you can get into advanced stuff and have a good chance of success 

---- Alan Wolfe <Atrix2 at cox.net> wrote: 
> 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
> 
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org