OMG Ponies!

If you are interested in RealSense Technology check out the Intel RealSense App Challenge. RealSense is a suite of software and optional hardware that let’s you explore human computer interaction.

Check out this video from last year’s winning entries:

Intel just released their latest RealSense SDK and Developer Kit, with which you can take part in this years challenge! There are two tracks, Pioneer and Ambassador. Members of the libGDX community can participate in the Pioneer’s track, which consists of two phases:

As every year, i’m gonna summarise what i found most interesting about this year’s I/O. Sadly, there isn’t a lot of public material relevant to game developers. According to the schedule there have been a few hands-on talks with Intel, Nvidia, ARM etc. on performance tuning, but no videos are available on that. So, breaking with the tradition a little, i’ll highlight what i found interesting from a more general point of view. Here’s the keynote (danger, very long, very robotic, kinda boring):

New Android version “L”

Now, hold your horses. The new version is still in the making and will be released this fall. However, you can get preview release images for the Nexus line of devices and emulator images. A lot of new features went into this one, some are quite interesting for us libGDX folks:

Dalvik’s out, ART is in. Starting with L, ART is the new default VM on Android. Dalvik has been completely removed from L, which is a good thing. Preview builds of ART didn’t work with libGDX due to some JNI issues on ART’s side. Those have been resolved and merged into L.

Separate rendering thread. Previously the UI toolkit thread did both processing and rendering. Not anymore, there’s a separate rendering thread to which the UI toolkit thread is sending display lists essentially.

64-bit support. This has been long coming, and it must have been pain to fix up the class library which used 32-bit ints to store pointers to native peers. While this mostly opens up the possibility of more addressable RAM, it also may give us some new instructions/registers ART and native code can exploit.

OpenGL ES 3.1 support and Android extensions pack. It appears that most GPU vendors in the Android ecosystem are now pushing for OpenGL extensions for tessellation, geometry and compute shaders (and still not OpenCL…) as well as things like ATSC texture compression. We’ll see how that pans out, i’m not sure it’s to relevant for libGDX at this point.

USB audio. Not sure if they finally fixed the audio latency, which i guess is part software/driver part hardware related.

Project Volta. Aims at giving users more control and insight into battery usage. There’s also a method level kind of battery profiler called Battery Historian which is really awesome! Here’s the talk on Project Volta which i haven’t seen yet.

There’s of course a metric ton of other additions, but i didn’t feel that those were to relevant for game devs. Check out Chet Haase and Adam Powell’s talk on what’s new in Android L:

Material Design

Most of Android’s current design was introduced with Ice Cream Sandwich, with iterations in Jelly Bean and and KitKat. With the new Android release called ‘L’ we get a new iteration called Material Design. Apart from the nitty gritty design principles you should follow, the big obvious things for non-designers like me where:

Shadows: every view now has an elevation value (z-coord), based on which the framework can draw orthographic soft shadows. It looks awesome, and gives us a back a bit of the the feel before everybody went insane with “flat” designs.

Animations: everything is animated. I’m not a super big fan of this as it’s easy to overuse it. But the things presented so far looked very non-intrusive while giving things a nice natural touch. I especially like the new activity transitions, which can take a few of the activity that’s being left and animate it into the activity that’s being started.

Quite a few talks have been given on Material Design. My favourite is of course the Romain Guy/Chet Haase. They are giving a bit of a behind the scene talk, with Romain explaining how the shadow rendering works. They also tell us why Romain was fired from the Android team and is now working on boring robots instead.

Chet Haase and Adam Powell also gave a nice round-up talk on how to write Material Design apps for Android. Adam will likely replace Romain in upcoming I/Os, which is sad, sorta.

Android Wear, TV and Auto

Introduced in the keynote, Android Wear is what you expect: smart watches that can hook up to your Android devices and desktops/laptops. Definitely not for me, but some people seem to like to order their pizza with those things (as demonstrated in the keynote video). Android TV is a bit more interesting, as it means that TV set vendors may start using Android as the OS running the TV. This is sorta like a death blow to Ouya and other micro consoles and may indicate that Google is not interested in playing the console game after all. Android Auto must have been the most underwhelming thing next to wear. While Google was able to round up a few manufacturers that will ship their 2015+ line ups of cars with Android Auto, i can’t really find the appeal. Similar to wearables. You hop in your car, then have your phone hook up to the console of your car. Maybe i’m just to old, so all i really need is Android TV.

Android Fireside Chat

I always look forward to the fire side. Some insights:

Java 8, no comment. This led me to believe that Google may pull a Swift on us (though very unlikely given the investment in Java within the framework)

Google’s not gonna pull a Swift on us, so says Dianne Hackborne. Neither will Scala become the new lang for Android.

Eclipse support is on it’s way out according to Xavier Ducrohet and David Burke, though improvements in the Gradle Eclipse integration should keep Android working in Eclipse. Somewhat.

Getting a bit cozy are you, what with your scene2d application compiling smugly? Say no more, I have a treat for you!

As you know, TableLayout is one of my (Nate’s) OSS projects. The core performs UI toolkit agnostic layout and only a small bridge needs to be written to layout for the toolkit of your choice. The UI toolkits it supports are Swing, Android, TWL and of course libgdx’s scene2d.ui. Sadly, few outside of libgdx have seen the blessed layouting light and continue to plod along with suboptimal tools. Anyway, the bridge makes for some slight API awkwardness and extra indirection under the covers. Since TableLayout is mostly used for scene2d and given that I certainly don’t want to (or plan to) subject myself to the pain of using other UI toolkits, I figured we might as well fork TableLayout and integrate it properly into libgdx.

Rest assured, everything is now completely forked. What is left are two classes: Table and Cell. They work mostly as they did before, but you’ll need to organize your imports since they are now in the scene2d.ui package. The API has changed slightly:

Cell#getWidget -> Cell#getActor

Cell#setWidget -> Cell#setActor

Other methods with “widget” in name -> “actor”, since they take Actor, not Widget.

cell.getLayout().getTable() -> cell.getTable()

Cell#ignore is gone. This was never used AFAIK mostly on account of not being very useful.

TableLayout and Toolkit are gone. Table does it all.

In addition, Value has changed a bit. It is simpler and no longer specific to Table. I plan to use it elsewhere soon, eg in Container.

So there you have it. API breakage should be easy to fix and the new Table works as it did before.