Category Archives: MonoGame

Developing with Unity for MonoGame II


There were some responses to my last blog post entry.

Among the comments and feedback, there was also the question: why using Unity?

This question was a little surprising to me, because my impression is that Unity is currently the absolute dominant game development environment?!

I personally think that Unity offers enormous advantages:
– Rapid development, fast edit / test cycles
– Allows easy customizations of the editor by means of simple scripts
– The asset store

BTW: What are your favorite features in Unity?

I made a 3 minute screencast showing a typical turnaround cycle:
– Construction of a new level in Unity
– Add the level to the FFWD configuration
– Conversion of the project to XNA
– Compilation of the assets (Content Pipeline) in VS2010 to .xnb files
– Transfer of .xnb files to a Windows Phone 8 project
– Deploy and test the game

Of course this can only be a quick overview of the workflow. I will write more posts about it.

Are there certain things that you want to see in the next blog post?

If not, I’m going with things that I think are interesting about this workflow.

So just let me know what you are interested in.

Developing with Unity for MonoGame

Developing with Unity for MonoGame

This is part one of a multi-part blog post about developing with Unity for MonoGame. Mombari is an upcoming game for Windows Phone 8. First take a look at the first gameplay video of Mombari.

I sat in the audience as David Helgason announced the support for Windows Phone 8 at the Unite conference 2012 in Amsterdam.

I expected it in the summer of 2013, but it could be available sooner, especially if one takes  this blog entry into account: Unity 4 Beta program for Windows Phone 8 apps

So why MonoGame then?

MonoGame makes sense when you consider that the framework has supported Windows Phone 8 very early and this approach has allowed games testers to already test the game during the early stages of development on the real target device.

A First Overview



FFWD is an open-source framework written by Thomas Gravgaard from the Danish company PressPlay that allows you to port your Unity3D projects to XNA.

So wait, XNA isn’t supported on Windows Phone 8, right? On current Windows Phone 8 devices there is only a restricted version of XNA for backward compatibility available. Since you can’t use the new features of the hardware its only role is to run WP7 apps. Then MonoGame entered into the frame. MonoGame is an open-source framework that implements Microsoft’s XNA 4 framework on several platforms, including Windows Phone 8. It is developed thanks to several volunteer developers.

The game is developed and tested in Unity. FFWD has a two-fold job: it converts the Unity project into a XNA project at compile time, and at runtime it emulates a subset of the Unity runtime environment on top of XNA.

The XNA part has been overtaken by MonoGame. Underneath MonoGame one finds SharpDX, which is a tight C# wrapper around the native DirectX API. SharpDX is also an open-source project started by the developer Alexandre Mutel. MonoGame on Windows uses SharpDX as an interface to the native DirectX functionality.

Both MonoGame and SharpDX are actively maintained.

The Beginning

I always want to test for showstoppers at the beginning of a project and not when you have already made substantial progress and burned a lot of your budget.

To be frank, what I first thought about actually using this stack of frameworks was that it wouldn’t work. I started to play around with MonoGame and then I gave myself two weeks to build a prototype with the core elements and was prepared that I would fail somewhere.

Interestingly, the prototype actually ran really well.

That’s it for today. See in the next part of the blog post what a typical turnaround cycle looks like: Unity -> FFWD -> VS2010 Content Pipeline -> VS2012 -> Windows Phone 8 Device.

Pitfalls when Developing HLSL Shader


When you only have a pixel shader sometimes you get weird results or it is working in one context (e.g. an actual device) but is not working correctly in another context (e.g. emulator or another device).

If you try something different you will see that if a vertex shader and pixel shader are compiled together as a technique it works.

What could cause this behavior?

If one take a look at the output of the fxc.exe tool one can see that the predefined semantics (e.g. COLOR0 or TEXCOORD0) of former DirectX versions are gone. Instead the parameters are mapped to register in order of the parameter appearance in the signature of the function.

So it’s a good idea to use the complete signature, e.g.

float4 PixelShaderFunction(float4 pos : SV_POSITION, float4 color1 : COLOR0, float2 texCoord : TEXCOORD0) : SV_TARGET0

Output of the fxc tool for this signature:

// Input signature:
// Input signature:
// Name                 Index   Mask Register SysValue  Format   Used
// -------------------- ----- ------ -------- -------- ------- ------
// POSITION                 0   xyzw        0     NONE   float
// COLOR                    0   xyzw        1     NONE   float
// TEXCOORD                 0   xy          2     NONE   float   xy

So for example if the second parameter in the signature is omitted the output is:

// Input signature:
// Name                 Index   Mask Register SysValue  Format   Used
// -------------------- ----- ------ -------- -------- ------- ------
// POSITION                 0   xyzw        0     NONE   float
// TEXCOORD                 0   xy          1     NONE   float   xy

So TEXCOORD is wrongly mapped to register 1.

That means one can omit parameter at the end but not at the beginning or in the middle.

Anyway to use the complete signature seems to be a good way to have the desired result in any context.