Libgdx, Andengine & Rokon Micro-Benchmarks

Nicolas send me a his benchmark suite for libgdx, AndEngine and Rokon. Each engine renders a scene of 32×32 pixel sprites in a grid, a total of 336 sprites, filling up nearly all of the screen. I performed the tests on 2 devices, a Hero with 1.5 and a Nexus One with 2.2

Rokon didn’t start on neither my Hero nor my Nexus one.

– Hero: ~17fps
– Nexus One: ~41fps

– Hero: ~51fps
– Nexus One: ~51fps

Yes, you read that right, the libgdx version, which uses the SpriteBatch class for rendering, performs equally well on both devices. Now, in my opinion the test is not entirely fair as AndEngine has to perform a lot of other stuff besides the rendering. However, the main reason why it sucks so much on the Hero is that each sprite rendering issues a lot of glTranslate/glPushMatrix/glPopMatrix commands as well as rendering each quad seperately (the VBO containing the vertices is bound only once though).

You can find the source for the benchmark here.
An apk can be found here.

The more i see these semi-scene graph engines like Rokon, AndEngine or Cocos2D on Android the more i believe that they are not the way to go. You can’t please every genre with these engines and if you have to get better performance you’ll have to dive deep into the source of these engines and modify it. Simple puzzle games or your average Snake clone are a no brainer with those engines. However, something like Replica Island is pretty much out of reach when using these libs at the moment.

I still believe that especially beginners in Android game programming should start out with AndEngine & co. Their nice APIs are much easier to use than the down to the metal approach of libgdx (altough it has nice helper classes in the math and graphics package which should ease your programming pain a lot).

13 thoughts on “Libgdx, Andengine & Rokon Micro-Benchmarks

  1. Hi Mario,

    I am writing a 2d games library for Android loosely based on some of the concepts in cocos2d. I am not an expert in games programming by any means but I liked the scene graph way that cocos2d separates the screen elements into nodes which you “run” actions on. After reading your post here I am intrigued by your statement that a scene-graph is not the way to go in terms of performance. Surely – ultimately – you will have to partition the actions for screen elements into individual sections of code which act on the appropriate element. The key thing to making the screen draw fast is to do something like your SpriteBatch class which collects up the elements and draws them in in one go (I have probably got the wrong end of the stick here but at least that’s what I ‘think’ your class does). The scene graph can call ‘draw’ which updates the list of textures to be drawn and then when that is complete there could be a global update which does the batch draw. Would that not be just as fast with the nice ability to treat your scene as a tree of screen elements?

    Love your site btw. Lots of great stuff here.

  2. Hi Al,

    In general there’s nothing wrong with a screen-graph approach as you described it. However there’s another side of the coin: updating the scene graph itself. If you have a flat scene-graph you won’t probably run into performance problems. With deep hierarchies you can shoot yourself in the foot pretty fast, especially when it comes to collision detection. Also, writing a general scene graph API is no easy feat if you want to please everyone. What i also don’t like about the semi-scene-graph APIs on Android is the missing seperation between game logic and game presentation. A node does everything, draw itself, play a sound etc. This not only makes it hard to port it to a different backend but also has some performance problems as it does not allow to batch stuff up. Of course you could provide each node with an interface which itself is a batch implementation for rendering. But none of the engines out there have to so far (or else i’d have written a backend for them using libgdx so i can develop on the desktop :)).

    I think Andengine covers a lot of ground and is really great for many things. My post should not in any way keep anyone from using it, i actually encourage using it despite its short comings.

    Thanks for the comment! I value such input.

  3. Hi Mario,

    Thank you for your reply.

    “What i also don’t like about the semi-scene-graph APIs on Android is the missing seperation between game logic and game presentation”

    Good point. But, if you look at cocos2d you will see that the nodes are all about presentation and the actions associated with the nodes are all about the logic. That is, a scene holds layer with nodes to be presented but the logic for the nodes is held in a separate list as “actions”. The list is processed on each game loop. The actions have a reference to their node but that’s it. All the logic is processed in a giant loop across all the associated actions for the current scene. Each action gets executed in turn and maybe it will play a sound and finish or not. It’s a clever design. The game loop – update – draw – is maintained. This can be altered to – update – draw – batch draw and gain the advantage of a batch type draw.

    What’s the alternative? Placing the logic for a screen element into the controlling application might gain the advantage of having an overview of the whole current scene but it loses the nice oo approach. Is it any faster?

  4. Well, i usually completely seperate the actual simulation logic from the rendering/audio paths. The simulation is completely independent of anything, user input, network input, you name it. It offers a public interface which allows to change things within the simulation, e.g. command units to go to some specific place, move the spaceship etc. The modules for presentation then either register themselves as listeners in the simulation (e.g. a simulation might call all registered listeners when a unit dies etc.) and perform their tasks accordingly. Rendering is completely plugable, it simply takes a simulation instance and inspects it’s current state, rendering things accordingly. This allows me to easily plug in any rendering module i want, go from 2D to 3D etc.

    Due to the missing interaction between simulation and presentation the whole thing is a lot more structured and easy to understand. Seperation of concerns. While in Cocos2D there’s a seperation into nodes and actions you still have to keep both your logic and rendering state in the nodes from what i could gather. I’d rather not have this.

    I by no means say that the way i usually code is the best, it all depends on what you and your team are comfortable with. I tend to keep things as simple and seperated as possible, trying to avoid all those sideeffects which are hard to follow in engines like Cocos2D (at least for me). If Cocos2D and other semi-scene graphs work for you, then more power to you πŸ™‚

    My approach allowed me to port the space invaders clone from its original framework to libgdx in 20 minutes, i could totally rework the presentation of it without ever touching any simulation classes, include new control schemes without doing anything to the simulation etc. etc. You can find the original version of that clone here, the libgdx version can be found here. I wonder how hard it would be to port something like this from say Cocos2D to Andengine.

    Having said all this i want to emphasize that we are talking about mobile and thus really small games. The rules are a bit different for such games compared to something like Mass Effect, at least in my opinion.

  5. Oh, and by the way: kudos for the Noiz2 port for Android! I love that game. I just noticed that Newton and Noiz2 nearly have an identical icon :p

  6. HI Mario,

    Thank you for an excellent and very clear reply. That does answer my question. I can see that is maybe a better approach in some respects. There is a a fair bit of management going on in the cocos2d in terms of removing nodes and actions to reflect the game state as far as I can tell. Trying to reimplement this type of design I am coming up against this issue. We’ll see how I get on. I enjoy the intellectual exercise of it.

    Thanks for the kind words on Noiz2. I think that game was a little too weird for people as I thought it was going to be a big hit but instead it seemed to polarise opinion. Only people with taste got it the rest complained about the vector graphics, hilarious really. Thanks again for taking the time to reply.

  7. Thanks for the review on AndEngine. Let me tell you your review help me have a better understanding of the 3D engines for Android and clarified how difficult is to program for the very different devices Android has. I was thinking I was a extremely lousy programmer ( I am but not as bad for not having a formal education in CS) but I see that way more intelligent programmers struggle to make their software run properly in Android. I just hate that Android does not have a standard screen size for cellphones, that would avoid a lot of pain and grief for a lot. Now I know I need to put more time for iPhone development if I want to make any money in this industry.

    Love Newton, excellent game I hope to see it for the iPhone soon. Just one thing, and this is just my opinion, graphics should be made more polished like a la Space Physics. Did you made the graphics yourself or you had a graph designa?

  8. I don’t think that the different screen sizes are a problem really. It’s the same on the desktop so i’m used to that. The same goes for graphics hardware, you have a multitude of different gpus out there both in android devices as well as on the desktop. Understanding the APIs you use is key to get a well performing application for multiple platforms.

    I don’t think that there’s a lot of money to make on the IPhone at this point in time. The market seems saturated and hitting it big is a lottery.

    Thanks for the comments on Newton! The graphics are typical programmer’s art and i won’t change them i think. Newton is gradually phasing out, it was an initial experiment and i don’t plan on investing more time. Unfortunately i’m not willing to invest 1k for a Mac plus another 99$/year to be allowed to develop for the IPhone along with the risk that my app might not be accepted for publication. So there will never be an IPhone port of any of our games. Stupid principles πŸ™‚

  9. Hi Mario,

    Links to source and apks seem to be broken, can you point out where I can get source for the benchmarks?


Leave a Reply

Your email address will not be published.