Shared publicly  - 
 
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.
39
9
Gravitas's profile photoAndreia Gaita's profile photoEthan Lee's profile photoIlya K.'s profile photo
44 comments
Ilya K.
 
I'm really hyped about this right now. Does that mean you'll be switching your ports over when it happens? Also, I don't think "preserving" XNA should be the goal. The ideal way for me would be to improve on FNA, and keep the XNA compatible wrappers around the occasional backwards compatible bits in a separate module, just like KDE does with Frameworks 5 and kde4support. If there's a way to do it better and keep backwards compatibility, I don't see a reason not to. Of course, that still limits the scope of the possible changes, but just freezing the API in place sounds ... wrong, especially for a free software project.

Edit: what I'm saying is that XNA is pretty great for lots of things - it's not a dead API that needs to be revived (think DosBOX) - it's a great API that still works well for new games. If it can be made better, then why not?
 
+Ilya K. I'm not opposed to an extension system to improve things here and there, but I won't be wrapping XNA4 stuff when XNA4 is our target. Remember, we're NOT succeeding anything. This may be a problem if you're trying to make new stuff with the library, but this isn't something you'd want to make a new game with in the first place. There are newer, better technologies for that, and that's not something we need to compete with.
Ilya K.
 
+Ethan Lee
You mean Unity2D? I can't really think of anything else high level.
 
+Ilya K.
Unity2D, SDL2#, Godot, Torque, lots of things for 2D are out there. I couldn't hope to list them all.
Ilya K.
 
+Ethan Lee Does Torque exist on Linux yet? Also, just looked into Godot. Sounds pretty damn cool.
 
+Ilya K.  I think someone got 2D working, possibly 3D as well. Might be buried in a GitHub branch, but that's what I heard. Don't know for sure.
 
"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."

So what platforms will this support? iOS and Android are two of the big reasons I use MonoGame currently and if those are gone, then I wouldn't switch to this.
Ilya K.
 
+Ethan Lee Oh well. Still, I'll be following the FNA stuff, might even try to help.
 
+Kris Steele Desktop platforms. Windows/Mac/Linux would be starting points. If you're a mobile dev, you don't need to worry about this library. This is designed with a very specific focus on desktops, rather than a one-size-fits-all solution.

SDL2 actually does support iOS/Android, but the Xamarin license leaves us out in the cold. I'd be interested in seeing if someone can make the SDL2 version run over there with the Xamarin Mono runtimes, but I won't be involved in that particular thing.
 
+Kris Steele I've edited the post a bit at the end to note that this is a desktop-focused library. Thanks for the question.
 
"The goal should be to run any XNA game accurately without modification of the XNA game's source code." Yes please!!! I've been hoping for something like this for a while.
 
You bring up a lot of valid points about MonoGame's failings. I found a version that works, found errors in others, and now am afraid to change to anything else. It works for what I'm doing at least. I found some controller bugs for instance that were fixed in one version then rebroke in later versions (I assume because of a poorly done merge) so I ended up staying with the middle version that works.

I see the issues you've presented but it would be nice if this was something in the main MonoGame trunk instead of something new. As you already stated, the community isn't big and isn't organized (did you say that? I'm saying it at least). Another version of MonoGame serves to split that more and if your goal is to have continued development of this library, not having it in the main MonoGame trunk also decreases the user that will be doing that. I'm not clear what the larger MonoGame community is doing either... Mobile? PC? Mac? For me personally I use MonoGame because I have XNA games already that I want to port to desktop and mobile devices so I'll only be using a framework that covers both.

I don't think any of your reasoning for wanting to do this separately is bad, it all makes a lot of sense, but I think there are some solid reasons not to as well.
 
 +Kris Steele It'd be nice to have something that does fit everything, but internally the project's design simply doesn't allow that to happen. Right now it's designed only with one platform in mind, but your guess is as good as mine as to what that platform is.

I mean, look at this thing:

https://github.com/flibitijibibo/MonoGame/blob/monogame-sdl2/MonoGame.Framework/Graphics/GraphicsDevice.cs

If we're going to write code as if we're only focusing on one platform, I know which one I'm choosing.

It's hard for me to talk about mobile devs, as I've simply never had that market. In my head it's just "I'm losing a market that I... never, had?" Again, it'd be nice to have one solution for every problem, but until that solution works everywhere we need to break off into separate segments and give ourselves some focus. NO programmer should be this afraid to make a change to as little as one file in fear of breaking absolutely everything.

On paper it sounds like we're just cutting stuff, but trust me. Just keep reading that file over and over again until you do. You'll have to take my word for it on this front.
 
The MonoGame team has been behind switching to SDL2 for over 6 months now.  The big blocker has been how huge a switch this is...  not breaking things in the process.

Still this is great...  there is plenty of room for other XNA like libraries.  We can merge in parts of Ethan's work at a later date.
Xo na
 
I'm not sure how much this helps, but all of my games are coded in XNA and I wish for a way to maintain these codebases and bring my games to Xbox One / PS4, Xbox 360 / PS3, and PC. Anything that can help do this, would be great. I love XNA and C#. If I have to, I will be using other technologies and porting my games to make this happen. I appreciate all your work, Ethan, even if I have not yet used it. I wish I understood more about it, such as how the Xaramin license holds you back. Because I have not been involved, I am in no position to make judgements or suggestions. I am not fully aware of exactly what MonoGame and all the variations are., detailed and technically speaking I mean.  All I can do is let you know what I want to do with my XNA codebases. Can you take my games to Xbox 360/One, PS3/4, and PC?

I like the idea there should be only one MonoGame. (Should I be calling it SDL2? Even the naming convention I am uneducated on.) Changes should be version numbers. So that we do not have random branches and generally we can move forward as a community.

-- Matthew Doucette, Xona Games
 
+Tom Spilman  Right, this is definitely something to note. Even if I actually do branch off to make FNA, I'll still have MG-SDL2 to merge in as many things as possible into that project. There's enough stuff in there, and the two projects' goals are certainly close enough, to warrant keeping close ties between the two projects. They'll just temporarily have different targets, which takes a good workload off of everyone.
 
+Xo na I actually think the original MonoGame project has a PS4 version in the works, you can ask +Tom Spilman about that. For other platforms, I'm not sure. For now, FNA would be laser-targeted at the PC, so Windows/Mac/Linux would be the starting point. For the rest, the original MonoGame project has some targets that are worth looking at.
 
I think the most important thing here is that you made your goal clear: XNA preservation. Libraries of this sort are extremely important to the ecosystem of PC game software as more and more games get left behind on old operating systems and hardware, unable to be played anymore. That goal doesn't seem to align with where Monogame is going. I've always viewed plain Monogame as more "inspired by" XNA, even though that's an exaggeration. It's sort of compatible and it's possible to get it to work, but it's not really achieving complete correctness. Monogame's website explicitly calls for new games based on it, not so much based on XNA. Your goal of preservation and XNA correctness is very specific and will help drive the FNA project forward. Based on that alone, I think a fork is valuable and worthwhile. Given this focus, it may be worth contacting software preservation groups for cooperation/support.

A lot of people will focus on platforms and portability. Don't worry about that. Let SDL2 and other open source libraries handle that for you.

That's all theory though. As you brought up, the tough part is support. Communities are hard. Time is (extremely) limited. Big codebases like monogame/monogame-sdl2 are hard to tackle changes on in small amounts and/or by new developers. I think you're going in the right direction though given how open you've been with Monogame-SDL2's development. Good social networking, good project/issue management software and good documentation is critical to community. Another key point you make is "This can and should be a community effort from game developers AND game players". I think that's going to be another key factor here. Can we (and it has to be we, not just you) all build a community around FNA? I think this effort is worthwhile and I'll do what I can to support it, but as you know my time is extremely limited for projects like this. FNA will depend on whether or not people can/will step up to contribute.

One more thing: Even if others don't contribute significantly to FNA, will the inability to merge much upstream to Monogame make you burn out on this library sooner than if you had forked? Burnout avoidance is good to consider. Sorry that this last thought is a downer.

Good luck and I hope to be able to contribute as time allows wherever this project goes!
 
I'm agree with you +Ethan Lee and I've contributed in MonoGame, I've ported the Monodevelop plugin to Linux and it's important for me that the library work well on this platform. By the way there are others questions : why only talk about porting a game and not about creating a game from scratch ? Monogame is made only for porting ? Why talk about 2D all the time ? Is Momogame used only by 2d game developers ? So it's the same questions about your potential new fork. My friend +Franck Jeandinot is doing an awesome job from Linux, do FNA could help him to not using a VM to compile assets ? Thanks for your answers
 
+Yannick Comte  I'm mostly concerned with preservation at the moment, since that's the best way to quickly get to a working implementation. At an extremely high level of accuracy you could definitely make new games with it and retroactively have support for XNA4 in your game, but I wouldn't currently recommend doing that, as there are a lot of gaps left to fill.

I actually just recently did some work to the graphics engine that should provide 3D support for OpenGL on top of the current 3D asset support, but I've not used it for "real" 3D yet. That work was applied to Reus. Another port I have this year does do full 3D, so we'll see how well it actually works.

I won't be focusing on a Content pipeline, but the original MonoGame project is looking at that. I'll be focusing more on running XNA4-built data without rebuilding it, in the same manner that I did the XACT rewrite.
 
Just a Linux hobbyist chiming in here, but from my point of view the refocusing on the SDL2 backend and compatibility sound great.  What I worry about (and I see this was brought up on Twitter... and which I think Yannick is working towards) is what it would mean for the content pipeline that is still very incomplete in MG.  I'd rather miss being able to load non-xnb content, if it was removed to bring things more in line with XNA.... and building content on Windows is not appealing to Linux hobbyists.
 
+Yannick Comte 

> why only talk about porting a game and not about
> creating a game from scratch?

I think because MonoGame is still lacking a complete content pipeline.  As soon as we have that completed it can be a complete package without XNA dependencies and hacks to work with the XNA pipeline.

We are getting close, but not yet there.

> Is Momogame used only by 2d game developers

We have a big 3D game using advanced techniques like deferred rendering running under the MonoGame desktop DirectX platform.  We developed it under MonoGame exclusively without using XNA.
 
+Tom Spilman I know that, I made a 3D game from scratch with MonoGame and I know that nice games has been made, such as Infinite Fly and Armed ! 
My game first tageting Windows Store but for Desktop I've used +Ethan Lee port because I can easely play song/music and I've just one executable for my game.+James Allardice 

@All: I don't think that a lot of people use Linux to develop (many developers use Linux to test there builds, but not developing) games, but I've some people on my blog who want a nice C# solution du make game on Linux and I can't say here that MonoGame is the right tool for that.

MonoGame is a great Framework, a lot of work has been done and it's nice to see all these contributions. But IMO it must evolve now, we aren't in 2008, as +Ethan Lee said, XNA is dead.
 
As someone still very much learning XNA. The prospect of keeping it simple and focusing on simplicity of deployment on some of my personal favorite platforms is appealing.
Unless a skeleton key to all of the platforms in the world rears it's head any time soon, why wouldn't a developer want to use something as simple as this?
 
Demonstrating continued interest.
 
The problem I see is that XNA is indeed dead.

How many games out there will actually need to be ported from XNA in the future vs just starting off with MonoGame from the start? I would hope that developers start to move away from XNA. Today many might still begin with XNA but that's because less have heard of MonoGame, theres heaps of XNA books, tutorials, unicourses, etc... And there is still parts that are lacking (such as the 3D API, or content pipeline as pointed out above) but as word spreads and development progresses we would likely see the switch to MonoGame by default.

Also remember that many of the older games that haven't been ported might just never receive the treatment.

I also don't really understand the why behind dropping specific platforms either, quite a few devs might port to MonoGame just to get support for Windows 8 and Android and then find out they can also support Linux.

Basically I like the idea of rewriting the 3D and making the XNA4 API accurate but not so much killing off it's extra stuff, I would prefer to see an API that continues to grow.
 
> I would hope that developers start to move away from XNA.

On the MonoGame team we figured that in 2014 is when we can start to really break XNA compatibility.  The logic being that Xbox 360 and Windows Phone 7 being old enough that many won't be looking to target it any longer.

Look for more on that soon.
 
I agree with +David Bishop  the API don't must break the standard XNA but It must
improve with new features. However some choices must be made, specially for platforms such as Linux where OpenTK is really not a good choice. The needs of Windows.Form is horrible because it's not well supported on some distributions (Mandriva, Mageia for example) and because of that it's not working.

On Windows MonoGame have a DirectX backend and it's great, IMO OpenTK must be dropped and replaced by +Ethan Lee 's MonoGame port. SDL2 is largely better for that. In fact SDL2 work well on all Desktop, include Mac. The main problem is just the dll/so/dylib of SDL2 that must be present with the executable and if you want sound, video, etc.. you must ship a lot of dll/so/dylib.

Moreover I've noticed that MonoGame SDL2 is slower than DirectX port for 3D operations. I don't know why but my game is loading instantanetly on Windows 8/Metro but take 30 seconds with SDL2 port Oo' But I saw that the renderer was short of rewriting, I hope it will improve performance, because currently Linux is not as magical as Windows.
 
I definitely support this general idea.  How much progress have have you made on the new OpenGL renderer.  I've definitely found the old one ..... lacking
 
+Ethan Lee , thanks Ethan!  We'll probably try pulling that into our mg-SDL2 code and see how it goes.  Do you happen to have any benchmarks as to what the rough performance increase is from the original mg-SDL2 branch?
 
+Geoff Brown It's roughly a <1% improvement on my setup, but debugging it is so much easier that it hurts. Profiling with apitrace is WAY faster now.
 
+Ethan Lee before I digg too deep.  You said <1% improvement.  What framerate are you getting on said setup?
 
+Geoff Brown On the old renderer, Rogue Legacy was getting around 560fps on my setup. With the new one, it's around 570.

Is there a custom MG-SDL2 branch I should know about? I haven't seen any patches, so if there's a custom branch somewhere I'd like that to not exist if possible, for compatibility reasons.
 
+Ethan Lee Alright, that sounds reasonable.  I wouldn't expect that you could squeeze too much more out of that.  I'll be interested to see what my crummy laptop that gets 5fps in Hive gets with it.  My desktop gets around 600.  That same laptop can run it via XNA at around 30fps which is a whole lot more tolerable :)
 
+Ethan Lee Where do we get the latest source code of FNA? We are developing a game at Karlsruhe Institute of Technology (currently based on MonoGame) and I would like to depend on MonoGame-SDL or FNA, but I would need something to tell my supervisor. Is it your current mgsdl2-opengldevice branch or do you already have another repository for FNA?
 
+Tobias Schulz Currently the "stable" branch is `monogame-sdl2`, with `mgsdl2-opengldevice` being the first thing that breaks MonoGame upstream compatibility. While `mgsdl2-opengldevice` will be merged within the next few weeks or so, the first FNA release probably won't be until later this year, as I need to do a full code audit of the MonoGame library before the fork is complete. I've rewritten a LOT of it, but not quite everything... (yet?)
 
+Ethan Lee For some years my professor recommends XNA for student projects and I would like to convince them to switch to an open source implementation and FNA sounds perfect for that, but I would need at least something "official" from your project. The readme files in your branches refer to the MonoGame website, which I think has nothing to do with your fork - are you planning to mention MonoGame-SDL/FNA on your own website?
 
+Tobias Schulz  Eventually, but you're better off telling the university to stop using dead libraries rather than use a preservation project for new things.

A lot of the marketing glitter will come after FNA's complete, as I'm more focused on making a good library before I pimp it everywhere. MonoGame-SDL2 is official only in that it shipped in a dozen commercial games, several of which were in multimillion-dollar promotions. Not much else.

I'll probably edit the README soon, though it will probably say something along the lines of "This will become FNA, more on that later," rather than the content of an actual README file.
 
+Ethan Lee Well many people at my university have experience with XNA, and they probably won't switch to something entirely different soon. Another reason is that C# is considered to be easier for student projects than C++ and there is a policy that we should use object oriented APIs if possible, so we can't use raw OpenGL. And there wouldn't be enough time in a semester to use more difficult libraries. And a C#-based engine like Unity would be too high level.

So if we could use MonoGame/FNA here, we would at least have Linux and Mac support and we could be sure that there will be bugfixes since it is not dead as XNA. And there will always be people doing forks with extended features. Some other students here are currently trying to use GLSL shaders with MonoGame, not HLSL converted to GLSL with 2MGFX, and a clean OpenGL-based reimplementation of XNA would be awesome for things like this.
 
I'm a game developer, working for some years on long-term projects (among which a high-quality 2D RPG, a framework to port games from the rpg-maker community). I'm using XNA, and I want to modernize my tools.

Some monthes ago, I considered using MonoGame, but well... you point out the problems. Unity 2D seems too high level and not open enough for my goals. Your library could be a solution and, though i'm not a very technical developer, i would be glad to be a user of it, for many games.

If I sum up, FNA would :
- Focus on XNA4 accuracy
- Work on Windows except Windows 8, MacOs and Linux
- Not evolve (not from you at least) : once its XNA accuracy goal reached, it would remain the same
 
+John Riselvato If you know of any XNA games that need a Linux/Mac version, forward them to me or the library. That's about the best donation you can give; since it's mostly driven by myself, donations would mostly amount to a Jagermeister fund... not exactly the same as development costs. :P
Add a comment...