So some of you might have seen some recent work I've been doing... stuff like this:

EDIT: New screenshot, this time it's not borked!

And apparently, a loooot of people were interested in this! So, I've decided to make an "official" post on what this is. Or rather, an FAQ!

Q: What is this, exactly?
A: This is Fez running on a modified version of MonoGame. Rather than using OpenTK for window management/input and Tao for controller support, it uses SDL2#, a library I started in early April.

The fez-sdl2 branch of MonoGame can be found here:

Q: What are any of those things?
A: Right, I should go in order:

- MonoGame is an open implementation of the Microsoft XNA framework, a library Microsoft developed to make Windows and Xbox 360 game development more appealing to C# programmers and "indie" game developers. It's a very, very high-level library (and by "high-level", I mean "you start the framework with a Game.Run()" call...), so its target market is pretty similar to Unity, except that you write a little bit more engine code with XNA. The actual XNA API is high-level enough to where you really don't write any platform-dependent code, it's really just library-dependent. This is how MonoGame works; you implement the XNA bits, then send that to platform code. Pretty simple!

- OpenTK is meant to be a cross-platform C# library that handles window management, input, OpenGL/OpenAL bindings, and a whole bunch of other things. I'm not going to talk much about this library, because you only need to know one thing: it is absolute garbage. Display management alone is so mind-bendingly psychotic that it essentially makes OpenTK unusable, and even unportable. I'll elaborate on this later.

- Tao is the C# SDL bindings library. They also have OpenGL and OpenAL bindings, but nobody uses these for some reason.

- SDL2# is a library I'm developing to make the above two libraries obsolete. It's pretty much what it sounds like: SDL2 bindings for C#, and we currently take OpenGL/OpenAL bindings from OpenTK for MonoGame compatibility.

Q: Awesome, you're porting Fez to <platform>?
A: Nope!

Fez itself has a few problems that make the port a bit difficult for Linux (MacOS is out of the question instantly due to the need for NSApplication stuff in Main() EDIT: Ported MonoKickstart to OSX, this no longer applies). Here are some of them:

- There's a WinAPI call on start. You can actually wrap around this with a sofile and a FEZ.exe.config, so this one's not so bad.
- File paths. The dreaded '\\' character. If you're willing to name content files stuff like "Content\\Music.pak", you can get around this.
- The text reader has problems on Linux; you'll get beginnings and ends of words that are scrambled; this is probably the Fez engine compensating for '\n' on Windows.
- The Community Express SDK on Steam. Yeah.

Long story short, it'll only be on Windows for now unless you like broken games.

That's an important factor: I don't even have access to the Fez source, only their MonoGame branch (which has been on GitHub for a while: So, allow me to make this point clear:

This work is 100% unofficial and is in no way related to Polytron's work on Fez.

Q: So, what's the point of this then?
A: This was actually a little experiment of mine to see how portable my MonoGame-SDL2 backend was.

Let me take you through a quick tour of how MonoGame works. Not strictly tech, but more in the... I hesitate to say "PR" department, but I think you'll get it either way:

Check out MonoGame's website:

See that line about platform support? "We currently support iOS, Android, Windows (both OpenGL and DirectX), Mac OS X, Linux, Windows 8 Store, Windows Phone 8, PlayStation Mobile, and the OUYA console."

That sure sounds like the MonoGame library's making XNA porting easy right now!

There aren't enough "NOPE" images/videos on the Internet to balance that suggestion out.

The truth is, MonoGame is currently for Windows 8, and mayyybe iOS/Android. Compatibility with any other platform is coincidental, not deliberate. You may find some luck when porting your game, but more often than not, you get to scrub toilets with your face for a few months since there's no internal platform API to work with (I hope you like interleaved #ifdefs !).

If you wonder why there are some MonoGame titles out there that work really well, yet it's still so terrible to port with, it's because the current open source structure of the project is miserable: you are expected to fork MonoGame, hack it for your game, and call it a day. There is no expectation that your new code will even be good, it just has to "run". And, as expected, most of the hacks are absolute garbage, and nothing ever goes back to upstream.

This is why OpenTK is still being used: nobody on the core development team knows that it just doesn't work. Since the core team are on Windows 8, they never have to use this library, so it goes largely unnoticed. If you have to use an OpenTK platform, just hack it until it's close enough. Whatever. That's not to say that the devs are entirely incompetent; they've done brilliant things on the XNA half, but the platform half of MonoGame is undeniably awful.

Between May of last year and March of this year, I ported Blueberry Garden and "Codename lolno" to Linux and Mac with MonoGame. This was the process:

- Create the Linux sln/csproj files
- Try to boot the game
- Hack hack hack hack hack
- "It works!"
- "No it doesn't, you fraud, look at all these bugs."
- goto step 3, repeat until you're too tired to bother with bug reports.
- goto step 1, this time on OSX! Because OSX uses MonoMac, not OpenTK!
- goto step 1 again if you want Windows support! It's OpenTK, but not Linux OpenTK!

Let me make that last part clear: You have to port a MonoGame title to MonoGame.

In April, I was offered a third port (and later a fourth). And I realized I would have to do this over again.

Fuck. That.

In early April I started SDL2#. Exactly 2 weeks later, I had the SDL2 bindings and the OpenGL/OpenAL parts working, and 2 more weeks later, I had MonoGame ported to SDL2. Yesterday, I created an entirely new MonoGame platform sln, called "MonoGame.Framework.SDL2.sln". This works for Windows, Mac and Linux; there are no platform defs anywhere in MonoGame-SDL2. In less than a week, I had every one of my MonoGame ports running under SDL2# with no game-specific hacks, and they will all be shipping with this backend. We even get added perks like automated controller configurations via Big Picture and SDL_GameController.

Which brings us back to Fez.

Fez is a MonoGame title, but it's only for Windows right now, possibly due to MonoGame not being reliable enough to allow for a simultanous release. I don't know this for sure, but if I had to take a guess, this would probably be it. Right now, Renaud would have to re-port Fez for Mac, and then re-port Fez for Linux. Considering he's got another job entirely, and he's still got OpenTK woes on Windows, that is probably the textbook definition of Hell.

Since I had just finished MG-SDL2 for my games, and Fez was going to be out in a few hours, I decided to see how portable my backend really was. I forked his repo the morning Fez launched, and by the evening I had it running on SDL2#. The next day, I had it in-game... this is what you see in the screenshots above.

Q: Neat, does that mean it just works now?
A: EDIT: Yes! It actually seems to be working now. If you want to try this out (please play Fez for real first!), here's a binary patch:

Q: Something something Polytron something something
A: Quick reminder!

This work is 100% unofficial and is in no way related to Polytron's work on Fez.

That said, Polytron is aware of the SDL2# work, and we have contacted each other regarding the SDL2# port. This means absolutely nothing, and you should consider this project entirely irrelevant and unproductive until further notice. Just know that they're aware of the port's existence.

I hope that answered some questions out there... if not, ask in the comments, I'll try to keep this updated. In the meantime, I'm-a go play Fez now.

EDIT: Here's the "official" MonoGame-SDL2 branch, if you want it:
Shared publiclyView activity