XNA+WPF solution worked

Cory Petosky‘s website

Edit 11/17/2010:

While this article‘s XNA+WPF solution worked when I wrote it, in mid 2009, it no longer functions. This solution might get you halfway there, but I have not researched the other half as I am no longer regularly programming in XNA. Judging from the comments I‘ve been getting for the last couple years, this might not even be possible.

1. You can write code in any .NET language, which means you get to use C#, a very nice programming language with a lot of great features.
2. You can compile your project for the XBox 360 Community Games platform.

I‘m compelled to note that the primary disadvantage of XNA is that it‘s currently (and will be for the foreseeable future) Windows only.

Now, XNA is great, and it‘s based on DirectX, the Microsoft graphics layer that Windows has used for ages. But it‘s new, and like everything else Microsoft does, when stuff is new, it doesn‘t work well with others. In particular, they‘ve also recently released a new GUI framework called WPF. It‘s desireable in a lot of cases to mix your game framework with your GUI framework, so you can, say, make a nice looking set of tools to build your game with.

XNA and WPF don‘t play together nicely yet. They want to, they intend to, and Microsoft is working on making them friends, but currently it requires a set of tightly-coded leg irons to keep them together. Here‘s my technique for getting one inside the other.

Step 1: Make a game

This is probably the hardest step, but I know you can do it! It‘s beyond the scope of this article though. If you just feel like fooling with this, you can make a simple game that just redraws the screen background to a random color every frame.

Step 2: Make a WPF Window

Make a new WPF project. As far as I can tell, there‘s no way to directly inject XNA into WPF, so we‘re going to use an intermediate layer. We‘ll add a WinForms host to our WPF window, and then inject our XNA game into that WinForms host. Here‘s the basic code for your WPF window:

<Window x:Class="EditorWPF.Editor"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:wf="clr-namespace:System.Windows.Forms;assembly=System.Windows.Forms"
    Title="Editor" Height="Auto" Width="Auto">
    <DockPanel>
        <Menu Name="MenuBar" DockPanel.Dock="Top"/>
        <StatusBar Name="StatusBar" DockPanel.Dock="Bottom">
            <StatusBarItem>
                <TextBlock Name="statusText">Load or create a project to begin.</TextBlock>
            </StatusBarItem>
        </StatusBar>
        <WindowsFormsHost DockPanel.Dock="Bottom" Width="800" Height="600">
            <wf:Panel x:Name="RenderPanel"/>
        </WindowsFormsHost>
    </DockPanel>
</Window>

Be sure you‘ve referenced the System.Windows.Forms assembly for your project, or this won‘t work.

The menu and status bar are just to illustrate why we‘re doing this -- if we just put the XNA game by itself in the window, there would be no point to this technique. Anyway, now we have a WinForms Panel available to inject our XNA game into.

Step 3: Setup your game to accept Panel reference

Go into your Game class. We‘re going to edit the constructor to accept a single IntPtr argument called handle. The handle parameter is the internal memory handle of the panel we created above. However, we don‘t muck with the display heirarchy right in the constructor -- we add an event listener to the game‘s GraphicsDeviceManager for PreparingDeviceSettings, and muck with it then. Here‘s what your code should look like:

private IntPtr handle;
private GraphicsDeviceManager graphics;

public EditorGame(IntPtr handle) {
    this.handle = handle;
    graphics = new GraphicsDeviceManager(this);
    graphics.PreparingDeviceSettings += OnPreparingDeviceSettings;

    this.IsMouseVisible = true;
}

private void OnPreparingDeviceSettings(object sender, PreparingDeviceSettingsEventArgs args) {
    args.GraphicsDeviceInformation.PresentationParameters.DeviceWindowHandle = handle;
}

Step 4: Set up your WPF Window to instantiate your Game

Usually, when you create an XNA project, it generates a simple Main function that just instantiates and runs your game for you. In this project, we‘re not going to use this. Instead, we‘re going to manually instantiate and run our game from our WPF window.

This isn‘t quite as simple as you might think. If we just call game.Run() somewhere, our window will stop responding until we end the game. Since we don‘t intend on ending the game until the WPF window is closed, this won‘t work. Instead, we have to spawn a second thread and run the game there. This is much easier than it sounds.

Open the code file underneath your XAML file and add these two lines to the bottom of your constructor:

IntPtr handle = RenderPanel.Handle;
new Thread(new ThreadStart(() => { game = new EditorGame(handle); game.Run(); })).Start();

And, of course, add a private game instance variable to your class:

private EditorGame game;

...and that‘s it! Run your WPF project and you should see your game between the status bar and the menu bar.

Optional: Breaking it down

In case you‘ve never used threads, lambda expressions, or anonymous objects before, let me break down that weird line above.

new Thread(
    new ThreadStart(
        () => {
            game = new EditorGame(handle);
            game.Run();
        }
    )
).Start();

Working from the inside out:

() => {
    game = new EditorGame(handle);
    game.Run();
}

This is a lambda expression, a C# 3.0 language feature. It‘s a shorthand way of defining a function. You can do exactly the same thing with C# 2.0‘s anonymous function feature, but lambda expressions are shorter and more elegant. You could also, of course, define a normal instance method instead of using an anonymous thing at all, but I like anonymous functions when the scope of that function is small and restricted to a single method. The following method is entirely equivalent to the above lambda expression:

private void MyFunction() {
    game = new EditorGame(handle);
    game.Run();
}

The ThreadStart constructor takes a delegate as an argument. A delegate is basically a way to treat a function or method as an object. By providing the lambda expression directly as an argument, the compiler treats it as a "function object" and passes it in to the ThreadStart constructor. If you‘re still confused or curious, search for C# delegates, and then search for C# lambda expressions.

Our statement now looks like this:

new Thread(
    new ThreadStart(
        MyFunction
    )
).Start();

The new ThreadStart there just instantiates a new ThreadStart object, just like every other new expression you‘ve ever used. In this case, we‘re never going to use that ThreadStart object again, so I define it anonymously -- that is, I don‘t assign it to a variable to be reused again later. This is equivalent to the following:

ThreadStart myThreadStart = new ThreadStart(MyFunction);
new Thread(myThreadStart).Start();

The new Thread call does the same thing, except it then invokes a method on the anonymous object created. Again, this is because I don‘t care to worry about the thread after I create it. In the end, this whole chunk is equivalent to what I first wrote:

public Editor() {
    IntPtr handle = RenderPanel.Handle;
    ThreadStart myThreadStart = new ThreadStart(MyFunction);
    Thread myThread = new Thread(myThreadStart)
    myThread.Start();
}

private void MyFunction() {
    game = new EditorGame(handle);
    game.Run();
}

I prefer mine myself:

IntPtr handle = RenderPanel.Handle;
new Thread(new ThreadStart(() => { game = new EditorGame(handle); game.Run(); })).Start();

But both approaches are "correct." There are many people who would advocate the longer approach, arguing that it‘s easier to read and maintain. I disagree, but now you have the option to include either based on your personal bias.

Originally posted July 8, 2009.

Copyright 2012 Cory Petosky. Email me: [email protected]