https://gitlab.synchro.net/main/sbbs/-/commit/8fd7b6f2ca768062cab36f9e
Modified Files:
src/doors/syncconquer/door/door_io.c
Log Message:
syncconquer: subset the sixel palette on register-resetting terminals

Select SIXEL_PAL_USED for the full-frame and dirty-box sixel paths on non-SyncTERM clients; SyncTERM keeps FULL-on-change / NONE-reuse
unchanged. Matches the termgfx present path.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/380a07db7630ebed03b09572
Modified Files:
src/doors/syncconquer/door/door_io.c
Log Message:
syncconquer: use the shared dirty-rect diff

The third and last copy of it. This door marked a 16px tile grid from two
index planes, labelled 4-connected components, merged boxes within a gap
and gave up past a coverage or fragmentation budget -- the same code as syncretro and termgfx_termio, agreeing with the latter on every constant
that mattered (128 components, gap 2, 45%) and differing only in what a
tile spans.

That is what ../../termgfx/dirty.h parameterises, so the diff half goes
and dr_diff_coalesce becomes a call. Its own post-merge cap of 16 boxes survives as cfg.max_boxes; nothing else about the behaviour changes,
including which frames fall back to a full one.

What stays here is what the shared module deliberately does not take: the mapping from tile boxes to something drawable, which in this door means
two backends -- JXL blobs placed pixel-exact, sixel snapped to character
cells.

Both binaries build; neither has been run. This door needs game data and a terminal to exercise, so syncalert and syncdawn want a play-test before
this is trusted.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/f8589e01f493bd50dec0ce90
Modified Files:
src/doors/syncconquer/door/door_io.c
Log Message:
syncconquer: patch a palette change instead of repainting the frame

The same gate the sibling doors carried: any change to the palette forced
a whole frame, on both backends. The reasons were real -- the JXL backend
bakes the palette into each frame's RGB pixels, so a fade moves every
affected pixel's colour while leaving the index buffer the diff looks at untouched; and sixel colour registers are shared with what is already
drawn, so redefining one recolours the screen under the parts a patch
would not repaint.

Both are about which pixels a moved entry actually affects, and that is computable. Record WHICH entries moved and let the shared diff treat a
tile drawn with one of them as dirty even when its indices are identical (dirty.h's `stale`); the gate then has nothing left to protect. A change
that reaches no displayed pixel at all -- an engine rewrites its palette
freely and a scene draws with a fraction of it -- now de-dupes instead,
and is deferred rather than dropped: that path updates no state, so the
entries stay pending for the first frame that draws with them.

A SyncTERM box carries no palette by design, so the first box of such a
frame carries exactly the entries that moved. Every other terminal resets registers per image and its used-colour subset already covers it; the JXL backend carries pixels and needs nothing.

Measured on the sibling that could be measured -- Flight of the Amazon
Queen over Windows Terminal -- this gate was 267 frames carrying 77% of everything the door sent, after an earlier fix had already halved the
total. This door's content is different (a strategy map with a static
sidebar, not an adventure scene) so the share will differ, but the gate
is the same and so is the reasoning.

UNVERIFIED beyond compiling: syncalert and syncdawn need game data and a terminal, and neither was run. Worth a play-test on both, watching for a
region that keeps a stale colour -- that is what this class of change
breaks when it is wrong.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/7ee248d3313b59a9f9970a60
Modified Files:
src/doors/syncconquer/door/door_io.c
Log Message:
syncconquer: map the mouse against where the sixel actually lands

Clicking the top of a sidebar button did nothing on a sixel terminal;
the click had to land noticeably lower to register. SyncTERM looked fine,
which pointed suspicion at mouse granularity -- pixel reports there, cell reports elsewhere -- and that was the wrong trail.

A sixel is placed by CURSOR ADDRESS, so its true top-left is the addressed cell's pixel: the centering offset rounded DOWN to the cell grid. The mouse mapper inverted the offset the centering math ASKED for instead, so every
click was biased by the remainder. On a 1330x1480 canvas with 20px cells a 1330x831 image is centred at y=314 but drawn at y=300, and those 14 pixels
are about 7 game pixels of upward bias -- comfortably the top of a button.
JXL is placed by pixel offset and needs no correction, which is the real
reason SyncTERM escaped: it draws on the JXL tier, and at 640x400 its sixel tier happens to round to zero anyway.

The mapper now derives its origin from the addressed cell on the sixel
tier, and keeps the pixel offset on JXL. Measured against the door's own geometry across three cell sizes -- SyncTERM 8x16, Windows Terminal 20x20
and foot's 13px cell -- the error is now zero on both axes in each.

The geometry line also reports where the mapper believes the image starts.
It already reported where the image was PUT; the two being different was
the entire bug, and nothing on that line could have shown it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net