Main Thread: window, message pump and D3D11 DXGI. Render frame N.
Background thread: game logic and physics. Update frame N + 1.
Threadpool: worker threads.

It would be extremely helpful if someone could have a  look at my first attempt to separate the work between the Main Thread and Background …

@JoeJ  two things told this away. first was, when i switched to a framebuffer code that was far simpler and far less cycles (this was aligned to 32 bit instead of 24 bit bitwise magic). i expected some speed gain from the simpler pixel code, but instead, the speed fell by 15-20% or something, …

You didn't mention a language you're working in, this however may make a difference. In C# for example we have the .NET implementation already done in System.Threading.Tasks and many APIs like file I/O already provide an ‘async’ version which will return a task you could wait on completion. The int…

Flone said:
Handle all user input (so handle all windows messages).

You don't want to do that! Windows messages are messed up with a lot of stuff that you don't need and so you should never (even if most tutorials do so) do the entire game and message handling in the main thread! The message loop was…

Key_C0de said:
Your thread dispatching depending on granularity of work is interesting. Your multiple threads for physics integrations seems overkill to me, but you may be working on a big game, even aaa quality.

An example of when that happens (not directly physics related - could be used there too)…