JSON parsing

All I wanted was to parse some JSON. Well, not just parse, but round trip objects to JSON to objects, and I wanted to do it automatically. Apparently this isn’t the goal of projects like Jackson and Gson. If you have a field that is an interface type or a list of objects, these libs don’t store the concrete types in the JSON and so cannot reconstruct the object graph. Seriously, wtf?! Xstream + Jettison might be able to do it, but Jettison is a bit of a strange monster and outputs ugly JSON. Plus I shouldn’t need a handful of libs for such a trivial task.

We now have some new classes in libgdx for reading and writing JSON. JsonWriter is a builder style API for emitting JSON:

There is also a class called XmlWriter that has a similar builder style API for emitting XML (note for better consistency with the new classes, I renamed the Xml class to XmlReader).

For reading JSON, there is a class cleverly called JsonReader, which uses a fancy pants Ragel parser, similar to the XmlReader.

Now we get to the cool part! There is a class named Json which internally makes use of JsonWriter and JsonReader to automatically go to and from Java and JSON:

This works by writing concrete class names in the JSON. This is only done when absolutely necessary, so the JSON output stays looking nice and clean most of the time.

I know this is reinventing the wheel and all that, but all three JSON classes total only ~500 lines of code. They solve using JSON for Java object serialization in ways other libraries don’t, and are likely more succinct. These classes aren’t the end all solution to Java + JSON (eg JsonReader doesn’t do streaming), but I think they cover the majority of needs.

In other news, you can now download the latest nightlies from this link, which doesn’t include the date.

updates for scene2d GUIs and ImmediateModeRenderer

We’ve been working on a few things lately. There are many small improvements and a few larger ones that impact existing code somewhat:

  • Mario used TableLayout in libgdx for the scene2d GUI stuff, which is cool… except that he forked it, checked all the source into libgdx, and put a thin veneer of poo over it in the form of the Container class. 😉 Actually, TableLayout had thus far been focused on the DSL and his Container class provided a much better Java API, but I didn’t like having an additional layer on top of TableLayout. I’ve integrated his ideas from Container into TableLayout, which means Container is now gone. In it’s place you just use the TableLayout API directly, ie create a Table instead of a Container. Table has similar methods, and you can call Table#getTableLayout() for more advanced methods.

  • ImmediateModeRenderer has been renamed to ImmediateModeRenderer10, to better match with ImmediateModeRenderer20. There is now an interface named ImmediateModeRenderer which both 10 and 20 implement, so the same drawing code can work with both GL1.x and GL2.0.

  • New methods on the Xml class, our super lightweight (single method!) XML parser. There is also a new class: XmlWriter. This is a builder style XML emitter.

ETC1 Support and More!

We added a few new funky things to libgdx

ETC1 Texture Compression Support

ETC1 is a universally supported texture compression standard by Sony Ericsson. It compresses RGB888 images to 1/6th of their original size and helps the GPU reduce fill-rate related performance issues. If your textures don’t need an alpha channel, and if you can live with the lossy compression of ETC1 you should really give it a try.

Let’s go through the necessary steps.

Compression

Compressing a Pixmap loaded from a file and writting it to our custom ETC1 file format is pretty simple:

You can also use the ETC1Compressor tool in the new gdx-tools project which can convert entire directory hierarchies.

Loading

Once you have your ETC1 compressed image in a file, you can easily load it like any other image file:

Jupp, that’s it. Note: ETC1 compressed images will only work with OpenGL ES 2.0. In case you use ETC1 images in an OpenGL ES 1.0 application they will get converted to normal RGB565 images on the fly!



Gdx-Tools

We decided to merge all our default tools (Hiero, Particle Editor, Texture Packer) to a single project called gdx-tools. You can find it in SVN trunk/extensions/gdx-tools. I’d highly recommend running it from SVN. If you used the image-packer.jar in your project you can simply link to gdx-tools.jar instead, which is included in all nightlies and releases from now on. Note that the package name of the TexturePacker changed, update with CTRL + SHIFT + O in Eclipse 🙂



Asset Manager & Asynchronous Asset Loading

Still in development but fully functional. It’s a nice little asset manager that can load textures, bitmap fonts, texture atlases and so on, asynchronously! Check out the AssetManagerTest. While the API is dead simple, the internals are not. We do dependency tracking and other nasty things like reference counting so that you don’t have to worry about resources getting loaded twice or getting disposed while your app still uses them.

It’s also terribly nice for implementing a loading screen that is actually animated :D. The documentation is currently in its infancy but i’ll try to fix that up alongside the internal code changes in the coming days.



Rewritten Texture, TextureAtlas, BitmapFont, …

Due to the way the new AssetManager works we had to rewrite all the resource classes to some extent. This refactoring run turned out to be really beneficial as we separated loading the description of an asset (e.g. the Pixmap of a Texture, the glyph metrics of a BitmapFont and so on) from the upload of data to the GPU. This allows us to have asynchronous loading, where the meat of the resource is loaded in a separate thread and the GPU portion is uploaded on the rendering thread.

For you there’s nothing that changed really, apart from TextureData, which is a lot more sane now (and also allowed us the easy integration of ETC1!).

Changes to Scene2D

We had to change a few tiny things in scene2d that shouldn’t concern you.

All Actors now have a visible flag that you can use the change an actors visibility.

All input methods of an Actor are now public (for various reasons).

We also have an experimental FlickScrollPane now that we’ll fix up over the next weeks.

Nate will follow up with the new features and changes to the UI library he did over the last two weeks. I’ll signal you guys when the AssetManager is final (The API is final btw.).

More wonderful things to come. For more detailed info on what changed consult our change log.