ReaperOfVeriod/Going-Commando
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0x152c70 rejected as the camera; the savestates are not consecutive frames

Browse Source 
Ran the cheapest confirmation from a991088 on the candidate:

    [247.000, 194.000,  49.890]  step   0.000
    [293.960, 411.810, 115.000]  step 232.133
    [506.306, 311.614, 116.656]  step 234.804
    [300.170, 227.480, 128.000]  step 222.933

Rejected. A camera between consecutive frames moves a little; this moves ~230 units
per step and is not monotone on any axis. It is per-frame state but not a camera
position. a991088 wrote the prediction down before the measurement, so the
candidate is out rather than reinterpreted.

The more useful consequence: these four savestates are not consecutive frames, so
smoothness cannot filter the 2,005 candidates until consecutive frames exist.

Both cheap confirmations need something the savestates do not provide -- consecutive
frames, or an actual camera perturbation. That moves the camera hunt from offline
to needing a PCSX2 PINE session, the same category as the tfrag morph.

Worth noting the shape of it: the differential produced 2,005 candidates and the
confirmation reduced them to zero in one step, because the confirmation was
written before the measurement was interpreted rather than after.

286 passing with the disc and savestate present, clippy clean.
This commit is contained in:
ReaperOfVeriod
2026-10-15 03:04:33 +02:00
parent a991088103
commit 1aa94ee288
1 changed files with 36 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/plan/level-assets.md
+36
View File
@@ -2696,3 +2696,39 @@ plausible shape.
Point 3 is the decisive one and it is cheap -- it is the same technique the
lighting verification used. Points 1 and 2 need no emulator at all and run off the
savestates already on disk.
### Confirmation step 1 rejects 0x152c70, and the savestates are not consecutive
Ran the cheapest of the three checks on the `a991088` candidate:
S 0x152c70 across 4 frames:
[247.000, 194.000, 49.890] step 0.000
[293.960, 411.810, 115.000] step 232.133
[506.306, 311.614, 116.656] step 234.804
[300.170, 227.480, 128.000] step 222.933
**Rejected.** A camera between consecutive frames moves a little; this moves ~230
units per step, and the series is not monotone in any axis. `0x152c70` is
per-frame state, but it is not a camera position.
That is the check working. `a991088` recorded the prediction in advance -- "a
camera between consecutive frames moves a little, not 50 units" -- and the
measurement says otherwise, so the candidate is out rather than reinterpreted.
**The more useful consequence: these savestates are not consecutive frames.** They
are four separate captures from different points, so "moves smoothly between
frames" cannot be used to filter the 2,005 candidates at all until consecutive
frames exist. That is a gap in the method, not a gap in the data.
**What this changes about the plan.** The three confirmations from `a991088` were
ordered by cheapness, and the two cheapest both need something the savestates do
not provide: consecutive frames for smoothness, and an actual camera perturbation
for the third. Both require a PCSX2 PINE session -- capture four consecutive
frames, then move the camera and re-capture. The `docs/plan/pcsx2-verification.md`
setup exists for exactly this, and the tfrag-lighting verification used it.
So the camera hunt moves from "offline, savestates on disk" to "needs a session",
which is the same category as the tfrag morph. Worth knowing now rather than after
several more offline probes: **the differential measurement narrowed 2,005
candidates to nothing, and it did that in one step, because the confirmation test
was written before the measurement was interpreted.**