@aukStudios basically nailed it.
If I understand correctly, OpenGL, the graphics engine that Corona SDK uses allocates texture memory based on the size of the texture rounded up to the next power of two. For instance:
120x60 graphic ends up using a 128x128 block of texture memory. Ergo, if you have a 2048x1536 background image for instance, that becomes a 2048x2048 block of texture memory. There are 4 color channels per pixel, (Red, Green, Blue and Alpha) so that’s 4 bytes of memory for each pixel in that 2048x2048 block of texture memory or 16Mb of memory to hold that graphic. That same graphic if it’s scaled would be 1024x768 or would take up 1024x1024x4 bytes of memory or 4Mb. Scaled to 512x384 it would be 512x512x4 or 1Mb of memory.
Given older devices like the iPad1 and the 3Gs and tons of android devices may only have 256Mb of memory, you can’t have a lot of those 16Mb textures running around before you run out of memory. Having 1x, @2x, and @4x graphics takes up more storage space, but only having @4x graphics kills memory on older devices. You have to try and strike a balance where possible.
Use JPEGs for non-transparent graphics to keep storage space low (yea, there PNGcrush going on, but I don’t see the gains with JPEGs.). Figure out what graphics will scale up without having to have @4x versions of them: gradients, things with solid areas, etc) and don’t include @4x versions in the bundle for those, resuse graphcis where possible. In other words if you have two graphics that are only different by things on a common background, don’t have two large graphics with the artwork on them, but have a background and then the differences in separate files so that you’re only having to have that large graphic once and then build the different versions with smaller bits. Then you can save enough to let you have the 3 different sizes in the bundle [import]uid: 19626 topic_id: 32124 reply_id: 128007[/import]
