GameDev

All posts tagged GameDev

So you have a game, and you want to get regular builds for people to test. Now you can do a build yourself , but you’re not a philistine are you? You want to use Continuous Integration (CI).

What is Continuous Integration

If you don’t know, CI is where a server somewhere builds your projects for you when you commit changes. The idea being you script up the steps you need doing and let the server do all the hard work. I’ve used this on many occasions. Any time I find myself doing the same job more that twice, I’ll think about scripting it or getting a machine to do the job.

Now there are allot of CI systems out there, Team City, Jenkins, TFS to name a few. However this post is going to concentrate on the free offering of Travis CI. The reasons for this are, firstly its free, secondly it offers Mac hosts. Having a Mac host in the cloud for a CI system is quite a unusual thing.

Setup Travis.

Signing up for travis is quite simple. Head over to https://travis-ci.org and Signup with your Git hub account. It will ask you which repositories it needs access to. The process is really simple. Note that https://travis-ci.org is the open source free offering for projects which are..open source. Travis CI does offer paid for services for close source projects but the setup is pretty much the same.

Scripting your .travis.yaml

The core of Travis CI is that is looks for a very particular build script, `.travis.yaml`. If you have this file in the root of your repo, Travis CI will use it and run the build. It can work without the script, but I prefer to script things since it gives you more control.

This snippet tells Travis CI that we are a C# project (this is MonoGame right 😉 ). We also define the name of the Solution we are going to build. The next step is to define the operating systems we are running on. In this case osx. We also setup some global variables which can be used later.
Note they also support linux, and docker based images. So if they don’t have the exact system you want, a docker image might work.

The great thing is that Travis CI will automatically realise that we need Mono installed. Because we are using C# on mac, so that will be taken care off. It will grab the latest stable releases from Xamarin. By default Xcode is installed as well (on osx), so you can use this to build iOS apps too. But we need MonoGame..

what this code does is download the latest development branch from the MonoGame CI system. And then install it! Very cool.
The end result will be your Mac bot will have all the Pipeline tools an assemblies installed and ready to use.
Now if you want to just get the latest stable release you can use the following url.

First thing is to do a Nuget restore. For this project I am using the Remote Effect Pipeline extension from my previous post, so I need to make sure that package is in place. But if you are using MonoGame Nuget package you will need to do this as well.
Next step is to build the app, as normal. Rather than building the entire solution I am building a specific project. But if you want to build both iOS, DesktopGL etc you can setup a configuration in the Solution which just builds those projects.

Thats it!

Not much too it is there. If you have an open source project (or a closed source one) there is absolutely no reason not to setup some sort of Continuous Integration.

One of the issues MonoGame Mac (and Linux) developers face is not being able to build shaders. Getting a good shader HLSL compiler to work on a non Windows platform is tricky. Work is under way to get this done but it will take some time to get right.

That leaves Mac (and Linux) developers a bit stuck. Well there is a solution, a custom Content Pipeline processor. This is where the Content Pipeline can show its pure awesomeness.

The Problem

Lets break it down, we have a shader we can to build. But we MUST build it on a Windows box. One way is to do it manually, but doing stuff manually is dull. Rather than opening a Virtual Machine and copying compiled .xnb files about, I wrote a pipeline extension. Its goal to take the shader code, send it to the Windows box. Compile it and send the result back to be packaged into an .xnb.

The Solution

MonoGame has a tool called 2MGFX. This is the underlying tool which takes HLSL .fx files and compiles them to HLSL or GLSL. So what I did was create a service which just shells out to the tool and gets the compiled code (or errors). We then return the results and use the existing packaging process to produce the .xnb file or throw an error. Then I went one further. Hosted the server in Azure, which saves me having to boot my VM each time I want to compile a shader.

The resulting processor code for this is quite simple. The new class is derived from EffectProcessor. You will see that if we are running the processor on Windows we just fall back to the default EffectProcessor code. Which means you can use the same Processor on Mac and Windows.

One restriction at this time is that the .fx file needs to be self contained. In other words you cannot use include’s or have code in external files. One this I could do is plug in the MonoGame Effect pre-processor to pull all of those includes into one file. But that is a job for the future (or a PR 🙂 )

Pretty simple code isn’t it! At some point I’ll see if we can replace the .Result code with async/await. But I’m not entirely sure how the Pipeline will respond to that.

Using InfinitespaceStudios.Pipeline

Using this extension could not be easier.

If you want to use the default service

Open your project and find the Packages Folder. Right click and select Add Packages.

This will open the Nuget search Dialog. Search for “InfinitespaceStudios.Pipeline” and add the Package.

Once the package has been added. Open the Content.mgcb file in the Pipeline Editor.

Select the “Content” node and then find the References property in the property grid. Double click the References property to bring up the Add References Dialog.

Search for the “InfinitespaceStudios.Pipeline.dll” and Add it by clicking on the “Add” button. Note this should be located in the “packages\InfinitespaceStudios.Pipeline.X.X.X\Tools” folder. Once that is done, Save the Content.mgcb. Close it an re open it (there is a bug in the Pipeline Tool). The select the .fx file you want to change.

Select the Processor property and in the drop down you should see “Remote Effect Processor – Infinitespace Studios”. Select this Item.

If you are using the defaults just Save the Content.mcgb. Close the Pipeline tool and Build and Run you app. It should compile without any issues. If there is a problem with the .fx file the error will be reported in the build log.

If you are using a Custom Azure site or the Local Service on a Windows box you can use the RemoteAddress , RemotePort and Protocol properties to change the location of the server. Valid Protocol values are “http” and “https” if you have a secured service. The RemoteAddress can be a CNAME or IP address.

Conclusion

Hopefully this post has shown you what a cool thing the Pipeline system is. One of my future posts will be about creating a pipeline extension from scratch. So if you are interested watch out for it. In the mean time, if you are a mac user. Get compiling those shaders!

In the past it might seem that Windows users of MonoGame get all the cool stuff, and Mac / Linux users are left out in the cold. To be honest for a while that was true, but the great news is that more recently that has begun to change. On going community efforts have resulted in both MacOS and Linux installers which will download and install templates into the Xamarin Studio and MonoDevelop. They also install the Pipeline tool which is a GUI you can use to build your content for your game.

All that was great, but again Windows has something that Mac and Linux developers just didn’t have access to. Automatic Content Building, this is where you just include the .mgcb file in your project, set its Build Action to “MonoGameContentReference” and providing you created the project via one of the templates it would “just work”. Your .xnb files would appear as if by magic in your Output Directory without all that messy manual linking of .xnbs.

So how does it work.. Well to fully understand we need to dig into MSBuild a bit 🙂 I know recently I’ve been talking about MSBuild allot but thats because in my day job (@Xamarin) I’m dealing with it ALLOT! So its topical from my point of view 😉

So if you dig into your csproj which was created in Visual Studio via one of the MonoGame templates you will see a number of things. The first is a <MonoGamePlatform> element. This element is used later to tell the MGCB (MonoGame Content Builder) which platform it needs to build for. Next up is the <MonoGameContentReference> element which will contain a link to the .mgcb file.. This again is used later to tell MGCB which files to build. Note that you are not just limited to one of these. If you have multiple assets and different resolutions (e.g @2x stuff for iOS) you can have a separate .mgcb file for those and include that in your project. The system will collect ALL the outputs (just make sure they build into different intermediate directories).

The last piece of this system is the “MonoGame.Content.Builder.targets” file. This is the core of the system and you should be able to see the Import near the bottom of your .csproj. This .targets file is responsible for going through ALL the MonoGameContentReference Items in the csproj and calling MGCB.exe for each of them to build the content, it will also pass

/platform:$(MonoGamePlatform)

to the .exe to that it will build the assets for the correct platform. This is all done in the BeforeBuild msbuild event, so it will happen before the code is even built, just like the old XNA content references used to do. But this time you don’t need to do any fiddling to get this to work on a command line, it will just work. Now calling an .exe on a build in a .targets isn’t exactly magic, the magic bit is right here

This part is responsible for adding the resulting .xnb files to the appropriate ItemGroup for the platform that we are targeting. So in the case of a Desktop build like Windows, Linix we use Content. For iOS and Mac we use BundleResource and for Android we use AndroidAsset. Because we are doing this just before the Build process, when those target platforms actually build the content later they will pick up the items we added in addition to any other items that the projects themselves included.

Now the really interesting bit is that code above was not how it originally looked.. The problem with the old code was it didn’t work with xbuild, which is what is used on Mac and Linux. So it just wouldn’t work. But now the entire .targets file will run quite happily on Mac and Linux and have intact been included in the latest unstable installers. So if you want to try it out go and download the latest development installers and give it a go.

If you have an existing project and you want to upgrade to use the new content pipeline system you will need to do the following

Open your Application .csproj in an Editor.

In the first <PropertyGroup> section add <MonoGamePlatform>$(Platform)</MonoGamePlatform>where $(platform) is the system you are targeting e.g Windows, iOS, Android.

Because we love seeing indie games succeed, Xamarin wants to support indie game developers all over the world in bringing their games to billions of mobile gamers. We want every indie game developer to enjoy the power of C# and Visual Studio, so we have an amazing special offer this December:

Indie game developers only need to have published a game in any framework on any platform to qualify.

This is just fantastic news. If you have an app already on one of the many stores you will qualify, this includes Xbox Live! So all you XNA developers out there with game now have the perfect opportunity to move that game to MonoGame and publish on iOS, Android ,Windows 10, MacOS and Linux or even Apple TV!*

It is worth noting as well that porting you app to a Windows 10 Universal app will also allow your game to work on Xbox One (in the app section).

This offer expires on the 31st of December at 9pm ET , so make sure you apply before the deadline expires.

The MonoGame team have been putting allot of effort into a cross platform content pipeline, but given that for the most part we support loading native assets like .png, .mp3, .wav why bother? Well it all boils down to a couple of words.. performance, efficiency. Lets look at an example, graphics are probably the biggest asset a game uses, they are also a major resource hog. Textures will probably take up most of the room in your deployment and will be taking up most of the memory on your device as well.

Textures

So lets say we have a 256×256 32 bit .png texture we are using in our game, we don’t want to bother with all this compiling to .xnb rubbish that people do, so we just use the texture as a raw .png file. On disk .png is very impressive in its size, that image probably only takes up 2-5 kb on disk, keeping your application package size down. Great!

Now lets go through what happens when we load this .png from storage on a device (like an iPhone). Firstly its loaded from storage into memory and decompressed/unpacked from its compressed png format into raw bytes. This is done because the GPU on your device doesn’t know how to use a png image directly, it can only use certain types of compression. So we unpacked the image into memory, this is 262,144 bytes , 256x256x4 , the x4 is because we have 1 byte per channel Red, Green, Blue and Alpha. Note that 262 KB is quite a bit bigger than the compressed size. The next thing to do is create a texture for that data, because your device can’t compress on the fly (yet) it has to use that data as is. So in creating the texture we used 262kb of graphics memory on the GPU. That doesn’t sound too bad, but if you are using larger textures say 1024×1024 then you are using 4 MB of GPU memory for that one texture. Multiply that over the number of textures in your game and you soon run out of texture memory on the GPU. Then the GPU has to swap that data out into system memory (if it supports that) or throw an error when you try to create textures that won’t fit into available memory. So to sum up using

.pngs = smaller package size & higher memory usage & less textures

Now let look at a texture pre-processed using the content pipeline, because we know we are targeting iOS we know the GPU’s on those devices support PVRTC texture compression directly. So lets take our sample .png and compress that using PVRTC, what we end up with is a 32kb file (size depends on the texture,alpha channel etc). Hmm that is allot bigger than the .png on disk but that is not the whole story. The difference is there is no need to unpack/decompress it which saves on load time, also we can create a texture from that data directly so we only use 32kb of texture memory on the GPU not 262kb. That is a massive saving.

Now we just looked at iOS, but the same applies to desktop environments. Most desktop GPU’s support DXT texture compression so the content pipeline will produce DXT compressed textures which can be loaded and used directly. The only platform which is a pain is android, because android does not have consistent support for compressed textures at the moment MonoGame has to decompress DXT on the device and use it directly. However even android will be getting compressed texture support. There is currently a piece of work happening where the pipeline tool will automatically pick a texture format to use, so for opaque textures it will use ETC1 (which is supported on all android devices but doesn’t support alpha channels) but for textures with a alpha channel it will use RGBA4444 (dithered) but also allow the user to pick from a wide variety of compression options manually such as PVRTC, ATITC, DXT/S3TC, ETC1 and RGBA4444. This will give the developer the choice of what to use/support.

Audio

Now lets look at audio. All the different platforms support different audio formats, if you are handling this yourself you will need to manually convert all your files and include the right ones for each platform. Would a better option be to keep one source file (be it .mp3, .wmv etc) and convert that to a supported format for the target platform at build time? Ok it makes for longer build times, but at least we know the music will work. MonoGame uses ffmpeg to do the heavy lifting when converting between formats as it can pretty much convert any type to any other type which is really cool.

Shaders

This is an area that causes real pain, custom shaders. There are a number of shading languages you can use depending on the platform you are targeting. For OpenGL based systems that is GLSL, for DirectX based systems its HLSL, there is also CG from nvidia. The Effect system in XNA/MonoGame was designed around the HLSL language. It is based around the .fx format which allows a developer to write both vertex and pixel shaders in one place. Historically both GLSL and HLSL have separate vertex and pixel shaders, HLSL until recently compiled and linked these at build time, GLSL does this at runtime. Now without a content pipeline or some form of tooling a developer would need to write two shaders, one for HLSL and one for GLSL. The good news is the MonoGame MGFX.exe tool can create a shader from an .fx format and have that work on GLSL. It does this by using an open source library called libmojoshader, which does some funky HLSL to GLSL instruction conversion to create OpenGL based shaders but rather than doing that at runtime we do it at build time so we don’t need to deploy mojoshader with the OpenGL based games. All this saves you the hassle of having to write and maintain two shaders.

Now the drawback of MGFX is that is only runs on a windows box at the time of writing. This is because it needs the DirectX shader tooling to compile the HLSL before passing it to libmojoshader for conversion (for OpenGL platform targets). There is a plan in place to create a version of the .fx file format which supports GLSL directly so people who want to do custom shaders on a Mac or Linux can do, but this is still undergoing development so for now you need to use a windows box.

Models

For the most part the model support in XNA/MonoGame is pretty good. XNA supports .x, .fbx files for 3D models, MonoGame, thanks to the excellent assimp project supports a much wider range of models including .3ds. However some of these formats might produce some weirdness at render time, only .fbx has been fully tested. Also note that assimp does not support the very old format .fbx files which ship with most of the XNA samples, so you’ll need to convert those to the new format manually. On nice trick I found was to open the old .fbx in Visual Studio 2012+ and then save it again under a new name. Oddly VS seems to know about .fbx files and will save the model in the new format :).

Now what happens when you use a 3D model is that it is converted by the pipeline into an optimised internal format which will contain the Vertices, Texture Coordinates and Normals. The pipeline will also pull out the textures used in the model and put those through the pipeline too, so you automatically get optimised textures without having to do all of that stuff yourself.

Summary

So hopefully you’ve got a good idea on why you should use the content pipeline in your games. Using the raw assets is ok when you are putting together a simple demo or proof of concept but sooner or later you will need to start optimising your content. My advice would be to use the Pipeline tooling from the outset so you get used to it.

So in one of my previous blog posts we covered how to scale your game for multiple screen resolutions using the matrix parameter in the SpriteBatch. Like all good problems that was just one solution or many, and since then things have moved on a bit. While that technique is still valid, the bits we did about scaling the Touch Points are no longer really necessary. In this post we’ll discover how to use the MonoGame Touch panel to get scaled inputs for touch and mouse as well as how to use RenderTargets to scale your game.

What is a Render Target?

Ok so your new to gaming and you have no idea what this “RenderTarget” thing is. So at its simplest a RenderTarget is just a texture, its on the GPU and you can use it just like a texture. The main difference is you can tell the rendering system to draw directly to the RenderTarget, so instead of your graphics being drawn to the screen its drawn to the RenderTarget. Which you can then use as a texture for something else, like a SpriteBatch. Pretty cool eh 🙂

Scaling your game

While RenderTargets are really useful for things like Differed Lighting and other shader based things, in our case we just want to use it to render our game. Supporting lots of different screen sizes is a pain, especially when doing 2D stuff, if you are supporting both Mobile and Desktop/Console you will need to support screen resolutions from 320×200 (low end android) to 1080p (HD TV) or bigger.. That is a huge range of screen sizes to make your game look good on. Quite a challenge.

So in our case rather than scaling all the graphics we are going to render our entire scene to a RenderTarget at a fixed resolution in this example 1366×768. Having a fixed resolution means we know EXACTLY how big our “game screen” will be, so we can make sure we have nice margins and make the graphics look great at that resolution. Once we have our scene rendered to the Render Target we can then scale that to it fits the device screen size. We’ll introduce letter boxing support so we can keep the correct aspect ratio like we did in the previous blogs.

So lets look at some code.

Creating a Render Target in MonoGame is really easy, we add the following code to the Initialise method of our game

As you can see we tell the GraphicsDevice to use our RenderTarget, we draw the game, then tell the GraphicsDevice to not use any RenderTarget. We can how just use a SpriteBatch as normal to draw the RenderTarget to the screen. The following code will just draw the RenderTarget in the top left of the screen without scaling

However what we really need to do before we draw the RenderTarget is calculate a destination rectangle which will “scale” the RenderTarget so it fits within the confines of the screen, but also maintain its aspect ratio. This last bit is important because if you don’t maintain the aspect ratio your graphics will distort.

So first this we need to do is calculate the aspect ratio of the RenderTarget and the Screen

Next we need to decide if we calculate the destination rectangle, but we need to add a “letter boxing” effect. these are black bars at the top and bottom of the screen (or to the left and right) which fill in the missing area so that we maintain aspect ration. Its a bit like watching a Wide Screen movie on an old TV, you get the black bars at the top and bottom. The code to do this is as follows

You can see from the code we calculate how much to offset the rectangle from the top and bottom/left and right of the screen to give the letterbox effect. This value is stored in barHeight/barWidth then used as the Top or Left values for the rectangle. The presentWidth/Height is the height of the destination rectangle. The width/height of the rect will match the ClientBounds depending on whether we are letter boxing at the top/bottom or left/right.

So with the destination rectangle calculated we can now use the following to draw the RenderTarget

Note we clear the background black before drawing to get the nice black borders. You can change that colour to anything you like really.

What about scaling the Input?

By using a fixed size render target we will need to do something about the Touch input. Its no good on a 320×200 screen getting a touch location of 320×200 and passing that into our game world which we think it 1366×760 as it won’t be in the right place. Fortunately MonoGame has an excellent solution

TouchPanel.DisplayWidth = 1366;
TouchPanel.DispalyHeight = 768;

By setting the DisplayWidth/Height on the TouchPanel it will AUTOMATICALLY scale the input for you.. That is just awesome! But wait for it .. it gets even better. You can also easily turn the Mouse input into Touch input which is handy if you’re only interested in left click events.

TouchPanel.EnableMouseTouchPoint = true;

Now any mouse click on the screen will result in the Touch event. This is great if you want to debug/test with a Desktop app rather than messing about with mobile devices.

Things to Consider

This is all great but to be honest scaling a 1366×768 texture down for 320×200 will look awful! So you need to be a bit smarter about the RenderTarget size you pick. One solution might be to detect the screen size and scale down the render target but factors of 2 (for example) and use smaller textures. For example at full resolution 1366×768 you use hight res textures (e.g @2x on iOS) but on lower resolution devices you use a RenderTarget of half the size of your normal one and normal sized textures. Obviously you will need to scale your games physics (maybe) and other aspects to take into account the smaller area you have to deal with.. or make use of a 2d matrix camera.

The point being that smaller devices don’t always have the same capabilities are larger ones so you need to keep that in mind.

Its finally done, the Pipeline tool is now working on OSX (and Linux). Over the christmas break I worked with another MonoGame contributor (@cra0zy) to finish off the Tool and build the Mac OS Installer.

The app itself behaves like the one on Windows so we have a fairly consistent experience. The command line tool MGCB is bundled with the App so you can use the following as part of a build process

You can compile Textures, Fonts, 3D Models and Audio using this tool and the requirement to have XNA installed is totally gone. You can also use your own content processors and importers, exactly how you do that will be a topic of a future post 🙂

A few things to keep in mind.

There might be a few issues with Audio/Song’s atm, the MonoGame guys are looking to move over to using ffmpeg to get a better cross platform experience.

Only the newer .fbx file format is supported. If you are trying to use older models from the original xna samples they will need to be upgraded first. This can be done using either the Autodesk tools or just by opening the .fbx in visual studio 2013+

There is however one thing missing completely, Effect compilation. Because of dependencies on DirectX the 2MGFX tool cannot be ported to Mac (or Linux) at this time. There is a plan to implement a GLSL style version of the HLSL .fx format which will allow Mac and Linux (and Windows) developers to use GLSL in their shaders rather than HLSL. This will be designed to work cross platform from the outset. For now Effect files will need to be compiled on Windows.

Even with this functionality missing this is still an extremely useful tool, I would highly recommend anyone using MonoGame on a Mac to check it out.

Pipeline Tool on OSX

Don’t forget, MonoGame is a community driven project. The community is extremely friendly and helpful, so don’t be scared to join in.

Some of you might have heard that MonoGame now has its own content pipeline tooling, and it works! As a result the need to install the XNA 4.0 SDK is no longer required, unless you want to target Xbox 360 of course. For those of you looking for documentation on the new tooling you can head over to here for information on the Pipeline GUI and here for information on the MGCB tool. But I’ll give you a basic overview on how this all hangs together.

MGCB.exe

This is a command line tool used to create .xnb files. It works on Windows and Mac (and Linux for some content AFAIK). On windows at the time of writing you will need to download the latest unstable release from here to install the tooling. It installs the tools to

c:\Program Files (x86)\MSBuild\MonoGame\Tools

On a Mac you will need to get the source and compile this tool yourself. I am working on an add-in for Xamarin Studio which will install this tool for you, if I can figure out how to do it I’ll also knock up a .pkg file to install the tooling in the Applications folder too.

Using the tool is very simple you can either pass all your parameters on the command line like so

The other option is to create a .mgcb response file which contains all the required commands.

Now a .mgcb file has some distinct advantages. Firstly its compatible with the Pipeline GUI tooling, secondly it allows you do process a bunch of files at once and still have a nice readable file rather than a HUGE command line. Here is a sample .mgcb file

This will process the file and build your content, again on a Mac prefix the command with ‘mono’

Note that in in both cases I passed the /platform parameter and used the $(Platform) macro’s in the command line and the response file. This allows me to produce different content per platform. A good example of this is with textures, to get the most out of the iOS platform its best to produce PVRTC compressed textures. MGCB knows which texture compression works best on each platform and will optimise your content accordingly, as a result an .xnb build for iOS won’t work on Android. Well it might but only if the GPU on the device supports that texture compression. In reality its best to compile your content for each platform, that said for desktop platforms (Windows, Linux, Mac) you can get away with using the same content as most GPU’s on desktop PC’s/Mac support DXT texture compression.

Those of you familiar with XNA will have noticed familiar ‘processorParam’ values in the sample response file above. The great news is that all the various processor parameters on the various processors you had in XNA are also available in MonoGame.

Pipeline.exe

This tool is just a GUI over the top of MGCB.exe, currently its only available on windows, but it is being ported to Mac and Linux. When you create a new project file it creates an .mgcb file which to totally compatible with the response file mentioned earlier. So you can hand edit it, or use the tooling its up to you. The Pipeline tool is in the early stages of development but its already useful enough to allow you to replace the existing XNA content projects.

I’m not going to go into the details of how to use the Pipeline tool as it’s covered pretty well in the documentation. Like the MGCB tool it is included in the latest unstable installers and can be found in

c:\Program Files (x86)\MSBuild\MonoGame\Tools

It was a conscious decision on the team’s part NOT to go down a tightly integrated MSBuild style solution for content processing. At the end of the day a stand alone console app gives the developer allot of flexibility on how they want to integrate content processing into there own build processes (some of you might just want to use Nant, ruby, make or some other build scripting tooling). That said there are some .targets files available for those of you who wish to make use of msbuild.

That said, the other nice thing is the Pipeline GUI tool has an import function (on windows) to import and existing XNA .contentproj file into a .mgcb file. So if you want to upgrade your existing projects to use the new tooling there is an easy route.

Custom Content Processors

Now one of the fantastic things about the XNA content pipeline was the ability to extend it. The great news is that MonoGame supports that too, in fact the changes are if you have an existing XNA custom content processor (or importer) if you rebuild it against the MonoGame content pipeline assembles which are installed as part of the installer it should “just work”. At some point I’m sure templates for both Visual Studio and Xamarin Studio will be available for those of you wanting to create your own processors.

Things to remember

It is worth remembering that all of the work done on MonoGame is done in spare time and for free! So if there is a feature that doesn’t work or hasn’t been completed yet please remember that people work on this project because they love doing it they also have day jobs , families and other commitments.

One good example of this is the content processing on a Mac (and Linux), for the most part it will work for Textures, Models, Fonts and Audio (mostly) it will work fine, but there is no installer. Also shaders will NOT work, this is mainly because HLSL is just not supported on a Mac (On a side note the team are abut to embark on a project to support GLSL in the .fx file format which will allow users on a Mac to write their shaders using GLSL but at the time of writing if you use custom shaders you will need to compile those on a windows box).

People might be tempted to start complaining about how ‘it doesn’t work on a Mac or Linux’ and yes the support for those platforms is lagging behind the windows support (mostly due to a lack of contributors on those platforms). But we are working on it so please be patient and if its a feature you really really really want and no one seems to be working on it please feel free to ‘go fork and contribute’, just let the team know what you are up to so two people don’t end up working on the same thing.

So as you may have noticed I’ve been playing about allot with OpenGL and android recently and I started to see some very weird behaviour. The normal activity life cycle states that when the lock screen is enabled, the activity will be Paused, then Stopped. This seemed to be the behaviour I saw in the devices I was testing on until I tried a Nexus 4.. On lock it would Pause, Stop then Destroy.. WFT! and it would only do this on the Nexus 4.

This caused me a big problem because the app I was putting together was a game, so if the screen locked in the middle of a game it wouldn’t just pickup from where it left it would restart the entire app and loose your progress… Not happy.. So I spent ages looking at my code to try to figure out what was going on and I stumbled across the following property when messing about in my OnDestroy method of the Activity.

this.ChangingConfigurations

this.ChangingConfigurations

Hmm, what was that property about. Well it turns out this property tells you which configurations changed. When I looked at this when in my OnDestroy method I was it had a value of ScreenSize… Hmm A bit more research lead me to this from the android docs.

Caution: Beginning with Android 3.2 (API level 13), the “screen size” also changes when the device switches between portrait and landscape orientation. Thus, if you want to prevent runtime restarts due to orientation change when developing for API level 13 or higher (as declared by the minSdkVersion andtargetSdkVersion attributes), you must include the "screenSize" value in addition to the"orientation" value. That is, you must decalareandroid:configChanges="orientation|screenSize". However, if your application targets API level 12 or lower, then your activity always handles this configuration change itself (this configuration change does not restart your activity, even when running on an Android 3.2 or higher device).

So now it all makes sense.. When the nexus 4 (Andoid 4.3) was screen locking it was changing the Orientation to Portrait (helpful..not) which I was handling, but also raising a screen size config change, which I was not.. hence the OS destroying my activity. Normally when you get a new OpenGL based app in Xamarin.Android you get the following attributes added automagically to your activity.

These tell android that you want to handle these changes and not the OS, so the OS doesn’t restart you app when this stuff happens. Because of this change in Android 3.2+ we need to add the ScreenSize enumeration as well like so

In my previous post we looked at how to modify the ScreenManager class to support multiple resolutions. This works fine but what we also need is a way to scale the inputs from the Mouse or TouchScreen so that they operate at the same virtual resolution as the game does.

We already put in place the following properties in the ScreenManager

property Matrix InputScale …..property Vector2 InputTranslate …..

property Matrix InputScale …..
property Vector2 InputTranslate …..

InputScale is the Inverse of the Scale matrix which will allow use to scale the input from the mouse into the virtual resolution. InputTranslate needs to be used because we sometimes put a letterbox around the gameplay area to center it and the input system needs to take this into account (otherwise you end up clicking above menu items rather than on them).

So we need to update the InputState.cs class which comes as part of the Game State Management example. First thing we need to do is to add a property to the InputState class for the ScreenManager.

public ScreenManager ScreenManager
{get;set;}

public ScreenManager ScreenManager
{
get; set;
}

and then update the ScreenManager constructor to set the property.

input.ScreenManager=this;

input.ScreenManager=this;

Now we need to update the InputState.Update method. Find the following line

CurrentMouseState = Mouse.GetState();

CurrentMouseState = Mouse.GetState();

We now need to translate and scale the CurrentMouseState field into the correct virtual resolution. We can do that my accessing the ScreenManager property which we just added, so add the following code.

This bit of code transforms the current mouse position and then scales it before creating a new MouseState instance with the new position values, but the same values for everything else. If the ScrollWheelValue is being used that might need scaling too.

Next stop is to scale the gestures, in the same Update method there should be the following code