Other than cutting the amount of assets or their size there is not a lot you can do as a png will always be a 32 bit texture even if you supply an 8 bit highly compressed png in your apk.
My game, which allocates 100MB texture and at least 90MB Lua memory, sometimes gets shut down on iPad2 if the user has any other memory hog running - like Facebook.
I understand, in this case there are no more tricks …
Thanks again for your time
You can keep old scenes purged. You can watch your image sizes. Don’t make a 68x68 pixel image since it becomes a 128x128, make it 64x64. It will be 1/4th the size in memory. Each jump in Power of Two’s is a 4X increase in size since you’re doubling the size on two axis. If your image must be 68x68 on screen, have the image be 64x64 and tell display.newImageRect() to create it at 68x68. It will scale up a little, but it’s manageable. Avoid a lot of transparency around image too. I had a client once gave me an animation for a character that was supposed to take up roughly half the screen vertically and horizontally, but there was transparency that made the images fit the screen. In other words, on our 320x480 screen, each frame was 320x480 though the character was more like 160x240. The images were way larger than they needed to be. Once I trimmed them in, I saved a ton of memory.
Use ImageSheets where you can and keep them power of two based. It will save a lot of memory.
Rob
Wow very straight.
I had not thought about making 64x64 if the picture was a little bigger. For transfection I had already thought about it. ImageSheets are very useful for animations but for other images tend to complicate you read things, I prefer to use them only in case of an emergency. Small tips that solve great losses!
Thank you
Image sheets should always be used as this limits the draw calls open GL has to make and therefore your app will render faster.
This is true but every time I add or remove an image from a Image sheets I need to rebuild the sheet.
In my game there are characters and costumes for each addiction I should review everything or wrong? Also would there be very large sheetsnot a problem for lua loading?
I have about 60 characters 40*40 then a sheet 2400 * 2400. My @4x 160*160 then a sheet 9600 * 9600.
And with each update I would like to increase the number of characters
Use texture packer to create your image sheets as this automates the process. You can have multiple image sheets if the total size of your assets is greater than 2048x2048
Hello
Sorry if I reappraise this topic but it seemed useless to open a new one.
The fact is this by following the Rob council I did everything I needed and it works. I would just ask a question. Some of the backgrounds I use to avoid empty areas are 360 * 570. That is, the maximum in height and width. So my image @4x comes 1440 * 2280 and is about 2Mb. This is fine? Is not it too much for loading?
thank you so much
on high-end devices this is not an issue really.
Fine infinite thanks.
I asked this because I’m creating a sliding game I noticed that if I load about 25 images 960 * 1920 the game lag and any physical moves slow down a lot. Is there a quantity of memory that would be better not to overcome?
In the emulator obviously not by problems but on the devices there is a lot …
Seriously? I said 1 image is OK not 25! Why would you load 25 background images at such high resolution? Yeah the game will lag…
Unfortunately for my, I am serious… :unsure:
In my game there are palaces like “Endless-Skateboard” but high-quality ones are those pictures, I can get the number from 25 to 6. That’s enough? Is there a trick?
Please have two days in the ball …
have one background active and load the second when it is near to be shown. Google “lazy loading” you gotta optimise
OK thank you.
So even 6 is a high number? Do you just wonder how last thing you advice me?
Does the (texture:preload()) help or is it only harmful in this case?
Lets clarify a few things. The size of the file on the filesystem unless it’s a TIFF file will be smaller than the in-memory foot print. Your in-memory size is width * height * 4. PNG and JPEG both compress the file on disk to make it smaller.
Full screen images take up the most memory. The @4x version is 16X the size of the 1x version. 25 x 960 x 1920 x 4 = 184MB of memory which is most likely more than your app will get from the OS on a mobile device (tablets might be okay).
Clearly you should only load the background(s) you need.
Rob
Ok though if I do not preload the pictures when the user is running fast and I create the images at the moment there will still be a small lag. And that’s becuse I had decided to preload everything before
load the current background and the next background, when play moves to next background then discard previous background and preload the next background, etc.
Following yours tips or improving the app and now and much more fluid, thank you.
Just a little thing as I mentioned … I start creating background1 and background2. When I’m in background2 I remove background1 and create background3 etc. However, since I have removed all the texture:preload(), in this case the game freezes for half a second. It’s not much but it’s annoying to see, can you solve this too? Am I asking too much? I see many well done games and I would not want to be less …
Yes, I have a few suggestions.
1, try making your backgrounds out of many smaller graphics and use a lot of repetition. For example, don’t load a hires image of a forest. Have a couple of different tree images and clone them to simulate a forest.
2, if your game is fast moving then players won’t really notice the background too much so you could make your backgrounds 480 x 960 and scale them 2x. This would massively reduce your memory requirements and the images would load a lot faster.
3, stay with your hires images but split your backgrounds into slices, say 10, and load a slice per frame. In 10 frames you would of loaded your image but reduced the stuttering. You can play with the exact number of slices for best performance.