Saturday, 14 October 2017

The Ever-Changing Horizon

As of a few days ago, XAGE runs on .NET core.  What does that mean?  Let's have a quick and probably inaccurate history lesson.

.NET Core

In 2014 Microsoft announced they were open-sourcing .NET.  Their new direction involved splitting the framework, from the old monolithic windows-only .NET Frameworks and introducing the new fancy, cross-platform .NET Core.  While Microsoft committed to updating both, it was clear that they saw .NET Core as the future.

For a while everything was confusing.  The command line tools didn't work very well and were constantly being changed.  Microsoft toyed with using a new project.json file to replace the old xml-based *.csproj files, only to revert back again.  The documentation was initially poor and often out of date with each iteration.

With the release of NET Standard 2.0, things are looking considerably better.  The framework API now covers a much larger set of the existing functionality.  All key platforms can target this standard i.e. Windows, Mac, Linux, iOS & Android (via Xamarin) and UWP.  The tooling is now better, with support built directly into Visual Studio, by far the best IDE for development.

XNA, MonoGame & FNA

In 2006 Microsoft first released XNA, a simple framework built on top of .NET for making games.  The main draw was the ability to write games in C# and to target the Xbox 360 console.

A few years later, an open source implementation of XNA specifically for iOS appeared called XNATouch.  This later became MonoGame as the number of supported platforms grew and more developers became involved.

By 2013 Microsoft finally retired XNA.  The writing had been on the fall for a while, though its abandonment upset a great many hobbyist developers who had invested a lot of time and energy building their games upon it.  MonoGame and FNA stepped up to fill the gap.

FNA was a fork of MonoGame by Ethan Lee, using an SDL2 renderer instead of the unsupported OpenTK as used (then) by MonoGame.  One impressive aspect on FNA was its laser-focus on accuracy, which shows in the quality of the Linux and Mac ports it has produced (e.g. Fez, Roque Legacy).


At various points, XAGE has been built upon each of the above, including other implementations not mentioned here (e.g. Silversprite).  At the time of writing, MonoGame is used for its content building tools and handheld platforms.  FNA is used for the main desktop platforms.

With the recent support for .NET Core and potential plans for additional platform support (given the ubiquity of SDL2), the case for using FNA is strengthened further, though MonoGame remains an important and useful project.

Being able to use .NET Core solves distribution problems (no need to install the .NET framework, no complicated or brittle Mono binaries).  It also feels good to be back on the bleeding edge, which is a far cry from all the anxiety around XNA's protracted demise.

There remain some blockers for making the switch fully.  One being that XAGE uses Protobuild for creating all the relevant Visual Studio solutions and projects for the user.  Protobuild does not currently support .NET Core.

Regardless, we're in a pretty good position right now.  The big graphics rewrite started a year ago turned into a larger refactoring project that is resulting in a saner, more manageable codebase.  Once a few more reliability and usability milestones have been hit, we'll be looking to put out a release into the wild.

Wednesday, 15 March 2017

Xbox One Support

Since starting work on the big refactoring piece I haven't paid too much attention to broadening platform support. However, since Microsoft announced the Xbox Live Creators Program (essentially a replacement for the Xbox 360's Xbox Live Indie Games), I was curious to see how much effort it would be to get XAGE up and running on the Universal Windows Platform. It turned out to be this: two evenings, thanks to MonoGame v3.6.  Using the latest version of Protobuild, XAGE Editor will now automatically create a Visual Studio solution for UWP:

Some of the changes to the engine could be done without breaking anything, though some required introducing more preprocessor soup (#if #else #endif) due to breaking framework changes. Ideally once dotnet core matures then we can move towards NETStandard libraries for all platforms.
  • UWP forces all file IO to be asynchronous, so the simplest solution was to use a synchronous wrapper specifically for the WindowsUniversal libraries. 
  • Minor API changes were needed (e.g. replacing Delegate.CreateDelegate with MethodInfo.CreateDelegate, generic use of SystemException with System.Exception).
  • Replace all Stream.Close() with Stream.Dispose() where a using block is not used for automatic cleanup. 
  • Remove all errant use of System.Console.Write() for debugging.
  • Identifying the main UI thread using Task.CurrentId instead of Thread.CurrentThread.ManagedThreadId (access to threads is not exposed in UWP).
  • Inserting GetTypeInfo() into various reflection method calls and properties due to a very UWP specific workaround.
The result of this work is that XAGE now tentatively supports the Windows 10 Store and the Xbox One family of consoles. I've updated the list of supported platforms accordingly.

Not everything is quite implemented yet (serialization, audio etc) but I'll return to finish this up once the main refactoring is complete.