Quote:
Originally Posted by mc6809e
You seem really committed! Want a challenge? How about trying to make a copper-driven blitter queue that even crosses frame boundaries? In other words, it works even when VBLANK resets the copper address pointer?
|
I've been thinking about this, because at some point I'd like to be able to do much busier scenes, updated at 25Hz while scrolling the frontbuffer on alternate frames (the old Team 17 50Hz trick). My current idea is quite simple:
Code:
A1:
DC.W $0001, 0000 ;wait for blitter finish
DC.W BLTCON0, xxxx
DC.W BLTCON1, xxxx
...
DC.W BLTSIZE, blitsize
; danger zone
DC.W COP1LCL, A2
A2:
DC.W $0001, 0000 ;wait for blitter finish
DC.W BLTCON0, xxxx
DC.W BLTCON1, xxxx
...
DC.W BLTSIZE, blitsize
; danger zone
DC.W COP1LCL, A3
A3:
DC.W $0001, 0000 ;wait for blitter finish
etc. etc.
This relies on the fact that the blit operations typically used in 2d games (copy, fill, cookie cutter) are idempotent (i.e. we can repeat an operation and still get correct output). The "danger zone" is if VBLANK occurs between the write to BLTSIZE and COP1LCL; if that happens we end up repeating the blit that just started.
Is there any reason this won't work? You mention 3d: perhaps there are XOR-type operations there that aren't idempotent?
Also, I'm interested in your comment about the line on which VBLANK occurs. The manuals seem a bit vague about this: is it written down anywhere?