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) <[email protected]>

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