First RoboVM/libgdx app in iOS App Store

For about 2-3 weeks now i’ve been actively switching our libgdx game dev framwork’s iOS efforts over from Xamarin/IKVM to RoboVM. For those of you who missed the last few weeks of libgdx updates, here’s a breakdown what RoboVM is and why we use it.

What’s RoboVM?

The promise of RoboVM is a fully workable ahead-of-time compiler for JVM bytecode for iOS (and 32-bit Linux/Mac if you fancy that). RoboVM uses Soot and LLVM to transform the bytecode to native x86 or thumbv7 ARM code. RoboVM employs Android’s latest runtime class library iteration, making it compatible with pretty much any JVM library/language out there. RoboVM also comes with a set of bindings to the ObjC APIs of iOS. These bindings are realized via a custom Java-to-native bridge called Bro, and generated automatically from header files, with minor manual intervention. JNI is of course also supported, pending some more esoteric features.

Libgdx, Xamarin & RoboVM

Previously we leveraged Xamarin iOS plus a port of IKVM by Michael Bayne of PlayN fame to get our Java based game dev framework to work on iOS. This combination worked, but had its flaws. For one, not all of the Java runtime classes were supported, most prominently the package. Also, some parts we heavily rely on in libgdx, like JNI, were extremely slow with the Xamarin/IKVM hack. Note that this is not an issue with Xamarin iOS itself, but due to the nature of the IKVM port. Xamarin have been extremely helpful and gave us a few licenses at a very low discount for development. All this limitations also meant that running anything complex was always a gamble, and using other JVM languages was pretty much out of the question.

RoboVM fixes many of these issues. The JNI bridge is considerably faster, there are less layers of abstractions, all of the Android runtime classes are available, it will allow us to write games in Scala and JVM languages other than Java, and best of all, it’s entirely open-source under Apache 2. Libgdx development on iOS thus becomes essentially free, apart from the Apple tax (developer license, need for a Mac). Note that Trillian AB will eventually have to start looking into options to further fund RoboVM. If we get a chance as a community to help fund RoboVM, we should definitely do so. RoboVM is shaping up to be an excellent tool, and i think it’s worthwhile to support, just like Xamarin.

Niklas Therning from Trillian AB, creator of RoboVM, has laid the foundation for our RoboVM backend by porting our Xamarin/IKVM based libgdx backend over to RoboVM. We’ve since been fixing up many issues and missing features, and are reaching feature parity with the Android backend. You can follow the todo list on Github.

First RoboVM/libgdx App on iOS App Store, many to follow

To prove that RoboVM is a viable option, Niklas submitted the first RoboVM-based app to Apple last week. I supplied Niklas with the rights and sources for our libgdx Super Jumper demo. While it’s definitely not the fanciest game ever, it does exercise a large percentage of the few hundred thousand lines of libgdx’s managed and native code. Today, the app got approved by Apple, and is now available for your “enjoyment” on the App Store. I believe that this is an indication that our decision to go with RoboVM was the right one.

Meanwhile, others have started porting the libgdx-based games over from Xamarin iOS to RoboVM. Here’s the RoboVM version of Delver, by Chad Cuddigan, aka Interrupt. You should totally buy it either on Google Play or Steam! I did the “port”, which boiled down to converting oggs to mp3s and implementing a missing feature in our libgdx RoboVM backend.

Christoph of Noblemaster Games ported both hist latest game Demise of Nations as well as an older title called Desert Stormfront to RoboVM (you can buy Desert Stormfront and other games on the App Store, Google Play or directly from his site!). Both ran out of the box (Christoph, correct me if i’m wrong :)). Christoph also observed a considerable performance improvement going from Xamarin/IKVM to RoboVM:

Jonnus ported their libgdx game game Wings of Fury from Xamarin/IKVM to RoboVM as well, seeing pretty significant increases in performance. I’d attribute those mainly to the better JNI implementation in RoboVM.

You can find other stories on the forums.

Next Up

I plan on finishing the last bits of our RoboVM backend in the next few days to achieve feature parity with the other platform backends. Once that is complete, i’ll revamp our beloved setup-ui and replace it with something new. My goal is to make libgdx a truely polyglot game development framework, so we’ll need better integration with existing build and dependency management tools. I’m currently looking at Gradle, which seems promising, albeit a bit less ideal when it comes to IDE integration when compared with Maven.

Niklas is going to attend JavaOne in San Francisco next week. I hope he gets the time to demo some of the libgdx games we are currently preparing for this event.

Pretty cool to see how much can be done in just a few weeks. Thanks to our community for the support, and especially Pascal, Chad and Christoph for providing Niklas with real-world games he can demo at JavaOne! You guys rock!

More RoboVM Backend Updates

Today i continued working on some RoboVM backend todos. Multi-touch is now working properly, the fix was rather simple, once you understand that you have to enable multi-touch on a view in a single line of code on iOS.

You can now also use the gdx-freetype extension with the RoboVM backend. From the nightlies, get the extensions/gdx-freetype/ios/libgdx-freetype.a file, put it in your $ROBOVM_PROJECT/libs/ios folder, then add the following to your robovm.xml file:

You also have to link to the gdx-freetype.jar in your RoboVM project (or link to it from your core project, and make sure it’s exported in Eclipse).

I also managed to finally get the Bullet physics extension compiling for iOS. LLVM/Clang previously went into a “i’ll eat all your CPU” infinite loop. Applied a quick fix found on the bullet forums, and things compiled. Our wrapper uses SWIG to generate the JNI bridge, which in turn uses some more or less advanced JNI/VM features RoboVM doesn’t support yet. We’ll have to wait until that gets fixed in RoboVM before we can have our physically correct cloth simulations run on iOS.

In other news, i got all of Delver working on iOS today, including audio, which meant i had to convert all OGGs to MP3s for the iOS port. Apart from minor GC hiccups every now and then, the game runs at a splendid 60fps on my iPad 4.

Thanks to Chad Cuddigan, aka Interrupt, creator of Delver, for letting me get my dirty hands on the source! You can buy Delver on Steam or the Google Play Store.

Tomorrow i hope to find some time to tackle accelerometer and device orientation issues. Check the RoboVM backend todo list to get to know about the latest status.

Robovm backend updates

A couple of quick updates. First of all, you can track the progress and todos on the RoboVM backend in this file.

A couple of bugs have been fixed, including Preferences and various FileHandle/Files issues. Thanks for Niklas and Nex for that. Pixels per inch/centimeter calculations had a bug as well, that’s been fixed. The graphics context didn’t have a depth buffer, that’s been fixed as well.

I extended the IOSApplicationConfiguration so that you can specify the color depth, depth buffer precision, stencil precision and multisampling. You can also set a preferred frames per second value.

There are still a few issues that need ironing out. Multi-touch support has the highest priority, followed by orientation and accelerator fixes. After those it’s time to test all other features.

If you ran into issues with the JSON class, here’s a tip on how to get things going. You need to tell RoboVM to force linking in the classes you read in via JSON through reflection. You can to that in the robovm.xml file like so:

Which links in all classes from that package. You can also use other Ant like patterns, e.g. ** to include everything in a package recursively.

And finally, check the forums, a couple of folks already ported their games over, reporting very nice improvements in performance. Here’s Delver which i ported in about 30 minutes 🙂

Stuff is in constant flux, so make sure you update both the libgdx nightlies and the RoboVM Eclipse plugin. To update the RoboVM libgdx stuff, make sure you replace gdx.jar, gdx-backend-robovm.jar, and the ios/libgdx.a file in your RoboVM project!