If we assume for a moment that what you're doing is loading new images as sprites each game... then we're still only talking about 600 or so Sprites.
Now if we also assume that these are all quite "Large" Sprites... say 1024x1024 PX then we'd be looking at a grand total of 2.4GB VRAM being used.
On the surface this might sound like a big issue but actually., keep in mind that only 60 of them (240MB) is
actually in-flight., and this actually ends up being important; as it's smaller than the 256MB PCIe Block Limit; this means the Drivers (or in the case of Vulkan., the Memory Management System) can swap out said Memory Block between Active and Inactive Blocks at little to no performance penalty with the System Memory.
I mean, sure there might be a few seconds of initial lower framerates; but it essentially would end up in the Video Memory; and running like normal... and given System Memory is likely to be larger than the 2.4GB required from not releasing Images / Sprites / etc. well then there shouldn't strictly be an issue at 10 "New" Instances... possibly 16 or more.
No, the issue is less likely to be that you're not cleaning things up per se... as you're almost certainly still DRAWING all of those previous Sprites.
I mean you've said you're manually calling "DrawSprite( )"., that's not strictly necessary unless you're manually controlling the whole Draw Queue., actually it's a bad idea unless you are... because in most cases you're going to be drawing the Sprites twice.
•
Now something to note is when you load an Image., you DO NOT have to make a Sprite out of it... just as if you create a Sprite you don't HAVE to assign an Image initially; but by default it does expect it.
If (as I assume we're talking about some Tile-Based Puzzle Game)., you KNOW how many Sprites you need to manage and draw; then a simple solution is to ONLY create the number of Sprites you need...
As far as the Images used., well these can either be Pre-Loaded all at once (when you start the Game) or on a Level-by-Level Basis., where you are Loading / Deleting based on what will be used on such.
Remember my est. above (given you provide ZERO information) are based on the assumption of Large Images being used for the Sprites; chances are you're using much smaller images., and frankly none of the memory should be an issue at all... but I almost guarantee the sheer volume of sprites is.
Yes., AppGameKit can actually handle several thousand sprites just fine; but YOU can't manage that many Drawing them Manually as AppGameKit Script is SLOW, esp. when it comes to For..Next Loops.
Believe it or not but a Repeat...Until is a noticeably faster loop (~22ms difference when we're getting up to 10,000 Loops) and when you throw in a Draw Call as well; eh., well yeah you'll definitely start to see some slowdown at say 600 of them per loop.
So, go over your code and just make sure you're ONLY drawing say the Last 60 Per Frame; rather than an entire Array