Another post – another library! Yeah, I messed up with the last one, a silly mistake that should have been spotted a lot earlier on which meant that any kind of interruption in the game would cause big problems. No pausing, no tombstoning…
However, this also provided a good opportunity to update to the latest version of Monogame – well worthwhile as the new version sorts out landscape orientation in WP8 as well as better back-button handling. I also wanted to sort out my VS2012 setup so I could run the WP8 versions of my creation in the emulator (no substitute for a device, but a must-have for on-train development). Needless to say, there were problems…
The Downloads
At this point in time, the updated version of Monogame has not been baked into the installable that hooks into Visual Studio, so this must be downloaded from GitHub. I’ve heard that the fork required has now been merged into the main branch, which can be found here. Download the ZIP, it’s easier! Unzip it, but don’t build – I’ll come to why in a moment.
Assuming you have the Monogame templates installed into Visual Studio (available here if you don’t), the required template at the time of writing is the Monogame Windows Phone 8 Project – this will come with Monogame pre-referenced. Pull this reference out, then go to where you unzipped the new Monogame ZIP to and add the Monogame.Framework.WindowsPhone.sln project to your new game solution, then add a reference in your game to the Monogame project.
The reason for adding the Monogame framework as a project (rather than building and including a DLL) is that at this time, you cannot build a Monogame project in Visual Studio using the “Any CPU” setting. So building an ARM version of the Monogame framework would limit you to running on a device, and similarly the x86 build would confine you to the emulator. By including and building the framework with the solution, you can chop and change as required!
Sort that config!
However, a pesky reference to the old version of Monogame is left when building in x86 mode, which will block compilation! To sort this out, open the solution’s .csproj file in your favourite text editor and scroll towards the end – eventually you will come across an ItemGroup tag with the following comment: A reference to the entire .Net Framework and Windows SDK are automatically included. Following this is the conditional reference to the old version of Monogame when running in x86 mode – remove or comment this whole block out (including the itemgroup tags) to be rid of it!
Fix the XAML
Finally, there’s a couple of changes needed in the code generated by the template in order to make things work. Firstly, go to the GamePage.xaml file, delete everything inside the “phone:PhoneApplicationPage” node and replace with the following:
<Grid x:Name="LayoutRoot">
<MediaElement />
<DrawingSurface x:Name="XnaSurface" />
</Grid>
Similarly, if you want your game to run in landscape orientation, alter the “SupportedOrientations” and “Orientation” attibutes of the “phone:PhoneApplicationPage” node to have a value of “Landscape” in both cases.
Next, open the code file for the xaml page (GamePade.xaml.cs) – there will be a line something like _game = XamlGame<Game1>.Create("", XnaSurface);. Change the “XnaSurface” to “this”.
Wire up the Back Button
Congratulations! You now should have a Monogame project that will build an deploy on either a device or the WP8 emulator, dependent on your choice from ARM or x86 build config. However, if you run this, you will notice that the back button no longer quits the application – this now needs to be wired up manually, just as with good old XNA. So go to the Update method of your Game1 class and add the following:
if (GamePad.GetState(0).Buttons.Back == ButtonState.Pressed) { Game.Exit(); }
Should look very familiar to any former XNA coders!
And that’s it! Once again, great job to the Monogame team for their amazing work.
Ryokumas Rambles 