[Haskell-cafe] Re: FRP for game programming / artifical life simulation

[Heinrich Apfelmus]

Peter Verswyvelen wrote:
> Actually, I believe that many Yampa examples do separate the drawing
> from the update... The arrow provides the game data that *can* be
> rendered. If you provide interpolators for that game data, you can
> still achieve the same as is explained in "fix your timesteps" (in my
> own FRP experiments I have an update thread and a render thread).

But the arrow implementation determines the  dt  at which the arrows ~
(Time -> a) -> (Time -> b)  are sampled, no? The end result of a Yampa
arrows is a graphic, after all.

> But IMHO "fix your timestep" still misses an important detail, in that
> the delta-time that is measured is the duration of the previous frame,
> and it assumed that the next frame will take as long as the previous
> (who says that "integrate" from the article won't take longer than
> dt?). Now say you are updating at 100 FPS = 10ms, but the next frame
> actually takes longer, say 20ms. That actually means that you should
> have passed 20ms as the delta-time of the this frame, because the real
> time is ahead now! This is really noticeable as little jerky frame
> hick-up in the motion. In my first game (1987), I added an estimator
> to compute how long the delta-time of the next frame would be, which
> results in much smoother motion: you notice that the
> frame-sampling-rate drops, but you don't see a frame hick-up. I rarely
> see this in modern games, most PC and even console games suffer from
> frame hick-up (which could be defined as the real-time moving ahead of
> the game-time for a brief moment)

I'm not sure I follow, could you elaborate on what exactly causes the
frame hick-up?

As far as I understand it, the approach of "fix your time-step" is that
you have a physics simulation and a rendering engine. To ensure
numerical stability, the physics are calculated with a fixed time step
dt  which can be larger than the rendering frame rate. In particular,
one step of physics simulation should take less than  dt  real time,
because otherwise you're screwed.

The graphics engine just draws as fast as possible. To ensure
smoothness, it interpolates slightly into the future. The FPS number
measures the frequency of drawn graphics, not the rate of physics
updates. There may be multiple physics steps per drawing when the latter
is slow, or the other way round, when the latter is fast.


Regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com