There are several questions and articles which deal with timestep - for example:
- Should game logic update per second or per frame?
- Accounting for drift between ticks (this was my previous question)
Although that last one started to get into it in the comments - I still have an unanswered question about how to architect for a multithreaded system.
Given two threads:
- State Worker : simply does pure transformations on data.
- IO Renderer : Deals with input, and renders the latest available State object
Let's say the state-worker thread simply updates the game state in a continuous loop, while the renderer updates the screen on a fixed timestep (e.g. 60fps).
Let's ignore input for now.
The renderer does its job by taking the freshest data it has, which was passed in from the state-worker whenever it was finished (which may have happened dozens of times between renders.)
It seems to me like this would be the smoothest solution and it's extremely simple (no interpolation other than reading the delta time between state updates - irrespective of render updates).
Although very minor - and I said we can ignore input, it also gives a tiny bit more snappyness since it polls the input and syncs it with the game state updates which would happen far more frequently in this case vs. basing it on render ticks (at least for simple games).
What are the flaws with this idea? Or is it solid?