Google I/0 2014

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.

scene2d Table forked up

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.

Stage API changes: Viewport added

noone had a great idea, to provide a Viewport class for determining how world coordinates are scaled to screen coordinates. This was already possible using Camera of course, but it was not noob friendly. Viewport is standalone and just manages a Camera. This means any app that uses Camera can use Viewport to control the strategy for scaling the world to the screen. For example, maybe you want to stretch the world to the screen, or scale it up without changing the aspect ratio by using black bars.

After a couple iterations we’ve now integrated the Viewport class. It’s quite slick, you just pick from one of the ready made Viewport implementations and you’re good to go. See the nice wiki page for docs.

Here’s where I tell you about the pain you are in for! It makes sense for Stage to have a Viewport instead of a Camera (remember Viewport has a Camera). This makes controlling scaling for scene2d super easy, but the bad part is Stage had to change. Instead of telling the Stage the viewport size, you give it a Viewport instance that does what you want.

If your old Stage construction code looked like this:

stage = new Stage(width, height, false); // OR
stage.setViewport(width, height, false);

Then you need to change it to:

stage = new Stage(new StretchViewport(width, height)); // OR
stage.setViewport(new StretchViewport(width, height));

If your old code looked like this:

stage = new Stage(width, height, true); // OR
stage.setViewport(width, height, true);

Then you need to change it to:

stage = new Stage(new ExtendViewport(width, height)); // OR
stage.setViewport(new ExtendViewport(width, height));

There is another important change, resize used to look like:

public void resize (int width, int height) {
    stage.setViewport(width, height);
}

Now you’ll do this:

public void resize (int width, int height) {
    stage.getViewport().update(width, height, true);
}

The boolean centers the camera if true (only really needed for UIs). It can be omitted, which is the same as false.

The other changes that may affect you are where you are using the Stage’s Camera. You can use stage.getViewport().getCamera(), but note that Viewport has project/unproject methods that should be used instead, since they take the viewport into account.

Not too bad for you guys I hope!