App Optimization

Solar2D General Questions/Discussion
#1

I am re-writing an app we wrote in xCode to be Corona for cross platform ability. It is a puzzle app and I am very new to Corona so this is my first attempt.

I have one puzzle working well, and (I know this is probably a bad thing and probably my problem) using just iPad 3 resolution pieces and complete image.

I have two sounds (12K & 1.5K) loaded, 7 piece images (that combined use up about 1/3rd iPad 3 pixel area), 1 full screen transparent b&w PNG, a rectangle display object, I put everything in display groups and remove them (removeSelf & setting to nil) but I am not concerned about clean up, I am cleaning up well.

I am more interested in my peak memory when doing a puzzle, which seems a lot higher than I would expect it to be. While running one puzzle with the above resources I am using 29MB Texture ram and 130MB memory in general. After cleaning up all but audio and displaying the final image and two rect and one text display object I am down to 17MB texture ram.

I know using just iPad 3 resolution image is a stupid thing to do, this is my first go at it and I need to account for each puzzle piece image resolution (as they are all different) a long with their “correct” location which means it would be a lot more complex with each resolution image (which is what we are doing on iOS now with 4 resolutions).

[import]uid: 160288 topic_id: 32478 reply_id: 332478[/import]

#2

A couple observations on memory use:

  • Texture memory only allocates sizes to the next higher power of 2. If your images are 1050 pixels wide, it allocates them as 2048 wide – almost double the actual size. If you’re using ipad3 resolution, you may be really jumping the size of your allocations without realizing it (by crossing a power of 2 size boundary).

  • Masks use memory too. If you’re masking puzzle pieces, the masks use a similar amount of memory, and large (iPad3) images have large masks. Don’t know if masks also occupy texture memory though.

Also, the full screen transparent BG you mentioned, if it’s at iPad3 resolution, it’s probably using a good chunk of memory all by itself. Perhaps you could use a smaller image, and modify it’s xScale and yScale properties (it will only use the memory of the actual image size, not the scaled size). [import]uid: 79933 topic_id: 32478 reply_id: 129180[/import]

#3

I am not using masks, I have 7 pieces of the puzzle sliced.
Each piece is around 10K-19K and the map is 147K, so that’s 237K, even if I doubled that, that’s around 500K. No where near 29MB. The only other significant objects are the two sound files which add up to about 14K.

Full transparent BG is 147K out of that 237K.

Other than that, I just have a full screen display.newRect.

I create a table with the color, piece dimensions, and the correct X/Y.
I created one display group where I added all the pieces, the background rect, and the “map”.

I have one function that handles the touch event, but I am not creating any objects there, just moving focus, changing X/Y of the targeted piece, and moving to final space if it hits it. [import]uid: 160288 topic_id: 32478 reply_id: 129185[/import]

#4

It sounds like the part you don’t understand is that the images are not compressed as jpegs in texture memory.

They are fully expanded – so a 10x10 image is expanded to take at least 100 bytes of memory. In reality, pngs or jpgs are often 3 bytes per pixel of color (RGB). And on top of that, they often have a byte of alpha, which all adds up to 4 bytes of memory per pixel of expanded image.

A 100x100 image takes up 40,000 bytes of texture memory.

And add on to this the texture memory requirement that the 100x100 image occupies 128x128 of texture memory. THEN you multiply by 4 bytes per pixel (So a 100x100 image takes 65,536 bytes of texture memory, actually).

That is how you add up to your giant texture memory numbers… [import]uid: 79933 topic_id: 32478 reply_id: 129186[/import]

#5

If 240K of images turns into 29MB texture memory and 186 ram usage, how do you make games that are a thousand times more complex than throwing an image on the screen with 7 mini images as drag-able pieces?

I’ve seen games like InfinityBlade run on old iphones that can’t even handle 29MB texture memory well. [import]uid: 160288 topic_id: 32478 reply_id: 129188[/import]

#6

I have a feeling this will run on most devices I am trying to run it on, but I want it to be as efficient as possible without making it look like an 8 bit Nintendo. [import]uid: 160288 topic_id: 32478 reply_id: 129189[/import]

#7

You make games that run on phones with low texture memory by… Using less texture memory.

Don’t use images that are 2000x1500 pixels.

There are strategies for loading different sized images on different sized devices, or using “content scaling”, or tiles, dynamic image resolution, or…

There’s a lot of strategies for looking good on all kinds of iOS and Android devices. I was just answering your question about the texture memory usage.

Do some searches on those terms, or ask around. The info above is accurate, and should at least be helpful as you search for a strategy that suits your particular content well. With the right approach, you should be able to load fast, have a high frame-rate, and look good on almost any device. Good luck! [import]uid: 79933 topic_id: 32478 reply_id: 129190[/import]

#8

I appreciate that, using the high resolution ipad version cuts a ton of coding (probably about 80 hours). I figured since it is just one image and smaller images and only 240K compared to 100K it would still be small enough to work fine. Amazing how far from the truth that is. [import]uid: 160288 topic_id: 32478 reply_id: 129192[/import]

#9

As far as texture memory goes, a single full screen iPad3 image (1500x2000 pixels), your bg image, would take up 16 MB of texture memory:

1500x2000 --> upsized to 2048x2048 texture memory pixels = 4 MB texture memory

RGB and alpha x 4MB = 16 MB texture memory

So, yeh, the truth in texture memory hurts.

But the deja vu thing about it is that texture memory limits on phones are so retro — set top boxes since the 80’s have had similar restrictions on texture memory, sprite registers, etc… And as the graphics hardware improved, so did the overall look of the games.

But you always knew when there was a standout developer for a platform… Activision in the 80’s did it on the old atari platforms - they knew exactly what the hardware would do, and made darn good use of it. (another word I’ve heard used for it is the German term: Fahrvergnügen )

And every so often, when you’re lucky, you run an app that does the same kind of thing.

[import]uid: 79933 topic_id: 32478 reply_id: 129193[/import]

#10

A couple observations on memory use:

  • Texture memory only allocates sizes to the next higher power of 2. If your images are 1050 pixels wide, it allocates them as 2048 wide – almost double the actual size. If you’re using ipad3 resolution, you may be really jumping the size of your allocations without realizing it (by crossing a power of 2 size boundary).

  • Masks use memory too. If you’re masking puzzle pieces, the masks use a similar amount of memory, and large (iPad3) images have large masks. Don’t know if masks also occupy texture memory though.

Also, the full screen transparent BG you mentioned, if it’s at iPad3 resolution, it’s probably using a good chunk of memory all by itself. Perhaps you could use a smaller image, and modify it’s xScale and yScale properties (it will only use the memory of the actual image size, not the scaled size). [import]uid: 79933 topic_id: 32478 reply_id: 129180[/import]

#11

I am not using masks, I have 7 pieces of the puzzle sliced.
Each piece is around 10K-19K and the map is 147K, so that’s 237K, even if I doubled that, that’s around 500K. No where near 29MB. The only other significant objects are the two sound files which add up to about 14K.

Full transparent BG is 147K out of that 237K.

Other than that, I just have a full screen display.newRect.

I create a table with the color, piece dimensions, and the correct X/Y.
I created one display group where I added all the pieces, the background rect, and the “map”.

I have one function that handles the touch event, but I am not creating any objects there, just moving focus, changing X/Y of the targeted piece, and moving to final space if it hits it. [import]uid: 160288 topic_id: 32478 reply_id: 129185[/import]

#12

It sounds like the part you don’t understand is that the images are not compressed as jpegs in texture memory.

They are fully expanded – so a 10x10 image is expanded to take at least 100 bytes of memory. In reality, pngs or jpgs are often 3 bytes per pixel of color (RGB). And on top of that, they often have a byte of alpha, which all adds up to 4 bytes of memory per pixel of expanded image.

A 100x100 image takes up 40,000 bytes of texture memory.

And add on to this the texture memory requirement that the 100x100 image occupies 128x128 of texture memory. THEN you multiply by 4 bytes per pixel (So a 100x100 image takes 65,536 bytes of texture memory, actually).

That is how you add up to your giant texture memory numbers… [import]uid: 79933 topic_id: 32478 reply_id: 129186[/import]

#13

If 240K of images turns into 29MB texture memory and 186 ram usage, how do you make games that are a thousand times more complex than throwing an image on the screen with 7 mini images as drag-able pieces?

I’ve seen games like InfinityBlade run on old iphones that can’t even handle 29MB texture memory well. [import]uid: 160288 topic_id: 32478 reply_id: 129188[/import]

#14

I have a feeling this will run on most devices I am trying to run it on, but I want it to be as efficient as possible without making it look like an 8 bit Nintendo. [import]uid: 160288 topic_id: 32478 reply_id: 129189[/import]

#15

You make games that run on phones with low texture memory by… Using less texture memory.

Don’t use images that are 2000x1500 pixels.

There are strategies for loading different sized images on different sized devices, or using “content scaling”, or tiles, dynamic image resolution, or…

There’s a lot of strategies for looking good on all kinds of iOS and Android devices. I was just answering your question about the texture memory usage.

Do some searches on those terms, or ask around. The info above is accurate, and should at least be helpful as you search for a strategy that suits your particular content well. With the right approach, you should be able to load fast, have a high frame-rate, and look good on almost any device. Good luck! [import]uid: 79933 topic_id: 32478 reply_id: 129190[/import]

#16

I appreciate that, using the high resolution ipad version cuts a ton of coding (probably about 80 hours). I figured since it is just one image and smaller images and only 240K compared to 100K it would still be small enough to work fine. Amazing how far from the truth that is. [import]uid: 160288 topic_id: 32478 reply_id: 129192[/import]

#17

As far as texture memory goes, a single full screen iPad3 image (1500x2000 pixels), your bg image, would take up 16 MB of texture memory:

1500x2000 --> upsized to 2048x2048 texture memory pixels = 4 MB texture memory

RGB and alpha x 4MB = 16 MB texture memory

So, yeh, the truth in texture memory hurts.

But the deja vu thing about it is that texture memory limits on phones are so retro — set top boxes since the 80’s have had similar restrictions on texture memory, sprite registers, etc… And as the graphics hardware improved, so did the overall look of the games.

But you always knew when there was a standout developer for a platform… Activision in the 80’s did it on the old atari platforms - they knew exactly what the hardware would do, and made darn good use of it. (another word I’ve heard used for it is the German term: Fahrvergnügen )

And every so often, when you’re lucky, you run an app that does the same kind of thing.

[import]uid: 79933 topic_id: 32478 reply_id: 129193[/import]

#18

That makes sense now. Any way to decrease this usage (like use compression in memory) or anything?

I understand the math now.

Where can I find a list of all the texture sizes so I know what something will be loaded it. Like 64x64, 128x128, 256x256 and so on. [import]uid: 160288 topic_id: 32478 reply_id: 129334[/import]

#19

A simple calculation will give you what you need:

A 32x32 image would have 1024 pixels. Corona loads images at 32-bit per pixel, so that’s 32,768 bits for that image.

Divide by 8 (bits in a byte), which gives 4096 bytes - divide by 1024 to find the KB, which gives 4KB.

[import]uid: 33275 topic_id: 32478 reply_id: 129346[/import]

#20

@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]