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 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.
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)
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
Cc: A list for developers using the SDL library. (includes SDL-announce)
Subject: Re: [SDL] Delta time?
On Saturday 13 October 2007, @necron wrote:
Wow that paper is something. My opinion is that he easy answer is as
[…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
SDL mailing list
SDL at lists.libsdl.org