1

I'm trying to specify the art sizes for an Android game with ~10 screens. I want the game to run on API 8+, and on all size screens except "small".

Since we're using API 8, I use the old "4 categories of screen" feature - I plan to support

  • normal (480 x 320, and up to 640 x 480)
  • large (640 x 480, and up to 960 x 720)
  • xlarge (960 x 720, and up to 1920 x 1200)

A 1920x1200 png file is ~4.1MB. So 10 of them is 41MB, and we've almost blown our 50 MB app size limit (Play Store).

So three questions: 1. how do people support detailed artwork for game screens? Do I have to use bland colored 9 patch pngs files for the backgrounds? Or is it feasible to store all art at the 960x720 size, and allow it to be resized by Android for large and normal screens? 10 background files of this size total to about 15 MB, which leaves 35 MB for everything else.

What if I used jpgs instead of pngs? How much quality would I lose? Since I would only ever be downsizing, this should be OK, right? 10 jpgs of 960x720 is only 4.3MB.

  1. If I allow Android to resize it, how do I support screens that have a different aspect ratio than the 4:3 of 960x720? Is there a way to specify in the layout XML "use the drawables from the large folder, but "letter box" it onto the screen, so that the longest dimension just fits" ? (And for xlarge screens bigger than 960x720, just put the drawable in the middle of the screen - don't stretch it at all)?

  2. DPI resolution of the screen doesn't factor in this at all? DPI only needs to be taken into account when you want something to be roughly the same size on different res screens, like an icon or button. Correct?

Seems like this should be a solved problem with a well known pattern or template to follow. How have other people done it? Does everyone use either huge downloads post install (want to avoid) or 9 patch backgrounds?

Thanks in advance for any advice. I searched here on several terms, and looked at about 25 past answers, without finding what I am looking for.

Peter

Cerbrus
  • 70,800
  • 18
  • 132
  • 147
Peter vdL
  • 4,953
  • 10
  • 40
  • 60
  • You could adjust the compression levels on your images using say photoshop, gimp or paint.net. Sometimes it's a balancing act between size and compression. – Davos555 Mar 28 '13 at 16:00
  • 1
    In addition to Davos555 great suggestion, I should look at storing png files in RGB555 format. That uses 2 bytes/pixel, not 4 bytes. It drops the alpha byte, and compresses 8 color bits into 5. http://stackoverflow.com/questions/15595457/c-sharp-convert-argb-color-to-rgb555 – Peter vdL Mar 28 '13 at 17:58
  • Here's a related question, which has a completely wrong answer. http://stackoverflow.com/questions/5393359/which-screen-size-density-combinations-should-i-support-for-bitmap-background?rq=1 – Peter vdL Mar 28 '13 at 18:03

1 Answers1

1

Resurrecting the dead (thread): one way of doing things could be to provide just one set of bitmaps and do the scaling yourself. You can either provide large bitmaps and scale them down, or provide middle of the road bitmaps and scale them up (for large screens) and down (for smaller sizes).

The benefits of the former are that your art looks great on large screens and you are a bit more future proof (if you provide for this in your code). The downside is that you could (and actually likely will) run into Out Of Memory/Exceeding VM errors when decoding/loading these bitmaps on lower-end devices, even when doing it carefully. So I usually go for the second approach.

Scaling up can be done a number of ways, but one is to just load in the bmp at it's default size (use getResources().openRawResource(id) or BitmapFactory.decodeResource(etc) or even better use inputstreams or [according to some the best method] load/create using the FileDescriptor methods) and then scale it either by creating another bmp using createScaledBitmap() or if drawing to a canvas draw it to a destination Rectangle (better memory wise). For scaling down you can either use BitmapOptions like .inScaled or, again, use a smaller destination Rect in your canvas drawcall.

Doing it this way is way better and (for a game) faster than letting Android scale for you using those buckets (hdpi etc) and uses less memory if done right.

But beware as some bitmap loading methods are a bit buggy and create 'the bmp is too big for the VM' errors. Also learn to dispose of your bmps properly; a lot of people and Google/Googlers say Android does this and you don't have to set your bmps to null and recycle() them, but so far I've found that you do. Another caveat is to set the proper options (filtering/antialiasing etc) to prevent blurry bmps. And take care of un-optimal color/format/dpi settings on BitmapOptions/canvasses/SurfaceViews and even windows.

There's much more, but this should help anyone get started.

MacD
  • 783
  • 7
  • 23