3 ms·
The trick is to use a time accumulator. Each update you add the display deltaTime from your high resolution timer into this accumulator. Then, while there are w
by ced 17y ago
The trick is to use a time accumulator. Each update you add the display deltaTime from your high resolution timer into this accumulator. Then, while there are whole increments of your dt available you run a physics step and subtract the physics step dt from the accumulator.
I've got to be missing something: doesn't that yield fairly jerky motion? I thought that the 'obvious' solution would be to keep the physics time steps fixed, while interpolating (between physics frame) the position/orientation of objects at drawing time.
Oversampling is where you have an insanely high framerate (or you are viewing physics in slow motion) where one physics frame accumulates over several display updates.
So... If drawing is at 200 FPS and physics at 50, you end up redrawing the exact same frame 4 times. So what's the point of 200 FPS?
- eru 17y agoPerhaps the camera can move between diplays frames, while the physics frame stays the same?
- kd5bjo 17y agoHe gets into frame interpolation later in the article as a solution to exactly that problem.
- barrettcolin 17y agoThe idea (for the interpolating case) is that drawing occurs between two physics states; say at time0 physics has state0 (position, orientation etc) and at time1 physics has state1. Then the state at draw time is an interpolation of the states (lerp for positions, slerp for orientation quaternions etc) with parameter t (where t is (draw_time - time0) / (time1 - time0)). The non-intuitive thing is that drawing is always bracketed by a physics step in the past and a physics step in the future.