Good Afternoon!
I developed a scene through the Storyboard API with 6 spritesheets of 2048x2048.
My problem is that when you open the scene, it takes about 8 seconds to open, which is very bad.
Can someone tell me why this happens?
It is to have many images?
Thanks,
Tiago
Holy f… O.o
6 spritesheets with a size of 2048x2048 px, that is huge.
You load 100MB texture memory, I wonder that your device doesn’t crash. Or do you run it only on simulator by now?
Seriously, that’s way to big for nearly any device. I wonder what kind of images you load.
I would say you should try to stay under 20MB of texture memory (which is a bit more than one 2048x2048 spritesheet) for normal devices and some more for retina.
If you managed that your scene loading will speed up automatic.
Ok!
I understand!
Thanks,
Tiago
Hello,
I’m experiencing (to a lesser extent) the same issue as Tiago on my new Nexus 7 since I’m trying to use Dynamic Image Selection. My aim is to get a crystal clear picture on tablets so I use @2x and @4x imagesheets where it makes a big difference.
In order to minimize texture memory footprint, I split up my imagesheets so that each scene has its own imagesheet for images that belong only in that scene. I’ve made it so that at most 2 scenes are active at any one time. Inactive scenes have their imagesheet disposed of. So I’m pretty sure I got the memory footprint under control.
The tradeoff is that imagesheets have to be loaded with the scenes, which creates a slight hiccup (~1 second) before transition can occur. One example of a guilty imagesheet is a 948x240 png file. I use TexturePacker to pack my imagesheets by the way.
I’m concerned it will be even worse on slower retina devices. Have you guys got any tips and tricks to make the experience smoother for the user?
Should my imagesheets obey the power of 2 rule?
Does image file compression such as http://tinypng.org/ (therefore smaller size on disk) help much?
I’ve noticed that creating a lot of display objects at once can have an impact on the amount of time it takes for scene:createScene() to complete. Any tip regarding this?
Thanks,
Wenzil
The problem is that at the moment the scene transition occurs both scenes are “active” (use memory). Corona trys to clear out the memory used by scene 1 to load scene 2, which causes part of the delay.
As far as I know there’s nearly nothing you can do against that (except optimize your use of images).
Your spritesheets should have power of two (corona loads them in power of two anyways, so it makes no difference), but normaly TexturePacker handles that automatic. Image compression shouldn’t have a real affect to load time, because all images are loaded uncompressed in 32bit.
Deleting and creating many objects has effect on loading time too. You can try to load some of them in the enter scene and not in the create scene.
So, what can you do? Not much more then optimizing your spritesheets (make them as full as possible) and keep the amount of created and removed objects as low as possible.
Creating my objects in the enter scene (where I can) instead of create scene resulted in a pretty drastic improvement. Thanks for that 
Holy f… O.o
6 spritesheets with a size of 2048x2048 px, that is huge.
You load 100MB texture memory, I wonder that your device doesn’t crash. Or do you run it only on simulator by now?
Seriously, that’s way to big for nearly any device. I wonder what kind of images you load.
I would say you should try to stay under 20MB of texture memory (which is a bit more than one 2048x2048 spritesheet) for normal devices and some more for retina.
If you managed that your scene loading will speed up automatic.
Ok!
I understand!
Thanks,
Tiago
Hello,
I’m experiencing (to a lesser extent) the same issue as Tiago on my new Nexus 7 since I’m trying to use Dynamic Image Selection. My aim is to get a crystal clear picture on tablets so I use @2x and @4x imagesheets where it makes a big difference.
In order to minimize texture memory footprint, I split up my imagesheets so that each scene has its own imagesheet for images that belong only in that scene. I’ve made it so that at most 2 scenes are active at any one time. Inactive scenes have their imagesheet disposed of. So I’m pretty sure I got the memory footprint under control.
The tradeoff is that imagesheets have to be loaded with the scenes, which creates a slight hiccup (~1 second) before transition can occur. One example of a guilty imagesheet is a 948x240 png file. I use TexturePacker to pack my imagesheets by the way.
I’m concerned it will be even worse on slower retina devices. Have you guys got any tips and tricks to make the experience smoother for the user?
Should my imagesheets obey the power of 2 rule?
Does image file compression such as http://tinypng.org/ (therefore smaller size on disk) help much?
I’ve noticed that creating a lot of display objects at once can have an impact on the amount of time it takes for scene:createScene() to complete. Any tip regarding this?
Thanks,
Wenzil
The problem is that at the moment the scene transition occurs both scenes are “active” (use memory). Corona trys to clear out the memory used by scene 1 to load scene 2, which causes part of the delay.
As far as I know there’s nearly nothing you can do against that (except optimize your use of images).
Your spritesheets should have power of two (corona loads them in power of two anyways, so it makes no difference), but normaly TexturePacker handles that automatic. Image compression shouldn’t have a real affect to load time, because all images are loaded uncompressed in 32bit.
Deleting and creating many objects has effect on loading time too. You can try to load some of them in the enter scene and not in the create scene.
So, what can you do? Not much more then optimizing your spritesheets (make them as full as possible) and keep the amount of created and removed objects as low as possible.
Creating my objects in the enter scene (where I can) instead of create scene resulted in a pretty drastic improvement. Thanks for that