Monthly Archives: April 2013

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.

Using Windows 8 on a MacBook Air Late 2010

A nice feature of virtual machines is that you can always restore to a defined state of the test environment with a button click.

But sometimes you have to test on physical machines, especially if you need to test graphics related features.

My test machine for such purposes is a space-saving but already somewhat older MacBook Air.

First: Boot Camp Assistant only offers the opportunity to save Windows 7 drivers on a USB stick. The Windows 7 drivers can be used, so you should store them on a USB stick.

If you try to install Windows 8 via Boot Camp on a MacBook Air Late 2010, the Boot Camp Assistant returns an error message that Windows 8 is not supported on this machine.

Here are the instructions on how you can still install Windows 8. Important: prior to any experiments, a backup should be made.

Developers can download a 90 day trial version of Windows 8 for free from the Microsoft website. This ISO must then be burned to DVD.

Mac OS X on the MacBook is booted from a USB drive or USB stick. Then you start the program Disk Utility. Here the existing partition is resized and a second partition is created as FAT. It makes sense to use a meaningful name (e.g. ‘Win8’) for this partition. Windows 8 requires a NTFS formatted partition. Such a partition can‘t be created by Disk Utility without additional driver, so FAT is used.

Disk Utility

Disk Utility

Then the computer is shut down, the external DVD drive (SuperDrive) is connected, and the Windows 8 DVD is inserted. Hold down the Option key at restart. Launch the Windows 8 installation from DVD.

As target select the FAT partition. The partition must be reformatted as NTFS first before the actual installation can begin. After the installation is finished, another important step must be performed.

For whatever reason, Windows 8 freezes frequently on a Late 2010 MacBook Airs.

The deal is:

  • Start CMD as administrator and type:
  • bcdedit /set disabledynamictick yes

Windows 8 will  then run stable on the MacBook. There are three issues that stand out immediately:

  • the trackpad works only limited
  • the brightness is too high and can not be reduced
  • you can’t adjust the volume
Can't adjust Brightness

Can’t adjust Brightness

This is the time where you install the Windows 7 driver from a USB stick, and it works.

In Device Manager, you can see that not yet all the hardware devices are supported. Here one would have the search for drivers from the hardware manufacturer. That was not necessary to run my tests.

To be able to choose at boot time between the Windows and Mac operating system, only the Option key must be held down during startup.

To be able to restore different defined test environments, there are of course different ways. One is to use the Mac OS X program Winclone. This offers to save the entire Windows partition to an image which can be restored any time.

Winclone Restore

Winclone Restore

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.