keep color from [highcontrast] in [dragon]

[dankamongmen]

ncchannels_reverse() claims to invert the colors, but not touch anything else (including alpha). But it is illegal to have anything other than NCALPHA_OPAQUE with default colors (which is weird -- why can't you have NCALPHA_TRANSPARENT?).

[dankamongmen]

I've changed up ncchannel_set_default() and ncchannel_set_palindex() so that they can both stay in NCALPHA_TRANSPARENT.

[dankamongmen]

I've changed up ncchannel_set_default() and ncchannel_set_palindex() so that they can both stay in NCALPHA_TRANSPARENT.

so the problem there is that in postpaint_cell() we change anything that is NCALPHA_TRANSPARENT to the default color, moving it to OPAQUE along the way. this is done, so far as i can tell/remember, so that we compare equal to default cells in cellcmp_and_dup_far(). if we comment out that transmogrification, [dragon] clears its background on transition from [highcontrast], for instance. this happens because the blitter is explicitly setting cells TRANSPARENT, as it must.

but so if you get to the bottom with TRANSPARENT and don't get converted to default, how does that matter for [dragon]? either way, you're going to mismatch against the residue from [highcontrast] and force a damage, right? how is this working normally?

[dankamongmen]

so currently, the residue is left up, but it's stripped of color--it all switches to the default. so clearly the default case is having effect there. why do we hide the residue with the fg transition removed?

[dankamongmen]

yep, sure enough, there's a huge chunk of damage with these removed that isn't there normally. how?

[dankamongmen]

there seems deep evil at work here...or i'm on a goose chase

[dankamongmen]

because frankly i'd like to have [dragon] atop the colored output from [highcontrast]. it does not seem we can do that currently.

[dankamongmen]

hrmmm it seems to be damaged in both scenarios:

-CHANNELS: 0x6000000060000000 0x4000ad8040000000                                                                                    
+CHANNELS: 0x0000000000000000 0x4000ad8040000000                                                                                    
 STYLEMASK: 0x0000 0x0000                                                                                                           
 GC: 0x0000006c 0x0000006c                                                                                                          
 damaging due to cmp [l] 14 35    

but in one we rast a space:

-RAST 00000020 [ ] to 14/35 cols: 1 6000000060000000 

and in one we don't:

+RAST 0000006c [l] to 14/35 cols: 1 0000000000000000   

why?

[dankamongmen]

we show the right value (0x6c) in postpaint_cell(). how is it becoming 0x20 by raster time?

[dankamongmen]

ahh the space is coming from the rgbequal hack introduced near the end of 3.0.0!

[dankamongmen]

so is the issue just that the blitter shouldn't be marking all that stuff transparent? if it is marking it transparent, shouldn't it be clearing the glyph?

could we just blit to a different plane, rather than the standard plane?

[dankamongmen]

so yeah, i think the cell blitters ought be zorching any cell onto which they're blitting transparently. yes, that's pretty certain.

and [dragon] ought be blitting to a second plane.

[dankamongmen]

alright, clearing the cell when transparent seems both well-advised and works as expected. in the absence of other changes, it clears the background for [dragon]. now we'll throw up a second plane.

[dankamongmen]

got it, nice.

[dankamongmen]

alright, both issues are addressed. good stuff.