Timestep with multithreading

Question

There are several questions and articles which deal with timestep - for example:

• Should game logic update per second or per frame?
• https://gafferongames.com/post/fix_your_timestep/
• 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:

1. State Worker : simply does pure transformations on data.
2. 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?

Answer 1

I do see one flaw, your update worker (aka State Worker) will need input information to make the right updates. How can you update the player's position if you do not know that the player has moved. You would then be running collision tests on out-of-date data (See this image from IBM's tutorial on making a web game). Syncing the game state with the input state after updating said state will be difficult.

I think you should have a worker for your game's logic and another for all things to do with rendering. Rendering at a lower frame rate than the update, since rendering usually eats up the most processing time.