Caching

The Unity engine ticking speed is different from the simulation ticking speed and cannot be kept in sync. This means it is necessary to have a mechanism to cache actions made via input devices and send them into simulation when requested.

Ideal Scenario

An ideal scenario -in which the input is polled from an input device, saved into a cached Quantum.Input data structure and finally read in the same Unity frame when Quantum simulation ticks- is illustrated in the diagram below.

Rendering is FASTER than Simulation

It is common to have a faster rendering speed than simulation speed (e.g. rendering 60Hz, simulation 30Hz). In this situation, there will be Unity frames which advance without the simulation ticking; the simulation delta time has not accumulated enough time and thus will not poll input from the view in Unity. This notwithstanding the input must still be cached from input device, otherwise important input events could be lost resulting in input behavior that is not in line with player expectation. To solve this issue, the input is cached in the Quantum.Input data structure for two Unity frames if it has not already been polled by the simulation.

Rendering is SLOWER than Simulation

A less likely but still possible scenario is having the rendering speed being slower than the simulation speed (e.g. rendering 30Hz, simulation 60Hz). This situation will result in some Unity frames during which the Quantum simulation will advance multiple ticks. In order to avoid reading the same input multiple times, Quantum.Input data structure contains a Reset() method. Reset() is executed immediately after the input is polled from the simulation for a single Quantum tick. This situation is common in particular when encountering network lag or rendering spikes (e.g. 100ms spike results in 6 Quantum ticks being simulated in the next Unity frame).