Dynamic sprite deletion warning.

[ThreeOhFour]

I've just started using a dynamic sprite in my project, and when running a build and then closing it, the warnings log displays this:

"Game : (room:6)[R 758] Dynamic sprite 777 was never deleted"

Is there a point that I *need* to delete a dynamic sprite? It displays a GUI element and I plan to use this from the start of the game to the finish. But this warning makes me wonder if I should delete it on exiting the game or something?

[Snarky]

No, it's not really necessary: when AGS closes it frees up all the memory anyway. The only reason is so it get rid of the warning. It might be good practice to try to keep your game warning-free, so that if there is a bug elsewhere that creates a bunch of DynamicSprites that are never deleted, you will notice it.

[eri0o]

If I remember correctly this warning is only emitted when running in debug mode (I don't remember if only when run from editor too or not).

There's no AGS event that runs right before AGS closes as far as I remember. So I am not so sure on the usefulness of this particular warning..

I also think they exist since a long time ago - I remember them when I used AGS for the first time in 2017 - and I think they are just maintained until someone decides to re-evaluate and change them.

[Crimson Wizard]

This message is mostly useless even for its purpose, because user cannot tell what the sprite exactly is. The engine reports a internal number, which is assigned automatically, and depends on the order in which the sprite was created.

If there are many of dynamic sprite in the game, they would have to experiment step by step in order to find out whether this is an actual problem, and where.

This must be replaced with something more meaningful.

[Snarky]

The warning is not entirely useless. Of course, it's not really about ensuring you delete DynamicSprites that are meant to persist for as long as the game runs, but ones that are used once but which the user has forgotten to dispose. So if you suddenly start getting this warning unexpectedly, it may point to a bug in recently-added/modified DynamicSprite code. There have been a few times it has helped me spot bugs and failures to dispose sprites after use (e.g. in the SpeechBubble module).

And in practice I find that it's often not too difficult to figure out which sprites aren't being deleted, especially if you otherwise make an effort to clean up things whenever you can (for things that need to persist throughout you can do it when the player uses the in-game quit function, before you call QuitGame—though of course that doesn't apply if they close the game through the OS), so that the warning only appears when something has gone wrong. But if the warning could pinpoint it more precisely (e.g. refer to the line in script that created the Dynamic Sprite), that would certainly make things a bit easier.

[ThreeOhFour]

Thanks for the input, all!

No, it's not really necessary: when AGS closes it frees up all the memory anyway.

Yes, I read in the manual that the sprite cache loads and deletes sprites automatically, which is why I was confused about this warning.

If I remember correctly this warning is only emitted when running in debug mode (I don't remember if only when run from editor too or not).

I asked some testers to give me the details of their warnings.log file and it was present there, so it seems to be generated from compiled versions as well as when run from the editor.

There's no AGS event that runs right before AGS closes as far as I remember.

I did search in the manual for something like "eEventQuitGame" but it seems that such a thing doesn't exist.

The engine reports a internal number, which is assigned automatically,

Interesting to know! I noticed my warning referenced a number greater than my sprite count by one, so I assume that I can find which number a sprite has been assigned by assigning the sprite to something and then calling something like String.Format("%d", thing.Graphic); should I ever want to know this value myself.

At the moment I've just inserted a line to delete this sprite right before I call QuitGame, just to clear up the warning. But I also notice that the warnings.log file is warning about things like a Wait(1); call in a room_Load() function and that it closed a dialog when all options had been turned off, so I'm probably going to end up with some warnings in there, even if I try to clean up.

Thanks for the information, all!

[Crimson Wizard]

But I also notice that the warnings.log file is warning about things like a Wait(1); call in a room_Load() function

Well, you should not have any waits or blocking actions in room load, such things should go into "room after fade-in".

[ThreeOhFour]

Yes, this was a quick workaround in a room where object positions are calculated according to some variables, I'm going to replace the Wait() with a call to that function now. I just wanted to stop the strange jump to new positions after the fade in quickly while I was having people test it. 

[Crimson Wizard]

Yes, this was a quick workaround in a room where object positions are calculated according to some variables, I'm going to replace the Wait() with a call to that function now. I just wanted to stop the strange jump to new positions after the fade in quickly while I was having people test it. 

Normally anything you do in "room load" is happening prior to the first room's draw. There should not be any visible "jumps".

[eri0o]

If I remember correctly this warning is only emitted when running in debug mode (I don't remember if only when run from editor too or not).

I asked some testers to give me the details of their warnings.log file and it was present there, so it seems to be generated from compiled versions as well as when run from the editor.

What I meant as debug was actually the setting in general settings.

Spoiler

[close]

[ThreeOhFour]

Normally anything you do in "room load" is happening prior to the first room's draw. There should not be any visible "jumps".

I probably need to re-check whether I have the calculation in repeatedly_execute_always or late_repeatedly_execute_always (although I think I tried this!). The Wait(1); in room load did hide the problem, but was definitely intended as a quick hide until I fixed it properly.

What I meant as debug was actually the setting in general settings

Yep! I was replying to the bit about only when running from the editor! Or maybe I misunderstood what you meant by that, it's quite possible!