> 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.

Yeah, we gave a thought about double buffering as a way to avoid the
constraint of updating VRAM during vblank only, but (having read Mr.
Yerrick's paper) we found out that there is generally plenty of time
to complete all the transfers before a new frame is drawn, provided
you separate the actual transfers from game logic (this game logic
runing out of vblank, requests transfers which are processed all
together during vblank).

Of course there is the issue of compression. We were hoping that by
using a light compression algorithm (like RLE, or even BIOS
compression) we would still have enough time to complete all the
transfers during vblank, since in our engine no other operations are
required to run during this period.

> 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?

We 'solved' this just as Mr. Yerrick suggested, but you will still
notice some 'delay' between parts that are supposed to go 'together'.

Speaking of composite rotating sprites, we found out that using 2 or 3
big rotating parts in the same scanline would quickly waste all the
available rendering cycles (causing parts of our composite sprite to
disappear).

We noticed this only when testing it on real HW (all seems to be
perfectly fine in the emulator (VBA)).
This is the reason that made us to consider avoiding HW rotation and
faking it by animating with lots of pre-rendered frames directly
copying them from ROM to VRAM as needed.
Haven't you stumbled into the same problems?

Thanks to everybody who bothered to answer and good luck,

Ronald