Battery Drain and Display Objects

So I recently tested my game and discovered that it causes the phone to run hot, along with draining the battery rather fast. This was quite alarming, considering I must be doing something wrong to cause something that taxes the phone that much. I’ve been good about disposing all unused objects, event handlers, and timers. After a little research, I came across this article. In it, there is a section on reducing power consumption, and after some thought, I became baffled by the two seemingly different clashing best practices.

Basically this: My game consists of image display objects that are generated and thrown at the player. If the player hits these objects, they shatter into 8 to 10 pieces which consist of another 8 to 10 image objects. I create these objects on the fly, and dispose once they aren’t needed again, per best practice. My issue is that, the power consumption best practice dictates that I should reduce disk accesses, which DO occur every time I create an image display object, reading from the disk every time one is made.

So how might I address this issue? Keep in my, my game randomly creates and disposes a LOT of image textures on the fly.

Thanks!

So to answer some of my own question, I’ve discovered that texture images are cached on the first time being called, so even if I instantiate multiple display images, that texture should already be in memory. Still not sure why the battery still drains faster than desired…

It appears that your game use physics, I think that collision listener are something that also uses a lot of processing, so you should keep it to a minimum…

About the image, if you are using a lot of objects that uses the same image should not make difference.  If the images are different, you can gain some performance by putting them all in a sprite sheet.

If you use glider, you can run the Profiler to check memory consumption or simply use this code http://developer.coronalabs.com/code/output-fps-and-texture-memory-usage-your-app

So to answer some of my own question, I’ve discovered that texture images are cached on the first time being called, so even if I instantiate multiple display images, that texture should already be in memory. Still not sure why the battery still drains faster than desired…

It appears that your game use physics, I think that collision listener are something that also uses a lot of processing, so you should keep it to a minimum…

About the image, if you are using a lot of objects that uses the same image should not make difference.  If the images are different, you can gain some performance by putting them all in a sprite sheet.

If you use glider, you can run the Profiler to check memory consumption or simply use this code http://developer.coronalabs.com/code/output-fps-and-texture-memory-usage-your-app