Quote:
Originally Posted by Thomas Richter
Why? It also only runs the blitter, just through a different path. The only thing it does not do is interleaved. Frankly, I doubt that introducing another sprite engine after the last one was not used is not particularly helpful at all.
|
Fine. Back to hardware banging it is. Throw out Graphics.library altogether. Problem solved.
Quote:
Originally Posted by Thomas Richter
MrgCop() requires copper instructions to be already present in three intermediate copper lists, so that is not *quite* equivalent. It only takes three copper lists (bitplane, vpsrite and user copper lists) and not four (two bitplanes instead of one), so that is probably the only limitation that comes to my mind. Why would you want to create intermediate copper lists out of order?
|
It needs arbitrary numbers of copper lists to be able to implement a proper natural mergesort. Adaptive sort routines like a natural mergesort already take advantage of any ordered sections of list as it is.
One of the most common scrolling effects of the copper is a "tube" scroller where the bottom of the screen buffer has a negative modulo assigned by the copper to wrap the bitplane around to the beginning of the buffer and another copper instruction to restore the modulo to its previous value a pixel row lower. There will likely be additional copper instructions in between those 2 CWAIT CMOVE sequences for color changes (most likely NOT limited to vsprite color changes). This allows infinite vertical scrolling with little blitter involvement.