[Documentation] Document MonoGame Incompatibilities

[ShalokShalom]

Hi there :)

I read an argument about the difference between FNA and Monogame, pointing out the Switch support and higher maintenance on the side of the second.

How do you see this?
What are the benefits of FNA?

You might consider to clear this up in the documentation since both projects implement the the XNA platform and through that is it difficult for the newbies to differentiate.

Thanks a lot

[flibitijibibo]

I don't think too much about the comparison because in theory there should be no comparison to begin with. FNA is meant to be the preservation of XNA while MonoGame is supposed to be the successor. The overlap is largely because XNA ports are a moneymaker and as a result there is some pressure on their part to keep compatibility.

Where I think FNA excels, aside from the usual gimmicks you'd find on any project's website ever ("write once run anywhere" (which is always a lie, btw), "used by famous game X," etc.), is its clear and unambiguous focus. We implement XNA, we try to deploy it where we can, and we firmly place our role as only one among many in an ecosystem of Free and Open Source game software development that is very thinly spread as it is. With FNA, you can expect exactly this every single day:

• FNA now reliably mimics almost the entire XNA 4.0 specification, and if an FNA behavior does not match XNA, it is absolutely a bug, with the sole exception being platform behavior that is explicitly not defined in the specification.
• FNA runs correctly and identically on every platform it advertises support for, and the platform support is advertised when it is done, and ONLY when it is done and ready to ship for general use.
• FNA organizes itself in a way that allows projects using similar technologies should be able to reuse our research and code where applicable, and we can use others' research in exactly the same way. MojoShader’s Effect support, OpenAL Soft’s MSADPCM support, and TheoraPlay’s Windows support are a few examples.

MonoGame may have shiny features like PlayStation 4 support, but they will, as far as I can tell, never have those three bullets to the same extent that we do:

• MonoGame could continue to mimic XNA 4.0 (though not as good as us, but it could potentially be by design?), but that leaves them in a very restrictive environment of having to work with old formats, technologies, and even methodologies that people will increasingly not use anyway, and therefore cannot spend their time on newer formats/technologies/methodologies that competing frameworks and engines can provide trivially. This is the antithesis of anything I would call a successor. Someone could take the XNA spec and totally rework it in a way that, for example, fixes all my complaints about the content pipeline, but instead we just have another content pipeline with all the same problems. Cool for me I guess, as that's a cop-out answer I can give to people desperate for a bad pipeline to use with my XNA4 runtime, but not cool for anyone else.
• MonoGame advertises a TON of platforms where the consistency is all over the place. Once someone has it booting with one game, up on the promotional material it goes. When I have a piece of software that purports to run on platforms X/Y/Z, I expect my input and output to be exactly the same, with any changes to be very clearly documented. That is not the case here, and while this could be extensively detailed by any developer using it, the plain simple fact is that it is a problem and I am not convinced anyone who uses it is willing to sit down and fix it. Frankly this applies more to their community rather than their core team, as the core team is working on closed platforms primarily, which is where all their money is anyway. They really can't work on desktop or mobile anymore. I don't blame them for their desktop support as much as I used to.
• Everything in MonoGame is made by them. Everything. Even C# wrappers for the third-party libraries that they were eventually forced into using aren't separate projects. The XNA specification is hard enough to deal with, why add on more work for a team that's spread so thinly anyway? For a successor the reason would be that you're developing wholly new technologies to replace the old, but in this case we're replacing the old with fake versions of the old! Who benefits from MGFX or their internal XACT runtime or all these janky Frankensteiny content tools? And I'm not even trying to suggest that it all has to be brand new additions all the time; 90% of my own ideas for an XNA successor involve removing things from the framework. Throw out XACT, strip out the Effects framework, maybe even throw out Storage since every platform has managed to be completely incompatible with it anyway, the list goes on. In a way both projects have effectively done that for GamerServices/Net anyway (though we do have FNA.Steamworks to mitigate that), so why not other parts that are way past their time?

The secret and final point to these three points is that if you ask anyone who uses MonoGame about these points, you will get a different answer pretty much every time (other than "lol you have the source you do it," which is a condescending/patronizing answer that you would never say to your co-worker on a proprietary project so I dunno why people throw that around so arrogantly in FOSS). I suspect I know as much about the intent and direction of the project as anyone who actively uses it.

On the other hand, FNA has a very clear direction, it's just that we move very slowly from the public's perception. Yes, Switch is being worked on, as is Xbone, Android, iOS/tvOS, and so on. But it's not done yet. And I would prefer to simply say it's not done and invite people to help finish it rather than pretend it's here and constantly drag people around while we throw together a house of cards and pray that it stays standing. We have less people but our people are put to good use, and we openly and transparently limit our scope to guarantee quality and I think that gives our users (and our developers) a little more confidence knowing that we're not in a constant, never-ending rush.

Lastly, and frankly, compared to what we're actually trying to do, and considering how often the platform ecosystem changes, stuff like that is just superficial glitter. And once FNA's platform list catches up to MonoGame's, I think people will figure that out pretty quickly when they're finally willing to actually compare side-by-side instead of throwing us away just because we don't have iOS support or whatever it was they weren't going to use anyway.

[ShalokShalom]

Impressive ^-^

Monogame becomes less interesting to me then, since such decisions to support "swimming without getting wet" tend to act fragile in software development.

See the packaging in the main distros.

Well, I thank you very much for this comprehensive view and I think its clear that it belongs into your documentation.

I will also like to add that you seem to know very well what you are doing

[flibitijibibo]

I dunno if it's something I want to put in the manual only because it really shouldn't be there to begin with... I'd prefer to wipe my hands clean of the whole comparison between the two, since they really shouldn't be compared as two versions of one idea (even though that's how it plays out in practice). Even if it was on the front page I don't think it'd change anyone's mind. All it does is generate needless divides when I'd probably do well to at least encourage cooperation as long as they're still riding the XNA specification. I may not like their style but there's still some common ground to be met (fixing FAudio's license is one example).

[ShalokShalom]

Exactly that you point out their different characteristics is important?

[flibitijibibo]

I can try to figure out how to differentiate them on a technical level, but I dunno if that'll be easy. XNA4 vs. XNA4-but-not-really is even harder to document than XNA4 vs. XNA4 minus WinForms! But I could probably point out stuff like MGFX along with the usual changes like Song/Video content. Let me figure this out once FAudio has calmed down a little.

[ShalokShalom]

Well, I think you already did a great job, while this is up to you of course.

[rds1983]

Also FNA's code is much easier to read and understand. Though it is subjective feeling.

Speaking of which. Does FNA accepts PRs that slightly change original XNA4 spec?
I.e. right now, SpriteFont's constructor is internal and therefore it is impossible to create it in the runtime without using reflection. Would FNA accept PR making it public?

[ShalokShalom]

I guess its adviced to open an own issue for it since others like to share their opinion on this specific question.

[flibitijibibo]

@rds1983 That would break the spec, so no. To slightly change the spec would be to, well, change the spec. Luckily SpriteFont is terrible and you shouldn't use it anyway.

[tomspilman]

This is an interesting thread. :)

[flibitijibibo]

Tell me about it!

[flibitijibibo]

Documentation for MonoGame compatibility has been written:

https://github.com/FNA-XNA/FNA/wiki/Appendix-B:-MonoGame-Compatibility

EDIT: lol what's Ctrl+C

[ShalokShalom]

Thanks a lot ^-^