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.
Ok really endless thanks for your straight.
The 3 seems difficult to implement but also the most effective.
Thanks again!
I would recommend that you stay with what you have with one minor change:
application = { content = { width = 320, height = 480, scale = "letterbox", fps = 60, imageSuffix = { ["@2x"] = 1.5, --\<---- changed from 2 to 1.5 ["@4x"] = 3, --\<---- changed from 4 to 3 }, }, }
When you have your @2x images set to 2.0, what you will find is that screens 639 px wide and less will get the 1x image. 640 to 1279px wide would get the @2x images and 1280+ would get the @4x images. Devices like the Kindle Fire are 600px wide devices, that means that Corona has to scale up the 1X images up quite a bit (87.5%) to make it fit that screen, where as if you had the @2x images you’re only scaling them down 6.67% and scaling down is always better than scaling up.
By using 1.5 and 3.0 for the values, now 1x images are used for screens less that 480px side. Your @2x images get used for screens between 480 and 959 an your @4x images get used on 960+px.
Rob
Thank you
The second time you help me in a day. I like to keep this config because among those I’ve tried I think is the best. In a few words you have explained many of my doubts.
Only a small thing is unclear if my 1x image (ex. “palla.png”) is 100*100, my image “ball@2x.png” is 150*150 and “ball@4x”.png" is 300*300?
So is it correct?
No. If ball.png is 100x100, then ball@2x.png would be 200x200 and ball@4x.png would be 400x400. The values (1.5 and 3) in config.lua tells Corona at what screen size it should switch. The images themselves still need to be 2x and 4x in size.
Rob
Ok perfect thanks a thousand.
At this point I have another small question I had not thought of at the beginning.
Is it enough for pre-charging or does it need something for other resolutions?
local texture = graphics.newTexture( { type="image", filename="ball.png" } ) texture:preload() local ball= display.newImageRect( texture.filename, texture.baseDir, 100, 100 )graphics.newTexture() knows how to use the @2x and @4x images correctly.
Rob
You fixed me hours of thought thank you
The only issue with this schema is old iPads… if you have a LOT of graphics then the 1.5x loads retina graphics on non-retina capable devices and this causes issues with memory.
Note: it is not an issue until you are allocating more than 100MB of assets.
The non-Retina iPads are 768px wide. Under this schema they would pick up the @2x assets which would be appropriate for the non-Retina iPads. The 4x assets won’t get picked up until you hit 960px wide on the short side.
That said, the @2x assets will add up to a lot of memory in a hurry. For instance if you’re following the 360x570 background that is recommended, it’s really a 512x1024x4 texture or a 2 megabyte image. If the 4x got loaded it would be a 1024x2048x4 image or an 8mb image.
Rob
I do not think I get to 100 Mb but I could go very close …
Is there something I can do to reduce the issues with memory? Pre-charging is not enough?
I see many applications, even 3D (so very heavy) around …