Tweaking MonoGame for Mobile

So you have a great Xbox 360 or Windows game that you want to port over to a mobile platform. What kind of things do you need to worry about? There are some obvious ones that will come to mind first: screen size, input, and performance. Here's how to handle those factors with MonoGame.

Screen Resolution

With certain platforms, like Windows Phone 7 and iOS, you can almost guarantee the screen sizes of the devices you are going to be working on, but with some devices and platforms it's not so easy. Windows Phone 7/8 support hardware scaling, but with Android, Ouya, Windows 8, and the Retina displays on iPad and Mac, MonoGame developers need to take into account the various resolutions they might come up against. Sometimes you'll find yourself navigating a minefield of screen resolutions ranging from 320x200 all the way up to full HD.

One technique that has been used quite well in the past is to use SpriteBatch scaling. With this method, you can design your game to run at a particular resolution, then at run time figure out a scale matrix that will resize your game to match the actual screen size of the device you are running on. This matrix can then be passed to the SpriteBatch, which will scale your graphics. In the following code, we can see some sample code for calculating the scale matrix; in this case our

virtual resolution is 800x600.

var virtualWidth = 800;

var virtualHeight = 600;

var scale = Matrix.CreateScale(

(float)GraphicsDevice.Viewport.Width / virtualWidth,

(float)GraphicsDevice.Viewport.Height / virtualHeight,

1f);

With that matrix calculated, we can now call spriteBatch with the extra matrix parameter like so:

spriteBatch.Begin(SpriteSortMode.Immediate, null, null, null, null, null, scale);

// draw stuff

spriteBatch.End();

This will apply the scale matrix to the items being drawn in that batch. There are other considerations like aspect ratio and letterboxing that you need to take into account, but there are plenty of resources out there, which were originally written for XNA that can be reused in MonoGame and applied to new platforms. (For more on this topic, read this post.)

At a certain point, however, scaling won't solve your problems. Scale down too much and your graphics will become pixelated; scale up too much and they become blurry. At this point, you need to start looking at the assets. One technique you can use on iOS is have two sets of assets -- one for normal displays, and one for Retina displays. You can do this by adding a @2x suffix to the name of the larger asset and including that asset in your game package. The MonoGame content pipeline has been coded to make use of this trick on iOS, so if you have a raw asset or .xnb file which has a @2x version and you are running on a Retina display device, that higher-resolution asset will get loaded. All the developer needs to do it include those assets in the application. (This does make your app package larger, unfortunately.)

The other option is to have two versions of the game, one for normal and one for HD, each with different scales of assets. This way, people have the choice of downloading a larger high-definition game or the smaller normal one.

Handling Input Devices

Moving between platforms means you need to support various input devices. On the desktop platforms (Windows, Linux, and Mac), MonoGame uses the Simple Direct Media Library (SDL) to interface with the various joysticks and gamepads that might be available. The inputs from these devices are routed through the GamePad class. SDL does seem to have a problem reading the USB description of some of the Xbox 360 controllers, so on occasion it will fail to apply the correct configuration.

Mouse and touchpad input is one area where MonoGame has diverged from the normal XNA. On Windows Phone 7 and 8, if you use the XNA implementation provided by Microsoft, all of your touch events will be routed through to the mouse as well. This can make it very easy to port games over from Windows and Xbox 360 to those platforms. However, with the introduction of Windows 8, you now have devices which can have a mouse and a touch screen, and it is possible that game devices will want to use these separately. With this in mind, if you have a Windows game that you are porting to a Windows Store App, you will need to add support for touchscreens as your existing mouse code will not be used.