Hi GBAList!

Experimenting with big composite sprite-based
characters, we realized that it was very heavy to
render them on the GBA using many rotating parts (it
would quickly waste the available rendering cycles per
scanline).

This brought many questions about the way the GBA
renders the screen each frame. As we all know there
are 228 scanlines per frame, but only 160 of them are
actually used to render sprites and BGs.
Is the CPU totally 'free' for other tasks during these
'hot' 160 scanlines?
Are there issues with accessing different parts of the
memory map because, say, the CPU tries to update some
unused memory of the OBJ VRAM while the LCD hardware
is rendering sprites?
Would there be a possibility of contention on the
memory bus in a situation like this which would slow
things down? If so, by how much?

That's why we've been thinking of using fast memory
transfers (via DMA or CPU copies), during vblank of
course, of each frame of a sprite from ROM to OJBVRAM
(achieving animation of all sprites by streamlining
frames directly). We know this has already been
implemented in many games in a limited fashion, and
where wondering about the reasons for doing it just to
such extent (since this seems to leave plenty of cpu
cycles unused).

Maybe we are wrong, so please enlighten us.

Bye,

Ronald


_________________________________________________________
Do You Yahoo!?
Información de Estados Unidos y América Latina, en Yahoo! Noticias.
Visítanos en http://noticias.espanol.yahoo.com