If you come up with this limit when using short-lived sprites, the best is just clear them out when they become "useless" (I normally do this by using SPANIM and SPFUNC). I learned this browsing through NRouge's code xD.
If using long-lived (and probably stateful) sprites, my approach is when a sprite is candidate for clearing (off-screen, etc), I just dump all it's attributes in an array and clear it, and when it's needed, I make a new one and load it's attributes from the array.
Dealing With Sprite Limits
randoCreated:
There are a few ways to do this. For instance, you can make the sprites data based, and when they are on screen, you display them with SPSET. Or you could just have all the sprites set with SPSET and try to minimize your sprite usage. I personally like to hold all the sprite data in an array and print them on the graphic screen, by using GCOPY and/or drawing them with graphic commands. I was wondering what other people like to do, so that I could try different things; maybe come up with some really efficient way to deal with the limit of 512.
Early on Virtual Buffalo ran the risk of hitting the sprite limit, especially since the bottom screen needed a chunk of those sprites for menus and buttons. But it wasn't enough to just clear out the sprites that weren't being displayed, because the gameplay needed to be synchronized with the music. Loading all the sprites for a minigame simultaneously added an unacceptable flicker and delay.
The solution was to designate 3 collections of sprites. One for Minigame A, one for Minigame B, and a shared one for particle effects. While you play Minigame A, the sprites for Minigame B are secretly prepared in the background - one every 60th of a second. The moment you finish Minigame A, you immediately switch to Minigame B because the sprites are ready to go, and the sprites from Minigame A prepare for the next game. It continues back and forth like that forever.
With that system in place it only ever needed 25% of the maximum sprites at a time.