Drawing rectangular sprites with a lot of whitespace that get’s cut away through alpha-blending can be a waste for big, static, background elements. PolygonSpriteBatch is here to safe the day. Bach, Shiu and Obli worked on integrating it after a quick design round via Skype/Google Docs. A PolygonSprite is made up of vertices that form a polygon instead of a rectangle. This allows you to more tightly fit the geometry to the relevant portions of the source image. You can find more information at http://www.fainted.dk/?p=142, the new classes are in the latest nightlies.

TexturePacker v2

libgdx has a new texture packer! The old one was slow and the code was absolutely horrible. Here’s a run down of the major differences:

  • The new code is very nice and maintainable. Check it out.
  • Much better packing and much faster. The packing algorithm is the maximal rectangles (MAXRECTS) algorithm by Jukka Jylänki here. He has done some great research! His work was the basis for the new packer, with lots of additions. Packing into a fixed size bin is pretty straightforward, but packing into the smallest size bin possible is quite a pain, especially if you want it to complete in a timely manner. The new libgdx packer uses a brute force binary search and supports packing into multiple bins.
  • All existing settings are supported, except incremental. I may get around to that at some point. Some settings have been renamed for more flexibility, eg padding is now paddingX and paddingY. There is one new setting “fast”, which doesn’t pack quite as well (though it is still very good) but executes very fast. This can be useful when packing at the start of every run of your app.
  • The underscore file name conventions are gone. File names can still have a numeric index, it is simply any numbers at end of the file name, before the file extension. To better control packing in various ways, a “pack.json” file can be placed in each input directory. This contains the JSON for the Settings object. Each directory inherits all settings from the parent directory and any property set here will override those. This also means it is easier to use, as you don’t have to write any Java code. Just wite your “pack.json” files and point the gdx-tools.jar at it. I will write proper documentation for it tomorrow and update this blog post.
  • Files with “.9” before the file extension are considered a ninepatch. The pixels around the edge are read and stripped off before packing the image. The split information is stored in the pack file, enabling TextureAtlas to provide instances of NinePatch. The splits in the TextureAtlas file format are optional, so existing pack files are still compatible.

The new class is called TexturePacker2 and the old TexturePacker class is deprecated. It is committed in the “scene2d-new” branch, which will probably be merged in the next few days. These changes, especially the ninepatch support, will allow for the cleanup of the Skin class. It is currently a weird fork of TextureAtlas, storing both an atlas and styles. Probably it will be refactored to store only styles and TextureAtlas can be used for scene2d.ui.

Edit: The TexturePacker documentation is now up to date.


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.