Libgdx on iOS, day 4

When i said ALL the native stuff was working on iOS i was of course wrong. Turns out the IKVM MonoTouch port was missing some essential capabilities, namely, calling into Java from native code. This is needed for Box2D callbacks and things like determining the position of a direct ByteBuffer in the OpenGL wrapper code, among other things.

When Michael started porting IKVM to MonoTouch he ran into a couple of issues, among which one was the way IKVM handles reflection (which in turn is also used when calling Java from native code). IKVM actually performs code generation to speed up reflection, much like Java tools like ASM allow one to do. On iOS this is a no-go, since you can’t make memory executable and hence can’t JIT compile things. Michael went ahead and kinda operated on an open heart, ripping out the code generation reflection backend and replacing it with the slower, standard reflection that just looks things up like crazy all the time.

This works pretty well, safe for some performance loss. Except that a crucial part was missing: the JNI methods native code can call to invoke a method on a Java object went nowhere. It took me a while to figure this out, as i had to navigate the code of IKVM manually. Eventually i found the culprit: MemberWrapper#invokeJni was not implemented for the MonoTouch port. I changed it to use the slow reflection mechanism and things started working as expected. I issued a pull request for the simple fix which you can find here.

Moral of the story: our dependency on native code can turn up surprising issues on iOS at times.

6 thoughts on “Libgdx on iOS, day 4

  1. I don’t expect my comments to boost morale much, but I want to thank you for basically the entirety of libgdx. It relieves me even further to know you’re working on an iOS port. I was dreading porting myself since I believe in releasing on android and iOS at the same time. Having only limited iOS experience, it would have delayed the release of my project another year or so. The same way doubled screen resolutions like retina forced me to redo all of my hand drawn 2d assets in a massive world.
    I will contribute when it makes more sense for me to do so. I could lose the house if I do it now. Thanks again. I encourage as many as I can to use libgdx. It saves so much time in android development you would have to be insane to not use it.

  2. First off I just want to say you are an inspiration! Amazing stuff, man.

    With that said, I can’t wait for LibGDX iOS. Any early guesses on when it will be complete?

    Also, how would this work if I develop mainly on a PC? Can I just copy my main project code from my PC setup to my Mac setup at the end of the day?

    Thank you for everything.

  3. I am not an expert, but does not easier to translate GDX from java to Objective C then to use these solutions with monotouch and other mojo?

  4. Bojan, no that won’t work. No GC, no memory model, no standard library. The JVM environment is more than just the Java language itself.

  5. Randy, yes, you just fireup Eclipse on a Mac/pc, modify your shared core project, then run MonoDevelop to compile and run your app on the simulator/device. The later step only works on a Mac.

Leave a Reply

Your email address will not be published.