Quote:
Originally Posted by Samurai_Crow
SpritePorts that hold each sprite image would replace vsprites and simplesprites both by generating a Bitmap structure. Once there, if one wants to use the blitter on a SpritePort, it's just a matter of passing that Bitmap struct to create RastPort.
|
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.
Quote:
Originally Posted by Samurai_Crow
SortCop() would replace MrgCop() using a position header in the CopperNode structure. That structure will contain fully-encoded copper moves generated by macros. Copper skips are pretty useless and should be reserved for manual bypass mode, as should copper based blitter waiting.
|
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.
Quote:
Originally Posted by Samurai_Crow
QBlit() and the corresponding dequeue interrupt should have been rewritten in Assembly so they can stack push only the registers actually used and retrieve them at the end. C compilers just push and pop all registers to the stack indescriminately. What a waste!
|
QBlit and the corresponding dequeue interrupt *are* written in assembler, actually. While I do not know which compiler you use, SAS/C only pushes the registers its compiled code uses on the stack.