Separate logic and rendering threads?

Question

I have heard some people advising the separation of logic and rendering into different threads when making games. Apparently, while rendering needs to happen at ~60fps, logic may only need to happen at ~10fps.

I have a few questions about this:

1. How can the rendering be faster than logic, if logic is what changes the scene? Surely the rendering thread will be repeatedly drawing the exact same image until the logic kicks in to move the entities around the screen, etc?

2. Won't this create all sorts of nasty concurrency issues, as the logic and rendering may require simultaneous access to the game's objects?

3. Can I assume that it's perfectly acceptable to keep my logic and rendering in the same thread? I am using the LWJGL, whose tutorials all seem to suggest a common "game loop" which includes both logic and rendering.

Answer 1

1. If your game logic does not change the scene, your rendering thread could detect this by giving the scene a dirty flag. if the scene is not dirty, the rendering thread may return the old rendered scene again. Sometimes a scene will change even if the game did nothing due to animated objects like grass, trees or flags.

2. This will happen because two threads do access the same data. But if the game logic thread processes junks of objects locally and updates those chunks kind of atomically, the concurrent access to the same data should be reduced while processing that data. What I try to say is, do not process the concurrently accessed data in a fine grained way but in a coarse grained way to reduce locking.

3. In my opinion you should never over-complicate a design if not needed. If you have enough time to process the scene 10-times in a second and to draw it, then you should not use more than one thread. All the older games did it one threaded and it worked. As soon as your game gets more and more complex and one thread can't do all the stuff in 1 / 60 seconds, you may want to use more than one thread to take advantage of a multi-core machine. But you should wait until need be, before introducing many threads.

Answer 2

1. A sprite may be animating through a series of frames, but no game logic (crash detection, movement, etc) may be required.

2. You will need to use some form of synchronisation or locking.

3. It depends how much work your rendering and logic code sections are doing.