So, I\'m working on a game engine, and I\'ve made pretty good progress. However, my engine is single-threaded, and the advantages of splitting updating and rendering into separa
I've made my program using three threads (though more could be used).
Update logic (Does the data collecting and pre-processing)
Helper thread (Calculates time consuming cache pre calculations etc. at infinite sleep 1ms loop ... So this thread does not care where Update logic is going, or how fast. It just checks where it is going and calculates iF it needs to cache new items)
Render thread (Does ONLY rendering, everything it needs to render is pre-processed so it does only draw functions and calculates screen positions)
Doing this is super easy if you just have "thread safe" items you are drawing. But in game, I personally think that it is not bad thing if you render player 1 one tick ahead than player 2... Because you still want to draw as fast you can on games. Game logic thread makes sure there is no logical exceptions... So usually I think it does not matter what you draw and when, you just do it as fast as you can without thinking any "synchronizations".
I presonally prefer public static volatile item
to share data between threads. And AtomicIntegerArray
is a useful class for that too.