CLM logo Development Blog by CLM

Monitoring CPU usage on Android

Wow, almost year since the last entry? Time to fix that, especially when it’s such an important day — Anodia is available in the Apple AppStore for the exactly 1024 days! :)

Today I would like to share some of our experience with CPU usage on Android. As every platform is different, there are system specific aspects that we need to take care of. We noticed that Anodia on Android is using lots of CPU power when suspended, even though we’ve done the same logic as on iOS and Windows Phone. It turns out that we faced two problems:

First was related to our usage of OpenAL. Unfortunately there is no native support for OpenAL on Android, so we used apportable openal-soft port. It uses OpenSL as a backend, but as it turned out, OpenSL thread is quite busy even when all audio sources are suspended (~25% CPU usage on Sony Xperia Tipo) . Fortunately calls to alcSuspend/alcResume in game activity onPause / onResume methods solved this issue.

Second issue was related to listening for accelerometer data. On Android it’s required to unregister all listeners when suspending an activity. Otherwise it will consume CPU even when application is not used. In our case listening to accelerometer data caused ~3% CPU usage on Sony Xperia Tipo.

And that’s all, there is one simple lesson: adb shell top -m 10 and monitor tool from sdk are quite useful when it comes to monitoring CPU usage.

Transparency Optimization

During the implementation of a 60 FPS support we noticed that a few levels were not working as fast as they should. After digging a little deeper we found out that our bottleneck was the rendering.

In one of those cases, the texture we used looked like that:

What’s wrong with it? It’s 128×128 (16384 pixels), but it’s quite easy to notice that lots of pixels on the sides of it are transparent. After a few moments of trimming it down we got 108×108 texture that looks like this:

108×108=11664, so the new texture contains almost 29% less pixels It’s a quite good optimization! When a few dozens of sprites are rendered on the screen this might make a significant difference for your fillrate.

It’s important to remember that transparency comes at a cost, there is no way to discard transparent pixels prior to the texture fetch. Trimming down textures also helps to reduce size of the rendered sprites, which might lead to nice performance increase in GPUs that use tiled rendering (like the PowerVR GPUs used in Apple mobile devices).

In-App Purchases piracy

Today I want to discuss one issue that we noticed after introducing Anodia 2.0 version — piracy of In-App Purchases.

For quite some time, we’ve been using Localytics to gather statistics that help us improving our games. One of them counts the number of coin purchases. To be honest, I never supposed that the number of pirated IAP might be so high — just check the graph for Coins Purchase event:

Coins Purchase event was reported almost 10000 times, that’s huge. But, you know what? In the same time we had 150 IAP sales, it means that in our case 98,5% Coins Purchases events are due to piracy. Not to mention that not all players are visible in Localytics (because we send the events only when a player is playing Anodia and is on a wifi).

We’re probably a little bit guilty here as we’re not doing any kind of receipt validation, but I’m personally shocked by the scale of this problem. It’s a little bit sad too, as that additional income from IAP would make a big difference in going indie full time. Unfortunately it’s still not possible.

If you’re interested in per-country details, here they are:

As you can see China is the biggest IAP consumer (even though it’s one of the few countries where Anodia has a 4.5 star rating instead of a 5). If you are curious how many of those real 150 IAP sales were made in China, here’s your answer: 1. The cheapest of course ;) .

We’ll probably introduce receipt validation sometime soon, but I believe that this should be a little bit more protected by the App Store itself.

I would also like to thank everyone who resisted the urge to pirate the IAP and supported us. Thank you, it really means a lot to us!

BTW, Anodia 2.1 is available and it runs in 60 fps on devices with Retina Display and on all iPads. It’s really nice and smooth, you should check it out.

Living in a 60 FPS world

When we released the first version of Anodia we received a few questions about frame rate in our games. To be honest, our target was to have solid 30 FPS on almost every possible device (unfortunately first and second gen devices tend to be a little slower). It seemed that achieving more FPS would be very complicated, especially as some parts of our framework were not prepared for this (i.e. using frames instead of time deltas).

As a first step we decided to check if it’s worth effort at all. We changed hard-coded FPS from 30 to 60 and I personally was shocked — game was running at double speed, but all menus were perfectly smooth! GUI is completely time based so it was possible to make comparison on two devices.

Our logic was already decoupled from rendering, but it was driven by the same TaskManager class. The tricky part is that TaskManager updates were handled by NSTimer with 1 ms interval. It was time to finally use CADisplayLink and trigger rendering from there. After fixing some bugs in TaskManager and implementation changes in Renderer we were able to get 60 FPS without changing game logic (still updated 30 times per second).

This is when the real fun begins — at this point everything looks the same as in 30 FPS, time to interpolate. Framework required adaptation in GUI, ParticleSystem, FadeIn/FadeOut transitions. Just take value from the previous and the current logic update and do linear interpolation to get value in between.

When framework was ready for 60 FPS, updates in Anodia started — after changing bonus manager (those falling down bonuses) and game objects handling most levels are working perfectly fine. There are only a few that require some manual tweaking. As we were aiming in 30 FPS in the beginning, sometimes performance is a bottleneck, but it seems that this should be not so difficult to fix.

What does this mean for players? Anodia and Hexbee updates are coming soon, including smooth 60 FPS on iPhone/iPod with Retina Display and all generations of iPad. Unfortunately we are not able to test it on iPhone 3GS so no promises for this device.

If you are interested in this topic, Noel posted an interesting article that made our quest to 60 FPS a lot easier.

Anodia 2.0 is released!

Anodia 2.0 is available on the AppStore!

The biggest changes in comparison to 1.1 version:
- 48 new levels
- level unlocking in Quick Play mode
- Retina Display support for the new iPad
- unlockable equipment
- iCloud support for score, stars, unlocked levels and equipment
- and… Trevor (as shown below)!

Trevor is optional and can be enabled in the equipment menu. He adds a little personality and cuteness to you paddle.

We hope that You all will like this version as much as the previous one!

Anodia 2.0 is ‘Waiting For Review’

A few days ago we shared an information on our Twitter and Facebook that Anodia 2.0 is ‘Waiting For Review’. Keep fingers crossed for a quick approval!

What does this mean for us? We should finally have more time to write regular entries on our devlog and start prototyping new games. And we sure have a lot of (potentially) neat ideas that we want to try! :)

Automated stability testing and memory leaks detection

It’s over one month since the last entry, but we’re trying to focus on Anodia release. One of the tasks that we’re currently doing on a daily basis is stability testing and memory leaks detection, but it’s not just playing the game again and again — we’ve implemented automatic mode that plays game by itself and when a level is completed, a new one is selected randomly. During 12 hours such test completes almost 200 levels.

As for stability testing, we’re starting game under debugger and leaving it for a night. If something crashes there is usualy callstack available in debugger along debug logs — this should be enough to identify and solve the issue.

For memory leaks we’re just monitoring memory usage to check if it’s not increasing in some strange manner. For identifying memory leaks in Obj-C we’re using Instruments and for C++ code we’re using build on Windows with additional memory allocation tracing implemented in WinAPI.

It seems that we haven’t seen any crashes recently and we solved a lot of memory leaks. There is still some testing ahead of us, but the most important information is that we’re trying to focus on the best experience for the players.

Anodia 2.0 Sneak Peek #3

It’s time for a Sneak Peek number 3! I wish you could see those on the New iPad Retina!

Anodia 2.0 Sneak Peek #2

It’s almost half of May and unfortunately Anodia update is quite not ready yet. We’re busy on making is as good as possible and there is still a lot to do. As usualy with pareto principle, 20% of work takes 80% of time.

Meanwhile, here’s a small sneak peek of the things to come (and yes, those old levels are optimized for the new iPad Retina):

Impact of FAAD campaign on Anodia

We recently shared information about strange situation with Anodia Lite downloads, this time we would like to share some information about impact of FAAD campaign on Anodia. Agreement with FAAD is negotiated individually by developer and we’re not able to say anything about it, but I hope that information in this post will be useful.

Anodia was included in FAAD at the end of August 2011 — Anodia was free from August 29th to September 6th. It’s a little bit more than one day, but that’s actually the point of making such campaigns — try to be free as long as the game is getting up / stays high in ranks. Total amount of downloads during the free period was about ~2.2 mln and we reached #1 in free apps in a couple of countries, including USA.

Sales after campaign are certainly bigger then before it, this is the profit chart from the first 6 months of Anodia sales:

There are two spikes, the first one is when Anodia appeared on the AppStore, the second one is just after FAAD campaign. It’s easy to note that profit after FAAD campaign stabilized at a higher level then before it. To be honest, it never went back to pre-campaign level so we’re actually happy with the campaign results.

Cooperation with FAAD was a good move and we’re glad that we’ve done it.