GameMaker Question about Instances and Texture Memory [SOLVED}

[otterZ]

I am interested in how texture memory on a device is influenced by instances using sprites in different ways. I can't quite put into words exactly what I mean here, so here are some example scenarios below . . .

Example A) If I were to create an instance that drew a large sprite, let's say for example's sake the sprite had 300 images within that sprite. I created that instance and my device took a performance hit uploading it to texture memory. Let's say it was laggy.
Then, if I destroyed that instance, then created another instance (from a different object) in the same room / level which also used the exact same large sprite . . . would my device have to upload it to texture memory again? Or would it already be preloaded into my device's texture memory?
____________________________________

Example B) If I created an instance which used a large sprite, then drew it to the screen scaled down to 20% of its full size and my device took a small performance hit. Then drew it immediately full size (within the same draw event using conditionals and an alarm) to the screen. Would the full sized sprite take a performance hit, or is the sprite already drawn into the texture memory on my device for full size too, or would it have only the 20% version saved in my device's texture memory?

____________________________________

I don't want to know about sprite_prefetch here - l'm just interested in how texture memory is stored in relation to instance behaviour.

I am interested because the project I am working on is very much centred around large sprites; the game is working just fine, but I don't quite understand how GM is organising texture memory in regards to instance behaviour in the background.

I'd appreciate more experienced GM programmers' advice on how to understand this better

 

[NightFrost]

Background: texture memory is your GFX card's memory where texture pages are loaded. No sprite (texture) can be drawn without its page first being loaded into the memory. I assume this operation has priority, so no matter what already exists in memory, if necessary it will make room for new texture page to guarantee a draw. Having said that,

A) Not all 300 would be loaded, only the ones that need to be drawn. If you need to use several of the subimages, the swaps depend on draw order. If successive required subimages are on different pages then there's a swap between each. To put it in another way, each draw operation is a potential texture page swap. It all depends on what is presently loaded into memory, and where the next thing to draw resides. That's why you want to arrange sprites to texture pages in logical manner to reduce swaps.

B) Scale has nothing to do with it. Scaling happens during a draw, when the GPU does its shader magic (AFAIK all draws pass through the shader pipeline). You're essentially drawing the same sprite twice in succession, so there's no swap.

 

[otterZ]

Thank you NightFrost, this is great food for thought. That is interesting about scaling having nothing to do with it and about reducing swaps. I will experiment with this on a few mini experimental projects just to cement this into my mind. That pretty much answers my question, I appreciate you taking the time to reply. I'll mark this thread as solved.