@cspence
The powers of 2 texture memory size boundaries are:
1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, and 2048.
They stop at 2048 because if your image is larger than 2048, corona scales it down to be below that threshold, as most device texture hardware can’t handle texture bigger than 2048x2048.
A texture that is one notch lower than another takes less memory and blits faster (higher frame rate), so you basically want to use the smallest you can get away with and still look good on your target platforms.
There’s no way to reduce the size in texture memory through compression… It’s required to be expanded so that the devices graphics chip can quickly blit the image to the screen, so there’s no way directly around it (using any SDK). Some SDK’s might manage caching better than others, but corona seems to do a pretty good job of it, relatively speaking. (removing textures from text mem when you dispay:remove / nil the object, but still caching the compressed jpg elsewhere in memory so it can quickly expand and re-add it to texture mem).
In your case, I would strongly consider using iphone retina sized (640x960) resolution graphics and doing content scaling. Designing all your graphics on that format will keep full screen texture sizes down to 4 MB each (by not crossing the 1024 barrier).
Pieces smaller than 512x512 pixels would be smaller than 1 MB texture memory. And from my observations, the art looks pretty darn good when scaled up to ipad retina rez (and great when scaled down for older devices too).
A different problem is screen aspect ratio – iphones are 2:3, and ipads are 3:4 (width/height ratio). Essentailly your choices are, use dynamic scaling (which leaves a strip on the ipad sides), or stretch your content (which makes images look squished/stretched)…
So don’t worry, once you get past the memory issues, there’s plenty more hurdles to clear. Best of luck! [import]uid: 79933 topic_id: 32478 reply_id: 129349[/import]
