(Native) Heap Memory Statistics on Android

I’m working a tiny bit on an application called FaceIT from time to time which uses a shitload of bitmaps in the two activities it consists of. Note that i’m not responsible for the original application but just started fixing some bugs in it a couple of weeks ago. The app suffers from silly out of memory exceptions due to Bitmap data not getting freed as the Bitmap objects in the VM don’t take up enough memory so the GC collects them and frees the native heap memory associated with them (Which the GC knows nothing about). So i poked around a little and found out that there is actually a way to get the native heap memory usage of an app on Android!

Both return the respective sizes in bytes. With this it is quiet easy to monitor native heap allocations that happen with say Bitmap instances.

All hail Android! In other news: Collada is a bitch…

Crash Reports with Acra

I instrumented Newton with the acra library today. Acra registers an UncaughtExceptionHandler (which is also available in desktop Java) and everytime your application crashes bad on a user’s device it send an error report with information such as android version, phone model plus stacktrace to a Google spreadsheet you set up for that purpose. The steps to include this in your application are totally easy:

  • Create the Google spreadsheet as lined out in Arca’s Wiki
  • Create a class that extends CrashReportApplication and implement the getFormId() Method, returning the form id you got from your spreadsheet
  • add android:name=”YourCrashReportApplicationClass” to your AndroidManifest.xml file
  • Crash Reports!

I especially like the solution of using Google spreadsheets for this kind of crash reporting. It also works on devices < 2.2 (down to 1.5) which is a definite plus. Finally you can add your own reports besides standard crash reports at any point in your application. With this feature you could for example log the average FPS of your game. I used the standard crash reporting facilities of Acra and behold i got crash reports!
java.lang.NullPointerException
at at.knowcenter.pfx.gui.widgets.Label.dispose(Label.java:60)
at at.knowcenter.pfx.gui.Gui.removeWidgets(Gui.java:170)
at at.knowcenter.pfx.gui.Gui.render(Gui.java:136)
at com.badlogic.newton.game.MainMenu.render(MainMenu.java:167)
at com.badlogic.newton.game.Game.render(Game.java:126)
at at.knowcenter.pfx.backends.opengles.OpenGLESApplication.onDrawFrame(OpenGLESApplication.java:317)
at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:955)
at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:887)

Now that is nasty. Gui widgets in Newton are initialized in a lazy fashion. If the user is fast enough i try to dispose something which has not been initialized yet.

I hereby fully recommend the use of Acra in your application! The code is solid and doesn’t do anything nasty (e.g. send your stats to a 3rd party).

Deadly Chambers

Fellow developer Robert Green from Battery Powered Games released Deadly Chambers a few weeks ago. It’s an action adventure type of game where you try to escape various levels by shooting anything that gets in your way. It’s a nice pick up and play game and very polished. Here’s the trailer.

I could follow some of Robert’s development over the last couple of months in a couple of talks we had via GTalk. He put a shitload of effort into this game and i think it shows. Along the way i got to know some of the technical details of Deadly Chambers which are quiet impressive for a guy that wrote his first full blown 3D game (Light Racer 3D doesn’t count :)). Robert’s using a couple of old school techniques which work quite well on all those mobile devices out there. Lighting is mostly static from what i understand. His artist mastered the black art of generating light maps with Blender which gives the levels their nice look. The interesting thing is that the lightmaps as well as the textures are adapted to the device the game runs on, the better the GPU the higher the resolution of the lightmaps and textures. This makes the game run well even on those punny little MSM7200 chips you find in the G1/Hero.

The next piece in the puzzle is animation. Robert uses plain old MD2 interpolated key frame rendering. Modelling was performed in Blender, the export script seems to work nowadays :). Probably the biggest problem is the collision detection. He too stumbled across the articles by Peroxide and implemented those algorithms, stumbling over the same pitfalls i did. Calculating the intersections between ellipsoids and triangles is a pretty costly computation so you better first filter which triangles you send to the collision detection. For this Robert employed one of the oldest spatial partitioning schemes known as an Octree. You can query which triangles intersect a axis aligned bounding box with such a thing pretty fast so that makes it an ideal candidate for preselecting potential colliders before actually calculating triangle/ellipsoid intersections.

Along with the octree comes a portal system which uses manually placed portals for culling computations. It works pretty well and it seems manually creating the portals is still the way to go as automatic portal generation often needs manual post processing.

For all things GUI Robert went with plain Android GUI programming. I wouldn’t go down that rabbit hole myself to be honest, lacking the knowledge needed to skin and modify the Android GUI so it fits my game programming needs. However, the end result Robert came up with is incredibly well done. One wouldn’t be able to tell that it’s vanilla Android GUI stuff he’s using for his menus. The only place where he uses custom OpenGL GUI things is in game for the HUD and other things.

He included a shitload of input methods for the game, the multi-touch one being probably the most popular (but non-functional on first gen devices). By placing the analog sticks and buttons into opposite corners and some event filtering he was able to somewhat circumvent the multi-touch problems the N1 and Droid have. It is not a 100% perfect, but it’s the best multi-touch implementation i’ve seen so far.

All that being said, the game is really fun and you should check it out. There’s a demo version to get your mouth wet and a paid version for currently 2.99$. The game is great and the developer behind it knows his shit. So go out an buy a copy! Here’s the QR to the market for the full version (Click the QR code if you are on your device):


Btw, all the art and animation was done by Ryan Foss. He has a very interesting blog where he documents the making of Deadly Chambers. Go check it out!