I’ve been checking on the progress on the Xamarin front. As you may remember, we are phasing out the Xamarin backend. 我一直在坚持Xamarin前面的进展。您可能还记得，我们正在逐步淘汰掉Xamarin后台。 It

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.我创建了一个基于libgdx模板的Gradle，你现在能启动。它现在就可以开始使用，它最终将替代我们目前的setup-ui，使我的生活更有趣。它也将允许你构建和允许你的libgdx工程在CLI,Eclipse,IntelliJ和Netbeans.而最重要的是，你将不必在任何JARs或者更多本地库之间周旋，每一件事情将为你小心关闭。你能更新到不同libgdx版本,并且容易包含扩展的或其他第三方库。那么，这个神奇的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.

Gradle是构建和依赖管理系统，用Groovy和一些特定域的语言sugar.构建系统是负责编译你的应用程序和打包。一个依赖管理系统允许你定义你想用的第三方库，且系统将自动为你放那些库。准备的库是可用的在一些资源库里。历史最悠久的库在Java领地和Maven资源库,Maven中央仓库，几乎所有的事情都发布在全球中央仓库。

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):

下面是定义了一个libgdx工程在Grdle的许多依赖是什么，也用于FreeType和Bullet扩展（还没有GWT和iOS）。

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.

大约2-3周，现在我一直积极地切换我们的libgdx游戏开发引擎的iOS从Xamarin/IKVM到RoboVM.对于哪些近几周未更新最新版libgdx，这儿有一个详细说明为何我们要用RoboVM.

##What’s RoboVM?

##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.

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.

祝老婆开心快乐！ 祝全家人身体健康！ 也祝大家一切安好！ 中秋快乐！

Forcing a crash is a great way to test out the SDK, but is actually a little more tricky than you might think. 强制crash是很好的一种测试SDK的方式，但实际上是一个比你想象的更棘手一点。 How to force a crash We've built

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. 今天我继续工作在一些RoboVM后台待办事项上。 多点触控 现在完

A couple of quick updates. First of all, you can track the progress and todos on the RoboVM backend in this file. 一对快速更新。首先，你可以在这个文件中跟踪RoboVM后台进度和待办事项。 A couple of bugs have been fixed, including Preferences and various

To all watchers of the libgdx repository: i’m terribly sorry and hope i didn’t interfer with your work in any way

致libgdx资源库的所有关注者：我非常抱歉且希望我没有以任何方式干涉到你的工作。

This is meant as a cautionary tale about using Github’s API on a repository with quite a few watchers (460 in this case).

这是一个警示的故事通过在资源库上使用Github的API针对不少的关注者。（这个案例中是460）。

Earlier this year we migrated our code from Google Code to Github. We didn’t have a good migration plan for the 1200 or so issues back then, so we kept them on Google Code. We now have about 1700 issues on the tracker

今年早些时候我们从Google Code迁移我们的代码到Github。我们没有一个好的迁移计划去迁移1200个左右问题，因此我们保持他们在Google Code上。我们现在有大约1700个问题跟踪。

Today i finally wanted to tackle the issue tracker migration, using a Python script i found on Github. The script requires one to specify a Github user account that owns the repository the issues will get migrated to. I did a dry run on a fork of the main repo using my Github account, fixed up some issues in the script, and validated things to the best of my abilities. Things looked good.

今天我最终想去处理问题跟踪迁移，用一个我在Github上找到的Python 脚本。这个脚本必须指定一个我们将迁移到的自己资源库的Github 用户账号。我用我的Github账号在主资源库的一个fork上做了一个枯燥无味的运行，在这个脚本里解决了一些问题，且尽我最大的能力进行了验证。事情看起来挺好。

Then i ran it on the main repository. Luckily i was watching our IRC channel. After about 4 minutes, people started to scream. They each received 789 e-mails from Github. Every single issue i migrated, and every single comment of each issue triggered an e-mail notification to all watchers of the main repository.

然后我运行它在主资源库上。幸运地我一直在看我们的IRC渠道。大约4分钟后，人们开始尖叫。他们每个人都收到来自Github的789封邮件。每一个我迁移的单一issue，并且每一个issue的每一个单一注释触发一封邮件提醒给主资源库的所有关注者。

This wasn’t apparent to me during the dry runs, as i used my own Github account. The script posts all issues/comments with the user account i supplied, so naturally, i did not get any notification mails.

这个枯燥无味的运行对我来说不是显而易见的，作为我用我自己的Github账号。这个脚本用我提供的用户账号发布所有的问题或评论，所以自然地我没有接收到任何提醒邮件。

I stopped the script after 130 issues (4 minutes), and immediately started sending out apologies and a mail to Github support, to which i haven’t received an answer yet. I send roughly 300k mails through their server in a matter of minutes. If i hadn’t watched IRC, i’d have send out about 4 million mails to 460 people within an hour.

我在130个问题(4分钟)后停止了这个脚本，并且立即开始发送道歉还给Github支持一封邮件，我还没有得到答案。我通过他们的服务器在短短几分钟内就发送了大约30万封邮件。如果我没有看IRC，我肯定会在一小时内发送大约400万封邮件给460个人。

We are cleaning up the core a little, and in the process eliminate usage of Java collections and replacing them with our own collections. 我们正在清理核心的一点，并在这个过程中用我们自己的集合去替换和消除使用的Java集合。 One of our

A little less than a year ago, we moved all our code from Google Code to Github. That was a nerve racking but ultimately beneficial task. Since our move, we had almost 600 pull requests! 不到一年前， 我们迁移Google Code上所有代码到Github。它是