Update on Xamarin Studio & libgdx on iOS

Small update on the libgdx on iOS issues we talked about yesterday. First of all, i rebuild our IKVM-monotouch fork with the latest MonoTouch toolchain. The assemblies now reference the new signed MonoTouch assemblies. The updated IKVM build can be found in the nightlies.

If you downloaded the latest version of Xamarin’s iOS line (formerly known as MonoTouch, now known as Xamarin.iOS), your libgdx project will most likely crash. This is due to Xamarin Studio calling pngcrush, a supposed PNG optimizer.

nqffYxf

Libgdx’s image loading library of choice, stb_image seems to have problems decoding these crushed PNGs. You will see the following stack trace:

kbIgfUO

Now, the older MonoTouch version used MonoDevelop. That called a script called iphoneos-optimize. This resulted in the same problem, so we proposed a workaround, boiling down to modifying the script. The script was only called for device builds. In the new Xamarin Studio, pngcrush is called for all types of builds.

I reached out to some nice folks at Xamarin, which told me that a project setting will be available within 1-2 weeks that will allow us to turn of pngcrush easily.

If you can not wait, here is a temporary workaround. First locate pngcrush on your Mac. In the terminal:

Create a backup copy of it.

Create a file called pngcrush with the following content

this simply copies the file specified in the 5th parameter to the file specified in the 6th parameter. That’s what Xamarin Studio would pass to pngcrush as we saw above.

Now replace the pngcrush executable in the directory we located previously with the hackish script file. Double check that you made a backup!

Voila, all your iOS builds will start working again.

Again, this is only a temporary hack. Once Xamarin Studio gets updated, we can savely copy back the pngcrush file to its original place, and just flip a switch in the iOS project configuration.

I’ll post an update once the Xamarin studio update is out of the door.

Xamarin 2.0 relaunch and libgdx on iOS

That was an interesting night… This is a story of trying out coding things while being sick with a nasty flu your beloved american super best friend called Nate brought into your house. Don’t do it. Let’s recap. (Scroll to the bottom for a summary)

Oh no Xamarin Studio broke libgdx! (Not)

I started out by updating to the latest and greatest Xamarin.iOS (formerly known as MonoTouch, still displayed as Monotouch in the version info, confusing). Getting the update took a while. I first tried the auto-updated in MonoDevelop, but that didn’t show up any new updates. Turns out you have to get the installer from their site (just click any of the download buttons), and install it manually on top of my already existing MonoTouch installation.

Once installed, i opened their new IDE, called Xamarin Studio. Super slick and shiny, reminds me a bit of XCode. I started testing all our demoes, beginning with a test of the freetype wrapper. I usually try release and debug builds on both the simulator and an actual device on every MonoTouch update. The debug build worked on both the simulator and the device, the release build only worked on the simulator. For whatever reason, MonoDevelop/Xamarin Studio doesn’t show stacktraces when running something in release build, so i had to figure out how to do that. Turns out it’s simple. In the shell, do:

That will log any and all output of your iOS device. Turns out it was a linker issue that was easily resolved. Nothing you have to worry about, it’s a local build.

With that issue out of the way, i tried the next demo, Super Jumper. That one crashed on all build profiles. It took me about an hour and a half to figure out why.

With the old MonoDevelop, the iphone-optimizer script of XCode is invoked. That script “crushes” your PNGs, essentially making them non-PNG format compliant. We use the awesome stb_image for image loading, which naturally chokes on a non-compliant PNG. To work around this issue, we advise our users to modify that script, so no crushing happens.

For an hour and a half, i did not think about that being a problem, but it turns out it was. The new Xamarin Studio IDE doesn’t invoke iphone-optimizer, but instead invokes pngcrush directly. That effectively killed our little script hack. The fix is mostly straight forward: replace the pngcrush binary with a custom bash script that just parses the input params Xamarin Studio passes to pngcrush and copies the files from the source location to the output folder. I haven’t done that yet, cause my head is exploding and my nose is a waterfall. I’ll follow up with new instructions tomorrow here on the blog, as well as an updated wiki article.

The curious case of all those new MonoTouch licenses

Xamarin revamped their entire line-up, new features, new licenses, new everything! You can now get a “Free” license, that allows you to deploy to the app store, but with a limit in app size and features. One of the missing features is p/invoke, a mechanism that lets you call native code (C/C++/Obj-C/what have you) from within a managed C# or in our case Java application. Libgdx depends on native code for many of it’s API implementations. This means that the “Free” license will not work with libgdx.

Previously, we suggested our users to download the free MonoTouch Trial, which lets you test your stuff on the simulator only. This gives you at least some way to evaluate if libgdx + iOS is for you, before shelling out a few hundred bucks for a MonoTouch license.

Naturally, i was a little disappointed. Not being able to offer our users a way to evaluate libgdx + iOS before shelling out the money means that i feel a lot more responsible should someone pay for a license and have things not work out afterwards. Without a trial that works with libgdx, folks would have to pay a license before even being able to try out if their stuff will work.

Xamarin is not to blame here, the average user will be fine with the “Free” license for small apps, as p/invoke on 3rd party libs and the size restrictions aren’t that big if a deal. The “Free” license is actually a good thing, just not compatible with libgdx.

I took my confusion to Twitter and was quickly responded to by a nice chap called Michael Hutchinson. Michael enlightened me that the “Free” license is actually not a sort of Trial, but that there is in fact a real “30-days business Trial” version, just like with the old MonoTouch. The “Trial” version doesn’t have any limits on features or app size. You can deploy to both the simulator and the device with it, something you couldn’t do with the old trial. The only limitation is that you can’t deploy to the app store, and that your app is time limited.

This means that you can test libgdx + iOS on both the simulator and an iOS device with the 30-days business Trial!. Fantastic news actually, as the device might behave differently to the simulator. You can now fully develop your app for iOS, and only if your device release build works, you can consider buying a Xamarin.iOS license (formerly known as MonoTouch? I’m still confused).

Did i mention the licenses for indies are cheaper now? Instead of the previous 399$ they are 299$ now. Sweet. I’m not sure if the student licenses are still available, just drop Xamarin a mail if you qualify.

In Summary

  • The latest Xamarin release of Xamarin.iOS (formerly known as MonoTouch) works with libgdx.
  • A simple tweak is necessary, similar to the old iphone-optimizer trick. I will post info on that tomorrow
  • The new “Free” license does not work with libgdx
  • The Trial version does work. Oposed to the old Trial, you can now even test on your device before shelling out money for a license!
  • The “Indie” license works with libgdx, and costs 299$ instead of the old price of 399$. Note that LLVM is not supported (wouldn’t work with libgdx anyways)

I’ll also rebuild IKVM-monotouch once i feel a bit better. Not up to mess with that in my current state.

P.S

All the above said, i still feel a bit uneasy relying on paid-for, non-oss Software. Xamarin is an amazing product, but our use of it (IVKM-monotouch) does not qualify as a standard use case. As such, Xamarin does have no responsibility to keep IKVM working with Xamarin.iOS. It would be nice to have a readily available fallback, like RoboVM. Volunteers?

Vector2 Changes & Upcoming changes to Vector3/Intersector

We are about to remove all the temporary Vector2 instances from libgdx. Reasons:

  • Most of our Math classes are not thread-safe. Some methods use static scratch vectors and matrices. Invoking those methods on multiple threads will result in unexpected results
  • Using the same temporary multiple times in a single calculation can lead to issues. This is likely to occur if your calculation involves a method that internally uses a temporary

As a first step, we removed the temporaries from Vector2, as well as the Vector2#tmp() method. If you relied on those temporaries, the solution is easy: create your own statics in your application.

We’ll do the same for Vector3 in the near future.

Also, Intersector will change. You will have to instantiate an Intersector object. If you do things multithreaded, you can instantiate one Intersector object per thread to keep things thread-safe.

As a side note: Xoppa introduced a Vector interface. That way you can treat Vector2 and Vector3 almost like they where the same thing.