Google i/o 2012 Summary

I won’t blagh about what new products were introduced. Let’s get to the meat of things. Here are the highlights i think are relevant for us game devs.

Technical stuff: no big API additions that are all that relevant to OpenGL ES game dev shops. What’s really interesting this year are all the new analysis tools. I think they are awesome.

  • Triple Buffering & vsynch: touch and rendering are now more tighly bound to vsynching. You can explictely interfer with this, sounds interesting, though i’m not sure it’s relevant to OpenGL ES apps. My hope would be that eglSwapBuffers was truely vsynched, but who knows :/. Called “Project Butter” officially, should be called “Jank-Busters”. See the “For Butter or Worse” talk below. It was also said that there was some touch coordinate prediction going on, which might mean that laggy drags are a thing of the past. I’d be worried that it fucks up multi-touch on specific devices even more :/
  • Access to low-level media codecs: Not sure if really relevant, here is the release note section on that
  • New Input Framework: helps you discover connected input devices and get notifications on disconnects etc. Not sure if there’s a lot of users out there actually attaching peripherals, still nice that it’s there. Release note section
  • OpenGL ES Tracer: now this one is really neat. It will keep track of all GLES calls, GPU-side objects and even allows you to display (partial) framebuffer contents. The only bummer is that it works only on devices with Android >= 4.1, but it’s a neat alternative to the GPU specific tools by Qualcomm, Nvidia etc.
  • Systrace: this one i’m really excited about. It directly hooks into the OS and tells you exactly what happens at what point in time, globally. It can be used in addition to the profiler in DDMS. Identify delays/performance issues with the profiler in your app, then match that up to the things that happen globally, as traced by Systrace. Really cool. Using “HTML5” as the output format is also a very smart choice imo. Sadly there’s no official documentation on this yet, or at least i couldn’t find any. Check out the “For Butter or Worse” talk below.

Here are the talks i found interesting:

  • What’s new in Android?. Most things aren’t relevant to people directly working with OpenGL ES.
  • For Butter or Worse. Discusses the new vsynch and triple buffering system and demonstrates how to use the new analysis tools to some degree. Really sweet. Also, Romain Guy and Chat Haase presented this one which makes it an automatic must-watch. Jank!
  • Doing more with less. Very hands-on talk about optimizing Android applications. Walks you through optimizing a real-world gallery app. Very well presented, kudos to
  • Monetizing Android Apps: Haven’t fully watched it, we were busy with our hangout. Had some nice graphs and a good overview of the matter. You’ll need to watch all of it.
  • Google Play: Marketing 101: Didn’t watch this at all, but i got it on my “to-watch” list.
  • Dart: a modern web-language: i’m a sucker for languages that i know every skillset can use. Dart seems to be geared towards this goal. If there was a Java -> Dart frontend, we could replace the slow GWT backend eventually. Also, they have a stand-alone VM (source-code VM, not byte-code, interesting) which could be used to do all kinds of crazy things.

TableLayout updates

scene2d.ui has been using TableLayout for a long time. TableLayout sizes and positions actors using a logical table, similar to HTML tables. The resulting layout does not (usually) use pixel coordinates, so it automatically adapts to different resolutions. It can also scale positions, sizes, padding, etc based on the screen density. It is an extremely convenient way to position UI widgets. If you are manually doing the math to calculate widget positions, TableLayout is highly suggested. Once you learn the API, you can use it for libgdx, Android, Swing, and TWL.

Beyond just layout using a table, one of the big ideas in TableLayout was a DSL (domain specific language) for describing UI widget hierarchies. Writing layouts in code is flat. It is difficult to see the hierarchy in complex layouts that have a lot of nesting. Describing layouts in XML is a huge pain, and JSON isn’t much better. The TableLayout DSL put a minimal amount of cruft around the important bits. In the beginning it only allowed layout, using the half dozen or so TableLayout constraints. Features were added to reduce the amount of Java code by allowing more to be described in the DSL. Eventually it could do object creation, set field and bean properties, and more. The DSL syntax was still relatively simple, but the extra features certainly didn’t help new users get started.

Unfortunately, it turns out that the usefulness of the DSL is limited. Very often with a complex UI, portions of it are dynamic. Eg, sections A, B, or C are optionally shown based on some state, or you have a table or other container that has items added by code. The DSL can describe the main structure and then code can fill in the rest, but this ends up being awkward. When a large portion of the UI is built by code, the DSL no longer makes sense for the minimal remaining structure. At this point you are back to the Java API and probably would have saved time if you started there.

As TableLayout got used for a few big apps, the Java API has started to look very similar to the DSL. It is still flat, but specifying constraints is quite concise by using a builder pattern. Constraints can be specified for all cells, all cells in a column, all cells in a row, or for an individual cell. This greatly reduces repeating yourself. Here’s a quick example:

With the recent scene2d updates, I thought it was time for a TableLayout refuctoring. The DSL has been removed, along with a TON of support code, leaving only the Java API. It’s a little sad because it was a lot of work and very powerful — it even had an editor for the DSL, with syntax highlight and realtime rendering of the layout. Ultimately though, I came to the conclusion the DSL isn’t the right way to go. Implementing the DSL positively affected the Java API in many ways, so not all is lost.

A few other TableLayout changes have been made. All the int values have been changed to float. Also, it no longer parses strings for constraints. Instead, there is a Value interface, which can be implemented to compute a value however you like. This is a lot more flexible and avoids allocation. Setting the logical table size is gone, it was rarely needed and confused people. The scaling property is gone, it is replaced with the flexibility offered by Value.

These changes only affect the libgdx scene2d-new branch. If you use TableLayout, this is your heads up about the changes! The branch will likely be merged into trunk in the next few days.

Edit: The TableLayout documentation is now up to date. It has been completely rewritten.

-Nate

scene2d updates

libgdx has a 2D scene graph, cleverly named scene2d. It supports rotated and scaled actors, hit detection, input, etc. On top of it we’ve built a small UI framework, scene2d.ui. Even though all of this has been a bit messy and severely underdocumented, lots of people make use of it. It’s been a while without an update and it has become obvious that it could be improved in a few areas. Lots of refuctoring has been done over the past few weeks. Mostly only scene2d has been affected, but there were a few other changes that may affect you. I will mix them in so you have to read about all the super cool scene2d stuff, even if you don’t care! Some highlights:

  • Public fields are gone, replaced with setters and getters. This turned out not to be so bad. It is often more convenient, since you can now call setBounds(x,y,w,h) on one line, rather than four lines of field assignments. The methods also help make the API more consistent. While most are simple, in a few cases methods are needed to do something more interesting, and mixing fields and methods gets ugly. BTW, Eclipse has a Quick Fix (ctrl+1) for “replace field access with getter/setter”.
  • The action system has been rewritten. It is simpler, more powerful, and has more actions. Action pooling is easier. Relative actions (moveBy, rotateBy, etc) can be combined, even if they operate on the same properties. The syntax has improved, utilizing a static import rather than weird dollar signs, eg:

  • The input event system has been replaced with a generic event system. This system can be used for any kind of event that actors might care about. Eg, touch events, a slider value changing, a selectbox selection change, or your own events. Previously, to handle an input event, the actor needed to be subclassed. Now a listener can be added to any actor to receive input events. Listeners are provided for common handling, such as detecting clicks. There is even an ActorGestureListener that makes it easy to receive gestures like pinch zoom, fling, pan, long press, etc.

    Each actor has a list of listeners that are notified for each event. Similar to the DOM event model, events are propagated in two phases. First, during the “capture” phase an event is given to each actor from the root down to the target actor. This gives parents a chance to intercept and potentially cancel events before children see them. Next, the event is given to each actor from the target up to the root. This allows actors to handle an event themselves or let the parent have a try at it.

  • Two new input events have been added: enter and exit. These are fired whenever the mouse or a finger touch enters or exits an actor. This was difficult to achieve with the old system, now it is provided.
  • InputProcessor has changed, touchMoved has been renamed to mouseMoved. touchMoved didn’t make sense, as this event only occurs on the desktop when the mouse moves, no touch is involved.
  • TextureRegions and NinePatches in all UI widgets have been replaced with an interface called Drawable. This has a draw method and some simple metrics. A few implementations are provided: TextureRegionDrawable, NinePatchDrawable, SpriteDrawable, etc. This allows for more powerful UI skinning, as you can draw anything you like for backgrounds, etc. SpriteDrawable enables whitespace stripped regions from a texture atlas to be used in a UI. Skin automatically handles drawables in JSON style definitions.
  • FlickScrollPane is gone and ScrollPane has become more powerful, gaining all the abilities from FlickScrollPane and more. Scrollbar drawables are optional, so it can be configured to operate exactly like FlickScrollPane used to. If scrollbar drawables are provided, they can be configured to fade away after touch scrolling. Touch scrolling can be disabled, so it can behave exactly like the old ScrollPane. With the new event system, you have control over propagation of events inside the scrollpane. Widgets that would normally trigger touch scrolling, such as a slider, now work inside a scrollpane.
  • Various utility classes have been added. Pool.Poolable is an interface with a reset method that is called when an instance is put back in a pool, making it easier to recycle objects. ReflectionPool uses reflection to construct instances, which can often get rid of the boilerplate involved with subclassing Pool. The Pools class has a Map and static methods for obtaining and freeing objects, which makes pooling very easy. The Timer class is an efficient way to have tasks executed in the future. DelayedRemovalArray and SnapshotArray provide different ways of handling concurrent modification.
  • GestureDetector has been changed to use floats. Previously it only worked with screen coordinates, so it used ints. For it to work with scene2d it needed to be changed.
  • Everything has proper javadocs. That is, proper by my own crazy standards, which are an attempt at providing all the information without leaving out anything crucial OR being too verbose. We don’t pretend javadocs are the only documentation needed. Real documentation is in the works.

Various other refuctoring has been done in scene2d, methods renamed, constructors changed. We know this causes many of you a small amount of pain, but it improves the quality of the library. Hopefully you find the improvements worthwhile. Of course, if you are planning to release soon, now may not be a good time to upgrade.

All of the above work has been done in the “scene2d-new” branch. We would love your feedback, so if you have a little time, please feel free to do a code review. You can submit your feedback via email or come on IRC and chat. Act now, because in a couple days we will merge the branch with trunk. Now is a good time to give feedback on parts of libgdx you’d like to see improved, in scene2d and beyond.

-Nate

Edit: The first part of the scene2d documentation is done. This is for the core of scene2d, so it is a little low level if you are only using it to build UIs. More coming soon.