rtg: leave COMPLEMENT lines to Picasso96

[codewiz]

This fix comes straight from the ZZ9000 driver that Z3660.card forked from -- same reasoning, same code, only reindented. See BlitterStudio/zz9000-drivers PR #53 (fix/rtg-line-endpoints), where DrawLine() gained:

/* Line does not expose the RastPort's FRST_DOT state, so an accelerated
 * COMPLEMENT line cannot tell a fresh Draw from a connected Draw. Processing
 * a shared vertex twice is observable with XOR. Keep every other mode on the
 * fast path and let Picasso96 preserve exact join ownership for COMPLEMENT. */

struct Line carries no FRST_DOT flag, so an accelerated COMPLEMENT line cannot tell a fresh Draw() from one continuing at a shared vertex. Under XOR, rendering that vertex twice inverts it back, and the result depends on which of the two segments claims it. Every other draw mode is idempotent at a shared pixel and stays on the fast path.

How it shows up

p96cts DrawLine-complement draws a closed pentagram: five segments, five vertices, each shared by two Draw() calls. Four pixels came back inverted relative to the reference.

Testing

Verified under Copperline with p96cts Z3660 640x480x8 and 640x480x24: DrawLine-complement goes from FAIL (4 of 64000 pixels) to PASS at both depths, and no other scene changes.

Independent of #18 -- different function, applies cleanly in either order. With both applied, Z3660 passes 21/23 at 8 bits and 19/20 at 24 bits; what remains is BltBitMap-minterms and BltBitMap-planemask, which look like a separate issue in the planar blit path.

🤖 Generated with Claude Code