Quote:
Originally Posted by roondar
To be honest, I did not manually calculate the values generated by the code for the mask, but I'd say that just swapping the values around as you do is not enough unless the mask is set to either $ffff or $0000.
Here's my thought experiment:
Suppose that the ascending mask is set to first word %000111 and last word %100000 (pretending this mask represents all 16 bits rather than just 6). For descending mode this needs to be flipped around because the first word mask is applied to the last word of each line and vice versa.
But that would mean that the first word fetched (i.e. the last word in the blit) now has a mask of %000111, which is surely not correct as that cuts of pixels on left and leaves pixels on the right. My guess is that you'd instead need to generate a mask based on the shift value and direction.
Edit: this would be a lot easier if I actually had access to my assembler to check some stuff. Doing it all from memory is not the best way 
Edit 2: the above is not correct, I forgot that flipping the two values around does mean the last word in the blit gets the correct value.
The only thing I'm still wondering about is what the left vs right shift means for the value of the mask. I'm still thinking that a mask for a left-shift blit and a mask for a right-shift mask can't be the same.
|
I don't think the first and last word masks affect the destination...it only affects how the are retrieved from the source.
Anyway, even if I use 0xffff for both first and last world masks, nothing changes.