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.
祝老婆开心快乐！ 祝全家人身体健康！ 也祝大家一切安好！
Forcing a crash is a great way to test out the SDK, but is actually a little more tricky than you might think.
How to force a crash We’ve built a convenient API you can use to cause a crash:
[[Crashlytics sharedInstance] crash];
- First, make sure you place your test crashing code in a different place than applicationDidFinishLaunching. This is only for testing – Crashlytics will detect crashes in your applicationDidFinishLaunching method. A good place could be a button action.
- Next, compile, build, and run your app.
- Then, make sure that a debugger is not connected. By default, Xcode will launch applications and attach a debugger. This will prevent the crash from reporting – detach it!
- Force the crash by pressing the button you attached the crash code to, and then relaunch the app.
Advanced If you’d like to see other kinds of crashes, you can experiment:
int *x = NULL; *x = 42;
You may also want to raise an exception. Some common ways to do that are:
你或许也想去制造一个异常。一些通用方法是： ` [NSObject doesNotRecognizeSelector]; [arrayWithOnlyTwoElements objectAtIndex:3]; `
Keep in mind that exceptions are not guaranteed to a crash. (The full code path, including code in system libraries matters here.)
Fun fact Divide-by-zero is illegal on i386 and x84-64, but is a valid operation on ARM! Dividing by zero will cause crashes in the simulator, but not on iOS devices.
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后台待办事项上。 多点触控 现在完全可用，修复相当简单,你立刻就能理解，你必须启用多点触控，在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:
你现在也可以用RoboVM后台 的gdx-freetype 扩展。从nightlies获取
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.
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!
材料是在不断变化的，因此确保你更新libgdx最新版和RoboVM Eclipse插件。更新RoboVM libgdx材料，确保你在你的RoboVM工程里替换gdx.jar,gdx-backend-robovm.jar和ios/libgdx.a文件。
To all watchers of the libgdx repository: i’m terribly sorry and hope i didn’t interfer with your work in any way
This is meant as a cautionary tale about using Github’s API on a repository with quite a few watchers (460 in this case).
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.
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.
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.
We are cleaning up the core a little, and in the process eliminate usage of Java collections and replacing them with our own collections.
One of our contributors started with box2D, see this pull request.
- methods that returned ArrayLists, such as body.getFixtureList(), now return Arrays
- method calls to these objects will need to be change from ArrayList API to Array API, i.e. bodyFixtures.size() –> bodyFixures.size, bodyFixtures.isEmpty() –> (bodyFixtures.size == 0)
bodyFixtures.size() -> bodyFixtures.size,
bodyFixtures.isEmpty() -> (bodyFixtures.size == 0)
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。它是一个神经折磨但是最终是个有益任务。 自从我们迁移以来，我们收到了差不多600个pull request!
A few months ago we rewrote our website, with the help of Bitowl and XKlibur from IKIGames (whom you all should follow!). We added some nice features, like allowing you to submit your games to our gallery, among other things.
Now it’s time to complete the cycle. Today i’m going to migrate our issue tracker to Github, and move the Wiki there as well. Sinistersnare (you can meet him on IRC) went crazy and manually translated our entire Google Code Wiki to a Github Wiki. Not sure yet how to repay him, but we all should be super proud to have such kind souls in our community!
现在是时候完成整套了。今天我将迁移我们的问题跟踪到Github,并且也移动Wiki. Sinistersnare（你能在IRC见到他）疯了并且手动转移我们的整个Google Code Wiki到Github Wiki. 不知道该怎么报答他，但是我们都应该超自豪的在我们的社区有许多心灵鸡汤。
The final step will be to integrate the wiki with the official site, and replace the current documentation page. This will be done in a similar way as it’s already done for the news blog posts. And i will add a comment system via Disqus so folks can leave comments. The Github Wiki will be publicly editable, through the history we can track if someone does something stupid and revert. I hope this will futher help improving the libgdx documentation and make it easier for newcomers to find the info they need.
Wish me luck and send a pony to sinistersnare!