Sorry for the typo, Line 9 should be:
9. accumulator -= fixedDt.
in the simulation it's written like above, otherwise i would not get numUpdatesThisFrame greater than 1.
Sorry for the silly mistake :D

--- On Wed, 3/18/09, Andrew Ellem <andrew@artoon.co.jp> wrote:
From: Andrew Ellem <andrew@artoon.co.jp>
Subject: Re: [Algorithms] Fixed time step loop with varying framerate
To: prog_ady@yahoo.com
Date: Wednesday, March 18, 2009, 6:43 AM

Is this the actual code you're running?

This loop here looks pretty broken to me:

7.     while (accumulator >= fixedDt)
       {
8.           UpdateSimulation(fixedDt);
9.           accumulator -= accumulator;  10.         numUpdatesThisFrame ++;  
           }

Shouldn't it be
accumulator -= fixedDt;

I don't understand how numUpdatesThisFrame isn't always 1.


> I've stumbled on a problem these days while programming a small
simulation. I've read a few articles with a main title of: "Fix
you're time step" and concluded on the following loop:
>  0. numTotalUpdates = 0;
> 1. fixedDt = 1.0f / 400.0f; // how small is enough?
> 2. while (IsRunning())
> {
> 3.     DispatchEvents();
>  4.     static float accumulator = 0.0f;
> 5.     numUpdatesThisFrame = 0;
> 6.     accumulator += GetFrameTime() ; // time since last update
>  7.     while (accumulator >= fixedDt)
>         {
> 8.           UpdateSimulation(fixedDt);
> 9.           accumulator -= accumulator;  10.         numUpdatesThisFrame
++;               }
> 11.    numTotalUpdates++;
> 12.   renderInterpolator = accumulator / fixedDt; // safe to say it's
in 0..1
> 13.   Render(renderInterpolator);
> }
>  As far as i know this is physics engine friendly main loop because
physics engine deal great with small fixed time steps when approximating
integration.
> As i was saying i was running a simple simulation of a circle that was
hitting obstacles and was being reflected as expected. Actually there was more
going on, on the screen, but the main idea of the simulation is of a circle in a
2D environment colliding in a breakout game fashion.
> I repeatedly run the simulation with VSync on and observed an annoying
stuttering/choppy movement of the circle. The stuttering is almost random like.
After some profiling i found out that numUpdatesThisFrame was varying kind of
weird: it was growing from 6,7 to 15 or even 24. I changed this line to this
line
>  6'. accumulator = some_constant;
>  and the ran the simulation again with VSync on. The stuttering was gone
and since the value of some_constant was tweaked for my processor speed the
motion was neither to slow and neither two fast.
>  So something was happening that caused big times between frames which
implied an unnaturally big numUpdatesThisFrame value. The framerate was very
high though, without VSync on i was getting a few thousands frames per second so
i thought to myself that bothering with why does sometime the time beween frames
was unnaturally big, was not the way to solve the problem.
>  I thought the way to tackle this issue is to compensate for the random
big times between is to write additional code in the main loop. I never dealt
with the problem of fixed time steps and varying framerate and i can't
really know how to start.
>  One way i thought was to first detect when a big shift occurs and then
try to correct it.
> The numbers of updates per frame form a series of intger numbers. The
series is unlikely to be convergent in the pure mathematical point of view but i
think it's intuitive to observe that its values will get closer to some
fixed values. I can calculate an approximation of this value by an arithemetic
mean like so:
>  approximateConvergenceValue = Sum(sequence[i]) / numTotalUpdates,
1<=i<=numTotalUpdates;
>  A better approximation of this value would be to use a quadratic mean
like so:
>  approximateConvergenceValue = Square_Root(Sum(sequence[i]*sequence[i]) /
numTotalUpdates), 1<=i<=numTotalUpdates;
>  This is pretty close to the most frequent values of numUpdatesThisFrame
so i guess it's a good approximation. I'm puzzled when applying this
detection to correct the framerate and also keep approximateConvergenceValue to
a good approximation. The simulation would ideally self adapt to work the same
using this calculation(minimizing the effect seen on screen as a result of the
adaption)
>  So how does one usually deal with fixed time step loops and varying frame
rate?
> 
> 
> ------------------------------------------------------------------------
> 
>
------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> ------------------------------------------------------------------------
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list