Monogame 3.2 with WPF Editor

Hi there!

I’ve been digging around the forums and tutorials, but can’t really find an up to date article that describes what I want to do.

So the idea is that I have an ‘engine’ project that derives from Game (so I get all of the updates and managers) and then a WPF editor that hosts the window for the engine rendering.

I’ll need to have multiple WPF controls (embedding in a windows form host is fine) so I can run the editor & things like texture browsers/particle system editors at the same time.

I’ve tried creating and running the Game instance from within the editor, but that pops up window unique to the Game instance, and I haven’t been able to figure out how to explicitly set it’s window handle; I’m left with a game window and my WPF application running simultaneously.

I’ve also tried not deriving my engine from Game and setting up my own GraphicsDeviceManager, but the trouble is whenever I try and create a GraphicsDevice I get an Null Reference Exception

Anyone have article links or pointers on how to accomplish this?

Thanks for your help!

I really want to know how to create a WPF window with a Game embed.
I’m searching a lot, but I don’t get success.

Actually creating a WPF window with a Game embedded doesn’t take too much work.

Create your WPF window, then add a WindowsFormsHost to it (you’ll need to reference System.Windows.Forms in your project).

Before you call Game::Run, pass the windows handle (an IntPtr) of the WindowsFormHost to your class that manages the Game instance. You’ll also want to register an event handler with your GraphicDeviceManager::OnPrepareDeviceSettings.

When you call Game::Run, the function you registered with OnPrepareDevice settings is called, and you just set the window handle of the PresentationParameters to the window handle of your WindowsFormsHost. The Game will then run in your WPF application.

This article describes it in detail

1 Like

Thanks @Orangeatang!

haven’t seen this tutorial before.
It works like a charm :smiley:

Hi, to my regret is impossible to me to make a project in this way. :frowning:
When I try I catch this exception:

An unhandled exception of type 'System.BadImageFormatException' occurred in mscorlib.dll
Additional information: Could not load file or assembly 'Game1, Version=, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.

Anyone can tell me how to fix this error or share a correct project.
I would be very grateful :slight_smile:

I’ve seen this happen when the program builds as 64bit, but but links to 32bit dlls… that possible?

Also make sure you’re targeting .NET 4.0.

Indeed, that is possible, thanks.
P.S. In this world only my inattention will destroy me :wink:

Looks like you’ve already got a solution, but in case it helps anybody else: I wrote a MonoGame module for my Gemini framework, which shows one method for doing interop between WPF and MonoGame (mostly based on code from other people).

The end result looks quite similar to the XNA module: (in Controls/DrawingSurface.cs and Services/GraphicsDeviceService.cs)

1 Like

Hi @tgjones,

My first solution was using the WindowsFormsHost, but I got in trouble with the airspace issue.

Your solution works very well. I made an entire test here:

I also made an GameUpdater class based on today’s branch from monogame.
It works very well and the FrameRateCounter shows as expected, but in slow FPS the entire WPF application run slow, not only the DrawingSurface.
If you want to test, change the type variable from the BlurGameModule class to 3 (CPU blur) or 4 (GPU blur).

Do you already have any solution for the update method or any sugestions for my GameUpdater class?


but in slow FPS the entire WPF application run slow

Yep, that’s an inherent part of using this technique. DrawingSurface does all its rendering by subscribing to WPF’s rendering event:

CompositionTarget.Rendering += OnCompositionTargetRendering;

So if the MonoGame content is slow to render, it will slow down the rest of the WPF UI. I don’t think there’s any easy way around that, using this technique.

Do you already have any solution for the update method or any sugestions for my GameUpdater class?

Do you mean a solution for the slow FPS?

Perhaps setup another thread and draw from there? I am not sure if it is possible to call draw directly on DrawingSurface. DrawingSurface is inheredly tied to WPF composition.

Do you absolutly need to use DrawingSurface? The airspace problem will be solved on win10, until then the alternative is SwapChainRenderTarget and bring up a new Window or draw UI from MonoGame.

I was referring to the GameUpdater class. Anyway, you awnsered it above:


I didn’t know that the airspace would be solved on win10.
I first tried the WindowsFormsHost to leave Monogame intact, but we did a lot of things to integrate it in WPF successfully.
One of the biggest problems was handling two different tabs with a host to MonoGame and different sizes.

With the DrawingSurface method we removed a lot of code to deal with different tabs and mixed integrations between WPF key events and WindowsForms mouse events and cursors.

Now, everything is WPF.