Post news RSS Porting "Blocks That Matter" to Win/Mac/Linux

Mono Game and Java : two methods, two results. We explain the differences between them and which one we have chosen. Video included.

Posted by on

Blocks That Matter is already available on Xbox Live Indie Games, so it was developed using C# language and Xna framework. Xna is a framework only running on Xbox or PC (windows only). All of these take advantage of the .NET Framework 4.0, a Microsoft technology.

Since we really want to consider Mac and Linux users, we decided to port the game to those platforms with a single version.
There were some choices to make. I came with 2 solutions, and will see what will give the best experience on the 3 platforms.

> The ‘easy’ way

Some dev friends (Garry, Marc and Elisée) pointed me out “Mono Game”.

> Presentation

Mono Game
is a cross-platform port of the Xna Framework that uses Mono instead of the .NET Framework. So, what is Mono (quiclky)?

is a cross-platform implementation of the .NET Framework (including compilers). It means that if you program using Mono, you will write exactly the same code that if you were using .NET Framework itself… but your code will run on all platforms Mono supports.

Mono only deals with .NET Class/Compiler/CLS, there is no binding for libraries useful to make games (like hardware accelerated rendering, audio, gamepad input, etc).

In order to have such libraries support, Mono Game use OpenTK. OpenTK allows a .NET (and Mono) wrapping of C libraries such as OpenGL (for rendering) and OpenAL (for audio).

> Why this is the easy way?

With the last complicated paragraph, you may wondering why the hell this is supposed to be the ‘easy’ way, because it involves a lot of frameworks and libraries so far! In fact all of those libraries help you to keep your originally written C# code, all you have to do is compile against those libraries,
the syntax of your code will be the same. Sexy isn’t it?

> What I got so far with Mono Game

The Mono Game actual port take me less than a week-end. I made some modifications on the Mono Game library (which is open source) to be able to run Blocks That Matter because the library didn’t handle XML file loading/parsing, no keyboard input (only touch screen support for iPhone/Android).

There is no audio support for now in Mono Game, you’ll have to write it by yourself by using OpenTK (thanks to OpenAL binding), and make some Xna classes implementation too.

Since the sound support was not crucial for a first test, I decided to give it a try with no sound support. Here is what I got in few hours:

The rendering is a bit ‘laggy’ and this is not entirely due to the Fraps capturing. Even without Fraps, I get some very bad frametime (more than 33ms, since our game loop threshold the deltatime, knowing that a 60fps game take 16ms to deal with a frame).

I must investigate to see where is the bottleneck… maybe it’s in Mono Game… or maybe it’s simply in Mono. I don’t think it’s in the game code since the game was running well with the Xna/C#/.Net implementation, even on my crappy Mac Mini (running on Windows).

> Pros Mono Game
- Easy to maintain all the version (console, Win, Mac, Linux) since it’s the same codebase
- Not really much code to provide for the game to run with Mono Game
- Not really a port, more an ‘emulation style running’

> Cons Mono Game
- Very bad performances for now
- Not so easy to deploy on Linux (many dependencies)
- Not really a port, more an ‘emulation style running’ -(yep, that’s a cons too)

Here is the ‘hard’ way, not the ‘real hard’ one. It consists of porting the game code in Java, including an equivalent of the Xna Framework, and the functionalities brought by the .Net Framework.

> The "hard" way

> Presentation

Java is a programming language and has the particularity to be thought to ease the multiplatform deploying since it rely on Virtual Machines to run a bytecode.

Since Java is not meant to display hardware accelerated stuff, neither to play complex audio effects, a special feature allows Java to use some C or C++ libraries. It’s called JNI, and with it, some libraries like OpenGL (rendering) or OpenAL (audio) can be wrapped and manipulated from Java code.

That’s what I use through a ready to use library called LWJGL. This library eases the creation of many things (create window, OpenGL context, etc) and wraps useful library gaming oriented.

> Why this is the ‘hard’ way?

It’s the ‘hard’ way mainly because you have to rewrite some code (sometimes a lot), because Java and C# do not act the same way. Hopefully the two languages got some similarities: they both use a
managed memory system, and propose a strong Object oriented programming.

Since C# is some kind of Microsoft response to Java, the two languages share the same DNA, and it’s not rare to see some troubling similarities in the classes from the Java Classes Library and .NET.
Here is a function that says if an upgrader can open or not when the player collects a new piece.

These codes are very similar, sometimes it’s worst than that. Let’s say it’s a regular porting case.

> What I got so far with Java

Every cinematics and levels are loading. The inputs (keyboard and gamepad) are handled, the sounds are not implemented yet. Here what I get after between 2 and 3 weeks of porting the thing:

As you can see, the framerate is much better than the one obtained with Mono Game (running on the same machine with the same capture tools for the same time). There are still some stuff that are not very well implemented (like the font that are all fucked up, and the tetrobot eye positioning).

As for the Mono Game version, I didn’t implemented the sounds yet (even if part of the code have been ported).

> Pros Java

- performances are here for this little game
- sometimes really near from C# in term of code syntax
- in browser applet could be envisaged (to promote a level, or a demo)
- deploying on various platform with the same performance results (see image below)

> Cons Java
- sometimes really far from C# in term of code syntax
- have to rewrite (or copy/past and adapt) a lot of code

> What would be the "real hard" way?

The real ‘hard way’ port would have been rewrite the whole game in C++. But this mean that the rewrite would have been longer than Java, since C++ has nothing to do with C# or Java (except they are all Object oriented languages).

> What's next?

I think I will concentrate my efforts on the Java version since it’s the one with the best performances and easier deploying. The next step for me is to get the sounds working. Then correct the
little bugs here and there, replace the placeholder font handling and make some Java optimization (because there is a room for optimization, my Java is quite rusty sometimes). And of course, including new functionalities for the PC versions.

Yep, that’s a lot of work! But you, PC gamers, deserve a decent version of the game too!
And I think we will need some volunteers to run a test sample on their machine (we already got some volunteers, but we will soon ask for more!).

See you next time!



Best perfomance-wise port would be C++ but it would look much more like a new game instead of a port, seeing the rewrite you'd have to do.

Anyways, I think Java would be the best option here, as it's similar to C# and can run in a lot of platforms.

I wish you good luck with the porting, and nice to see some developer looks foward on another platforms other than Microsoft's (I currently use Windows 7, but I'm a GNU/Linux lover too. :P)

Reply Good karma Bad karma+2 votes

Hi Alxe!

Glad to see that I'm getting the same conclusions as you: C++ would be the best but that will be more a rewriting of all the stuff than a port.

And yes, it's sad to see a lot of game coming only for Windows OS while many of MacOs and Linux gamers will not have a chance to even try those games.

We know some people that are waiting the Linux build, and we will be glad to hit Desura on Linux too :]

Reply Good karma Bad karma+1 vote

Thank you for choosing Java! It provides so much more cross-platform ability, which us awesome for us Linux users.

Reply Good karma Bad karma+2 votes

You're welcome,

That was the configuration where I feel the most comfortable regarding the user experience :) (and also regarding the amount of work on our side!)

Reply Good karma Bad karma+1 vote

I'm sorry to see that you chose Java over Mono but it's understandable considering that MonoTouch and XNATouch (XNA cross platform implementation) are both dead when Novell was purchased.

There are other mono alternatives which are much faster in performance.

Reply Good karma Bad karma+1 vote

Hi NullSoldier!

I'll be interested to know what are the mono alternatives that are much faster in performance. I'll will try them :)


Reply Good karma Bad karma+1 vote

This is why you avoid using C# from the beginning :P
I recommend you go back in time and never learn C#: instead become comfortable with C++. Then in the past you can write the whole game in C++ and not have to worry about Microsoft -to use the technical term- "owning your ***" ;)

Sorry: shouldn't be mean since you're clearly going to a lot of trouble to port the game to Linux and Mac. It's very nice of you: many developers wouldn't bother. Thank you for your time and effort - it really does mean a lot to us poor finished-game starved Linux-users :D

Reply Good karma Bad karma+3 votes

Swing Swing Submarine is getting a lot of exposure from XBLIG. Microsoft is taking a cut of their money, but there are thousands of console gamers out there that can now buy and play BTM that would never have seen it otherwise.

In my opinion, Microsoft is doing indie developers a favor.

Reply Good karma Bad karma+1 vote

Hehe, you're right wilbefast, we should have avoided C# :] But we really wanted to have a game running on a console before we die... and XNA was the easiest way to do this!
Since XNA do not allow you to use the C++ XDK... then we had 'no choice'.

We really care about all players, that's why we try to port it with the thing that would gave a great portability AND not a lot of effort to port the game.

As for C++, I'm comfortable with it, but I choose C# for the reasons above, and Java because Java and C# have a lot in common :)

Thanks for your comment! Really appreciated :]

Reply Good karma Bad karma+1 vote

There is another aproach, try - it offers great cross-compiler toolchain including .NET -> Java but also Objective-C and so on. It cross-compiles on byte-code level, so avoids code differences.

Reply Good karma Bad karma+1 vote
Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.