2

In my Game i'm loading around 13-15 Png's which include few sprite sheets(6-7) of 2048x2048 dimension and others 1024x1024 and some 512x512.

and now i'm facing the huge memory warning. There is no way for me to reduce the number of sprite sheets in my game :(.

So, m thinking to convert all the 2048x2048 sprite sheets from png to pvr.ccz format.

Is that the optimal solution or Some thing else is there, which i'm completely missing?

Any help would be highly appreciated.

aToz
  • 2,463
  • 1
  • 24
  • 34
  • Just to clarify, Do you have 6-7 SpriteSheets with 13-15 .png files on each SpriteSheet or 13-15 .png files with an additional 6-7 SpriteSheets. – Michael Sep 13 '11 at 04:12
  • @Michael:No actually i've 6-7 sprite sheets of 2048x2048 which has some 200-240 animation frames on it.Also, few sprite sheets are of 1024x1024 which also includes animation frames same like the first one. – aToz Sep 13 '11 at 05:53

1 Answers1

1

If all the PNG/texture images have to be available for each frame, then each will be stored uncompressed in texture memory and thus the memory problem. No GPU (to my knowledge) can render directly from a compressed PNG (or JPG for that matter) image.

The only options are to drop to, say, 4444 colour or to use PVRTC (probably at 4bpp). [Update: WRT PVRTC, I'm assuming this is an iphone game.]

Simon F
  • 1,036
  • 8
  • 23
  • Thanks for the reply, i've checked my game after setting the RBBA4444 value, even after that the memory warning is still there and also the crash,I've compressed all the png's by png index color mode compression and it seems like i'm good to go with it,but some of the art is looking very weird :(.. but the crash issue is resolved. – aToz Sep 15 '11 at 09:30
  • The compression method you use for PNG is irrelevant - the API will have to decompress them (to 8888) before they are stored in memory accessible by the GPU. You _have_ to use a texture compression method** that is supported by the GPU which, in this case, would mean PVRTC at either 4bpp or 2bpp (though the latter is more intended for natural/3D textures) **Texture compression nearly always uses a fixed rate of encoding (unlike PNG or JPEG which varies) and permits random access to the texture data without having to decompress large sections of the texture (again, unlike PNG or JPG). – Simon F Sep 19 '11 at 09:01