How To: Audit Image RAM

There are a multitude of concepts that people miss when jumping into programming, especially with a streamlined engine like Construct 2!

Ashley and everyone else on this site really come together to help explain these concepts, but sometimes we don't realize we've missed something until it's too late.

In the case of our team, we missed the concept of image RAM and how it affects stability of your app. We designed our first app for the iPad only to realize 90% into the project, our game crashed nonstop. This was because our images took up over 300MB in RAM! It's a miracle it even ran at all.

So what we had to do then was audit and cut back where we could to get our app down to a reasonable size. We were able to cut it down to just under 100MB, but at the cost of image quality reductions, and the end stability still wasn't where we had wanted it.

What I aim to do with this blog post is set people on the right path from the get go with how image RAM works and to provide you the system I used to audit my image RAM. This should help you to get a good visual overview of which of your images are wasting the most RAM and where you can cut the fat.

You can plug in the image asset list from your exported project and the sheet will give you some nice color coded information that isn't too hard on the eyes.

Just click the banner above or, you can click this link too: http://pangolingames.com/how-to-audit-image-ram/

There is a RAM vs Storage overview before it gets to the utility itself, that should hopefully help explain how image download size and image size in RAM are not the same thing.

In any case, I hope you find it an enjoyable and enlightening read!

This explains pretty much why abd how to worry about this, and I think it is the first time that I actually saw the fact that a 512x512 = 2x256x2x256 = 4 × 256 x 256 calculation is implied, I hope people will understand after that than designing a game with oversized assets is non sense, and that compressed image is not an image by itself, and so must be fully uncompressed.

Also it is basically a rule of thumb: the less memory you take, and the less calculations you do, the better your game will run, and the difference between good design and bad design is that a better design will do the same job with less, while a very baddly designed game will run in "theory", but will fail in practice when everything comes into play (this is also a reason why people should try to learn those things, I don t think they need to know everything about hiw it works in practice, but at least what is a better design, and for exemple inspire themselves of old games, which were far more limited).

You can also use a single assets layout in C2 and throw all images and animated sprites on there, C2's estimate is quite accurate if you have all assets on one layout.

Otherwise its good to know that a 512 x 512 frame = 512 x 512 x 4 bytes = 1MB in memory. 256 x 256 x 4 = 262kB in memory etc.

The worse thing you can do is have a image that is only a bit larger than the texture size, ie. you have a 550 x 530 image. It's actually 1024 x 1024 x 4 = 4MB in memory!

When I was working on my first game, the screen res was 1280 x 720p so I made a lot of BGs to fit that exactly.. not good. Each BG image is 2048 x 2048 x 4 = 16MB in memory. It wasn't funny.

Thanks for reading through and providing feedback!

— We had made the same mistake as well with BGs taking up waaay too much space, and by the time we realized, it was too late. We elected to reduce BG size rather than recreate them all using different techniques. It wasn't funny for us either

I'm still expanding my knowledge on the whole RAM thing, and am curious about the different image compression in RAM techniques that I didn't know existed at the time of writing the post. If C2 could leverage PVRTC and like methods on a broader scale, it could drastically improve the performance of all games. C2 does some RAM magic on export, but from what I've read the criteria the image has to meet is narrow, so most are rendered 32-bit, and from what I remember I think it doesn't go lower than 16-bit. I'd be interested in being able to get images from 32bpp to 2bpp, taking up 1/16 the space in RAM, especially since most of our artwork is cartoony and would not suffer from lossy compression methods like a photo would.

That said, I know there isn't a standard compression method across platforms, and those images would have to meet a narrow criteria across the board to be utilized in RAM that way, so it wouldn't be an easy implementation. Fun idea to entertain though.