Have you ever played Fez on Linux ? Transistor ? Speed Runners ? Shenzen I/O ? Bastion ? or more recently, Owlboy ? Well if you have, you have benefited from the work of Flibitijibibo who is directly responsible for the port of such titles to your platform.

[podcast_episode episode=“3104” content=“title,player”]

Download: [MP3 File] | [OGG File] | Podcast RSS Feed

We sat down, figuratively speaking as we were all connected remotely, with Ethan Lee aka Flibitijibibo a few weeks back. As you know, we are on a quest to get to talk to as many porters and porting companies as possible, and Ethan Lee has been on our list for a long time. You may know him as Flibitjibubo, the man who ports faster than his shadow, thanks to the open-source FNA framework he has created to replace the void left by XNA when Microsoft stopped supporting it. There are still many games made with XNA and FNA becomes a natural tool for such games when the possibility of a Linux port is discussed. Recently there are also developers who start developing new XNA-like games directly with FNA, in order to have cross-platform compatibility right from the start. A very impressive feat by someone who is pretty much working alone on this project.

So where did it all start? Where is FNA going from on ? We invite you to listen to the podcast to find out more.

As it’s unlikely all of you stumbling on this article will listen to the whole thing (while we do recommend you do so), here’s some extracts that are worth highlighting.

FNA is Middleware in itself, and Middleware is a touchy subject when it comes to porting, as so many tools and libraries become obstacles when you consider adding a new platform.

Flibit: Middleware. Almost all of them really suck. Not in the unusable sense, but for what Middleware is advertised, it’s really, really dishonest, when you compare it to the reality of the situation. It’s one of the reasons I was starting to be really, really impatient with Monogame, because most of what is advertised was just flat all lies. Even if people would argue that FNA works better on the desktop than Monogame, Monogame is still the most popular one because they advertise a whole lot more - even things that are not 100% functional, they will still advertize it. For FNA, I don’t really have the time to keep that up, I don’t pretend to have things that I don’t have, and I don’t feel like stretching myself out. People ask me for Android and iOS support […] I could in theory do that but I am sure it would be a bunch of crap […] because I don’t care enough. […] Right now I am looking at Nintendo Switch support for FNA […] but it’s one step at the time for me, and I don’t want to make it look like “we do everything perfectly - no work at all!”. My conscience would not allow me to do that.

When it comes to porting, most articles these days spend time showing how OpenGL games perform worse than their equivalent DirectX versions. Flibit confirmed again what many of us assumed all along about the real story between such differences.

Flibit: A lot of OpenGL code optimization is not necessarily that it’s designed for Direct3D. The problem is that the Direct3D code that they use is usually not correct. I’m sure Aspyr and Feral will tell you that the Direct3D code they had to deal with was so, so objectively incorrect, and the only reason it’s working is because the driver vendors made them a special version of the drivers. That’s the thing that makes OpenGL porting difficult. It’s not necessarily that it’s slower, or faster, or that some features are missing… it’s literally that the code is wrong to start with. There is nothing you can do about that unless you go and fix it first. For AAA games I don’t want to think about how difficult that is. One really good example in FNA is sprite batches. The sprite batch in FNA is pretty freaking fast. But if you take for example a game that draws every sprite in individual draw calls… you will have thousands of sprites on the screen, and every single sprite has its own draw call. By default it should be slow, even with Vulkan. But Direct3D may have found a way, for example by deciding not to do any validation. But OpenGL, by doing every single draw call, it will go through everything it needs to do, but in reality if you put all the sprites into a single buffer and draw them all at once, it’s good. And it applies to Direct3D as well. Sometimes when I work on optimizing some games for FNA, I find something that is objectively slow, I ask the developer to switch one item and ask them to see how it works on Windows, and they usually say “Holy crap you made it so much faster how did you do that?”. So it’s not that OpenGL is slower, but when the program is slow, OpenGL will exaggerate the slowness. It’s very much the reason why multiplatform code development is very much a code quality tool, because sometimes that might happen to work, even though it should not, would totally get destroyed on another platform, because it’s not giving the same special treatment.

While Flibit usually ships ports for Mac and Linux likewise, most of his work is actually done on Linux, even for the Mac platform.

Flibit: Most Mac users would be surprised that I do almost no development there (implied, for their platform).

About Middleware engines like Unreal 4 and CryEngine, now supporting Linux, we discussed with Flibit whether or not they reduce the workload for porting to Linux. He has some interesting comments.

Flibit: It’s a little weird. I think it reduces the workload, but it reduces the workload for a sector of the industry where the workload is multiplied by orders of magnitude. It’s great that Unreal Engine has Linux support in a SDL backend. But the amount of work to get Unreal Engine to work on ANY platform, even if it’s technically supported, it still a lot of freaking work. It may be the case that it does not need as many people to put it together, it still requires specialists. When you look at the size of Unreal 4, just for one target, I mean, it’s… it’s UNREAL how big Unreal is. If you do a line count of that thing your face just melts at the result. CryEngine is about the same. On top of being a massive engine with massive backends, they probably don’t have enough people ironing it. The only reason why Unreal Engine support for Linux is so good is because people look at it. I don’t know if it’s the developers or not, but somebody is looking at it. […] Because AAA games programming is so complicated, I don’t know if it will ever shrink down to having just a few people do it.

We had the opportunity to touch upon Steam Machines as well, and why it failed to pick up the interest of most gamers. This has been discussed over and over again, but he had a good way to put things back in perspective.

Flibit: It’s hard to gauge, for gamers it’s hard to understand what makes Steam Machines interesting. People can understand the dictionary definition of what open-source means, but what we have done a very poor job at advertising, for Steam Machines in particular, is that we have not demonstrated ways in which in your can leverage its openness. I run RetroArch on the Steam Machine all the freaking time. A Steam Machine is a tiny little thing, the size of the WiiU. It runs Bioshock Infinite at 60fps and 1080p but it can also run this other stuff too. […] At this MAGFest in January I brought with me 4 X360 controllers and 4 gamecube controllers. And they were all working at the same time on this one box. I had Dolphin running on it, I was able to play Gamecube and Wii games on it, and that was totally compatible, It’s one of those things I like to demonstrate with my games too: I start with the Xbox360 controller, then I unplug that and use the PS4 controller, Then I unplug it and use the Gamecube controller. Then the keyboard and mouse. All in the same session. People react to that. But that’s not the kind of things you think about when you think of a console, because you usually have the image of that console’s controller. And probably the main problem in that regard with the Steam Machines is that they advertise the Steam Controller, which makes sense because it’s their controller. But people are really skeptical of it, so it adds to the skepticism of the console. But the benefit of the openness of that console is that you don’t have to use that.

The fact that Valve invested so many efforts into making Linux a new platform is commendable in the first place. Flibit made a parallel with what Microsoft did back in the days and how long it took them to make a stand.

Flibit: Adding a platform, no matter who it is, is really, really difficult. It’s a case where Valve is kind of the only company that is big enough to accomplish that. When a multi billion dollars company is still struggling with it, it can be discouraging for a lot of people, because don’t realize what it is to add a platform. People forget. The first 10 years of the Xbox were dismal. For the company. Imagine having an entire division of your company that is literally burning money, for 10 years. It’s something you have to fight with a lot. It’s the reason why I really hate benchmarks. It focuses on frames per second. It’s 300 fps vs 275… “this isn’t worth it!”. Of course this only happens with games that they can clickbait titles on. Nobody is going to do a benchmark for Towerfall. That’s what I love about showing these machines. People are then not looking at these bar charts, they are looking at available software they can actually play. When I have Rocket League running on my Steam Machine, you put it next to the PS4 version, there is no difference. And that’s fine. People are so obsessed with competitiveness. It used to be about bits. Then Framerate, then resolution, then anti-aliasing. People will come up with any reason to be competitive. The best thing we can do is not to be absorbed in that.

There’s a lot, lot more in the podcast that would be worth writing down here. You will just have to listen to it for yourself!

Many thanks to Flibit for his availability!