Hi Ronald

I can give you a bit of info on the sprite stuff as I know it.

Our engine builds composite sprites all over the place w/o any real
slowdown. We currently double buffer our sprite VRAM such that it
doesn't matter when we load the it. While this 1/2's available
sprite VRAM, it allows us much more freedom in our VBlank for other
things such as palette loads, OAM updates, scroll registers, or
other fancy effects. Originally, we did just as you are suggesting
(loading directly during VBlank), but found that it made it very
difficult to render all the sprite VRAM we needed in the alloted
interrupt as we have other things we wish to do in VBlank. One
other very big reason to double buffer is that it gives you time to
compress/decompress the char/oam data of your sprites. As sprite
chars can take up a good portion of your cart space (some of our
games have sprite data running 40%+ of available space compressed!)
compression is a necessity.

On other issues you touched on - as long as we operate only in the
HBlank period during sprite redraw, we have free reign to do
whatever we want with VRAM - or whatever for that matter. We don't
encounter any CPU/Bus contention that we can detect. Beware of
using DMAs though. It locks the CPU down for the entirity of the
transfer (so it's not actually a true DMA, just a real fast
transfer.) Also, if an interrupt comes along it and it also wants
to DMA, bad things occur. Stick with CpuFastCopy or ldm/stm
commands if at all possible.

BTW, do to weird round off, when we rotate/scale a multi-part sprite
around, the sprite tends to break up a little. Have you guys
figured out the trick to fixing this?

Hope this helps!

Mike