Hi guys, in my Zombie Tsunami-like game, when it comes need the need to load several images at one time (when the environment changes), I experience a lag (or loading time) of 500ms. I know that 27 images are quiet a lot, but there isn’t something I can do in order to avoid this?
Thank you.
Thanks for your reply roaming gamer.
1 - some of them are 600x400, the others are smaller (200x100)
2 - Galaxy Note 3
3 - I’m using the latest corona build
4 - png
5 - yes
6 - yes
7 - display.newImageRect()
8 - composer
Hi @estiennelornzo,
To avoid a lag when a new image (or in your case, a bunch of new images) are loaded into memory, you can pre-load them before your level or scene begins. The most efficient (and in my opinion, easiest) way to do this is to combine them into an image sheet - which is a single image with all your images included - and load that image sheet at the start of your level or scene. Once they are loaded into memory, there is no delay using those images for the creation of new display objects. Image sheets, or sprite sheets, are often thought of in relation to animated sprites, but they can be used for static images just as easily!
Here is a link to the Corona Labs guide for using image sheets: http://docs.coronalabs.com/daily/guide/media/imageSheets/index.html
There are many ways that you can organize your image sheet and/or create it (including manually doing it with Photoshop or a similar application), but I think it’s safe to say that most of us who use image sheets regularly are big fans of an application called Texture Packer (https://www.codeandweb.com/texturepacker). Texture packer makes the whole process easy - you just drop in your images, use the easy-to-understand GUI to adjust your preferences and it kicks out an image as well as a lua file with all the necessary code. Texture Packer isn’t free (but I think there might be a free trial period), but it’s well worth the cost. Regardless of which tool you use to generate your image sheets, I think it’s something you should look into - it could very easily save you time and headaches down the line.
Good luck!
Hi schroederapps, thanks for your answer!
I had tried to load every image at the beginning of the application, but, since I have a lot of images inside my app, the used texture memory was too high to make the game runs smootly on older Android devices. What is -in your opinion- the texture memory limit which I don’t have to exceed in order to have a smooth application?
As I said before, prior my question was posted, I used to load every image at the beginning, setting their “isVisible” property on false, and they used almost the same texture memory that the sprite generated by Texture Packer uses, so I don’t think I will get better performance if I use this tool. Moreover, when I used to load all of the in one time, I didn’t get the lag between two environments (obviously), but very bad performance.
Do you think that Texture Packer is the way, even if I got 200+ images?
Thank you.
Hi @estiennelornzo,
The # of images itself is not necessarily the concern, but rather the total number of pixels and hence texture memory required (after all, 200 images sized 20x20 pixels would fit relatively easily into a single sprite sheet). And trying to support a wide array of Android devices is always going to lead to frustrations with the capabilities of older devices. That said, keep in mind that because the “power of two” rule will apply, you’re almost always going to wind up wasting texture memory loading a bunch of smaller images individually:
Copied from __http://docs.coronalabs.com/guide/basics/optimization/index.html:
In OpenGL, textures obey the Power of 2 (PoT) rule. This means that any texture rounds up to the next highest Power of 2 (2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, etc.) in terms of the texture memory it occupies. Thus, an image sized 320×480 and another sized 280×400 will both consume 512×512 of texture memory. Note that the next highest PoT occurs independently on either the horizontal or vertical, and the effective size does not always adhere to a “square” configuration — thus, an image sized 920×40 will round up to 1024×64 in required texture memory, not 1024×1024.
So I still encourage you to use an image sheet, for the optimization in texture memory usage, as well as for the simplicity in your project folder - ditching 200 image files for a small number of image sheets just makes things easier to manage, in my opinion. And I still recommend TexturePacker - though you may see some improvement by adjusting some output settings (more on that below).
Also, keep in mind that for better performance, you may want to avoid having unnecessary invisible display objects on the stage - since you’ve already loaded your image sheet, you should be able to create new display objects and destroy old ones with no noticeable delay.
Now, as to what your texture memory usage limit should be, that’s hard to say. At a certain point, you may just want to say that your game has certain performance requirements that make older Android devices non-supported. But I understand that’s not ideal. For myself, I try to keep image sheet usage to no more than two 2048x2048 image sheets in memory at any one time (4096 x 4096 for retina/HD screens). And you should keep in mind that Texture Packer does not necessarily limit the size of your output image sheets by default. So double-check the settings and make sure that the maximum size is 2048 x 2048 to ensure that you don’t end up with an image sheet too big for the devices you’re targeting.
All that said, if your game simply requires enough texture memory that there’s going to be a loading delay from time to time, you can always go the route of turning that bug into a feature and coming up with a clever loading scheme that “hides” the load time by employing some sort of transition between environments or scenes where a loading hiccup isn’t as noticeable. And at the very least you can try to be extra strategic about when you load new images into memory or create new display objects so that the hiccups occur at non-mission-critical moments.
In any case, good luck! And if you find a solution that works well for you, please remember to share it here so others can learn from your experience.
Best,
Jason
Thanks for your reply roaming gamer.
1 - some of them are 600x400, the others are smaller (200x100)
2 - Galaxy Note 3
3 - I’m using the latest corona build
4 - png
5 - yes
6 - yes
7 - display.newImageRect()
8 - composer
Hi @estiennelornzo,
To avoid a lag when a new image (or in your case, a bunch of new images) are loaded into memory, you can pre-load them before your level or scene begins. The most efficient (and in my opinion, easiest) way to do this is to combine them into an image sheet - which is a single image with all your images included - and load that image sheet at the start of your level or scene. Once they are loaded into memory, there is no delay using those images for the creation of new display objects. Image sheets, or sprite sheets, are often thought of in relation to animated sprites, but they can be used for static images just as easily!
Here is a link to the Corona Labs guide for using image sheets: http://docs.coronalabs.com/daily/guide/media/imageSheets/index.html
There are many ways that you can organize your image sheet and/or create it (including manually doing it with Photoshop or a similar application), but I think it’s safe to say that most of us who use image sheets regularly are big fans of an application called Texture Packer (https://www.codeandweb.com/texturepacker). Texture packer makes the whole process easy - you just drop in your images, use the easy-to-understand GUI to adjust your preferences and it kicks out an image as well as a lua file with all the necessary code. Texture Packer isn’t free (but I think there might be a free trial period), but it’s well worth the cost. Regardless of which tool you use to generate your image sheets, I think it’s something you should look into - it could very easily save you time and headaches down the line.
Good luck!
Hi schroederapps, thanks for your answer!
I had tried to load every image at the beginning of the application, but, since I have a lot of images inside my app, the used texture memory was too high to make the game runs smootly on older Android devices. What is -in your opinion- the texture memory limit which I don’t have to exceed in order to have a smooth application?
As I said before, prior my question was posted, I used to load every image at the beginning, setting their “isVisible” property on false, and they used almost the same texture memory that the sprite generated by Texture Packer uses, so I don’t think I will get better performance if I use this tool. Moreover, when I used to load all of the in one time, I didn’t get the lag between two environments (obviously), but very bad performance.
Do you think that Texture Packer is the way, even if I got 200+ images?
Thank you.
Hi @estiennelornzo,
The # of images itself is not necessarily the concern, but rather the total number of pixels and hence texture memory required (after all, 200 images sized 20x20 pixels would fit relatively easily into a single sprite sheet). And trying to support a wide array of Android devices is always going to lead to frustrations with the capabilities of older devices. That said, keep in mind that because the “power of two” rule will apply, you’re almost always going to wind up wasting texture memory loading a bunch of smaller images individually:
Copied from __http://docs.coronalabs.com/guide/basics/optimization/index.html:
In OpenGL, textures obey the Power of 2 (PoT) rule. This means that any texture rounds up to the next highest Power of 2 (2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, etc.) in terms of the texture memory it occupies. Thus, an image sized 320×480 and another sized 280×400 will both consume 512×512 of texture memory. Note that the next highest PoT occurs independently on either the horizontal or vertical, and the effective size does not always adhere to a “square” configuration — thus, an image sized 920×40 will round up to 1024×64 in required texture memory, not 1024×1024.
So I still encourage you to use an image sheet, for the optimization in texture memory usage, as well as for the simplicity in your project folder - ditching 200 image files for a small number of image sheets just makes things easier to manage, in my opinion. And I still recommend TexturePacker - though you may see some improvement by adjusting some output settings (more on that below).
Also, keep in mind that for better performance, you may want to avoid having unnecessary invisible display objects on the stage - since you’ve already loaded your image sheet, you should be able to create new display objects and destroy old ones with no noticeable delay.
Now, as to what your texture memory usage limit should be, that’s hard to say. At a certain point, you may just want to say that your game has certain performance requirements that make older Android devices non-supported. But I understand that’s not ideal. For myself, I try to keep image sheet usage to no more than two 2048x2048 image sheets in memory at any one time (4096 x 4096 for retina/HD screens). And you should keep in mind that Texture Packer does not necessarily limit the size of your output image sheets by default. So double-check the settings and make sure that the maximum size is 2048 x 2048 to ensure that you don’t end up with an image sheet too big for the devices you’re targeting.
All that said, if your game simply requires enough texture memory that there’s going to be a loading delay from time to time, you can always go the route of turning that bug into a feature and coming up with a clever loading scheme that “hides” the load time by employing some sort of transition between environments or scenes where a loading hiccup isn’t as noticeable. And at the very least you can try to be extra strategic about when you load new images into memory or create new display objects so that the hiccups occur at non-mission-critical moments.
In any case, good luck! And if you find a solution that works well for you, please remember to share it here so others can learn from your experience.
Best,
Jason