Separating rendering from HWND

Question

I'm considering separating my game simulation from the message loop. It seems odd to me to have other systems tied directly to the window in which my game is running. Most examples I see are implemented similar to the following (I'm glossing over details here, code is only meant to get the idea across)

... WndProc(...)
{
    //PeekMessage
    //Update input
    //Update timer
    //Update simulation
    //Update renderer
}

To increase separation of concerns, I'd like to move the update of input, simulation and renderer out of the specific window itself. This seems simple to accomplish

... WinMain(...)
{
    //Update window
    //Update input
    //Update timer
    //Update simulation
    //Update renderer
}

... WndProc(...)
{
    //PeekMessage
}

There is information that must be obtained from the window to be consumed by the rest of the game. Namely, input (if using the message system), window size, window focus, etc. I should be able to use callbacks or passing in references to state objects the window will update to get this information.

This approach allows me to separate each concern into it's own class. The window code is implemented in a Window class, input in Input, etc. I can use WinMain or a Game class to create each system and coordinate state between them.

Further, it allows me to divorce the renderer from the HWND itself. It seems smelly to me to have the renderer embedded directly within the Window. What if something happens to the window? What if I want to use the same renderer to output multiple views into separate windows (via CreateAdditionalSwapChain)?

The questions that arise from this:

Primary:

• It seems I can just rebuild the swap chain to hook up to a new window. Do scenarios exist where the HWND could be invalidated or destroyed but I want to retain my rendering context? Or is this overkill?

Secondary:

• Are there flaws to this approach I'm not considering?

• Are there better implementations I'm not considering?

Answer 1

Take a look at the Direct3D Game templates on GitHub. The Win32 desktop HWND processing and message pump in Win32Game_201x is isolated to a single module which can be replaced with something like the ICoreWindow render loop and message handling as is done in the UWPGame_2015 template. All the templates use the same basic Game class which handles the Direct3D device creation and swapchain.

It's quite common for cross-platform engines to isolate the platform-specific main loop and window handling from the graphics rendering. That said, there are a lot of pitfalls here particularly with respect to multi-threading. See DirectX Graphics Infrastructure (DXGI): Best Practices if you plan to do threading in your application.