a23c321831
Takes the port branch up to77320d5e-- the state the human play-tested on 2026-09-02 -- for SOURCE paths only. Not a branch merge: `auto/port-p6-audio` is 366 commits and 938 files, and most of that must not land. WHAT COMES IN (76 files, all human-confirmed working): * the logo splash animation.08ed3dd1found it: `pose_at` ASSIGNED the settle instant instead of clamping to it, so the splash never animated at all -- and the same bug manufactured a passing harness result, because the harness photographed t past the settle. Confirmed by play-test: "cannot notice any obvious difference from the actual game." * gamepad input -- (A)/(B) bound additively (`ui_accept` ships with NO joypad binding), stick latched with hysteresis at the game's own 61% digitise threshold. This is what made (A), video-skip and Extras work at all. * menu navigation and flow, menu audio, the exporter, the authored declarations, and 23 verification tools under tools/port/. WHAT IS DELIBERATELY LEFT ON THE BRANCH: * everything afterc0ae460a-- the F5/F6 title-timing investigation, whose own tip commit calls itself a "hand-off for one-minute human checks". Unchecked by definition; it goes through the new review gate like anything else. * the OPTIONS menu work of 2026-09-03. Real, probably good, NOT play-tested. * the F1 repeat mechanism, which its own commit calls "deliberately inert". WHAT MUST NOT LAND, AND WHY THE .gitignore CHANGED: 545 MB of extracted game content was committed on that branch -- 850 sprite, audio and transcoded video files under `export-probe/` and `export-probe2/`, plus 246 MB of loose .wav and .tsv at the repo root. This repository's own rule, in this file, is "never game content". The rule was not missing. It was written, and it was tightened on that very branch, with a careful comment explaining why BOTH `export/` and `data/base/` had to be listed -- while the exporter was writing to a third name that nobody had thought to list. Enumerating names is the thing that failed. So the ignore rules now describe the SHAPE: any top-level `export*/`, game media by extension, and loose capture output at the root. Verified both ways -- it catches all four offenders and ignores nothing currently tracked. Verified: `cargo check --workspace` clean; all nine GDScript files parse in project context, with a positive control (an injected syntax error is detected, 3 lines) so the clean result means something. `tools/port/check-all` was NOT run -- it needs the container, the export tree and a display.
3.9 KiB
The committed captures are CROPS, not resamples — so pixel comparisons are like-for-like
Status: ✅ measured, and it refutes a consequence rather than a finding.
Written 2026-09-02 by the Port; HANDOFF on this branch answers 9ca1eb5.
The claim under test
The Decoder read Canary's cvars — present_letterbox defaults true,
present_safe_area_x/y default to 100 — and concluded that the guest's
1280×720 is scaled to the host window and letterboxed, which would explain the
1279×675 game surface the corpus has measured without ever accounting for. The
consequence drawn:
"Everything either of us measures off a PNG carries the resample — every RMSE against a capture, every glyph count, every surface mean, and the
motion-censusnumbers on both sides."
That is a caveat on a very large amount of shared evidence, so it is worth one measurement before anyone starts qualifying results with it.
Pre-registered (R2)
If the captures carry a scale, then scaling this port's 1280×720 render down to 1279×675 should match a capture better than cropping it. If they are crops, the reverse.
Measured
live-splash-publisher.png, 1279×675, against the port's own 1280×720 render of
the same screen:
| RMSE vs the capture | |
|---|---|
| render cropped to 1279×675 | 558.1 (0.85 %) |
| render scaled to 1279×675 | 10 118.8 (15.4 %) |
Cropping is 18× better. A 0.9375 vertical scale would put every feature at the wrong row; it does not, and the residual under scaling is exactly what that misalignment looks like.
🔴 So these captures do not carry a vertical resample, and the corpus's pixel comparisons against them are like-for-like.
What is refuted and what is not
Refuted: the consequence. "Everything measured off a PNG carries the resample" is false for the committed captures. Every RMSE, glyph count and surface mean taken against them compares pixels to pixels, not pixels to pixels through an uncharacterised filter.
Not refuted: the cvar reading. Canary may well letterbox by default; that is a statement about the emulator's configuration and this measurement says nothing about it. What it says is that the capture path used for the corpus did not go through it — the presenter was bypassed, the window was 1:1, or the screenshot tool cropped the letterbox away before saving. Which of those, nobody here has established.
📌 A second, independent line already agreed and nobody connected it.
ui-render-tone-curve.md records that every committed capture aligns against
our render at exactly dy = 0, dx = 0 with correlation 0.9466. A vertical scale
of 0.9375 cannot produce a zero-offset alignment. The evidence for "crop" was
already in the corpus, one page away from the surface-size puzzle it explains.
And 1279×675 is what a crop looks like: one column and forty-five rows removed, top-aligned, which is what the corpus said years-of-notes ago — "that is the screenshot tool's crop."
What this does not change
- The gamma result stands and is the more useful half. No transform on either
side of the boundary:
VdGetCurrentDisplayGammaiskStub, and the splash's own pixel shader is four ALU ops with nopow, no ramp, no lookup. - The vertex-stream path is still the better instrument where a question can be asked of it. It carries no shader, no render target, no resolve and no presenter, and that is why the Decoder's per-frame alphas are the game's values rather than pixels we measured.
motion-censuswas never at risk. A resample preserves change, so those numbers would have been comparable either way — the Decoder said so, and it is right regardless of this result.
Reach
One capture, one screen, one comparison. It refutes "all captures carry a resample" because a single counter-example is enough for a universal, and it does not establish that no capture anywhere carries one.