Hosting XNA in a windows forms control and in turn hosting that control in WPF
-
Hello, this is a long story. I will try to make it as short as possible, so please bear with me. A while ago a friend and I started out to write something what you might call a browser game. The first version used ASP.net web pages and a nice three tier architecture. Along the way we felt that a game which more or less looks like a collection of forms is not really exciting. So we did away with the web pages and replaced them with a webservice and a windows forms client. This was a bit better and also offered the advantage of buffering data on the client and doing some GDI+ based rendering. But there was still room for improvement. So why not host XNA in windows forms? This was not easy to do since WinForms are event oriented while an XNA apllication runs in an endless loop to render as many frames as possible. In the end I came up with a WinForms control that featured the functionality of XNA's Game class. Under the hood a WinForms control still uses a Win32 window which XNA (or better: DirectX) needs as a rendering target. Also, I used the Application.Idle event to trigger the rendering of a new frame. Well, WinForms still are a bit limited on the design side, so why not move on to WPF? So we went just ahead and based the client on WPF. The only problem is hosting XNA in WPF. For starters we put our WinForms XNA host control in a WPF WinFormsHost and... nothing happened. It turned out that the Application.Idle event never fires in a WPF application and so no rendering was ever done. So this is my first question here: Does anybody know an event or other means to replace this? I have a crude workaround by putting a timer with a short timeout period on the XNA host control which triggers the rendering. It works fairly well, but the rendering is not as smooth as it used to be. Indeed, I would like to do away with the WinForms control entirely and replace it with a WPF control. The problem there is that DirectX needs a Win32 Window as rendering target. Do WPF controls still have Win32 windows under the hood or does anybody see another way to provide this in a WPF control? You see, the whole thing goes over a few tables and benches, so I posted it here in the forum for the .Net framework. I hope you don't mind. And thanks in advance for the replies. PS: The whole project, of course, is 'homework'. In the sense of doing this as a hobby at home. My bosses at work only want me to write boring business apps :-D
-
Hello, this is a long story. I will try to make it as short as possible, so please bear with me. A while ago a friend and I started out to write something what you might call a browser game. The first version used ASP.net web pages and a nice three tier architecture. Along the way we felt that a game which more or less looks like a collection of forms is not really exciting. So we did away with the web pages and replaced them with a webservice and a windows forms client. This was a bit better and also offered the advantage of buffering data on the client and doing some GDI+ based rendering. But there was still room for improvement. So why not host XNA in windows forms? This was not easy to do since WinForms are event oriented while an XNA apllication runs in an endless loop to render as many frames as possible. In the end I came up with a WinForms control that featured the functionality of XNA's Game class. Under the hood a WinForms control still uses a Win32 window which XNA (or better: DirectX) needs as a rendering target. Also, I used the Application.Idle event to trigger the rendering of a new frame. Well, WinForms still are a bit limited on the design side, so why not move on to WPF? So we went just ahead and based the client on WPF. The only problem is hosting XNA in WPF. For starters we put our WinForms XNA host control in a WPF WinFormsHost and... nothing happened. It turned out that the Application.Idle event never fires in a WPF application and so no rendering was ever done. So this is my first question here: Does anybody know an event or other means to replace this? I have a crude workaround by putting a timer with a short timeout period on the XNA host control which triggers the rendering. It works fairly well, but the rendering is not as smooth as it used to be. Indeed, I would like to do away with the WinForms control entirely and replace it with a WPF control. The problem there is that DirectX needs a Win32 Window as rendering target. Do WPF controls still have Win32 windows under the hood or does anybody see another way to provide this in a WPF control? You see, the whole thing goes over a few tables and benches, so I posted it here in the forum for the .Net framework. I hope you don't mind. And thanks in advance for the replies. PS: The whole project, of course, is 'homework'. In the sense of doing this as a hobby at home. My bosses at work only want me to write boring business apps :-D
Hello using WPF and XNA together seems to be a little tricky. I've seen two different approach for integrating XNA and WPF XNA integration inside WPF Integrating XNA with Windows Presentation Foundation however these techniques are more like a hack than a reliable solution. if you need a GUI for your game I suggest you to have a look at NeoForce Controls good luck
-
Hello using WPF and XNA together seems to be a little tricky. I've seen two different approach for integrating XNA and WPF XNA integration inside WPF Integrating XNA with Windows Presentation Foundation however these techniques are more like a hack than a reliable solution. if you need a GUI for your game I suggest you to have a look at NeoForce Controls good luck
Yes, tricky is the right word. A GUI and a typical DirectX (or XNA) application do not have too much in common. The GUI application tries to use the CPU sparingly by handling events and idling most of the time. A DirectX application tries to get all the CPU time it can and make the best of it. My approach to bringing XNA and WPF together resembles the second one you mentioned. The main difference is, that my control tries to replace XNA's game class and does not try to tweak it into accepting the control as render target. The game originally was supposed to be a web application and still retains the behavior of a website because the client connects to the server over a webservice. This way it will certainly not be a hot action game. Most of the time there will still be some kind of forms and while we want a good design, we also value such things as data binding or our MVP libraries to keep the code short and orderly. A DirectX application will make those things more awkward and NeoForce still misses some controls we would certainly need. The game is going to be something like the good old Master of Orion. The players will be exploring unknown planets and build colonies, research new technology. There will be trade, espionage, politcs and some strategic and tactical combat. But at no point will the player be shooting himself. Instead he will mashall his fleets, troops and commanders. In the end we need a GUI more than DirectX. Let's say the player is looking at his colony. On a website we could display a grid with all buildings he has. Efficient, but not very appealing. Puzzling together some kind of image would be possible, but a little awkward. Rendering a dynamic image would be a little hard on the server and Microsoft does not recommend it because GDI+ is officially not safe to use in a web application. Sending the information of the player's colony to a client is a more logical choice. We can then leave the work of visualizing the colony and its buildings to the client and also eliminate the need to send a large bitmap at every page request. Under WinForms we have to deal with some ugly flickering and sometimes a hard time when trying to get rid of the typical WinForms look, but GDI+ at least can efficiently compose a custom image. A static image may not be state of the art, but at least it is a custom image generated in no noticable time. WPF was mage to allow rich means of designing and animating your GUI and there is no ugly updating and flickering, making the whole thing look much less old