Port the game loop

[This article is for Windows 8.x and Windows Phone 8.x developers writing Windows Runtime apps. If you’re developing for Windows 10, see the latest documentation]

Shows how to implement a window for a Windows Store or Windows Phone game and how to bring over the game loop, including how to build an IFrameworkView to control a full-screen CoreWindow. Part 3 of the Port a simple Direct3D 9 app to DirectX 11 and the Windows Store walkthrough.

Create a window

To set up a desktop window with a Direct3D 9 viewport, we had to implement the traditional windowing framework for desktop apps. We had to create an HWND, set the window size, provide a window processing callback, make it visible, and so on.

The Windows Store environment has a much simpler system. Instead of setting up a traditional window, a Windows Store game using DirectX implements IFrameworkView. This interface exists for DirectX apps and games to run directly in a CoreWindow inside the app container. Pure native Windows Phone apps use the same CoreWindow and IFrameworkView framework as Windows Store apps. Hybrid XAML and DirectX apps have a slightly different structure.

Note  Windows supplies managed pointers to resources such as the source application object and the CoreWindow. See Handle to Object Operator (^).

Your "main" class needs to inherit from IFrameworkView and implement the five IFrameworkView methods: Initialize, SetWindow, Load, Run, and Uninitialize. In addition to creating the IFrameworkView, which is (essentially) where your game will reside, you need to implement a factory class that creates an instance of your IFrameworkView. Your game still has an executable with a method called main(), but all main can do is use the factory to create the IFrameworkView instance. This code is standard for most DirectX-only Windows Store apps and pure-native Windows Phone apps.

Main function

//-----------------------------------------------------------------------------
// Required method for a DirectX-only app.
// The main function is only used to initialize the app's IFrameworkView class.
//-----------------------------------------------------------------------------
[Platform::MTAThread]
int main(Platform::Array<Platform::String^>^)
{
    auto direct3DApplicationSource = ref new Direct3DApplicationSource();
    CoreApplication::Run(direct3DApplicationSource);
    return 0;
}

IFrameworkView factory

//-----------------------------------------------------------------------------
// This class creates our IFrameworkView.
//-----------------------------------------------------------------------------
ref class Direct3DApplicationSource sealed : 
    Windows::ApplicationModel::Core::IFrameworkViewSource
{
public:
    virtual Windows::ApplicationModel::Core::IFrameworkView^ CreateView()
    {
        return ref new Cube11();
    };
};

Port the game loop

Let's look at the game loop from our Direct3D 9 implementation. This code exists in the app's main function. Each iteration of this loop processes a window message or renders a frame.

Game loop in Direct3D 9 desktop game

while(WM_QUIT != msg.message)
{
    // Process window events.
    // Use PeekMessage() so we can use idle time to render the scene. 
    bGotMsg = (PeekMessage(&msg, NULL, 0U, 0U, PM_REMOVE) != 0);

    if(bGotMsg)
    {
        // Translate and dispatch the message
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }
    else
    {
        // Render a new frame.
        // Render frames during idle time (when no messages are waiting).
        RenderFrame();
    }
}

The game loop is similar - but easier - in the Windows Store version of our game:

The game loop goes in the IFrameworkView::Run method (instead of main()) because our game functions within the IFrameworkView class.

Instead of implementing a message handling framework and calling PeekMessage, we can call the ProcessEvents method built in to our app window's CoreDispatcher. There's no need for the game loop to branch and handle messages - just call ProcessEvents and proceed.

Game loop in Direct3D 11 Windows Store game

// Windows Store apps should not exit. Use app lifecycle events instead.
while (true)
{
    // Process window events.
    auto dispatcher = CoreWindow::GetForCurrentThread()->Dispatcher;
    dispatcher->ProcessEvents(CoreProcessEventsOption::ProcessAllIfPresent);

    // Render a new frame.
    RenderFrame();
}

Now we have a Windows Store app that sets up the same basic graphics infrastructure, and renders the same colorful cube, as our DirectX 9 example. If you'd like to see the sample code presented in this walkthrough, download the Simple Direct3D 9 to DirectX 11 Windows Store porting sample.

Where do I go from here?

Bookmark the DirectX 11 porting FAQ.

The DirectX Windows Store templates include a robust Direct3D device infrastructure that's ready for use with your Windows Store game. See Create a new DirectX 11 project for Windows Store for guidance on picking the right template.

Visit the following in-depth Windows Store game game development articles:

• Walkthrough: a simple Windows Store game with DirectX
• Developing Marble Maze, a Windows Store game in C++ and DirectX
• DirectX audio development roadmap
• Working with input and controls in your DirectX game

Pure native games for Windows Phone are very similar in structure to Windows Store games. The hybrid Direct3D and XAML app types for phone use a different structure and have access to different sets of phone features. For more information see, Choosing the right project template for your game for Windows Phone 8.

For more information on game development for Windows Phone, see Games for Windows Phone.