I have a working fixed time step because this article encourages it. It's also implied you should segregate rendering code from update code. Fine. But from what I understand, an accumulator is used to hold the application from rendering until it "catches up". How is that any different from a variable time step? Either way, rendering happens after about the same period of time. If I used a variable step and ALT+TAB'd away for a few seconds, everything would surge into new positions. On a fixed step, everything moves bit by bit, but ultimately into the same position that ends up getting rendered. I fail to see the point. I know it's encouraged to have a fixed step, but I'm missing something. I can only bring some sense into it if I were to clamp the accumulator if it gets too large. Could someone clarify what is being done to give display and physics their own "frame rate"? I've looked at the article several times, and it's just not clicking.

The accumulator isn't for the renderer it is for the physics simulation of your game world. Then the renderer will interpolate between the current and the previous physics states based upon how much time has elapsed between the time step.

For example, assume your game has a fixed time-step of 0.001 seconds and at time 0.001 your object is at position (2, 5); at time 0.002 the object is at position (4, 10); and at time 0.003 the object is at position (4, 20). Then your renderer will go, "hey, right now I'm at time 0.0015 which is 50% between the time steps, what should I draw?" and it would interpolate between the positions (50% between x and y coordinates of both states) to get the position (3, 7.5) and then draw that. Then at time 0.0018 (80% ) the renderer would draw the object at position ((4-2)*.8+2, (10-5)*.8+5) or (3.6, 9). Then at time 0.0021 you would do the same interpolation (10%) of the newest physics state and the previous state.

Let's say that your physics updates faster than your renderer can keep up... then you don't have to change anything! The same code works for if the renderer goes faster than the physics and vice versa. As long as the physics can update once every millisecond the player will still be able to play your game, even if the rendering is a little choppy.

Also, when you ALT+TAB away from the game you should either pause the game while the user isn't looking (stop updating the accumulator, disregard any time lapse) or continue updating the physics--depending on what you would prefer or, if the game is multiplayer, what the requirements of the situation dictate. I can't think of any situation in which you should just stop updating the game while still accumulating time.

Ok, so the idea is to use a fixed time step to more easily see two distinct states of locality. The renderer would sample the time it is currently at, and the physics engine would return the interpolated state.

I'm having trouble picturing it in code, but the underlying concept is clear now. Thanks so much!

Also I'm not sure if you picked this up from the article, but the important reason for using a fixed time step is to keep your physics simulation stable. When you integrate your physics equations by calculating values at discrete points, you will get different results based on the delta between your frames. This can be very problematic, because it means that if you use a variable time step then the exact same inputs would result in different results for two user that achieve different frame rates! In extreme cases where the framerate gets really low, your simulation can "explode" and you'll get all sorts of reality-defying behavior (objects falling through floors, cars bouncing off the ground and into outer space, etc.)

I implemented it few weeks ago.
I use 200 updates per second (The physics is simple at this time), so I didn't even need to interpolate the render.

Since in most games the rendering will be the bottleneck, I think any recent CPU can handle 100 updates per sec.

I found this article quite helpful. (Before I read it, I thought of "time-step" as a magic, that I never will understand)
http://dewitters.koonsolo.com/gameloop.html

Quote:Original post by szecs
Since in most games the rendering will be the bottleneck, I think any recent CPU can handle 100 updates per sec.

This is a bit like saying "Because in Spa Francorchamps La Source is the bottleneck, the cars can reach 300 km/h and more on Kemmel".

Quote:I think any recent CPU can handle 100 updates per sec.

This is a bit like saying "Any recent CPU runs at 100 Hz or more."



Fun aside: Basically, it depends on what you do in your code. E.g., Pong physics can be ticked many million times per second even on ten year old CPUs, while realistic and detailed physics simulations like e.g. physical stress tests for skyscraper designs run at some orders of magnitude below 1Hz on John Does personal computer.

OK I didn't express myself so good.
I thought of an average simulation.
Of course if John Doe wants skyscraper, than of course there will be a nice task to interpolate one second.

What I was trying to say, if you can easily run it with 100, why to bother with interpolation? NWM.