Re: [pygame] frame independant movement

[B W <stabbingfinger@xxxxxxxxx>]

Alan,

With the GameClock recipe it'd just be a matter of decreasing ticks_per_second (e.g. clock.ticks_per_second /= 5). Though if you're using interpolation/prediction to smooth out your frames you may really notice things like collision artifacts, as a wider separation of ticks versus frames results in more predictive calculations between ticks.

This may be fine for continuous motion, but if the physics dictate a change in speed or direction then the object visibly overshoots the point where it should have changed. When the physics catch up during the next tick the object jerks back onto the right path. Without a good predictive algorithm, this is more noticeable when frame rate is much higher than gametick rate.

You can easily see this cosmetic problem in the GameClock demo by adding a line "(TICKS_PER_SECOND/5, 0)," to SETTINGS.

I have noticed this in Internet games where the common design smooths out network latency by using a prediction algorithm in the game client. There may be ways to improve the cosmetics. But I have noticed that Internet games usually seem to just not deal with the issue because it is adequate to rely on the player's brain to compensate.

I first noticed this in Everquest: when other players' avatars inch forward for a closer look at a mob of enemies they run out "too far" as displayed by my client, and then suddenly they snap back to where the game server reports they really are. At first I had many alarming moments, but eventually my brain became adept at edited out the discrepencies and I did not notice them unless I purposely looked for them.

On a nostalgic note... You EQ players, remember DC (disconnect) death? Lose your server connection and wake up dead because the server assumed no network packets meant keep going--which, if you were running, usually meant you were on course for a cliff, ocean, lava, or gathering a train of hungry critters. Rush out to buy a lottery ticket if you were saved by a wall or snagged on a tree! Ah, the fun of that particular peril. :) A good prediction here could have included keep-alive packets from the client, and noticing their absence.

Gumm

On Fri, Aug 27, 2010 at 10:42 PM, R. Alan Monroe <amonroe@xxxxxxxxxxxxxxx> wrote:

> In other words, use a small enough time step that the difference
> is not big enough to be a problem. But if you're doing that, you
> might as well pick one sufficiently small time step and use a
> variable number of them per frame, so that the physics is
> always predictable whatever the frame rate.

While we're on the time topic, is there an easy way to do slo-mo, a la
Peggle Extreme Fever or a Burnout multi-car pileup?

Alan