How to delete a texture page?

[dawidM]

Hello, I am creating a html5 game, and I figured out that the initial loading time is proportional to the number of sprites I add to the game ( through IDE as resources). I have a lot of graphics, so if I add all the sprites, the game loads around 40-50 seconds. I found a way to shorten this time significantly, by deleting sprites from IDE and loading them just before a particular level ( "lazy load").

I use the add_sprite function and the asynchronous event. Almost everything works well, now the initial loading time is shortened to 7 seconds but I have a different problem. When I went to the debug mode I was shocked...

It turns out that GameMaker creates one texture page per one sub-image of the sprite!!! So if I want to load 3 sprites ( each of them containing 25 sub-images) it creates 75 texture pages! I was very surprised, but I figured out that this they way that GameMaker works - pretty odd but I can do nothing about it. So to prevent the game from dropping FPS, I thought that I can maybe delete the texture pages of the sprites I do no longer need.

The question is how? How can I delete a texture page with one sub-image of the sprite I added by the function add_sprite? I tried sprite_delete and texture_flush but they both don't delete the texture_page. What are my options?

Regards,
dawidM

 

[Bart]

How are you loading the sprites? Do you have 75 calls to sprite_add? Or only 3?
It seems very odd to me that each sub-image would take up an entire texture page.
That'd mean a sprite gets split up over multiple texture pages.

Did you have a look at the texture functions? I haven't used all of those myself yet but there's quite a few there that may be of use.

 

[TheouAegis]

How are you loading the sprites? Do you have 75 calls to sprite_add? Or only 3?
It seems very odd to me that each sub-image would take up an entire texture page.
That'd mean a sprite gets split up over multiple texture pages.

Did you have a look at the texture functions? I haven't used all of those myself yet but there's quite a few there that may be of use.

How are you loading the sprites? Do you have 75 calls to sprite_add? Or only 3?
It seems very odd to me that each sub-image would take up an entire texture page.
That'd mean a sprite gets split up over multiple texture pages.

This has been an issue in Studio since its incarnation. Not sure if it was an issue in GM8 since you couldn't see texture pages, but it was a major criticism of GMS. You could check the debugger to see if it has been fixed yet.

 

[dawidM]

I have only 3 calls sprite_add. I was extremely shocked when I run the debugger and saw that each sub-image has its own texture page (Before I thought that maybe each sprite would have had its own texture page - it wouldn't be optimal but still acceptable). As you can conclude, 75 texture pages is not perfect for optimizing the game performance, so I want to delete those texture pages I do not use. But how? It has to be some function for this, but those ones I tried didn't work.

 

[Bart]

This has been an issue in Studio since its incarnation. Not sure if it was an issue in GM8 since you couldn't see texture pages, but it was a major criticism of GMS. You could check the debugger to see if it has been fixed yet.

Oh... That's something I actually didn't know yet.
So GameMaker links a sprite to multiple texture pages. Hmm...

I verified using the debugger in GM2.2. That's actually what seems to be going on behind the scenes. Same for creating sprites from surfaces.

Seems like the best way then, though by far not an obvious one, might be to use sprite_add with only a single sub-image, then figure out a way to see what's on that page yourself.
So you have a guarantee that the entire texture page is freed when you delete the sprite using sprite_delete.

Haven't tested, but maybe one of sprite_assign/sprite_duplicate/sprite_replace can be used as a workaround?

 

[TheouAegis]

You'd just have to test. I fear sprite_delete() and maybe sprite_replace() might be a major slowdown point. File reading is not a fast thing, image reading less so. And then you'd also be rewriting the texture page each time too. I always considered sprite_replace() as being for sprite swapping between levels, not between steps.

The other functions won't help with texture swapping, but I suspect that would end up being the least of your problems compared to sprite_replace().

Like I said, I don't know how bad sorite_add was in GM8 since it didn't use texture pages (or at least hid them), but it's definitely a stain on GMS. Recreating an NES game might be ok with sprite_replace() -- I've used it for pallet-swapping in GM8 -- so maybe if your game has the level of sophistication of an NES game, you could juggle texture pages. However, by the sounds of it the number of page swaps is already an issue in the early stages of your project.