write through graphics lines on Mac fade to "darker than background" and those pixels stay stuck off

[scratchdiver]

Using tek40xx to connect to some emulated php-11 system and I have written code that uses "write through graphics" mode to draw animations. The first lines drawn look fine, but they fade to darker than the greenish BACKGROUND value; then when another write through graphics line is drawn, it will not light up pixels that were previously faded to "darker than background". This causes repeating animation drawings to basically be mostly black and not drawing.

I have found that I can make the problem go away if I change the alphablend function in tel_drawline.c from this:

if (!wrthru || p[1] == BACKGROUND) {

to this:

if (!wrthru || p[1] <= BACKGROUND) {

the repeat animations now work fine. The write through lines still fade to darker-than-background which seems like a separate issue. I have tried changing the value of BACKGROUND lower but anything below about 20 seems to hang the program.

[Isysxp]

Thanks for finding this, I had completely forgotten to sort this out. I have patched 1 line in tek_main.c which has the same effect as your code. Specifically:
line 512: unsigned char lon[]= {2,BACKGROUND+4,0}; // Setting for writethrough
NB: I haven't tried this under OSX so if it is still a problem, do let me know.

Regards, Ian.

[scratchdiver]

Thanks for responding. I made your change (while reverting mine) and I still see a sort of inability to draw on previously drawn and faded pixels. I think there is an implicit expectation that fading pixels reach the BACKGROUND value exactly in order to be re-written by a later draw. But I think fading pixels do not necessarily land at the exact value of background because the render code uses the multipliers in the p6 phosphor vector, and the fading pixel can essentially step over the precise value of background.

so the line in tek_drawline.c
if (!wrthru || p[1] == BACKGROUND) {
might never become true again if p[1] winds up at like background - 1 etc. (I have a suspicion that there was an original version of the code that essentially had a static sequence of fade values from the original vid_setpixel() in tel_main.c, but then later this alpha blend line draw code was used and the behavior of alpha blending with in-progress fades probably changes the exact sequence of fade channel values, so the progressive multiplication ends at a different non-background value sometimes.)
I am actually a bit perplexed by this if expression, it seems to exist to essentially skip over drawing a pixel if the pixel is in process of fading. It seems to me that a pixel in the process of fading actually should be drawn on a new request, this should "reset" the fade from peak brightness again.
If fact if I just make the whole if condition always true, essentially always run the conditional code, I get the most consistent draw quality and fade quality.

Also, unrelated, but I found an issue with the cursor blink leaving dark shadows where in vid_setcursor() the blink off state is setting pixels to 0x2000 but the value of BACKGROUND is decimal 40, so the off state of the cursor leaves a little extra dark shadows after it draws. this is noticeable if a test file is printed with lots of spaces in it.
I changed that value to be 0x2800 which matches the value of BACKGROUND and I don't see anymore shadows.

[Isysxp]

Thanks again and sorry for the hassle. The problem is that the decay calculation in refresh() can result in a green pixel value which is < BACKGROUND. I have added and simple conditional here and corrected the background value back to BACKGROUND (rather than BACKGROUND+4). Could you give this a try and see what happens with your app. I hope this might fix the cursor problem as well.