#robovm

Hi ! The libGDX Jam started yesterday, and the theme is "Life In Space". After a bit of brainstorming, I came up with an idea of a puzzle-platformer game in which you control a guy, in a jetpack equipped space suit that tries to escape his wrecked spaceship.

You can follow the complete devlog where I'll post the code details here : http://itch.io/jam/libgdxjam/topic/12039/apprentice-softs-devlog

Today I show you the very first video of this project. For now I did the Box2D and Tiled setup, and I work on the hero displacement mechanics.

More to come soon !

———————————————————– Salut ! Le libGDX Jam a commencé hier, et le thème est «La vie dans l'espace". Après un peu de réflexion, je suis arrivé à une idée d'un jeu de puzzle-plateforme dans lequel vous contrôlez un gars, dans une combinaison spatiale équipée d'un jetpack qui tente de s'enfuir de son vaisseau détruit.

Vous pouvez suivre le devlog complet où je vais poster les détails de code ici: http://itch.io/jam/libgdxjam/topic/12039/apprentice-softs-devlog

Aujourd'hui je vous montre la première vidéo de ce projet. Pour l'instant j'ai configuré Box2D et Tiled, et j'ai travaillé sur les mécanismes de déplacement du héro.

Desktop/Android/BlackBerry/iOS/HTML5 Java game development framework

In OMG Dancer! (Play | iOS) We wanted the players to be able to access their own music library to play the game with. Whilst this might be a simple feat if you are focusing on a single platform, but here at Super Cookie Games we like to go cross platform from launch. So this means that we need to learn how to access the music library on iOS and on Android.

The requirement was straight forward, we need to get access to the songs by genre id available on the device and then create a map of song id to genre name, then we want an array of all the songs on device.

First lets tackle Android. To begin with you will need a ContentResolver this is accessible from you Activity via a call to the method

getContentResolver()

This is actually in ContextWrapper which the Activity inherits from.

Once you have that you can simply query for the information, or content, you actually want. Like so.

Cursor genCur = contentResolver.query(MediaStore.Audio.Genres.EXTERNAL_CONTENT_URI, new String[]{MediaStore.Audio.Genres.NAME, MediaStore.Audio.Genres._ID}, null, null, null); if (genCur != null && genCur.moveToFirst()) { do { int nameIndex = genCur.getColumnIndexOrThrow(MediaStore.Audio.Genres.NAME); int idIndex = genCur.getColumnIndexOrThrow(MediaStore.Audio.Genres._ID); String genreName = genCur.getString(nameIndex); long genreId = genCur.getLong(idIndex); Cursor tempcursor = contentResolver.query(MediaStore.Audio.Genres.Members.getContentUri("external", genreId), new String[]{MediaStore.Audio.Media._ID}, null, null, null); if (tempcursor != null && tempcursor.moveToFirst()) { do { songIdToGenre.put(tempcursor.getLong(tempcursor.getColumnIndex(MediaStore.Audio.Media._ID)), genreName); } while (tempcursor.moveToNext()); tempcursor.close(); } } while (genCur.moveToNext()); genCur.close(); }

In the above code example you can see we are querying for the Genres of music on the device. The result is a cursor that we can iterate over to ge and we use that data to populate a map.

Next we can query for all the songs. It might be worth pointing out it is possible a song might not have a genre!

Uri uri = android.provider.MediaStore.Audio.Media.EXTERNAL_CONTENT_URI; Cursor cur = contentResolver.query(uri, null, MediaStore.Audio.Media.IS_MUSIC + " = 1", null, null); if (cur == null || !cur.moveToFirst()) { return; } int artistColumn = cur.getColumnIndex(MediaStore.Audio.Media.ARTIST); int titleColumn = cur.getColumnIndex(MediaStore.Audio.Media.TITLE); int albumColumn = cur.getColumnIndex(MediaStore.Audio.Media.ALBUM); int durationColumn = cur.getColumnIndex(MediaStore.Audio.Media.DURATION); int idColumn = cur.getColumnIndex(MediaStore.Audio.Media._ID); do { long songId = cur.getLong(idColumn); items.add(new Item( cur.getLong(idColumn), cur.getString(artistColumn), cur.getString(titleColumn), cur.getString(albumColumn), songIdToGenre.get(songId), cur.getLong(durationColumn))); } while (cur.moveToNext()); cur.close();

A little less complex than the genre request, this snippet is fairly straight forward. We query, get a cursor, extract the song information and then add a data object that contains all the information.

When it comes to playing the song, we just request the path of the file using the song id and pass that to our player.

String[] projection = {MediaStore.Audio.Media.DATA}; CursorLoader loader = new CursorLoader(context, getURI(), projection, null, null, null); Cursor cursor = loader.loadInBackground(); int column_index = cursor.getColumnIndexOrThrow(MediaStore.Images.Media.DATA); cursor.moveToFirst(); path = cursor.getString(column_index); cursor.close(); Uri getURI() { return ContentUris.withAppendedId(android.provider.MediaStore.Audio .Media.EXTERNAL_CONTENT_URI, songId); }

the path variable ends up being the internal path we need to play. Like so:

Gdx.audio.newMusic(Gdx.files.internal(path));

One thing to note is that I had to strip off “/storage/emulated/0” from the start of the path.

Awesome so that is Android, but what about iOS?

Well, we want to access the iPod API to get a list of all the songs the device knows of. This is pretty simple compared with Android, using RoboVM, we just make the following requests.

MPMediaQuery mpMediaQuery = MPMediaQuery.createSongsQuery(); for (final MPMediaItem song : mpMediaQuery.getItems()) { if (!song.isCloudItem()) { musicTracks.add( new Item( song.getPersistentID(), song.getArtist(), song.getTitle(), song.getAlbumTitle(), song.getGenre(), song.getAssetURL(), (long) song.getPlaybackDuration() * 1000)); } }

The only caveat here is that an iOS device will report cloud based songs as well, in this instance we filter them out.

Now, with Android playing the music track was straight forward, we got a path to it and played it! With iOS it isn’t as straight forward. You get an asset URL which is great if you plan on playing the music through the native player as you can just throw it at it! However we need to access the music so we can play it ourselves. Get ready for some funky coding gymnastics.

private void export(final Item item) { AVURLAsset avurlAsset = AVURLAsset.create(item.path, null); final AVAssetExportSession exporter = AVAssetExportSession.create(avurlAsset, AVAssetExportPreset.Passthrough); String extension = "m4a"; if (item.path.getPath().contains(".m4a")) exporter.setOutputFileType("com.apple.m4a-audio"); if (item.path.getPath().contains(".mp3")) { exporter.setOutputFileType("com.apple.quicktime-movie"); extension = "mov"; } final String exportURL = getApplicationDocumentsDirectory() + "/omgmusic_" + sessionId + "_" + item.getId() + "." + extension; final File exportFile = new File(exportURL); exportFile.deleteOnExit(); exporter.setOutputURL(new NSURL(exportFile)); exporter.exportAsynchronously(new Runnable() { @Override public void run() { item.filePath = exportFile.getName(); if (item.filePath.endsWith(".mov")) { File mp3File = new File(getApplicationDocumentsDirectory() + "/omgmusic_" + sessionId + "_" + item.getId() + ".mp3"); mp3File.deleteOnExit(); exportFile.renameTo(mp3File); item.filePath = mp3File.getName(); } } }); }

I finally got a chance to test DukeScript.  I compiled a sample application on iOS and ran it.  It seems to do what is promised - and it’s fast and reasonable. It uses RoboVM to actually run Java client apps natively on iOS, thus allowing to write code in html / css and logic in Java and package / run it natively on mobile devices.  From this first glance, it looks very promising for satisfying requirements for my mobile development.

I am still in search of a mobile framework that will make a single code base possible for iOS and android while being production ready.

I tested JavaFX for iOS / Android from #javafxports.  Disclaimer:  javafxports is in very early alpha (even if that) stage, so who knows what the state of javafxports will be in the future.

JavaFX has a lot of promise in my mind.  It's feature-rich, performs well and it's designed the right way, i.e. interface is written in a declarative language instead of "programmed".  What's not to like?

Of the desktop, it works really well.  Since nobody cares anymore about desktop component fidelity, JavaFX looks good and works well on the desktop.

As far as mobile, I was disappointed.  The iOS version (what I tested) didn't even work until I got a bug fix from the javafxports team (kudos for the quick fix BTW) for the gradle build script.  Once I got ti to work, it was clear that javafx wasn't built for the mobile environment.  Components "sort-of" worked and some thing were very slow probably due to the incompatible rendering pipeline timing.  There were many hangups / freezes and effects were ill-timed.  Perhaps this was due to the early nature of javafxports, or perhaps JavaFX rendering pipeline and iOS are so disconnected in nature that this approach will never work right.

I would say this approach is at least a year away from being usable in production, if ever.

So far, single-source mobile framework for business application remains illusive.

I am still in the process of picking a mobile framework for a business application.  

#RoboVM seems promising.  The fact that they are translating Java byte code into iOS / Android native is an engineering feat all to itself.  For a business application, I am trying to use a single code base.  Since RoboVM maps Java to platform native APIs, RoboVM doesn't quite get me there.  But, aside from that, it seems like you can create fast, good-looking apps in Java and use the Java ecosystem to do all you need in RoboVM.  My fear about code translator is the same as #GWT, which is the compilation is extremely slow and the code is not debuggable.  RoboVM seems to compile fast and debugging is a supported feature.

Conclusion: RoboVM is promising, but only gives Java and Java ecosystem for mobile development, and not quite a single code base.

Recently Google revealed their new Inbox app, the iOS port of which uses their j2objc tool to translate Java source to Objective-C. I thought I would share a few experiences with RoboVM, which compiles JVM bytecode directly into native iOS binaries.

When developing a game, the libGDX and RoboVM libraries contain almost all of the cross-platform support you'd want. The only platform-specific code you absolutely need is a small launcher, which looks something like this:

public class IOSLauncher extends IOSApplication.Delegate { @Override protected IOSApplication createApplication() { IOSApplicationConfiguration config = new IOSApplicationConfiguration(); config.preventScreenDimming = false; config.orientationPortrait = true; config.orientationLandscape = false; config.depthFormat = GLKViewDrawableDepthFormat.None; config.useAccelerometer = false; config.useCompass = false; config.allowIpod = true; return new IOSApplication(new AppMain(), config); } public static void main(String[] argv) { NSAutoreleasePool pool = new NSAutoreleasePool(); UIApplication.main(argv, null, IOSLauncher.class); pool.close(); } }

Note that IOSLauncher implements UIApplicationDelegate, so you can add delegate methods for app lifecycle, push notifications, URL handling, etc. right in this file. You also have access to the main UIViewController.

If you need to implement functionality not provided by the base libraries, RoboVM has a bridge to C or Objective-C native code. It's fairly simple to use, for instance I need to extend the default bindings to add an iOS 8-specific API call:

@Library("UIKit") @NativeClass class UIPopoverPresentationController extends NSObject { @Property public native void setSourceView(UIView v); }

Unlike JNI there is no native glue to write! Fortunately RoboVM has a pretty complete set of Cocoa Touch bindings, so usually the binding you need already exists, for example:

UIActivityViewController controller = new UIActivityViewController(activityItems, null); iosApplication.getUIViewController().presentViewController(controller, true, null);

In most instances you'll want to design an interface that exposes the desired functionality, then implement it against the different platforms, using Class.forName() to look up the platform-specific implementation. I've implemented bare-bones advertising, game services, IAP, and sharing interfaces along these lines.

There are still a few outstanding areas, for example stack traces are not exposed to the app, so you can't walk stack frames and printStackTrace() does nothing. However, you can install the Flurry bindings (or pick your favorite crash reporting tool) and enable crash reporting:

private void setupCrashReporting () { Flurry.setCrashReportingEnabled(true); Flurry.setAppVersion(APP_VERSION); Flurry.startSession(API_KEY); }

Unfortunately this isn't the entire picture, because in my tests the symbolication for my app's code was wrong (Flurry uses their own symbolication engine AFAIK) and I had to do it manually using the command line. Hopefully this will get better.

There's also no console output by default on iOS targets, but you can easily whip up a class to pipe it to Foundation.log(), e.g.:

System.setOut(new FoundationLogPrintStream());

How's performance? Pretty good, although I haven't measured in awhile. For my app, which has some CPU-intensive calculations, it seems a Kindle Fire HD and iPad 3rd gen are on about equal footing (ignoring GPU differences of course). You can take full advantage of multithreading and the RoboVM folks have done some optimizations to optimize memory allocation for this case.

There are GC pauses, but I haven't really noticed them often, and I don't go out of my way to avoid creating garbage either. You can also use the XCode Instruments tools to profile your app (among other things) and the stack traces are pretty well understandable.

libGDX has a setup UI that creates the initial project directory structure, and installs any plugins you may need (like font rendering, physics library, etc). This is only done once, and from there you are left to tweak to your heart's content.

Here's what my main project directory looks like:

Seems pretty complicated, but there's a lot of stuff here. There are separate directories for code specific to the Android, iOS, Desktop, and HTML targets, and code shared by all projects (I added 'shared' later to denote code that is not game-specific but shared by all projects). The platform-specific code is typically very small.

I put most of my source art in the "art" directory, but by convention the final assets live in "android/assets" and the other targets copy or refer to them as needed.

Gradle is the command-line build tool used by libGDX. It's pitched as a lightweight alternative to the enterprise-y Maven tool and a more powerful alternative to the tried-and-true Ant tool. But it also uses Maven to find dependencies. And your build scripts are actually written in a programming language called Groovy. And ... never mind. Explaining it all could fill up an entire blog.

You can use Gradle as an Eclipse plugin but it's useful to know how to use the command line. To build stuff you do something like this:

./gradlew android:assembleRelease ios:createIPA html:dist desktop:dist

This builds an APK for Android, an IPA for iOS, and a bundle for HTML5. Here's what building the desktop version looks like (on a good day):

Now I have a "desktop-1.0.0.jar" file I can run immediately, or use something like JarWrapper to package it into a nice installable package.

The Android target is pretty straightforward, as it relies on Google's Android build tools and Gradle plugin.

The iOS target uses a tool called RoboVM, which is a Java compiler and runtime library that uses Apple's XCode tools on the backend. Sometimes this takes awhile when RoboVM has to recompile all of your class files into native code, but you can build and launch your app on the device or simulator right from the command line.

The HTML target uses the Google Web Toolkit (GWT) which among other things contains a Java-to-JavaScript compiler. The Java dialect spoken is not strictly compatible with the JDK (not even as compatible as Android) and lots of library classes are not available. With a little elbow grease, you can work around the limitations, but it'll be a bit ugly. I have separate versions of some of my source files that are specific to the GWT and automatically copy them in before the build.

RoboVM works very well, and I haven't had any real issues that weren't related to binding to native iOS frameworks (and these were resolved). Debugging is a bit of a problem as Java stack traces are not available when exceptions are thrown, but there are other ways, like piping stack traces to Flurry (more on that later).

GWT is fine once you get it set up properly, but the performance lags both the Android and iOS ports. For my AI routines I use a lot of 64-bit integers which are emulated in JavaScript, so this probably contributes. Debugging is also tricky. Threads don't exist. Nevertheless most of the code and shaders translate perfectly to WebGL, and it's pretty amazing.

Next time I'll go into specifics of each platform, and how you bind to things like ad networks and social media APIs.