Re: [Algorithms] Fixed time step loop with varying framerate
Brought to you by:
vexxed72
Menu
▾
▴
Re: [Algorithms] Fixed time step loop with varying framerate
|
From: Manolache A. <pro...@ya...> - 2009-03-18 04:52:56
|
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 <an...@ar...> wrote:
From: Andrew Ellem <an...@ar...>
Subject: Re: [Algorithms] Fixed time step loop with varying framerate
To: pro...@ya...
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
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
|
