https://gitlab.synchro.net/main/sbbs/-/commit/a971badeea5084c7eda2b3d9
Modified Files:
src/doors/syncscumm/door/video_term.cpp
Log Message:
syncscumm: capture the frames the encoder saw, for exact replay
Comparing two builds of the encode path on GAMEPLAY has no good answer otherwise. A cutscene is deterministic and can just be replayed by both,
but it is full-motion video: most of its frames legitimately exceed the
patch budget, so it measures the one case none of this work can improve.
Actual play is where the patch path earns its keep -- and a point-and-click game does nothing without a human in it, while no human walks the same
route twice closely enough to see a ten-percent difference.
So capture what the encoder was handed. A touch-file writes every
(indices, palette) pair passed to termgfx_termio_present() to /tmp/<door>.<pid>.frames; replaying that file through two builds gives byte-identical input where the only variable left is the code. One session played once, and the corpus stays valid for the next change too.
Deliberately the pair passed to present() rather than the game surface:
the quantized overlay path substitutes its own indices and palette, and a measurement of the encoder wants exactly what the encoder got.
Gated by a touch-file, not an env var, like the trace and wirecap gates
next to it -- the BBS execvp()s the door with no shell, so a variable set before launch never arrives. Absent, nothing is opened and nothing is
written. Buffered, so a capture cannot turn present() into a synchronous
write on the frame path.
Co-Authored-By: Claude Opus 5 (1M context) <
noreply@anthropic.com>
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)