How do I use delta time time-stepping in a triple-buffering scenario?

Question

I am creating a graphics application in Metal. One of the things we are suggested to do is to use triple buffers in order to allow for the GPU and CPU to work more in parallel. Essentially instead of writing frequently changing data to the same spot in memory you alternate between three offsets and then pass in a drawing offset for the GPU that way the GPU is not reading something the CPU is currently trying to write.

One problem with this is that it means that what is drawn on screen will be from 2 frames ago.

So my question is what does this mean for time-stepping? Heaven forbid I have an incredibly variable frame-rate how do I make things seem smooth when the dt value I have for the CPU simulation frame is actually two frames behind?

Answer 1

It's worth noting that even without double/triple buffering, if the framerate jumps from 30 to 60, for example, the first 60fps frame would've been calculated with the previous frame's time-step -- 33.333ms instead of 16.667ms. So even if you're not double/triple buffering your dynamic buffers for animation or what not, one still faces the problem of highly variable framerates making the entire simulation more jittery than the actual framerate.

Using a smoothed time-step can help. You just keep a rolling average of several frames' time-step. When the framerate is constant, it makes no difference. When the framerate varies widely and wildly, the average will still mean you're simulating and animating at the correct rate on a macro level, but you'll avoid having your smallest time-steps used in your longest frames (and vice versa).

Answer 2

What technology you are creating your app in is largely irrelevant.

Time stepping only applies to app state updates. Rendering should be performed on the most up to date data available at rendering time:

In a single thread scenario, updates and rendering are sequential, and therefore frame rate is dependent upon how fast you can get through the update phase.

In a two thread scenario, you offload the update work to a second thread, and that is where your app/game state is updated, or the memory is written to. In your main thread, you just loop through the renderer, only reading the latest game state updates for rendering. In this way, your rendering is never a frame behind.

Double/triple buffering is a graphics hardware technique to prevent screen tearing, by always ensuring that there is a complete frame to render. It is not necessary to allow the cpu and gpu to work in parallel.

I would advise you to learn the fundamentals and best practices of multithreaded programming, and do some research on multithreaded game engine design.