https://gitlab.synchro.net/main/sbbs/-/commit/f72a5729d772dc5db32a1c2d
Added Files:
src/doors/syncretro/probe_core.c
Modified Files:
src/doors/syncretro/CMakeLists.txt
Log Message:
syncretro: add probe_core, a libretro core diagnostic

Every SyncRetro console so far was scoped from measurement rather than from
a core's documentation -- M3_MULTICORE.md sec 2 is a table of what fceumm
was observed to do -- but the harness that produced it was thrown away. This
is that harness, kept, because the questions that decide a console's cost
are all empirical and all cheap to get wrong from a distance:

- does the core ask the FRONTEND to rotate (env 1), or hand us an
already-rotated buffer? Decides whether a portrait arcade game needs a
rotate path in retro_bridge.c or nothing at all;
- what geometry/fps/sample_rate does it report, and does it CHANGE them
after load (env 32/37), which the door reads only once;
- which core options does it actually read, and is it playable on their
defaults;
- how many distinct colours does a frame really have, i.e. is the sixel
quantization exact.

It links the door's real retro_core.c and retro_options.c and answers env exactly as retro_env.c does, so the report is the door's own view of the
core and a probe run is a live test of the shipped option store. Each policy the door does not implement can be flipped on (-accept-rotation, -optver)
and each one it does can be flipped off (-no-options); that difference is
the work estimate. It links no termgfx, no xpdev and no libjxl, opens no terminal and needs no BBS.

Opt-in: cmake -DSYNCRETRO_PROBE=ON. Not built by default and not part of
the door.

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