Thanks for the replys. Overlapping by 1 pixel is the method we are
considering, but it'd be nice to know exactly how the hardware
decides where to put each pixel of a rotated/scaled sprite. Our
tests show that it doesn't exactly follow the standard rotate/scale
fixed point transformations as we'd expected. We've tried both
trancated fixed and rounded (+0.5) fixed an neither exactly match
what the hardware is doing. Overlapping 1 pixel will fix the gaps
but will make the sprite texture shift a bit which is not optimal.

Bah, it's not a big deal, just looking for an exact algorithm. The
truth is right now for scaled/rotated sprites, we just make them
small enough to fit into a 64x64 and deal with the VRAM hit.

Fun question: Anyone try switching the GBA over to fast interrupts
such that you don't have to manually save all your registers upon
interrupt? It'd be fun to write a handler to do that instead of the
standard one that works off of normal interrupts. Getting to
interrupts wouldn't carry near the overhead they currently do (I'm
spoiled as I'm used to the GBC where it only took a couple cycles to
get into the interrupts.)

Mike