So, after some profiling I've realized that a lot of my precious CPU time is being spent on calculating sprites. Not just the reads and writes, but also all the meta stuff, picking the right palette, doing offsets to read out animation data, flipping the sprite if it's turned around, etc. I got a neat animation system that I'm very happy with, but it's a little costy.
I've been optimizing all of this to be as fast and clever as possible, but the one thing that really irks me is that most object's sprites end up being exactly the same each frame, so I'm constantly recalculating the same results over and over.
So I've been trying to implement some sort of caching mechanism, so that I don't have to recalculate everything if nothing has changed. I usually know when things have changed (changed object state, scrolled the background, etc) so I know exactly when to reuse the cache and when to refresh it.
But building an efficient and lightweight cache has proved difficult.
The simplest and fastest way would be to simply reuse my DMA's Sprite RAM, and not clear it every frame. Maybe adjusting some x and y positions if the game has scrolled. But, all the sprite flickering techniques I know involves scrambling the order of the sprites every frame, which means no object ever gets the same Sprite RAM position twice in a row. This ruins everything.
Next up I tried allocating some more RAM as a temporary buffer, so that objects could put their sprite data there, and then it could be copy-scrambled over to the real Sprite RAM right before the DMA. But, to allow for all 64 sprites that's 256 bytes of RAM down the drain. Ouch. Not sure I want to spend that much memory.
According to the wiki, a "simple OAM cycling technique" can be implemented by using a write to OAMADDR before the DMA transfer. However, due to OAMADDR writes also having a "corruption" effect this technique is not recommended. Also, if the technique works like how I think it does, the OAM cycling would be very crude and might leave objects invisible for several frames.
So, is my quest impossible, or are there some other ideas or techniques?
I've been optimizing all of this to be as fast and clever as possible, but the one thing that really irks me is that most object's sprites end up being exactly the same each frame, so I'm constantly recalculating the same results over and over.
So I've been trying to implement some sort of caching mechanism, so that I don't have to recalculate everything if nothing has changed. I usually know when things have changed (changed object state, scrolled the background, etc) so I know exactly when to reuse the cache and when to refresh it.
But building an efficient and lightweight cache has proved difficult.
The simplest and fastest way would be to simply reuse my DMA's Sprite RAM, and not clear it every frame. Maybe adjusting some x and y positions if the game has scrolled. But, all the sprite flickering techniques I know involves scrambling the order of the sprites every frame, which means no object ever gets the same Sprite RAM position twice in a row. This ruins everything.
Next up I tried allocating some more RAM as a temporary buffer, so that objects could put their sprite data there, and then it could be copy-scrambled over to the real Sprite RAM right before the DMA. But, to allow for all 64 sprites that's 256 bytes of RAM down the drain. Ouch. Not sure I want to spend that much memory.
According to the wiki, a "simple OAM cycling technique" can be implemented by using a write to OAMADDR before the DMA transfer. However, due to OAMADDR writes also having a "corruption" effect this technique is not recommended. Also, if the technique works like how I think it does, the OAM cycling would be very crude and might leave objects invisible for several frames.
So, is my quest impossible, or are there some other ideas or techniques?