Strategies for Slow Loading

[slimshaky]

What strategies do folks use to combat long loading times?

I'm working on my second port to Saturn using Jo Engine. It's a modest sized game but it's big enough that I am seeing a 15-30 second pause on game launch when I try to load all of the assets. I'm thinking about splitting the loading into three parts: intro assets, title assets, and game assets. I do not have separate levels.

Do people tend to load assets in chunks to minimize a one time hit? On bigger games, do you unload assets at the end of a level (just curious)? Are you using some kind of loading indicator while assets load? Are there any general optimization strategies used to try to reduce the size of assets in hopes of reducing the loading time?

 

[nando]

Part of it is because the Jo Engine TGA loader is just slow. Because of how it works, it copies the file to HWRAM, parses it, and then copies it to VRAM - this isn't efficient.

It also has to parse the palette header every time (unless you're using RGB, but you will run out of VRAM faster), - and even if you set it to use the same palette slot, it still has to read that unnecessary data from the CD into HWRAM for each individual sprite file, wasting even more time.

You can definitely break up the loading into different parts (I do that), and you can use jo engine's sprite sheet loader so you're at least not parsing/seeking multiple files (RAM is a constraint here). You can also avoid using nested folders, because that takes additional seek time and directory processing.

But ultimately the better option is not to use the default loader/format and make your own. Check out the difference here between the jo engine TGA loader and my own custom one - keeping in mind I added *more* sprites to the custom one, to the point that I couldn't even load these assets without breaking them into multiple files on Jo Engine:


I basically pack about 350 individual sprites into a handful of container files. each scene loads a single container, which is also compressed, so loading from CD is really fast. It basically decompresses it straight into VRAM, so I'm only limited by VRAM on how many sprites can be packed together.

 

[Ponut]

What bottlenecks you usually isn't the transfer time or the processing time, its loading individual files and changing folders. Putting everything in root and combining multiple files into one package is how make faster.

 

[slimshaky]

Part of it is because the Jo Engine TGA loader is just slow. Because of how it works, it copies the file to HWRAM, parses it, and then copies it to VRAM - this isn't efficient.

It also has to parse the palette header every time (unless you're using RGB, but you will run out of VRAM faster), - and even if you set it to use the same palette slot, it still has to read that unnecessary data from the CD into HWRAM for each individual sprite file, wasting even more time.

You can definitely break up the loading into different parts (I do that), and you can use jo engine's sprite sheet loader so you're at least not parsing/seeking multiple files (RAM is a constraint here). You can also avoid using nested folders, because that takes additional seek time and directory processing.

But ultimately the better option is not to use the default loader/format and make your own. Check out the difference here between the jo engine TGA loader and my own custom one - keeping in mind I added *more* sprites to the custom one, to the point that I couldn't even load these assets without breaking them into multiple files on Jo Engine:


I basically pack about 350 individual sprites into a handful of container files. each scene loads a single container, which is also compressed, so loading from CD is really fast. It basically decompresses it straight into VRAM, so I'm only limited by VRAM on how many sprites can be packed together.

Thank you for responding. Is there an example of an alternate TGA loader on a Jo Engine project or are you pointing to usage of SRL as providing benefits in this area?

 

[slimshaky]

What bottlenecks you usually isn't the transfer time or the processing time, its loading individual files and changing folders. Putting everything in root and combining multiple files into one package is how make faster.

Thank you! I will give these things a try and will plan on reporting back on the results as a future reference for others.

 

[slimshaky]

I performed one quick test and got good results. I was doing some additional searching and found the thread below where they talked about manually changing folders just once. I updated my code to do that and my load time dropped from 18 to 8 seconds. I will still look at some of the other suggestions, but this is an easy win to get started.

Post in thread 'Balloonatics Thread'

Jan 14, 2022

Thanks to @SuperReye, I have greatly improved the loading time of Balloonatics and Flicky's Flock. See the diff here: Faster Load Time, Thx Reyeme · slinga-homebrew/Flickys-Flock@09e7abf.

TL;DR: The jo_sprite_add*() that take a directory argument has an optional input end up calling jo_fs_cd() twice (once to change into the dir, and once to change back out). This is a slow process.

This is slow:

g_Assets.SSMTF1Sprite = jo_sprite_add_tga("TEX", "SSMTF1.TGA", JO_COLOR_Transparent);
g_Assets.SSMTF2Sprite = jo_sprite_add_tga("TEX", "SSMTF2.TGA", JO_COLOR_Transparent)...

• slinga

• 

 

[nando]

Thank you for responding. Is there an example of an alternate TGA loader on a Jo Engine project or are you pointing to usage of SRL as providing benefits in this area?

SRL definitely makes it easier, since I can use a higher-level function to copy arbitrary data to VRAM (TryLoadTexture()), which reads from my own compressed container files. But you could probably still do the same thing in Jo Engine, it will just take more work.

Not using folders definitely helps a lot - but you can honestly get from 8 seconds to like, 1. IMO the CD isn't truly the bottleneck here. I feel like loading times on most CD based games were mostly due to lack of optimization (some are blazing fast, others are excruciatingly slow for no reason - I'm thinking VR Virtua Racing here, haha).

If you want to check it out, I have my loader here - GitHub - bimmerlabs/TMSF: tilemap / spritesheet format - although this isn't the finished version, I need to update it (I added additional compression), and the tools for generating the containers are not included yet.

also, look into jo_sprite_add_tga_tileset(). You can put multiple sprites into one .tga, it won't be nearly as fast as mine but it will still be faster than loading individual files for every sprite. I have an example of that here pixelpoppypong/core/assets.c at main · bimmerlabs/pixelpoppypong