I’ve been sick the last few days, and figured i’d learn Gradle. I created a Gradle based libgdx template, which you can start using now. It will eventually replace our current Setup-UI to make my life more enjoyable. IT will also allow you to build and run your libgdx projects on the CLI, Eclipse, IntelliJ and even Netbeans. And on top of that, you’ll not have to juggle any JARs or native libraries anymore, everthing is taken care off for you. You can update to different version of gdx, and easily include extensions or other 3rd party libraries. So, what is this magical Gradle?
Gradle is a build and dependency management system, using Groovy and some domain specific language sugar. A build system is responsible for compiling your application and packaging it up. A dependency management system allows you to define which 3rd party libraries you want to use, and the system will automatically pull those libraries in for you. Provided the libraries are available in some sort of repository. The most established type of repository in Java land are Maven repositories, with Maven Central being the global central hub to which almost all things get published to.
Here’s what defining such dependencies looks like in Gradle for a libgdx project that also uses the FreeType and Bullet extensions (no GWT and iOS yet):
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.
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.
RoboVM许诺它是一个完全可运行的ahead-of-time编译为JVM字节码iOS(和32位的Linux/Mac，如你看中的那个)。RoboVM使用Soot和LLVM转换字节码为本地X86货thumbv7 ARM代码。RoboVM采用Android的最新运行类库迭代，使其兼容几乎任何JVM库/语言。RoboVM还带有一组绑定iOS的ObjC API.这些绑定实现通过一个自定义JAVA到本地的桥叫弟兄，并自动生成头文件，有轻微的人工干预。当然也支持JNI，处理一些更深奥的功能。
##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 java.net 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.
之前我们利用Xamarin iOS附加PlayN的Michael Bayne开发的IKVM的部分整合我们的基于Java游戏开发框架工作在iOS上。这种组合工作，但是有它的缺陷。例如，不能支持所有的Java运行时类，特别显著的是java.net包。此外，一些地方我们严重依赖于libgdx，像JNI,Xamarin/IKVM极其缓慢。注意这个不是Xamarin iOS自身的问题，而是归咎于IKVM端口的性质。Xamarin一直有非常有帮助，给了我们几个很低折扣的开发许可证。所有这个限制也意味着运行任何复杂的都是一场赌博，并使用其他JVM语言几乎都出问题。
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.