SpritesMind.Net

I'm playing with the sprite engine, but I think that the cache system must be reviewed. I've made a video showing the problem.
There are 4 sprites, 3 of them doing the same looped animation, and another (player controlled) that changes the animation, to look up or down.
Making those 1 frame animations, makes the whole sprite cache, to refresh.. so all VDP space is rewritten, you can se a fps drop also.
I think that the sprite engine, must be some more flexible about this. Maybe defining a cache space for each sprite. In my example, I don't need tiles of 3 sprites to be reloaded, and its tiles should not be overwritten by another sprite.

Check out the video, it's sloppy but I hope it can help to show what I mean.
http://youtu.be/2SQHB0IiIJI

it seems near the problem i met last week:
viewtopic.php?t=1968

A way to handle this is to use frameRate (change frame every n frame)
this way, you define the max value for 1 frame only animation
Don't know if sgdk sprite engine use it but it's how mine (based on SGDK's raw sprites ) is working, for flexibility (like frame rate linked to the current animation not to the sprite itself)

You could argue defining a no-frame-change for 1 frame animation would be easier but, in fact, it will add a test and, trust me, this test eats some cycles you'd like to keep for something else !!!!

I've debugged a little, and I see that unpacking compressed tilesets takes most of the time. Using compressed sprites I get down to 35fps on worst case. And using uncompressed sprites the lowest is 49-50.
Could be the uncompressed tilesets could be cached somehow?
Anyway, I think that it could be very useful to define how much VRAM space will be used on wich sprite, and use that space to update its own tiles. I think it makes sense for a player character while other sprites can be uploaded as it's working right now.

EDIT:
SPR_setVRAMTileIndex It's exactly what I was asking for. XD

Yeah the sprite cache stuff definitely can be improved a bit but it's really complex and when you improve on some sides then you can get nasty effects in others situations so it is definitely complicated to get something good for all situations. It's also why i am allowing a fixed tile VRAM index =)
And yeah, the decompression takes a big amount of time ! I really need to implement a fast and good unpacking method.