Level load performance
by John Vanderbeck · in iTorque 2D · 05/20/2012 (5:46 pm) · 6 replies
Hey gang,
So things are coming along very nice on GraviTile and I can see the end in sight! I now have all game modes working, and you can start the game up in the menu and go from root menu all the way into the game and play, which is awesome.
However once I got this working, I noticed that loading my levels takes a very long time. This baffled me because really my game is extremely simple, consisting of very small levels with only a few graphics.
In looking at the console, it appears every time I load a level it takes over 2seconds for iT2D to exec the level data blocks file. If I play a level, exit then go right back in, it does it all over again, despite the fact that most all of the data blocks are set to pre-load and NOT unload.
Any tips or suggestions on making things faster?
So things are coming along very nice on GraviTile and I can see the end in sight! I now have all game modes working, and you can start the game up in the menu and go from root menu all the way into the game and play, which is awesome.
However once I got this working, I noticed that loading my levels takes a very long time. This baffled me because really my game is extremely simple, consisting of very small levels with only a few graphics.
In looking at the console, it appears every time I load a level it takes over 2seconds for iT2D to exec the level data blocks file. If I play a level, exit then go right back in, it does it all over again, despite the fact that most all of the data blocks are set to pre-load and NOT unload.
Any tips or suggestions on making things faster?
#2
About point #2 from Mich: You could make an unused level of common objects to easily create the datablocks for assets you always use. Just exec it manually somewhere convenient (like after the menu loads, as a scheduled action), and you should have slightly better overall loading time.
It's time to replace the libpng version too, Mich. See if it is a little faster, or if you can completely replace it with OS functions :)
05/20/2012 (11:26 pm)
Floyd-Steinberg dithering will help you get good-looking PVRs. Try TexturePacker if you don't have those fancypants Adobe things. RGB565 (square art, backgrounds) or RGBA4444 (other shapes). 16-bit colourspace halves the size, then PVR squeezes it down to 1/8th. The dithering ensures it looks as close as possible to the original 24/32-bit image. You may also try RGBA5551, where opacity is either on or off, for performance.About point #2 from Mich: You could make an unused level of common objects to easily create the datablocks for assets you always use. Just exec it manually somewhere convenient (like after the menu loads, as a scheduled action), and you should have slightly better overall loading time.
It's time to replace the libpng version too, Mich. See if it is a little faster, or if you can completely replace it with OS functions :)
#3
Thats actually what I thought I was doing when I set my datablocks to "preload" and "not unload" but apparently not?
I will try to move the data blocks outside of the level and exec them manually and that way the accompanying images will be loaded once and kept?
05/21/2012 (4:09 am)
I don't use very many images. There is no reason I couldn't load them all up into memory and keep them there, as each level uses the same images just in different ways.Thats actually what I thought I was doing when I set my datablocks to "preload" and "not unload" but apparently not?
I will try to move the data blocks outside of the level and exec them manually and that way the accompanying images will be loaded once and kept?
#4
05/21/2012 (4:36 am)
What you need to do is remove your function that unloads all the datablocks at the end of a level and only unload whats meant to be unloaded - the same way you don't need to add all the datablocks to every level datablocks anymore 
#5
- get the dimensions of the image before frame packing
- support the KEY image type
I've removed that step in
www.garagegames.com/community/blogs/view/21744/
and datablock load time goes down to around 50ms.
Basically the fix is to add dimension information to the imagedatablock, and to replace KEY with direct coordinate data - I used Zwoptex.
08/23/2012 (1:26 pm)
I'm currently using GLKit to speed up loading and I found that the source of the "unnecessary massaging" comes from a image load step done to- get the dimensions of the image before frame packing
- support the KEY image type
I've removed that step in
www.garagegames.com/community/blogs/view/21744/
and datablock load time goes down to around 50ms.
Basically the fix is to add dimension information to the imagedatablock, and to replace KEY with direct coordinate data - I used Zwoptex.
#6
08/19/2013 (9:09 pm)
I am almost a green hand on image processing program. But I think choossing a fine 3rd party tool whose way of processing is simple and fast can make the image processing work much more convenient than before. I suggest check its free trial package first if prossible before we make our decision. I hope you success. Good luck. 
Employee Michael Perry
ZombieShortbus
We are kicking around the idea of creating a different content pipeline. The rough idea is that before you deploy, you "package" your game. This will convert the raw images (PNG and JPG) into a more optimized format for loading in T2D. This concept is still happening at just the discussion level, so no tech plans had been made.
For now, the following tips will be helpful:
1. Use compressed formats when possible. JPG is easy, PVR is preferred.
2. If there is an image datablock being used in more than one level, try to keep it around even after a level unloads
3. If you have actual game objects that get used in more than one spot, you can make them persist outside of level loading and unloading. To do this, remove them from the scene before the level ends. This will cause them to exist in memory regardless of a loaded level. Then you add them back to the new level scene.