Tag Archives: LibGDX

Last November, after updating to OS X “El Capitan”, we started seeing a strange warning message when running DragonScales 2:

“WARNING: 140: This application, or a library it uses, is using the deprecated Carbon Component Manager for hosting Audio Units. Support for this will be removed in a future release. Also, this makes the host incompatible with version 3 audio units. Please transition to the API’s in AudioComponent.h.”

DragonScales 2 was built with LibGDX, and before updating to “El Capitan” it did run with no problems, warnings, etc. After some research, we were informed that this was caused by an OpenAL-Soft issue (which has already been fixed.) Specifically, Apple is deprecating some libraries, e.g., the Carbon Component Manager, and the OpenAL-Soft library was referencing such deprecated Carbon Component. When a game referencing these deprecated libraries is executed, newer OS X (e.g., El Capitan) shows the above warning. However, as told, this OpenAL-Soft issue was already solved on last November: the library is updated and ready for prime time.

A build of OpenAL-Soft is part of the LWJGL natives bundled with LibGDX. If you don’t use an updated build of OpenAL-Soft you’ll keep receiving the deprecation warning. As we commented on this thread, a quick fix is downloading the latest LWJGL3 build, grab the native libopenal.dylib and drop it over the OpenAL native bundled with LibGDX.

A caveat, though, about using the OpenAL-Soft included in LWJGL3 (at time of writing.) Some testers of DragonScales 2 for OS X reported a nasty crash. Here’s part of the crash report:

Clearly, our OpenAL library was referencing a function not provided by OS X. It turns out that our testers were using an older OS X version (10.7, I think) whereas the libopenal.dylib bundled with LWJGL3 was targeting OS X 10.9. In fact, output of otool -l libopenal.1.17.0.dylib includes these lines:

cmd LC_VERSION_MIN_MACOSX
cmdsize 16
version 10.9
sdk 10.9

As our publishers require support for OS X >= 10.7, we had to compile our own libopenal.dylib. We set OS X 10.6 as deployment target and 10.11 (El Capitan) as the root SDK, by using these CMake variables:

After its Windows, Mac and Linux release, DragonScales 2: Beneath a Bloodstained Moon is getting ready for Android. We’ve been testing the Android port of our new game and so far, so good. Here are some screenshots of the game running on a Kindle Fire device:

There are still some minor fixes to apply, such as adjusting strings (“Click” to “Tap”, etc.) but everything looks fine so far!

Good news! A few months ago we developed The Rainbow Machine Air Edition, a version of our game The Rainbow Machine tailored to harness the incredible capabilities of Leap Motion devices. Our game is now available for free in the Airspace Beta program, so if you’re a Leap Motion user with access to the Beta program, please take a look at our game here. All your comments are welcome!

Essentially, The Rainbow Machine Air Edition uses Leap Motion’s gesture detection and motion tracking device and API to offer a novel play experience. As our game is based on LibGDX (using LWJGL as backend for desktop) integrating the Leap Motion API was a pretty straightforward task, which allowed us to release the game for both Windows and Mac OS X. Regarding the gameplay: in The Rainbow Machine Air Edition you use your fingers (or “tools” like some chopsticks or pencils) to control and position a bar. In each of the game’s 140 levels, once the bar is set, a blue ball will automatically fall down and if you have properly placed the bar then the ball will bounce and reach the treasure chest of the level!

Do you want to know what’s the most important part about The Rainbow Machine Air Edition?… That we had a lot of fun creating our Leap Motion game! And we hope everyone who plays The Rainbow Machine Air Edition will also experience a fun time. By the way, it’s been a great pleasure to work with the Leap Motion team: support is prompt and complete, they gave useful feedback, conducted an exhaustive testing of the game, and provided a flawless guidance throughout the process. A pleasure to work with them, indeed.

Now we’re looking forward to the official opening of Airspace. Stay tuned! And thanks for reading! 😀

The author of LibGDX has just published an excellent and reflective post: THE JVM – A VIABLE PLATFORM FOR (MOBILE) GAMES?. A thought-provoking reading. Our humble answer to this question is yes. But things could be better, much better. For instance, as we all know, the approach to port your LibGDX game to iOS, albeit effective and a victory of cleverness, is notoriously contrived. It feels like we are working with fine porcelain which could break anytime, anywhere. Even for the desktop, Java game development and distribution can pose unexpected challenges. For instance, bundling your jar for distribution on Windows can face surprising hurdles:

We cannot provide further details because of NDAs, but there are some DRM wrappers which don’t interact well with launch4j outputs.

Bundling has to take special care to handle the “Missing msvcr71.dll” problem (Java 6. For Java7 your problem will be msvcr100.dll). Take a look at this.

On Mac OS X, things might get even harder. You’ll have to use the AppBundler, work through several configuration files, and even compile your own JRE.

Regarding mobile deployment, well, if you’re using LibGDX, Android is your most natural mobile target. iOS is possible too, but it’s not that natural mostly because Java is not a first-class citizen there. Blackberry devices, which allow for Java development, are not possible at the moment with LibGDX because BB has no JNI support. For Bada you’d use C++. For Firefox OS you’d use HTML 5. Tizen is based on HTML5 (may support Java too). Play Station Mobile requires C#. Windows Phone 8 allows C++, C# and Visual Basic, I think.

That said, we’re not big Java fans. Honestly, we’d rather work on C++, or Python, or C#, or even PROLOG, and we really don’t care that much for the other languages that target the JVM. We’d rather work on Vim with a bunch of makefiles. However, after completing our first game, NagiQ, a word game for desktop, we wanted to be able to deploy our next titles on mobile devices, specifically, Android devices. As Google insists on Java as your first language of choice, we followed the Java/LibGDX route. The great part here was LibGDX. Java is a good language, but what we really enjoyed was using LibGDX: its design is very, very good. What we want from a framework/SDK/library is good abstraction layers and cross-platform capabilities, and LibGDX excels at offering both. Furthermore, you can go lower level if needed, and you can browse and alter the source code if needed. That’s wonderful. We are much less interested on tools. Our dream: LibGDX in C++, coding with Vim, having a set of makefiles for automagically creating versions of our games for desktop and several mobile targets (Android, iOS, BB, PSM, etc). A dream. Just a dream.

Our feeling is that the JVM is getting behind. C# is becoming the preferred managed solution out there on mobile devices. For the time being, our plan is to stick to LibGDX. And as LibGDX is based on Java, we’ll keep using Java.

This little post is an answer to a comment in Hacking LWJGL, LibGDX and The Rainbow Machine. By the way, please note that the workarounds discussed on such post are not needed anymore, as LWJGL team has fixed the reported issues.

Warning

LWJGL for Mac OS X (using Java 7) is still labeled as experimental. It might contain bugs. As of this writing, there is no official release yet. Thereby, please be very careful if you’re planning to use this experimental branch, and test your game thoroughly. Read this thread to understand what’s the current status of this branch.

For a couple days I’ve been busy browsing and modifying source code. The best part of this work is that I’ve learned quite a lot by reading the internals of LWJGL and LibGDX: the authors of such libraries are really clever people. And definitively, the good design in these libraries makes them easier to understand. What I’ve been up to lately is porting The Rainbow Machine to Mac OS X, but using Java 7 (for now, the version currently on sale at FireFlower Games and Mac Game Store is based on Java 6.) The problem: LibGDX is based on LWJGL (for Desktop versions), and LWJGL was not working on Mac OS X with Java 7. However, the LWJGL gurus are already working on an experimental branch which has made great progress. It’s still labeled as experimental, though. I downloaded that version of LWJGL, compiled it, and updated my version of LibGDX. So far, so good. Now, time to change The Rainbow Machine project. I replaced my “official” LibGDX libraries with the ones I had just compiled… and after that the game refused to run.

Further tests showed that LibGDX was getting locked in Display initialization. This lock can be prevented if we ensure that AL.create() is called after Display initializaton. This is a LWJGL thing, because the following simple LWJGL program won’t run either:

There is a clear workaround: swap audio and video initializations. I did the germane modifications in LibGDX (I changed LwjglApplication.java), et voilà, the game runs nicely.

Then I kept playing for a while and did not notice any issues until I decided to close the game by pressing CMD-Q: the game was immediately killed, and that’s not the desired behavior. I want The Rainbow Machine intercepting CMD-Q and behaving as if the red X close button was clicked. In fact, closing the game by means of the menu has a similar effect to CMD-Q. After reviewing LWJGL and the Java source code, I found a simple workaround. I was expecting windowShouldClose in org_lwjgl_opengl_Display.m to be called whenever CMD-Q was pressed. However, windowShouldClose is only called when the window is going to be closed. The window, not the app. If I close the app by clicking on the red X close button, windowShouldClose is indeed invoked. But CMD-Q does not trigger it.

Then I took a look at QuitStrategy, and set it to CLOSE_ALL_WINDOWS (the default action being SYSTEM_EXIT_0… that’s how the app responds, a direct exit(0).) However, modifying QuitStrategy had an unexpected outcome: CMD-Q stopped working, i.e., now the game would not close by pressing CMD-Q. A quick glimpse at Java’s source code revealed that Java dispatches a WINDOW_CLOSING event to the Frames of the game. It seems our game does not receive such notification, or I have yet to learn how to capture it. Thereby, I defined my own QuitHandler in createWindow (file MacOSXDisplay.java):

This handler simply cancels the game quit, and notifies MacOSXDisplay’s handler about the quit request. And that’s it. The discussion on this widely popular thread revealed that the LWJGL team was thinking of using CMD-Q for effectively killing apps immediately, as an option to kill a crashed LWJGL app (for instance, to avoid mandatory full reboots for crashed fullscreen apps.) However, they’ve noticed that holding CMD-Shift-Option-Esc for 3 seconds kills the app too. Therefore, CMD-Q won’t have to kill the app.

In the following days I’ll keep testing The Rainbow Machine. However, of course I’ll be waiting for a non-experimental release of LWJGL on Mac OS X. Specifically, I’d rather not to modify LibGDX: that’s a philosophical issue, suitable to internal workflow here in IKIGames. BTW, if you liked this post you migth want to follow us on twitter.