Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In a few games in the Android Market/Google Play Store, huge bitmaps are drawn onto the screen.

For example, the game Unicorn Dash: Unicorn Dash island

and Robot Unicorn Attack:

Robot Unicorn Attack island

I'm assuming the entire island (which is multiple screens long) is loaded into memory. With probably around 10 different islands, how can something like this be possible? I've attempted to do something similar in one of my games, but I always ran out of memory. The bitmaps are (estimated) at around ~2000px x 500px at the largest which comes out to about 4mb each uncompressed? If you had 10 of them it would require 40mb of memory! So obviously I'm missing something. Is it plausible to be loading and unloading bitmaps into memory while the game runs? Or is there some other technique that I'm not aware of?


I extracted the images from Robot Unicorn Attack and saw that they were indeed whole images (not split up) of around 2000*500 pixels.

share|improve this question
Well for one they're probably not uncompressed images. Using PVR or DXT or whatever it is android devices use. – Tetrad May 2 '12 at 20:25
I think you missed some Unicorn apps: What about Tiny Unicorn? </nonconstructiveComment> – John McDonald May 2 '12 at 20:25
@Tetrad I've never heard of either of those, but a Google search tells me that they are some sort of textures for 3D? I'm not too familiar with 3d graphics, so can you explain further? Thanks – you786 May 2 '12 at 21:12
If you're using OpenGL you can use hardware compressed images instead of uncompressed images. Even if your game is "2d". You'll want hardware acceleration of whatever it is you're rendering. – Tetrad May 2 '12 at 21:26
+1 very interesting question. – ashes999 May 3 '12 at 17:38
up vote 2 down vote accepted

Is there some other technique that I'm not aware of?

You could use OpenGL to use compressed/palletized textures (see this thread for tips) -as others pointed out in comments.

I'm assuming the entire island (which is multiple screens long) is loaded into memory

Not necessarily.

Is it plausible to be loading and unloading bitmaps into memory while the game runs?

Definitely. If your textures don't fit in memory, even compressed, you have to use some kind of texture streaming. In a nutshell:

  • When loading the level, load only the textures necessary for the first few screens;
  • Find a working heuristic to determine when to unload/load textures (e.g unload textures that are further than N screens back, and load textures that are at most N screens upfront);
  • Load your new textures in a separate thread (so the game keeps running while you do so).

Be aware though that like any multithreading technique, this is error-prone and you need to design you process carefully to avoid nasty issues.

share|improve this answer
Well I guess the most important point is that these games are probably using OpenGL and not the 'regular' android graphics. This allows graphics to be stored in a compressed format in memory. @lorancou if you want to just prefix this information to your answer, I can accept it ASAP. – you786 May 3 '12 at 17:32
Done as you suggested! – Laurent Couvidou May 4 '12 at 0:33

Look at how libgdx manages bitmap data to get an idea of how to get around the Java OOM Exception that you're running into. Basically, what they do is use a native backing store for the bitmap data in which is gl bound in I've used libgdx to bind 10-15 512x textures with no memory issues on 1st gen devices. If I tried to manage the bitmaps in Java memory, it would fail like you are seeing.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.