https://gitlab.synchro.net/main/sbbs/-/commit/372fa69084a25dc894f391f9
Added Files:
src/doors/syncretro/COMPILING.md
Modified Files:
src/doors/syncretro/README.md xtrn/syncarcade/README.md
Log Message:
syncretro: document the build, per-platform, in COMPILING.md

SyncRetro was the only one of the five termgfx doors without a COMPILING.md. The README's Building section is three code blocks, which is enough to repeat
a build you have already done once and not enough to do the first one: it
names no prerequisites, no configure options, and does not say what the configure output is telling you.

The gap that prompted this is the *nix path specifically. Two of this door's artifacts are per-platform -- the binary and the libretro core -- and both are installed by scripts (deploy.js, getcore.js) that put them in an <os>-<arch> sub-directory rather than at the door root. A console first installed from a Windows host therefore looks complete while having nothing a *nix host can
run, and nothing said so. SyncArcade was in exactly that state.

So COMPILING.md leads with Linux/Unix: the prerequisites (including that termgfx needs a C++ compiler, and what libjxl and libsndfile each buy), the build, the two configure lines that report which tiers were found, the configure options, deploy.js and why the sub-directory exists, that the core
is downloaded rather than built and must be fetched once per platform, probe_core as the smoke test for a freshly installed core, and the tests. Windows keeps a short section pointing at build.bat and the README.

Also corrects xtrn/syncarcade/README.md, which told a sysop who had already installed a sibling console that they had the binary already. True only on
the platform they installed it from.

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

https://gitlab.synchro.net/main/sbbs/-/commit/64d990434fbc087594847d4f
Modified Files:
src/doors/syncretro/COMPILING.md DESIGN.md M2_INPUT.md M4_AUDIO.md README.md SYNCDOS.md syncretro_input.c syncretro_io.c
Log Message:
syncretro: stop probing for a JXL tier this door never rendered

The docs claimed a JXL graphics tier and the door probed the terminal for
it, but syncretro_io.c's tier list has only ever held sixel and the block-character text modes: termgfx_jxl_encode is not called from anywhere
in this door, and the built binary contains no such symbol. The reply to
the Q;JXL cap-probe was parsed into g_jxl_supported, which nothing read.

So the probe and the dead flag go. The termgfx side stays untouched -- termgfx_query_jxl and termgfx_caps_parse_jxl serve syncdoom, syncduke, syncmoo1, syncconquer and termgfx_termio, where the tier is real and live. SyncTERM is still detected here by the two remaining paths, the CTDA
`<`/`=` marker and the audio-caps reply; the door already depends on CTDA
for physical-key reports and the CTerm version, so a client that fails to answer it is degraded well before this mattered.

DESIGN.md gains a section recording WHY, which was written down nowhere:
these cores -- FreeIntv, FCEUmm, MAME 2003-Plus -- emit small
palette-limited framebuffers that sixel renders well and cheaply, and JXL's advantage is photographic detail they do not have. The encoder, its build detection and the cap-probe all remain in termgfx, so a future core with a larger or more detailed framebuffer can be given the tier on SyncTERM; the section says what wiring it up would take.

COMPILING.md no longer tells a sysop to install libjxl-dev to build this
door, because it buys them nothing.

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

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