libgdx 1.0 roadmap

So we are heading towards the 1.0 release of libgdx. Here’s the list of things i’d like to add.

  • 3D Model loading/rendering: loading of skinned and static models. We currently support OBJ (to some extent) and MD5 (without materials, those have to be hooked up manually). The new core API will only understand a binary format in 1.0, an import tool for Ogre XML and possibly Collada (ugh) will mediate. During development time you can hook up the 3rd party loaders via simple plugins (jars…). See
  • Model Preprocessing: Conversion of skinned models to simpler keyframed models. That’s already implemented to some extent and known as baking (at least between me and Dave :)). While it takes up more memory it’s a lot less heavy on the computational side of things
  • DecalBatch: integrate Vevusios awesome DecalBatch as a counterpart for the 2D-only SpriteBatch. Useful for 3D particle systems and more advanced 2D rendering. Consolidate with SpriteBatch? Probably not.
  • AnimatedSprite: I’m still not happy with the idea of an AnimatedSprite as it promotes the wrong pattern imo. But who am I to judge! Wavesonics and Cyble have done some great work and posted it on the forums. With their permission (and one or two tests to be integrated in our “test suite”) I’d like to add it to the core API. For now you can use the Animation class or roll your own.
  • Application Configuration: at the moment you can only configure a few things related to the application Window/activity/OpenGL/EGL context. I’ll look into making this more flexible, namely full-screen support, easier integration of Jogl/Lwjgl application into Swing/SWT UIs (with context sharing), turning off unneeded listeners on Android (sensors) and so on. The constructors of the different Application implementations will change slightly (they’ll expect an XXXConfiguration object), nothing super API breaking
  • TrueType Fonts: that was actually part of libgdx up until version 0.6 or so. For various reason it got replaced by Nate’s BitmapFont stuff in conjunction with Hiero. I’ll add this functionality back in with the help of stb_font, just as we use stb_image for our image manipulation API. (Btw, did you know that Andengine still uses a modified version for TTF font rendering of our original code? All hail open-source :))
  • GPS, Gyro, new Android Key constants:: We have most input devices covered (save for cameras). The GPS and Gyro is the last big thing on the todo list. I haven’t looked into the differences between handling Gyros and Accelerometers on Android, might be the same thing API wise actually. Android 2.3 adds a couple of new key constants which should also get some love
  • libmpg123: Add support for libmpg123 decoding back in. It’s actually just a matter of getting the build up and running and packaging the shared libs along side our gdx-natives. Thotep will hopefully like this πŸ™‚
  • Box2D Pre-/Post Resolve: while super useful you can actually do this already without that resolver interface. See the box2D test bed. It’s the only thing that’s actually missing from the JNI wrapper so for completeness i might just add it. Maybe i find the time to update to the latest and greatest version as well (probably not).
  • Native Math: some of the math classes could need some native code love on Android, namely the Matrix class and some of the Intersector methods (ray vs triangle soup).
  • tile map rendering: I’ll have to look into Dave’s mighty TMX at some point and see whether i can improve performance a little. Maybe make things a little bit more generic and decouple them from the TMX format
  • 3D scene graph: very, very, VERY simple 3D scene graph support. For many game’s it’s just overkill and you should usually separate your logical scene graph from your graphical scene graph (unlike our scene2d package…). To not further encourage a wrong pattern i’ll try to keep this at the most basic level
  • Space Partitioning: I really love spatial hash grids as they are more than sufficient for most games and very easy to implement. I’ll try to implement those for 2D and 3D (2D is done and discussed in the book actually…).
  • bug run: Fix the four bugs on the issue tracker
  • Keycode Constants: KEYCODE_ must die!!! (Nate’s request)

Given that the book is almost finished and that i have a little bit more free time a lot of this should be possible in the next 1-2 months. Contributions are of course welcome as always (they of course have to pass our nitpicking and unfair screening process).

That’s the plan. Let’s see how it turns out. Leave feedback and suggestions in the comments!

13 thoughts on “libgdx 1.0 roadmap

  1. I totally agree the pattern needs work. This evening I will try getting the new one ready. For usability the current is very user friendly (one class for all). But I think the best solution would be two separate classes, one derived from sprite and one from atlassprite. Will keep you informed of my findings in the forum.

  2. Oh, maybe i didn’t explain to well what i mean by pattern. With an AnimatedSprite class you actually have logical object state (walking, flying etc.) in a graphics object. Even worse, when people start to derrive from Sprite/AnimatedSprite and add logical members and methods to it you have a tight coupling between graphics and logic. In my opinion that’s a bad idea, even for simple games, as it does not allow for separation of concern. Instead we offer the stateless Animation class. Each instance encodes a list of TextureRegions for one animation (e.g. walking, jumping etc.) and the frame duration. No further states are kept. When you render your object, you simply take an objects state (walking, jumping) and the time it has been in that state (which is also a logical state) and pass it to the Animation class which will return the proper TextureRegion. The logical object has no idea that it is actually rendered which is a cleaner design imo. Bonus: you can simply change the rendering of your world without touching any of your logical objects.

  3. Mario, that is exactly what I have – An AnimationComponent, of which one or more which gets added to my game object (one for each state), and the texture region gets rendered accordingly.

  4. Moved discussion thread about the animatedsprite back to the forum (else it gets cluttered and offtopic in these comments :))

  5. Feel free to destroy any part of my tile map loading. I have been meaning to change the block size to be based on the number of tiles instead of pixels. Not sure exactly what to do for culling to remove the need for pixel-based stuff. I’m sure someone could write a more generic rendering class. I’ve been really busy with “real life” stuff to get any programming done lately πŸ™

  6. @Cyble, agreed let’s get this to the forums.

    @Dave, no worries, what we have is totally fine for now. I can relate to “real life” stuff πŸ™‚

    @BurningHand, fancy component system eh? Nice πŸ™‚

  7. Frank, i won’t cover the roadmap of libgdx 1.0 in the book i’m afraid πŸ™‚ Spatial hash grids for 2D are in there though!

  8. Hi there,

    speaking of 3D Scene Graphs, i’m currently in the process of doing such a thing. It’s not as simple as expected I guess, but it’s aimed to implement a basic set of the classic scene graph features, such as nodes, entities, inheritance and translation between world and local space.

    I’m developing it for a commercial project right now, but I’d absolutely love to contribute to libgdx, so please let me know if you’re interested!

  9. Hi, I’m using your Box2D JNI bindings from libgdx for a 2D action-RPG in android – Nice job, by the way!! – and I’m trying to stop a collision response in the collision event. You say here that you haven’t implemented the Box2D Pre-/Post Resolve, as you don’t need it – I have looked at the Box2D testbed to find out how to do it without the pre/post solve, but can’t figure out how to do it. Can you give me a clue please?

Leave a Reply

Your email address will not be published.