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