Reply 80 of 80, by Zorko
So, this algorithm is a good starting point. Although it can be slightly improved, since we have one free register.
But it has some drawback. It outputs a sprite that is a multiple of a byte, not a pixel. I don't think we should convert bytes representation to pixels, but we should add another parameter to the sprite property. It may be a mask, or number of "nulled" extra bits of sprite. We need an accurate pixel-by-pixel output. If the "extra" bits on the right are insignificant for the OR/XOR operations, they are still important for AND/PUT.
So we need to improve this subroutine, as well as implement PUT/AND, since it can only work correctly with XOR/OR right now. Otherwise, the pixel accuracy of the sprite width suffers. You understand.