cpSpaceStep out of sync

[Baxnie]

Hello, i've a small problem with cpSpaceStep.

Here's my Scene::poll function, which is called every frame.

Code: Select all

void Scene::poll()
{
    float elapsedTime = g_clock.seconds() - m_lastTime;
    float fCycles = elapsedTime / m_timeStep;
    int cyclesToTry = std::round(fCycles);

    for(int i = 0; i < cyclesToTry; ++i)
      cpSpaceStep(m_space, m_timeStep);

    m_lastTime += m_timeStep * cyclesToTry;
}

FPS = 60
m_timeStep = 1./120;

Everytime poll is called, cpSpaceStep should be called 2 times.
elapsedTime would be (1/60), divided by m_timeStep (1/120) equals to 2.

Unfortunately, FPS is not always 60, it might be 58, 59, 61, 62, or anything close.
That way, elapsedTime will not always be 1/60 and then cyclesToTry will not be 2.

Using the round function:
int cyclesToTry = std::round(fCycles);
I've managed to keep 2 cycles most of the time, however sometimes it gets out of sync.

For every frame I get:
1, 3, 1, 3, 1, 3... cycles
And it should be:
2, 2, 2, 2, 2, 2... cycles

The amount of cpSpaceStep calls is the same for every 2 frames, however the movement completely loses its fluidity as there're a lot of moving objects on screen.
I've tried a few things to get rid of this 1,3,1,3.., but without success.
Does anyone have an idea to solve this?

Thanks

[slembcke]

Decouple your fixed timestep -> http://gafferongames.com/game-physics/f ... -timestep/

If your fixed timestep is pretty close to the same as your actual framerate, you can get some nasty looking stuttering. If you have extra CPU cycles to spare, run the fixed timestep at several times your frame rate. I often use 120 or 180hz for the fixed timestep. Then you don't really need to bother with interpolation like the article recommends. Also, I'd recommend extrapolation before interpolation since it's much simpler to implement and doesn't introduce extra latency.

[Baxnie]

A server will run this, so decreasing timeStep is not really an option. 120Hz seems to be a good choice right now.
The article was very interesting, however I don't get what's that interpolation applied to chipmunk.

From what I understood and saying it on a very stupid way, would it be:
Copy cpSpace, use cpSpaceStep with the remaining time on accumulator, draw this cpSpace, and then discard it?
If this is the right idea, it seems very difficult to properly implement it.

I've implemented article's algorithm without interpolation, however i can't see any difference from my implementation and article's using accumulator. I'm just keeping this accumulator variable inside m_lastTime.

[slembcke]

To apply interpolation, you have to know the current position/angle, the last position/angle, and the amount of real time that has passed since the last fixed timestep. You use the time information to figure out where between the current and previous position/angle that the body would be at. (Technically you are finding out where it would be one fixed time step ago). This is a calculation you would perform outside of Chipmunk when you are rendering things.

Extrapolation is a bit simpler. You only need to know the position and velocity (and the angular parts) of the body at the most recent fixed timestep (Chipmunk does that for you), and the amount of real time elapsed since then (which you need to track to implement the fixed timestep). Then you just use the velocity and time to figure out how much farther the body would have moved and use that as your drawing position. If you are making a client/server based game, you will need to do a lot of this anyway. The problem with extrapolation is that the object might collide with something the next timestep, and extrapolation might have told you to move it too far. In my experience the effect is *very* minor though. It's hard to spot unless you slow down time and know what you are looking for.