After over a year of work on what is now the MonoGame-SDL2 project, I've decided to pose a question to the XNA community. This is something really important, as it will affect development of this library permanently. Were this not such a major task, I'd probably just do it and leave it at that, but we're dealing with something positively huge.



For those who don't know, I'm the lead developer of a MonoGame branch called MonoGame-SDL2. Its main purpose is to provide an XNA reimplementation that is both accurate and portable enough to ship a single set of C# binaries on all target platforms without recompiling. The target platforms are primarily Windows/Mac/Linux, but the SDL2 base allows us to run in other places as well. It has shipped in nearly a dozen titles, including FEZ, Rogue Legacy, Dust: An Elysian Tail, the soon-to-be-released Escape Goat 2, and many others. So far it has done its job very successfully, despite being developed largely by one person, with a few contributions here and there from David Gow, Kevin Becker, and a couple other colleagues. Keeping up with MonoGame upstream has helped as well, but I'll be talking about that in a second.

The intention was to make this part of the standard MonoGame revision. As of now, that goal has not been met, and there are a number of reasons why. One of them has become a very serious blocker, which is why I am writing this today.

I am currently in the process of writing a brand new OpenGL renderer for MonoGame-SDL2, as the current renderer is simply inadequate; it's slow, not fully stable, and until recently was just plain incorrect in a lot of ways. There are/were a lot of places where it was abundantly clear that the original author simply did not know how to use OpenGL. So, as I begin work on much more graphically intensive titles, it's now time to get that fixed.

But this is not the first time I've had to do this. This is actually the third rewrite of a major component that I've done, basically stomping on whatever MonoGame upstream has been doing. The first was a brand new MonoGame platform based on SDL2 (the C# interop library, SDL2#, being something that I also had to write) and the second was a complete rewrite from scratch of the XACT runtime and SoundEffect engine. Keep in mind, this is in addition to the numerous other things I've modified in the library, many of which have not been merged into the upstream library. A pull request was submitted for the SDL2 platform in September of last year, but that has yet to be merged. I did not want to make another request for the XACT rewrite until the SDL2 platform was in. You may see where this is going.

Before hooking up my new OpenGLDevice into MonoGame, I took a look at the diffs comparing MonoGame-SDL2 to MonoGame's `develop` branch.

731 commits, 101 changed files, 13024 additions and 2451 deletions. That last statistic does not factor in the changes made within the 13 months that this has been in development. This does not even include the work I did that was merged into MonoGame.

A lot of work has gone into making sure that MG-SDL2 is easily mergeable into upstream, but between the above statistics and the upcoming work that will essentially trash a central hub that duct-tapes a lot of the varying platforms' code together, it's time to consider the other option before I start doing this OpenGLDevice stuff any further.



I am proposing a full fork of the MonoGame library into a brand new library that focuses solely on accurate XNA behavior, exclusively for open desktop platforms. This will instantly bring the platform list to one platform: SDL2. It will completely and fully remove ALL support for Windows 8 Metro, Windows Phone, Windows DirectX, PSM, iOS, and Android/Ouya. Only platforms supported by fully open technologies will be supported by this new library.

For the purposes of this post, I will temporarily call the new library "FNA". This may not be the final name if we decide to do this!

Before I get into detail of how FNA will work, I want to explain why I'm doing this, and what I need from developers to make this a successful project.

FNA NEEDS A COMMUNITY OF DEVELOPERS AND USERS! One problem MonoGame has, and a huge problem MonoGame-SDL2 has, is that there's simply not a community backing it. There are some devs hacking on it from time to time, but it's shocking when you compare the MonoGame community to the XNA community, even after Microsoft cut support for XNA. In order for this to work, I need people working on this. I need people using this. I don't just want to target XNA developers either; I want to encourage any enthusiasts of XNA games to look to this library as something that they can work on to preserve or even improve their favorite games.

Want to know how I got the attention of the FEZ developer before doing the Mac/Linux ports? I took the PC version that shipped on May 1 last year, and on the same day had it running on SDL2 over OpenTK and Tao! This was possible because Renaud used MonoGame for the PC version, and all I had to do was replace his revision of the library with mine! This is not a unique situation; any person that has one of my ports should be able to take MG-SDL2 on GitHub, make changes to it, and overwrite my library with theirs, and it should work. This can and should be a community effort from game developers AND game players, just as emulators and other similar projects have been in the past (and still are today).

The biggest fear I have at the moment is that MG-SDL2 will die as soon as I stop working on it. This is not feasible, as I cannot just work on MG-SDL2 forever. I have other things I could be doing. I have other things I want to do. Working on XNA games this past year has been great, and I still have many XNA games I'm working on, but being able to do something else with my life at some point would be pretty cool too.

Additionally, we need to take a drastically different approach to how we engage with developers that use the library. The absolute biggest failure that MonoGame has made is its failure to keep developers using a single branch of the library. While I was able to work on the FEZ MonoGame branch, there are TONS of games out there using hidden branches covered in hacks that we will simply never see, and like the original XNA versions, those games will become unplayable and incompatible without atrocious amounts of work to preserve them. Even if they were all available, as of writing there are 1014 forks of MonoGame up on GitHub. You could attribute this to GitHub's forking culture, or possibly even argue that it's just that widely used, but neither reason could possibly justify that many branches of a library that's supposed to just reimplement XNA.



So, now that I've begged and pleaded for your help, what are you actually helping with? Well, here's what FNA's goals will be:

FNA will NOT contain support for platforms that arbitrarily require proprietary technologies, or force us to depend on third parties for basic functionality or support. This does NOT mean we will ONLY support native desktop apps; support for other backends such as K. Gadd's JSIL for web browsers is perfectly viable under this standard. Our goal is to use technologies that do the porting work for us; while FNA will aim to be portable for code quality reasons, porting FNA will NOT be our focus. I will explain why in a moment.

Additionally, XNA accuracy will be the sole focus of FNA. FNA should NOT be considered a "successor" to XNA. XNA is dead, and attempting to succeed a dead library while adhering to its original design and API is a self-contradiction and is just plain stupid. Instead, FNA should be considered a preservation of XNA. The goal should be to run any XNA game accurately without modification of the XNA game's source code. Whether or not that XNA game is itself portable is not our business; for instance, a game not following a platform's save directory specification or filesystem case sensitivity is not going to be our problem to fix. Even if XNA had support for other platforms, these situations would be a problem there anyway.

This brings me back to "porting" XNA games with FNA. FNA development should NOT involve porting itself to everything. There are dozens, if not hundreds, of technologies that do this and do this far better than we ever could. There's a damn good reason I used SDL2 for platform support in MonoGame-SDL2, and it's not just for the branch name. If a platform doesn't have support for these technologies, that is the platform's problem, not ours. FNA will use portable low-level libraries and open standards in its provided platform implementation to run in as many places as we can without writing a single line of branched platform code. If there's an `#if PLAT` somewhere in the code, someone goofed up. The only way we can preserve XNA is if we make FNA preservable, and this cannot be done by running it on closed libraries that will themselves die by the hands of a third party at some point. Ideally it would be nice to have FNA be portable enough that closed platform implementations can easily use upstream FNA to handle the XNA work without conflicts, but if that time doesn't ever come, I won't lose any sleep over it.



These are the primary goals I have for FNA. But again, if this is going to exist, it is going to be a community-driven project. There is no turning back on these kinds of decisions, and I absolutely refuse to completely fork away from the original project only to be the sole developer of the ENTIRE PROJECT. So, while I intend to be generally strict regarding these goals, I am certainly willing to poll the community regarding development of FNA, or even better, receive tangible contributions to the project. We can talk about stuff all we want, but work has to be done for it to... you know, exist. That's how MonoGame-SDL2 got to its current position: less talky, more worky.



So, in summary:

- I want to make a lean XNA reimplementation for desktops that only has the SDL2 platform, with others as "maybe"s.
- I want to make XNA4 accuracy the top priority, with extensions as a secondary, optional feature.
- While portable, the library will not set out to magically port absolutely everything for you.
- Not a successor, but a preservation of XNA!
- None of this will work if a community doesn't happen.



Any feedback you can provide is welcome, and I hope to hear from both developers and users who have an investment in either MonoGame-SDL2 or FNA.
Shared publiclyView activity