Quote:
Originally Posted by Thomas Richter
The common denomiator of blitter and sprite engine is called a vsprite within a Bob. The simple sprite is a sprite exclusively allocated, whereas a VSprite is a virtual object that uses one of the hardware sprites as underlying resource. Thus, in that sense, the thing exists.
|
It exists but is too heavy to be useful. Just allocating a SpritePort doesn't use the blitter at all. Only the control words are written and the uninitialized chip RAM's width and depth are returned in an interleaved Bitmap structure from the sprite DMA buffer. If the application programmer wants a static image, they can blit it as a JAM2 image, fill it with a solid color or draw it as a vector image. Bobs can even be blitted to sprite buffers!
If you want to preserve backward compatibility, the SpritePort would fit between the VSprite structure and the raw sprite hardware buffer. SimpleSprites don't allow multiple SpritePorts to be allocated from the same channel making them just as inflexible as the VSprites are heavy. Both SimpleSprites and VSprites would be rendered obsolete.
Quote:
Originally Posted by Thomas Richter
Not clear what you mean. MrgCop() exists to merge already existing copper lists into one hardware list, in particular the lists from the viewports, the vsprites and the user copper list. They are already sorted by nature, but the tricky part is that the blitter can only do a limited number of operations per position.
|
MrgCop() requires the copper instructions to be already written in the order that they are used. This is seldom the case when dual-playfield mode is used with sprites. If you need to sort the order of the positions of the copper node structures proposed, merging after sorting becomes an utter waste of time. Just use a natural merge-sort to do both!
The header of the copper node structure contains the approximate raster position for the CWAIT to be generated from. It is followed by 1 or more CMOVEs computed at compile time using preprocessor macro functions.
A typical use case for sorted copper nodes are palette changes that scroll at different speeds from each other vertically along with other changes that need to interleave with each other at various different intervals. The positions in the headers for the CWAITs to be generated from are almost always quazi-random ordered relative to one another prior to being sorted.