Room load time increasing

I notice that my game is developing a small freeze before moving to the next room. Specifically, I'm making a 2D fighting game and, after picking characters and a stage, the screen pauses for ~100msec before loading the stage. It used to be immediate, but as the game grows this time seems to be slowly expanding. Interestingly, the stage music starts during that 100ms, which is the issue as much as anything - it's more obvious that the screen is frozen when the music plays early.

Curiously, this only happens the first time you go into a match. Going back to character select and going to a different stage (which is a different GM room) no longer causes the delay, despite the room being different.

In the end, it seems like this is caused by a need to pre-load assets or something along those lines. Any thoughts as to how to deal with this as my game size grows?
 

Yal

šŸ§ *penguin noises*
GMC Elder
You could measure exactly what happens using the profiler. (A breakpoint in a new 1-step dummy alarm could help you abort before any real in-game processing is run)

Chances are you're correct, though... GM isn't super-good at handling large textures, and even Skullgirls (which is written in an engine that has more control over them) had to have a system which unloads and re-loads textures dynamically. There's a "whoops you got 8-bit" failsafe if they don't load in time, where everyone gets replaced by a super-low-res texture that's stretched up to cover the correct area... these sprites are so small that they always fit in memory. (Remember, 2x the size means 4x the memory use, so it grows QUICKLY for HD sizes)
 

kburkhart84

Firehammer Games
Considering that it doesn't happen after the first time, I'm guessing it is indeed having to send the sprite texture pages to video RAM. A solution if that is the case...sprite_prefetch(), and/or texture_prefetch(). Calling these functions will make the texture pages load into VRAM right then. So, you could easily have a load screen(in case it lasts longer on other PCs), and in an alarm event on some object, call these functions to get it to load in the sprites you need for the next room. I'm suggesting an alarm event simply so that it gives a full loop's time to draw something first, otherwise the room will not have anything drawn. Note that this also would allow you to show little "tips" and similar if you wanted. You could also load several things in at once in a bigger project.

If you did not want to have a separate loading room, you could call those functions in some object just before changing rooms. This wouldn't stop the delay, but it WOULD make it happen before the music started in the other room, and it would not be stuck on a black screen in the meantime, rather it would still show whatever was on the screen before.

Finally, there exists texture_flush() which lets you unload graphics as needed. This is handy to keep VRAM usage as low as possible. If not used, theoretically, it could keep adding and adding textures to VRAM until it is full(if you had that many graphics that is).

The texture page/group feature set is something anybody using higher detail graphics should get familiar with.
 
Thanks to you both, that's super helpful advice. I had already broken my game into many texture-groups to better handle compiling after sprite editing, so that's a start. This snippet of code at game start seems to work great for me:

GML:
var texturegroup = texturegroup_get_textures("Default");
for (var i = 0; i < array_length_1d(texturegroup); ++i;)
    texture_prefetch(texturegroup[i]);
var texturegroup = texturegroup_get_textures("Misc");
for (var i = 0; i < array_length_1d(texturegroup); ++i;)
    texture_prefetch(texturegroup[i]);
var texturegroup = texturegroup_get_textures("Menu");
for (var i = 0; i < array_length_1d(texturegroup); ++i;)
    texture_prefetch(texturegroup[i]);
...etc, I did this for the ~10 texture-groups I have and the stages load much faster now!

I suppose the only downside to this is that it loads everything into VRAM right away, but I have to imagine it was loading all this into VRAM once a match would begin anyway. For now I suspect my game is small enough that this doesn't matter, but perhaps splitting the sprites into more texture groups would be good practice moving forward, and then work on unloading those resources after a match, etc.

Thanks again!
 

kburkhart84

Firehammer Games
If you know that all of those textures fit into VRAM just fine(based on the minimum requirements you are planning on having), then it isn't an issue having them all load at once. But if you were to have more art than what is good to have in VRAM at a time, then you would likely want to have more groups, one for each "stage" and depending on how much animation, etc... there is on the characters, maybe even have one each for them as well.

That said, the manual example shows basically the code that you have there...however, the description of the function says it can load the whole group at once, so theoretically you should be able to just supply "Default" to the texture_prefetch() function and it should theoretically work, instead of forcing you to have a loop. In fact, as that is the same way as the 2.3 beta manual is, I'm going to mention it as a suggestion in the beta forum that they maybe add a second example doing it that way.
 

Coded Games

Member
Also one strategy is to hide the brief freezes with transitions. A quick fade to black between rooms makes a 100 ms stutter unnoticeable when it happens at the middle of the transition.
 

NightFrost

Member
Games that have to load a lot between regions totally do loading screens. For example, Resident Evil and the door opening animations. Other possibilities are elevator waits, or loading tunnels (a simple tunnel long enough that there's time to push new texture sets to VRAM). And mist walls in Dark Soulsies, they blocked entrances in case bordering region was not yet fully loaded. Easy to see in DS3 at Firelink Shrine when you try to run out after teleporting in.
 
Top