Cube, but in the renderer’s eyes

Now, let's start digging in.

From Gameplay World to Renderer World

The renderer doesn't care about the gameplay classes.

It doesn't need to know how fast your player can move or what the HP is.

Its only concern is what needs to be rendered: a mesh, a particle, or a sprite.

Update and Sync between two Worlds

This image, from Design Patterns for Low-Level Real-Time Rendering, is a really good explaination of the architecture.

• The idea is that the game thread updates the gameplay logic, mostly through tick functions.
• Then, it captures the render-related information into FRenderProxy and sends it to the render thread.

An example:

1. Game world tick: our cube moved 3 cm forward
2. Capture: after the tick, we send this information to the FRenderProxy, by updating its transform info
3. Render thread update: since we need to render this frame, the render thread will update the new transform info to the GPU memory and ask GPU to render the cube based on the new transform info.
4. The cube appears at the new location, 3cm away from the last location
5. Our brain tell us, the cube has moved