Problems in inverse
Posted: Tue Mar 15, 2011 10:46 am
Take the example that a screen byte is 110110 and the required mask is 110011
For normal video (not inversed) the result is simple.
we AND the mask against the screen resulting in 110010
in code this would be
However if the screen byte is inversed then all bits we take as 1 will appear as 0.
So whilst 110110 AND 110011 will be 110010 it will appear as 001101 which is clearly wrong.
So we deal with inversed screen separately to invert the bits before masking.
So we invert 110110 to get 001001 then mask with 110011 to get 000001 then invert again
to get 111110 which appears on the screen as 000001 which is correct.
In code this is
Furthermore (oh yes) we then need to ORA with the bitmap graphic.
Trawling back through the above for normal video graphics we take the screen byte 110110
and AND with 110011 to get 110010 then OR with the sprite byte of 001100 to get 111110
And this is where things get tricky. Once we start dealing with inverse on inverse then
some may argue we should just replace the screen inverse byte, rather than attempt to merge
them.
If the inverse is in order to attain white on blue and the sprite byte is 000000
then the virtual black will look ok.
However (using AIC mode (split line technique)) we may be using inverse to attain white on red.
and a background of red is too bright and looks wrong.
Placing a contingency around which alternate line we are working on would then be the answer but
at what cpu cost?
Like...
For normal video (not inversed) the result is simple.
we AND the mask against the screen resulting in 110010
in code this would be
Code: Select all
LDA ScreenByte
AND Mask
So whilst 110110 AND 110011 will be 110010 it will appear as 001101 which is clearly wrong.
So we deal with inversed screen separately to invert the bits before masking.
So we invert 110110 to get 001001 then mask with 110011 to get 000001 then invert again
to get 111110 which appears on the screen as 000001 which is correct.
In code this is
Code: Select all
LDA ScreenByte
BMI ScreenIsInverse
AND Mask
...
ScreenIsInverse
EOR #63
AND Mask
...
Trawling back through the above for normal video graphics we take the screen byte 110110
and AND with 110011 to get 110010 then OR with the sprite byte of 001100 to get 111110
And this is where things get tricky. Once we start dealing with inverse on inverse then
some may argue we should just replace the screen inverse byte, rather than attempt to merge
them.
If the inverse is in order to attain white on blue and the sprite byte is 000000
then the virtual black will look ok.
However (using AIC mode (split line technique)) we may be using inverse to attain white on red.
and a background of red is too bright and looks wrong.
Placing a contingency around which alternate line we are working on would then be the answer but
at what cpu cost?
Like...
Code: Select all
LDA ScreenByte
BMI ScreenIsInverse
AND Mask
SendDirect
...
ScreenIsInverse
BIT AltLineFlag
BVS SendDirect
EOR #63
AND Mask
...