# [SDL] Fixed Rate Logic (was: stuck with multiplayer and some segfaults)

Olof Bjarnason olof.bjarnason at gmail.com
Fri Mar 11 14:00:03 PST 2005

```On Fri, 11 Mar 2005 15:39:32 -0600, Bob Pendleton <bob at pendleton.com> wrote:
> On Fri, 2005-03-11 at 19:59 +0100, Olof Bjarnason wrote:
> > Well of course fixed frame rate might seem jerky to the trained eye,
> > compared to "floating deltas", if you look at a ball or something
> > moving at a constant speed over the screen or the prime example,
> > scrolling text, since every now and then there is one more or one less
> > logic step taken between to consequtive graphics frames:
> >
> > Let's say we have 100 Hz game logic, and 60 Hz gfx. Then there are
> > 100/60 ~= 1.67 logic frames per graphic update. Then somethimes there
> > will be two logic updates between two graphic frames, and sometimes
> > one. Now when I come to think of it like this I'm not so sure I would
> > use dt = 10 ms (100 Hz) fixed logic frame rate since this WILL look
> > jerky :)
> >
> > Then again, increasing the logic frame rate to 1000 Hz will look much
> > smoother, but now we might start considering the computational amount
> > needed to take the physics steps that many times per "game time step"
> > ... hmm. With a simple game physic/logic or very few objects, like in
> > the pong game discussed earlier today, that might be feasible, but I'm
> > not so sure in a many-many object game.
>
> I've done it both ways, relative deltas based on the real elapsed time
> and fixed deltas with as many steps as you need between frames. The math
> is a little harder with relative deltas, but the computational cost is
> the same for each frame and it is approximately equal to the cost of
> computing the update for a fixed logic frame. So, if you are doing 1.67
> (100 Hz) or 16.67 (1000 Hz) or what ever number of fixed increment
> updates you are spending roughly 1.67 or 16.67 times as much computing
> power between visible frames as the relative deltas technique does for
> the same frame. In other words, you are potentially wasting a lot of CPU
> cycles that you could be spending on game play.
Yup, it's a time waste, but an engineering effort gain. Have I told
you I'm lazy ;)

> Another interesting thing, at lest to me, is that the fixed delta scheme
> is basically using an iterative technique to approximate the same result
> that the floating deltas produces. But, the floating deltas technique
> gets the exact (within floating point accuracy) result while the fixed
> delta technique gets only an approximation. Sort of like the difference
> between evaluating an integral over a range by solving the integral and
> evaluating it versus using an iterative numeric method to get the number
> you want.

Yes, but numerically the methods both use a technique called Euler
forward, which is not-so-good when it comes to "exactness" (for
example the acceleration is assumed constant for the delta-time step,
which is not correct if you have a "local" gravitational field near
the object in motion). The difference is that doing 16-17 steps
instead of one as you are proposing, means a lot more error
propagation. But, if you have constant acceleration both methods are
equally accurate -- and this is generally the case in a simple game
where you model gravitation as a constant added to the velocity-vector
each time step. If you want physically more accurate results in a
non-constant acceleration simulation, try Euler backward for example.
This method has higher computational cost as you might have guessed.

/Olof

>
>                 Bob Pendleton
>
> >
> > Interesting discussion!
> >
> > /Olof
> >
> > On Fri, 11 Mar 2005 19:12:08 +0100, Marian Schedenig <m.sched at gmx.at> wrote:
> > > On Friday 11 March 2005 12:55, David Olofson wrote:
> > > > Have a look at my Fixed Rate Pig example, which demonstrates "ultra
> > > > smooth" animation while using a very low, fixed logic frame rate:
> > > >  http://olofson.net/examples.html
> > > >
> > > > (Or look at Kobo Deluxe, which uses the same technique - though I
> > > > suspect you won't find that code as friendly to study. ;-)
> > >
> > > Everytime fixed rate logic gets mentioned on this list (i.e., every few
> > > days ;), I get more interested.
> > >
> > > The only problem is, I tried both Fixed Rate Pig and Kobo Deluxe, and they do
> > > NOT run entirely smoothly on my system (Dell Inspiron 8600 Laptop, Pentium M
> > > 1.6 GHz), 512 MB RAM, 64 MB GeForce FX Go5200 running at 60Hz, Debian Sid,
> > > KDE using the official Nvidia drivers). The effect is most noticeable on
> > > Kobo, which gives an obvious jerk every few seconds, both in SDL and OpenGL
> > > modes (with GL vblank waiting enabled). Pig (and the smooth scrolling
> > > example) run much smoother, but when paying attention, I still notice minor
> > > jerks (like single frame skips perhaps) every few seconds.
> > >
> > > Now perhaps it's just my system setup, but other games seem to run fine,
> > > including my own, which as far as I can tell seems to run absolutely
> > > smoothly, with OpenGL, but using the same framerate for the game logic as I
> > > get with GL flips, i.e. 60Hz, and using simple linear scaling for the game
> > > logic. For the current game (a simple vertical scrolling 2D asteroid shooter)
> > > that's not so much of a problem, since it seems to run fine on different
> > > systems and doesn't have complex maths or anything, but an older (and as of
> > > yet unfinished) 3D racing game had serious problems with collision detection
> > > and our acceleration function (again, simply scaled by the GL framerate
> > > delay), which might be solved by converting to a fixed rate logic.
> > >
> > > Any additional insights or tips would be helpful. :)
> > >
> > > Thx,
> > > Marian.
> > >
> > > --
> > > Hofstadter's law: "It always takes longer than you think,
> > > even when you take account of Hofstadter's law".
> > >
> > > --
> > > Hofstadter's law: "It always takes longer than you think,
> > > even when you take account of Hofstadter's law".
> > >
> > > _______________________________________________
> > > SDL mailing list
> > > SDL at libsdl.org
> > > http://www.libsdl.org/mailman/listinfo/sdl
> > >
> >
> > _______________________________________________
> > SDL mailing list
> > SDL at libsdl.org
> > http://www.libsdl.org/mailman/listinfo/sdl
> >
>
>

```