Shawn Hargreaves Blog
I often see people trying to use the XNA Game class in unusual places, for instance to host an XNA game inside a WinForms application.
That is usually a bad idea.
The Game class is designed to be simple, automatically setting everything up ready for you to start coding. If you are doing something complicated and want more control over the details of how your window is created, this is only going to get in your way.
Just say no! If you want to render into a custom window, don't use the Game class. It will be much easier and more reliable to directly create your own GraphicsDevice object.
If you want to use the content pipeline, you will also need to implement a custom IGraphicsDeviceService and IServiceProvider, which the ContentManager uses to locate the GraphicsDevice instance.
Roger Boesch posted some code for doing exactly that. His page is in German, but if du sprichst nicht Deutsches, Google can translate. Make sure you look at his code from the original page, though, because Google gets rather confused when you ask it to translate C# from German into English!
If we wanted to do away with the Game class for building, say, a small game engine that'll work on the 360, what would we pass for the handle to the window?
It doesn't matter. Xbox has no WinForms, and no window handles, so that parameter is ignored.
I have created a tutorial with example that will run XNA inside a Windows.Form (complete with resizing, etc).
It uses very few lines of code and is in english ;)
Shawn, I can't understand why you people underestimate the importance of some developers wanting to use XNA in winforms. Not everyone is a game developer and need a full screen 3D environment. I , for one, develop an interior design application for windows desktop. So I need 3D in my app, I dont want to use C++ and directx, as it is not an option compared to C# and xna. Please take people like me seriously and provide more samples of xna with winforms. I am an admirer of your blog and efforts. Turkey
ibrahim: have you looked at the WinForms samples from creators.xna.com?
Is it possible to use XNA from a WCF service? I want to create a WCF service that will build and load fonts but have no interface. However, I cannot instantiate an instance of ContentManager, even if I create a Game class and instantiate that.
> However, I cannot instantiate an instance of ContentManager
I don't know anything about WCF services, but I don't understand why, if you can run managed code at all, you would be unable to instantiate a ContentManager.
You will most likely have a problem creating a GraphicsDevice from a service environment, though, which will limit what kinds of content you are able to load.
Hi, I have read many of your articles about xna winform fullscreen mode. However, no codes or anything yet.
Please give me some guidelines to do it pls.
It is very common issue to have a window application what can switch between normal screen with many utilities and 3D screen only, just like media player. How to achieve that can does it affect the speed of the app?
His page is in German, but if du sprichst nicht Deutsches, Google can translate.
This is great :D
Was that Google, or can you speak German? It´s wrong anyway ;)
Seriously, the current accepted method of doing this is terrible.
The real solution is simple, you change the device handle that DirectX is targeting..
Let me guess, it won't work, interferes, blah,..
Just make a new overloaded constructor for Game, add an IntPtr handle parameter..
With me so far, now, in your templates, set everything up, just like it is, ie, using the same constructor as usual.. (That's it, the regular XNA setup will NOT be altered by these changes, thus, it cannot interfere..)
Then, add a WinForm template, that DOES use the new constructor, set a PANEL\etc as the target, make the backcolor CornflowerBlue so ppl understand it's the render window, etc,.
And like magic, we can make Winfors apps with ease.. (Wait, it's not magic, it's how DX was supposed\designed to be used in the first place.)
Next, I want DXInput exposed so I can use my third party controller, this will NOT mess with the XBox, why?
It won't interfere, because DXInput will be exposed under a new class library that is only loaded when you select a "Windows Game" or "WinForm App", etc,.. Again, like magic, problem solved, no conflicts..
> Wait, it's not magic, it's how DX was supposed\designed to be used in the first place.
The XNA GraphicsDevice object works exactly that way: you can construct a GraphicsDevice using any window handle you like.
It is the XNA Game class that does not support arbitrary window handles, and thus which cannot be used alongside WinForms. Note that Game has no equivalent in native DirectX.
The purpose of the Game class is to create a window and handle its messages in a simple default way. It doesn't really make sense for Game to take in an existing window, because if you already created the window, how would Game create one for you? And how would it handle messages for that window, when somebody else (in this case WinForms) already owns the WndProc?
It doesn't make sense to have more than one technology trying to do the same thing at the same time, and if you try that, the two technologies will just stomp over each other so you end up with neither of them working correctly. Either you can use WinForms to create and manage your windows, or you can use the XNA Game class, but you can't have them both managing the same window at the same time.
> I want DXInput exposed so I can use my third party controller, this will NOT mess with the XBox, why?
The lack of DirectInput support in XNA has nothing to do with Xbox. We simply chose not to spend our limited development resources on this particular feature, because we deemed it less important than other features which we chose to implement instead.
Just because XNA does not provide a C# wrapper around DirectInput, that doesn't mean you cannot use it in your Windows game! DirectInput is a stable and well documented API, and there are many ways you could interop to it from your C# code (p/invoke, IJW, COM interop...)
FYI, I already started implementing my solution in SlimDX, and it works exactly as I assumed it would.
My Form will initialize my Game class, which will create a GraphicsDevice, based on the constructor used..
By default, it will work just like XNA, but, by using the overload it allows you to use anything on the form for rendering, in my case, I'm using a Panel..
I'll have it done by tomorrow, but I have a lot of work to do, fleshing out my game class, etc,.. Regardless, my solution works fine, as I told you it would.
>My Form will initialize my Game class<
I meant the static entry point of my program, not the form.
For the Winform template, I just need to setup a new form, stick a panel on it, and override the Game constructor with some info about the panel, ie, handle, width, height,. (Save it as a template, and it's ready to rock..)
I created my Game class, it has a default constructor which looks like this..
// Create Form
Form form = new Form();
form.Text = "SlimDX: GameForm";
form.Size = new System.Drawing.Size(800, 600);
form.StartPosition = System.Windows.Forms.FormStartPosition.CenterScreen;
// Save Ref
this.Form = form;
// Attach Device
Graphics = new Graphics.GraphicsDevice(form);
Then I added this..
public Game(bool dummy)
WinGame form = new WinGame();
form.Text = "SlimDX: Winform";
Graphics = new Graphics.GraphicsDevice(form.ViewPanel.Handle, form.ViewPanel.Width, form.ViewPanel.Height);
now I can do this, for a GameWindow..
static void Main()
using (Game g = new Game())
and this, for a WinForm..
using (Game g = new Game(true))
The bool is just a dummy, it can be anything(true\false) and it still works.. It's not ideal, but it works.
Game.Run().. It uses the SlimDX MessagePump to create the game loop..
// Run Game
public void Run()
if (Form == null) return;
// Handles MessageQueue
MessagePump.Run(Form, () =>
// User Update
// Clear Graphics Device
Graphics.Context.Device.Clear(ClearFlags.Target | ClearFlags.ZBuffer, Color.CornflowerBlue, 1.0f, 0);
// Begin Scene
// User Drawing
// End Scene
The only difference between a normal form, and WinGame form, is that the WinGame form, contains a Panel, presized, and positioned, set public, and named "ViewPanel"...
So, there ya go, that should not cause any problems if implemented into XNA, you will obviously have more to deal with behind the scenes, and you may have to alter the solution a bit to make it workable with your code, however, I see no reason why you shouldn't be able to do this..