Support for rgba4444 (16-bit PNG)

Solar2D General Questions/Discussion
#1

We have been trying to figure out if Corona SDK supports 16-bit PNG. From reading some of the old threads from 2011, it sounds like while Corona SDK can read 16-bit PNG, it will still be expanded into 32-bit PNG in memory. So, while it helps to reduce the desk file size, it doesn’t reduce the amount of texture memory required.

But then I found a comment from Carlos somewhere (I can’t seem to find the thread now), that seems to indicate that on some Android devices, Corona would automatically reduce the images down to 16-bit.

I would like to get some clarifications on exactly what the latest is in terms of support for 16-bit PNG graphics. The ideal, of course, is if Corona would render the 16-bit PNG that we have as 16-bit graphics in memory, thus saving memory, and allowing us to pack more animations into our game.

Thanks!
Andrew
[import]uid: 41124 topic_id: 28735 reply_id: 328735[/import]

#2

All image files are loaded into memory as 32-bit uncompressed bitmaps, regardless of the file format (JPEG, 8-bit PNG, 16-bit PNG, 32-bit PNG, etc.). This is true on iOS and Android. This is a graphics hardware constraint. The hardware wants uncompressed bitmaps for fast rendering. It works this way for desktop apps too.

We’ve actually never loaded images into texture memory as 16-bit bitmaps on Android. At least not on the GPU. We do lower the color quality to 16-bit when loading a huge image if the device does not have enough RAM, particularly on really low-end Android devices such as the Droid, but it gets pushed into the graphics hardware’s texture memory as a 32-bit image in the end. We also do other tricks to by automatically downscaling/downsampling the image when loading it if the device does not have enough RAM or it exceeds the graphics hardware’s max texture size. But even on the Droid, small images are typically loaded at full 32-bit color quality, so the above case typically only happens for huge photos. [import]uid: 32256 topic_id: 28735 reply_id: 115929[/import]

#3

Thanks Josh. This really helps to clarify things!
[import]uid: 41124 topic_id: 28735 reply_id: 115952[/import]

#4

Here’s some tips to help make your app more memory efficient, in case you don’t already know.

Make sure that all of your image file’s widths and height (in pixels) are a power of 2. For example: 16, 32, 64, 128, etc. This is another OpenGL constraint. If your image width/height is not a power of 2, then Corona has to bump up the size of the image in memory to the next power of 2 and fill the empty space with alpha. For example, if your image is 300x200, then Corona will bump it up to 512x256 pixels in memory, the next power of 2 for both the width and height. This is a waste of memory and if a lot of your image files are like this then it can really add up.

Another good thing to do is to do “sprite packing”. That is, pack as many images as you can into a single imagesheet file. Even if the images do not belong to the same sprite. This helps you with the above issue where the imagesheet width/height needs to be a power of 2, but the individual images/sprites inside it do not. Also, it helps improve startup performance because instead you are loading one image file instead of several. There are 3rd party tools that can do the sprite packing for you, such as SpriteLoq, which you can find via the link below…
http://www.coronalabs.com/resources/3rd-party-tools-and-services/

Anyways, I hope this helps! [import]uid: 32256 topic_id: 28735 reply_id: 116089[/import]