Quote:
Originally Posted by roondar
I'd say option b) is not acceptable and option a) sounds like a non-optimal approach. However, I personally feel your take on option c) is rather negative. While it is true that transfering data from fast to chip is not going to be very fast, I am also pretty certain you don't actually need to transfer all that much per frame.
|
You're talking about prefetching. It may or may not work depending on how the game assets are used. I'm aware of the parallelism possible with the chipset.
Generally though you only really get parallelism on the last bit plane of a bob. If you're doing a load of blits in sequence you have to serialise access to the blitter.
The rest of the time you're waiting on the blitter. Polling the blitter's status is a chip ram bus access btw. If you want true parallelism you either:
a) use interleaved bitplanes which limits the vertical size of your bob and costs you duplicate mask data (ouch)
b) Use an interrupt restart and suck up the cost of the interrupt handler (ouch)
c) Limit it to one VBL, use the blitter finished disable bit and do it via the copper.
Many slots usable for the blitter typically get consumed by higher priority DMA.
Bitplanes, copper, audio (!) and sprites all steal cycles usable by the Amiga blitter.
I'd rather have a true bus master blitter which can access everything. I'd prefer that even if it only uses 68k bus cycles.
That way system fonts can be blitted from ROM, workbench background pictures don't consume any precious chip memory and bitmap fonts can be rendered from fast RAM.
Swings and roundabouts....