Believe me, comparing ExEn to a well crafted clock is neither an exaggeration nor a compliment. It’s a solid truth. I once again realized this fact. For a few days, I’ve been trying to port my new game to MonoGame. And I succeeded it at last. But the result is appalling. First of all, it crashes very frequently; font rendering is unacceptably bad, the application starts very slowly (I think because of the large XNB files). I’m not listing other problems that might be solved in the process. So I decided to stay with ExEn. MonoGame is not an option. If I can’t live with ExEn, I consider switching to Unity or to similar engines.

This puts a smile on my face

First of all, because ExEn has achieved its original goal: to be a replacement for MonoGame that developers would love using. The community entrusted me with over $10 000 of crowd-funding to make this happen. It happened. Thank you.

And also, because I appreciate the recognition of the craftsmanship that I put into my code. I don’t know much about clockmaking, but I imagine that master clocksmiths work to a similar philosophy: elegant, functional, precise, integral. It would be foolish to say that my code is absolutely these things – but when I fire up my IDE, this is always the aspiration.

~

The email goes on to say that the only problem with ExEn is the iPad 3 retina font bug. In an earlier blog post I described it as finally triggering my long-time-coming decision to retire from ExEn.

I am now happy to say that the iPad 3 font bug in ExEn is fixed!

This garbled text is no longer a problem. If you have an iPad game using ExEn up on the App Store, I recommend you update ASAP. You can get the latest version of ExEn from CodePlex.

This fix comes with a big thanks to Michael Falk, who originally reported the bug (in his game Ms. Particle-Man – show him your appreciation by buying it!) and who has been helping me narrow down the cause and the fix.

I should say that this fix is only a band-aid. Neither myself or Michael have an actual iPad 3, and the bug is apparently hardware-only. Not having an iPad 3 means that I haven’t been able to test this fix up to the standard that I usually keep for ExEn. But it has been verified to work by a few people.

My understanding of the issue is that there is an underlying problem with the way ExEn sets up its retina-display surface. If I somehow get my hands on an iPad 3, I will do a proper investigation and produce a proper bug fix.

I know this is not really what you might expect for someone who just retired from a project. But until MonoGame get their act together, I still feel a responsibility to ExEn users – like the gentleman who sent me that email – to keep their games running smoothly.

They invited me to submit a patch. But that won’t work. I don’t have the time to produce one. And, given that ExEn was made with different priorities to MonoGame, I don’t want to go in and wholesale replace large chunks of code. An integration of ExEn code probably needs to be done with more sensitivity than that – something I have even less time to do.

(While the wholesale replacing of large chunks of MonoGame is a possibility that I would gladly support myself, or even using ExEn as a new base for new MonoGame features, such action is a complicated process that would require the buy-in of all the major MonoGame developers, and great care in ensuring that none of their newer features break in the process.)

So it will be up to the MonoGame developers to scavenge what they find useful.

I’ve been chatting on the MonoGame IRC channel about their code, in an effort to reach a shared understanding of what in ExEn could be useful for MonoGame. Rather than have the knowledge be lost in the chat log, I’m going to write this brief guide to what features ExEn contains.

(I’m also rather sick today, so this gives me a nice low-energy-but-useful thing to do, while I hang out on IRC.)

If you have any questions about any of these, I would be thrilled to answer, and also to update this document to clarify anything.

~

In no particular order…

Project Organisation: (I don’t think my project organisation is ideal – MonoGame’s is just as good. I just mention it here to help you find your way around.)

ExEn is divided up into the “core” classes (ExEnCore) that are not dependent on anything else. This is usually maths stuff and data structures. The “common” code (ExEnCommon), which contains code that is common to all platforms that has dependencies such that it can’t be put in ExEnCore (often in the form of partial classes containing the platform-independent parts of a given class). And finally the platform-specific code for various platforms (ExEnSilver, ExEnEmTouch and ExEnAndroid).

ExEn ReflectAndCompare: This is a tool I made that uses reflection to test compatibility between XNA and the ExEn library. Not only does it test the classes, properties, methods and fields match, but it also pushes a whole lot of data through the methods on each class to check that the output matches. This is an internal tool, not really suitable for mass consumption, but it is extremely useful for checking implementation accuracy. It is available on CodePlex here, outside of the main ExEn repository.

Maths Types in ExEnCore: I’m not sure how different these are to the types in MonoGame – MonoGame is likely to have a more complete implementation of the XNA maths types. But the types and methods that are in ExEn have been extensively tested with the aforementioned ReflectAndCompare tool.

ExEn Types Don’t Allocate Memory When They Shouldn’t: In MonoGame KeyboardState allocates an array where ExEn correctly uses a bit-field (ExEnCore/Input/KeyboardState.cs). In MonoGame TouchCollection is a reference type deriving from List (so it allocates) whereas ExEn correctly implements IList on value-type fields (ExEnCore/Input/Touch/TouchCollection.cs).

If a user of MonoGame were to copy one of these types, their game would behave incorrectly. In ExEn their behaviour matches XNA perfectly.

This is an excellent opportunity to just drop the ExEn types into MonoGame. It’s low-impact and the ExEn code is unarguably better.

I suspect that there may well be other types in MonoGame that are exhibiting allocation behaviour that does not match XNA.

TouchPanel bug fixes: As well as the above, ExEn implements correct thread safety and allocation behaviour for TouchPanel (ExEnCommon/Input/Touch/TouchPanel.cs).

Drift-Smoothing ExEn Game Loop: ExEn has a shared GameLoop type that smooths out incoming ticks from the operating system before they go to Game.Update and Game.Draw. This is similar to the behaviour of XNA (although does not match exactly). This prevents dropped or doubled frames that happen due to timer drift. (See ExEnCore/GameLoop.cs.)

Automagic Retina Display Handling: One neat feature of ExEn is its ability to allow games to take advantage of the iOS retina display, without having to modify any code (just provide higher resolution assets). There are a number of components that go into this:

First of all, the ExEnScaler (ExEnCore/ExEnScaler.cs) is responsible for all of the transformation maths. It uses fractional maths (ExEnCore/ExEnFractionMaths.cs) so that it is always pixel perfect – it doesn’t suffer from floating-point precision issues. (This could be expanded to allow arbitrary “virtual” backbuffer sizes – something I never got around to.)

Then the View and View Controller (ExEnEmTouch/ExEnEmTouchGameView.cs) and the iOS GraphicsDeviceManager are responsible for setting up the backbuffer and ExEnScaler to the correct sizes. The code flow is a bit complicated because it goes through iPhoneOSGameView. But there are lots of comments, “Find All References” is your friend, and I can help via email if need be.

Finally, the Texture2D and SpriteFont loaders on iOS (ExEnEmTouch/BuiltInLoaders.cs) will load up “@2x” versions of those assets when required. To the user these Texture2Ds and SpriteFonts appear to be of normal size, but under-the-hood they provide retina-sized data.

Faster Fonts and Automatic Retina Font Generation: ExEn font data is generated with the ExEnFontShim XNA content pipeline extension. This generates PNG and custom binary metrics files for sprite fonts, as well as automatically creating “@2x” versions of the fonts suitable for retina displays.

These fonts can be loaded on the device much, much, much faster than trying to decode an XNB font. Especially if the fonts are DXT3 compressed  (which XNB fonts are by default).

Seamless Orientation Handling: The ExEnScaler is also capable of handling orientation changes. Although this is only used on iOS, and only because ExEn was written to support iOS < 4.2 where it was necessary to handle orientation yourself for performance reasons (ExEn blocks iOS from modifying the view orientation).

ExEn implements orientation as-per XNA on WP7. Most of the magic happens in ExEnEmTouchGameView.cs and ExEnAndroidSurfaceView.cs on iOS and Android respectively. It has special handling for the upside-down orientation on iPad.

The ExEn Orientation sample demonstrates orientation changes working correctly. In particular it handles transitioning from the iOS splash screen in any orientation at startup without any flicker (try restarting the app in different orientations).

Custom SurfaceView on Android that Doesn’t Crash: When I was making the Android version of ExEn, Mono for Android had a bug where the built-in game view in its OpenTK implementation would crash. From memory it is because it didn’t handle the activity pausing correctly (amongst other things). ExEn on Android provides a complete and correct implementation of OpenGL initialisation on Surface View (ExEnAndroid/ExEnAndroidSurfaceView.cs), covering all the OpenGL and multi-threading complexities.

Backgrounding Doesn’t Crash on iOS: It seems like MonoGame will crash on iOS (on the device) when the game gets backgrounded. ExEn doesn’t crash because it correctly pauses the game loop without touching the frame buffer. (ExEnEmTouch/ExEnEmTouchApplication.cs is a good starting point, also look at how isPausing is used in ExEnEmTouchGameView.cs.)

ExEn exposes a custom API (Game.OnEnterBackground) for users who want to respond to backgrounding (say, by saving their data). Although it would be nicer to convert this to match the WP7 tomb-stoning API. (ExEn was started before WP7 came out.)

And ExEn also correctly implements activation/deactivation events (not to be confused with backgrounding). Not sure if MonoGame’s implementation is correct – but it does exist.

Total refactoring of the game and graphics stuff: ExEn better matches the way XNA uses classes like GraphicsDeviceManager, GraphicsDevice, GameWindow, etc. It also allows better sharing of code between platforms by putting common code into ExEnCommon.

The most important change is to turn GameWindow into a thin cross-platform class, moving platform-specific stuff into separate classes (ExEnEmTouchGameView.cs and ExEnAndroidSurfaceView.cs), which have then themselves been significantly improved.

The way ExEn uses GraphicsDeviceManager as the platform-specific way of handling graphics startup better matches the behaviour of XNA. Also ExEn’s order-of-method-calls correctly matches the behaviour of XNA – including rarely used (but still important) things like calling BeginDraw and EndDraw (and using the result).

ExEn has its own implementation of the Game Components code. It’s fully tested to ensure it matches the method-call order of XNA. (I think MonoGame has some bugs here still.)

It’s important to get the calling order of these methods correct – otherwise it can introduce subtle bugs into the library user’s game.

I know this isn’t an easy one to shift into MonoGame, as it would replace a lot of code. But perhaps it would be worth it, as these classes coordinate some of the advanced features in ExEn. And they would themselves bring in a lot of the fixes mentioned in this document.

Hardware Accelerated Music on iOS: ExEn does all its audio through the AudioQueue API, whereas MonoGame uses OpenAL.

For sound effects, ExEn’s code works ok (except that I never implemented panning). But I think OpenAL is a better choice for MonoGame – especially as their OpenAL code will work cross-platform.

(Not sure if MonoGame supports this, but ExEn has handling for restarting looped sound effects and music when returning from the background.)

However for music playback I would strongly advocate lifting that code from ExEn.

ExEn supports hardware accelerated music decoding – allowing compressed music to be streamed directly from flash memory to the hardware decoder. This will free up a lot of CPU and RAM for more useful things (software decoding compressed audio is slooooooow).

It also correctly supports the game going to and from background on iOS. It supports playing nicely with other music-playing applications (eg: the iPod app). It’s also properly thread-safe, unlike MonoGame’s implementation (especially the MediaPlayer class).

(In ExEnEmTouch, see SoundEffect.cs and SoundEffectInstance.cs for the nuts-and-bolts of decoding and playing audio. See AudioSessionManager.cs for properly setting audio categories. See MediaPlayer.cs for correct implementation of locking plus various minor bug fixes. Finally Song.cs - there’s not much to it.)

Audio Improvements on Android: Similar to ExEn on iOS. ExEn on Android uses SoundPool for sound effects and Android Media Player for hardware-accelerated music. It correctly handles stopping and restarting audio in progress when the activity is paused (sent to the background). It also is correctly thread-safe.

(In ExEnAndroid: See SoundEffect.cs and SoundEffectInstance.cs for SoundPool playback. See MediaPlayer.cs and Song.cs for Android Media Player playback. See ExEnAndroidActivity.cs for where pausing/resuming handling begins.)

CatGirls Testing Application: This is a series of graphical interactive unit tests for various ExEn features. It allows easy verification of features across each supported platform. It’s an XNA game so it should be easy enough bring it into MonoGame as a sample.

The Orientation sample is also worth bringing in to verify orientation behaviour, particularly at startup (see the section on Orientation, above).

Cross-Platform Pluggable ContentManager: The logic of the ContentManager class (ExEnCore/Content/ContentManager.cs) has been made cross-platform. Actual content loaders are pluggable. ExEn uses this for the platform-specific business of actually loading content files (e.g.: ExEnEmTouch/Content/BuiltInLoaders.cs).

End-users can use this as a simple way to add platform-specific methods of loading non-XNB content. (ExEn does not include an XNB reader, so other methods of getting Content Pipeline content into ExEn had to be devised.)

Various Cleanup: Many of the classes in ExEn have been neatly formatted. The named colours are split out of the main Color type (ExEnCore/Graphics/NamedColors.cs). Maths types are organised into cohesive sections.

Platform-agnostic parts of various classes are partial classes in the ExEnCommon area (removing a lot of the convolution required to share code between platforms).

For example: the common parts of the Game class make up 259 lines of code. The platform specific parts of the Game class on iOS are only 86 lines. On Android: 49.

Take a look at the files (here, here and here) to get a full appreciation of this.

ExEn seems to implement IDisposable more consistently and correctly than MonoGame.

Other Stuff: Perhaps the rendering code in ExEn could be ignored in favour of MonoGame’s rendering code. I hear you have made serious improvements in this area. Still it might be worth looking at my SpriteBatch and Texture2D classes for some ideas.

~

Have fun with my code! If you have any questions about it – please don’t hesitate to contact me!

Up until that point I had been singing the praises of XNA, not only because it is a really fantastic library, but because it had this cross-platform support.

Of course, once I actually tried to use XnaTouch and SilverSprite I quickly changed my tune. Quite frankly the libraries were atrocious. Unusable. Poorly coded, ugly, buggy and slow.

Appalled, I started work on ExEn. It started from an amalgamation of XnaTouch and SilverSprite, but ended up being a near-complete rewrite. ExEn was created to live up to my very high standards. It’s performant, it’s has very few bugs – and none as blatant as its forebears, and it has a design philosophy that puts usability for real game developers first.

Of course, there is a wide chasm between a library for my internal use, and a library that anyone can use. So last year I experimented with crowd-funding. Thanks to contributions from the community, I raised enough money to take the time to work on a public release of ExEn, plus adding support for the Android platform.

The development of ExEn did not go perfectly smoothly – no software development project does. Adding support for the amazingly obtuse Android platform was especially challenging. But I think I did a pretty good job, and for the most part I enjoyed working on it. And the people who have been using ExEn for their projects have sent me nothing but praise.

ExEn is currently the best platform for porting SpriteBatch XNA games to iOS and Android.

As an added side benefit, since first announcing ExEn online, I have had many offers of contract work developing and porting mobile games using ExEn as the platform. (Incidentally, if you’re looking for a skilled C# and iOS developer…)

Sadly, all good things must come to an end.

ExEn itself is not a financially viable project for me. Not even remotely. Even with the contracting work it brings in, time spent working on it is essentially a loss for me.

This comes particularly in the face of competition from MonoGame. What once started out as XnaTouch, buggy and ugly, was endorsed by the Mono folks, renamed to “MonoGame”, and has seen its development accelerate at a tremendous pace in the last year.

My understanding is that MonoGame is still significantly buggy. Even as recently as this month I’ve had developers tell me they are switching to ExEn because they found MonoGame unreasonably buggy. And in spite of ExEn being a higher quality platform, MonoGame continues to acquire features, users and support at a tremendous rate. Not to mention: bug fixes. The simple fact of the matter is that they have way more resources than I do. Time is eventually going to make their library better.

(And on the Silverlight front, Silverlight 5 brought with it an XNA-based API for hardware-accelerated immediate-mode rendering, rendering some of the cleverest bits of ExEn obsolete.)

But this has been going on for some time now. What has prompted this blog post is that the iPad 3 (sorry, “the new iPad”) came out and I got a bug report. ExEn apparently has a problem with its automagic retina-display fonts on the new iPad. I suspect the fix is simple. But I can’t check it myself – I don’t have an iPad 3. (I figure that my iPad 2 is still good. I’m actually using it to write this post while I clone my failing HDD – another story.)

[UPDATE: This bug is now fixed in ExEn 1.0.1, Details]

Here is a screenshot (iPad 2 and iPad 3)

[UPDATE: This bug is now fixed in ExEn 1.0.1, Details]

Now – I could buy a new iPad – a significant expense for me and basically a loss when I consider that I have an otherwise perfectly functional iPad 2.

I also strongly considered crowd-funding the purchase of a new iPad – and perhaps even (in a fairly literal sense) buying some time to improve ExEn. In crowd-funding terms it’s a fairly small amount of money. I considered this so strongly that I actually shot the video for it. This option would still be a loss – this time of time. I would have had to put a large amount of work into the funding rewards and the funding drive itself – more than it would have earned back.

I decided, after a lot of reflection, to do neither. While those plans would have worked this time around, they are not sustainable. I don’t have the spare time or money to pour into ExEn development on a long-term basis (I wish I did). Even with the contract work that ExEn brings in it isn’t worthwhile. And I expect ExEn contract work will gradually dry up as MonoGame gains ground.

So rather than heading down this dead-end path, I have decided that it’s time to wind things up.

(I’ll still do what I can to fix this particular bug. I just won’t be spending money or an excess of time to do so. If anyone has a patch, I’d be very grateful.)

~

I don’t want to leave ExEn developers completely in the lurch. First of all, feel free to email me if you have any questions or concerns.

If someone out there wants to simply buy me an iPad 3, I would be thrilled to get ExEn to work as seamlessly there as it does on every other iOS device. Send me an email if you’re keen. (I know this isn’t as trendy as a sexy video and a crowd-funding project, but it’s a heck of a lot easier.)

Finally – and this is by far the most important - if you are a MonoGame developer: Please steal my code!

I would love to be able to tell all the ExEn users that MonoGame is a worthy replacement. So if you work with MonoGame email me and maybe I can help you integrate the best bits of ExEn into your library. You don’t even need my permission – ExEn is open source. (I haven’t looked at your code base for a while – but I’d love to be presently surprised to find ExEn code already in there.)

(Update: read my next post about nice ExEn features you can have.)

(Alternately, if someone out there is interested in taking over the ExEn project – and you have the time and skill to devote to it – I’d be happy to hand it over.)

~

Thank you to everyone who has supported ExEn. Together we made some fantastic software.

See you in the next project…

By using ExEn, Michael has made Ms Particle-Man available for iOS (App Store link) and as a browser-based game (website link). Michael also has the game running on Windows and Xbox 360.

ExEn lets you build and run your XNA (Windows, Xbox 360, Windows Phone) games on Silverlight, iOS and Android.

The short version is that Microsoft seems to have taken the DirectX SDK off its regular release schedule, and is instead rolling it into the Windows API. And that XNA is not a first-class citizen in Windows 8 (not supported by Metro or the Windows app store).

Promit’s conclusion is that this spells the end for XNA. In fact, ever since the //build/ conference, there has been a lot of doubt floating around about the future of XNA.

Based on what I know about the technology, I am a little more optimistic about XNA’s future.

XNA is based on DirectX 9. DirectX 9 doesn’t work on Metro (Microsoft’s new touch-friendly interface for Windows 8). It will still work on Windows 8, but will switch the interface to “classic mode” (aka: “the Desktop”). XNA would need to target a newer version of DirectX in order to work with Metro.

In XNA 4.0 (the current version) they dropped all of the DirectX 9-only features in anticipation of a future move to DirectX 10/11. But they’re still using DirectX 9, for two very good reasons:

One: DirectX 9 is the last version of DirectX that works on Windows XP (DirectX 10 and newer require Windows Vista and newer).

Two: Xbox 360 games are programmed using an API that is similar to DirectX 9.

XNA is, in essence, a wrapper around DirectX. There is nothing in XNA itself that requires any special “platform stuff”. There is absolutely no reason XNA should be on the critical path of Windows 8. Why should the already-risky Windows 8 risk waiting around for a DirectX 11-based XNA 5.0? XNA can easily be added later (along with app store support).

And this is exactly how XNA has worked in the past: XNA is an installable library, completely decoupled from DirectX and the core operating system.

It makes perfect sense that XNA is not a part of the initial launch of Windows 8.

My suspicion is that XNA 5.0 will be released with the new Xbox console, rumoured to be coming soon. I’m sure Microsoft is hoping that Windows XP will have finally gone away by then.

It is worth pointing out that Microsoft already has a partial version of XNA that runs on DirectX 11. It’s the Windows Phone 7 version, apparently. (It only supports the “Reach” profile, without custom shaders.)

Based on all these factors, it is my hope and prediction that XNA is simply in “stealth” mode ahead of a new, DirectX 11-based release. I recall a similar silence in the lead-up to XNA 4.0.

(And, failing all of that, I know someone who’s very good at porting XNA to unsupported platforms.)

The bug affected SpriteFont rendering on iOS devices with retina displays. If you have released a game using SpriteFont and this code (including if you are in the pre-release program), please be sure to update your game in the App Store.

Sorry about that Remember that ExEn is not yet officially released. You could say that it’s in “beta”. So these things will crop up occasionally. To get bug fixes as soon as they’re available, consider joining the pre-release program.

And I’m also wearing my gamedev.stackexchange.com shirt, which I received as a top user on that site.

Fun fact: I’m the top answerer of XNA questions on both Stack Overflow and Game Development SE.

ExEn is a port of Microsoft’s XNA API to iOS, Android and Silverlight. It is licensed under an open-source licence (MS-PL), so you can start using it to port your games right now, for free!

This version introduces support for Android. There are a few rough edges with Android support that I should mention: First of all the Android documentation isn’t done yet. The process for setting up a project for Android is similar to the process for iOS. Please take note that content for the Android platform needs to be set as “AndroidAsset” (and not “Content” as on other platforms).

And secondly: The code has not been tested on a wide variety of Android devices. Unlike iOS, Android suffers from fairly serious platform fragmentation and numerous weird device bugs. And I simply don’t have the resources to test it on enough devices. So please take note that ExEn for Android will not insulate you completely from the Android platform. It is up to you to test your game before releasing it – just as you would have to before releasing a normal Android game.

If you are using ExEn for Android, please send me an email and let me know how it goes. If you run into any device-related issues in ExEn, I’d be happy to work with you to try and fix them.

ExEn for Android requires a minimum of Android 2.1. However it should not be too difficult to modify it to target a 1.6 minimum if your project requires it.

And ExEn of course still supports iOS and Silverlight. This latest Public Preview version includes a number of improvements and bug fixes on those platforms. Most notably, ExEn now supports multi-touch (although not gesture recognition yet) on both iOS and Android.

If you would like to receive updates to ExEn as they are made, and to support the continued development of ExEn, please consider joining the ExEn Pre-release Program.

Jake writes:

It’s a port from a Windows Phone 7 XNA game Didn’t take long thanks to ExEn!

Congratulations on an excellent port, Jake!

You can play the Silverlight version of TriPeaks Solitaire here.