libgdx 0.81 released

Oki, just released 0.81. Fingers crossed that i didn’t fuck it up yet again. We fixed a lot of things and introduced a couple of new features. The list is way to long to recite here. Please refer to the SVN changelog, starting from revision 921 (you can page through this). I’ll just refer to the SVN changelog from now on.

Just a few highlights:

  • We included the Lwjgl backend and the TWL extension in this release. Note that the former is still experimental. Stick to the Jogl one for now i’d say. Textures are not pre-multiplied at the moment and mipmap generation is a joke.
  • We removed support for Mpg123Decoder at this point. We need to rework the licensing issues (dynamic linking instead of static on Android). I’ll probably setup a separate google project for that, like the GL 2.0 bindings project.
  • A nice bug in Color.toFloatBits(). See this thread for a discussion. Darn Java float implementation… Thanks to Matthias Mann for suggesting this “fix”.
  • All classes in com.badlogic.gdx.scene2d have protected instead of private members/methods now. No idea why i had those private. Thanks to Lefthand for pointing that issue out
  • BitmapFont to use cap height as origin rather than baseline. Named methods better. Added method to get text bounds. If you are as confused about this as me then poke Nate, he can explain it. Here’s a thread on the topic
  • Introduction of SpriteCache class. Can be used to implement tiled maps for example. See this thread
  • SpriteSheet and SpriteSheetPacker, for your sprite packing pleasure
  • Some improvements to SpriteBatch and Mesh be rewritting the backends. You can now do n-buffering with SpriteBatches too. This is useful if you don’t have a lot of sprites but all of them have different textures like in Nate’s game
  • Reverted the event based input processing back to a listener concept. InputProcessor stays the same, instead of Input.processEvents() you call Input.setInputProcessor() now though. See Java docs for more info
  • The Files and FileHandle interface received a major overhaul. They are pretty sweet to use now. Also, if you use internal files on the desktop the classpath will be searched first. Useful when you want to deploy your game as an applet of jws app.
  • Lots of other small bug fixes and improvements. For a full list check out the SVN changelog.

    Please report any bugs you find on the bug tracker!

5 thoughts on “libgdx 0.81 released

  1. Just discovered this library yesterday when I hit some show-stopper performance roadblocks with Google’s API. Really impressed. I was able to port a week’s worth of work in the Android API over to GDX in less than a day. GDX promotes a better architecture so I’m working with less code that’s performing *significantly* faster.

    I’m glad I discovered this in the 8.1 state as it seems pretty mature. I’m mostly a C++ guy… working more with Cinder, openFrameworks, etc, and this holds up. I’ve also got a ton of experience with XNA/C#.NET which I thoroughly enjoyed due its nice effort/performance ratio. I’m seeing a lot of similarities between this and XNA, which is a good thing.

    Keep it up!

  2. Hi. Great framework.

    However, I’m looking for a Java game framework with greap applet support, as I want to make browser based games too.

    Someone mentioned something about memory leaks, but that was a while ago.

    Is the library suitable for production quality applet deployment yet? Thanks.

  3. Yes. The memory leaks are not a problem with libgdx itself but with direct ByteBuffers. The JVM doesn’t seem to free them up when you reload an applet often. Use LwjglApplet as the base Application class and all will work out.

Leave a Reply

Your email address will not be published.