https://gitlab.synchro.net/main/sbbs/-/commit/11ca7941b118609f3b957220
Modified Files:
src/doors/syncmoo1/syncmoo1_geom.c syncmoo1_geom.h syncmoo1_io.c src/doors/syncmoo1/tests/test_geom.c
Log Message:
syncmoo1: render full-size on strict-DEC sixel terminals (Windows Terminal)

The sixel encode leaned on SyncTERM's integer pixel scaling unconditionally:
it encoded the frame at half size and set the pan;pad raster attribute to 2, trusting the terminal to draw each sixel pixel as a 2x block. SyncTERM/cterm does. A strict-DEC sixel terminal -- Windows Terminal, xterm -- reads pan;pad as a 1:1 pixel aspect and draws the sixel at its ENCODED size, so the picture came out at half the intended dimensions ("really small"), and the in-game
hand cursor drifted from the hardware cursor by the same 2x, because the mouse mapping assumes the image fills the whole ew x eh rect.

The sibling doors already guard this (SyncDOOM: hsc = !is_syncterm ? 1 : SIXEL_SCALE); syncmoo1's encode was terminal-agnostic. Thread is_syncterm into sm_geom_encode_dims: SyncTERM keeps the cheap pad/pan=2 encode, every other sixel terminal gets a 1:1 encode at the full displayed size (pad=pan=1). The displayed size is ew x eh in both branches -- sxw*pad == ew -- so the image fills the fitted rect and the cursor lines up on every terminal.

The 1:1 encode costs ~4x the raster bytes, but MoO1 is turn-based and mostly static, so frame de-dup absorbs it, and there is no correct alternative on a terminal that won't upscale. Unknown-yet reads as not-SyncTERM (the safe full encode) until a CTDA reply proves otherwise, matching the palette-persistence guard; on real SyncTERM the optimized path resumes once detection completes, seamlessly (both branches display the same ew x eh).

Verified: to a simulated non-SyncTERM terminal the door now emits
"1;1;640;384 (full 1:1) instead of "2;2;320; the geom unit test covers both branches; ctest 4/4.

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