libgdx RoboVM backend

I started working on the libgdx RoboVM backend yesterday. RoboVM is an ahead-of-time compiler for JVM bytecode, that targets iOS. It’s completely free for commercial usage, supports the entire JRE (through Android’s runtime class library), has super easy integration with Eclipse and soon Maven, and is all-around fantastics. Development is really fast, compile times are in the seconds range for the simulator (once the JRE has been compiled).

I’m doing this mostly because i want to offer a free alternative for the Xamarin/Monotouch based backend. Xamarin has been super supportive of our efforts in the past, but there are some technical hurdles that we can’t seem to overcome, e.g full JRE support, JNI performance, high compile times etc.

I got all our demo games to work in an hour. Niklas Therning, the guy behind RoboVM, supplied us with an initial RoboVM backend. I had to fix up a minor issues with ApplicationListener initialization order, and things just started to work.

It’s still early days. There’s a lot that needs to be done, but i have high hopes that this will become our new defacto iOS backend.

What’s currently missing in the backend:

  • touch coords are incorrect
  • no audio yet
  • Preferences are broken
  • some missing implementations

What’s currently missing in RoboVM:

  • Debugging
  • More optimizations. Performance seems to be good enough already, JNI calls seem to be a lot cheaper than with IKVM/Monotouch. I’m not sure if RoboVM uses LLVM’s full optimization pipeline yet.
  • A few bugs here and there, which we want to help to discover. RoboVM is tested against Android’s class library test suite, and pretty much all the tests pass.

One downside to RoboVM, apart from missing debugging support, is the use of the Boehm GC. Now, Mono (and hence Unity et al.) have been using that for quite a while, and with a little care, one can work around it’s issues (stop-the-world pauses).

My plan is to focus on this backend in the future, and only do maintenance on the Monotouch backend. If you feel to be able to help with the RoboVM backend, i’d welcome your contributions!

You can currently test the thing by

The backend source can be found on the master branch on github. It’s just like any other libgdx backend, single Java project that links to the core API and RoboVM runtime classes. Creating a new libgdx robovm project is as simple as linking to gdx/gdx-backend-robovm, and modifying the robovm.xml, robovm.properties, and info.plist files to meet your project’s requirements. See the demo game projects for examples.

I’ll package up the robovm backend in the nightlies asap for you to consume. For now you’ll have to work from source as outlined above.

And here’s a screeny:

box2dlights now build nightly

Many folks are using Kalle’s box2dlights library. As the name implies, it’s a box2d based 2D lighting system, that’s very simple to integrate into your game. We now build nightlies for it on the build server. I highly suggest using those from now on. You can find them at http://libgdx.badlogicgames.com/box2dlights/ Works with all backends, including the GWT backend thanks to siondream providing a few minor fixes.

Obligatory screenshot:

fbx-conv update

fbx-conv is a command line utility that parses Autodesk FBX files, and outputs a custom, ready for runtime consumption, 3D file format (either json, or binary json). The 3D format supports vertex skinned, animated hierarchical objects, with materials.

Since service is our success, i spent the better of this afternoon getting the damn thing to build on our build server. You can now fetch freshly compiled binaries for all platforms from http://libgdx.badlogicgames.com/fbx-conv/ without having to compile anything yourself.

Read the README.md file that comes with the distribution. Execute fbx-conv without arguments to get to know your options.

Xoppa started writting lightweight tutorials on our new 3D API. The second part shows you how to load our custom format files.

More info to come…