86da451bfee4ddb08073cf0f198d1c007dd49c41
5 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
sylph-decoder
|
78328c5022 |
re: the top-level clock freezes at the settle point -- closing the 114-vs-120 gap
Measured in the title draw capture, re-read with the per-quad parser. GP_TITLE build 4 declares t = 0..269, about 120 presented frames at this run's pacing. The title dwell lasted ~1100. ptcopyright declares alpha >= 1 for 106 units (t=138..244) and is drawn for 1050 frames; ptlogo1 declares an exit at t=264 and is drawn for 1095. Both vanish within three frames of the dwell ending. So the top-level clock advances through the build-in, stops inside the settle window [160,236], and holds. The exit ramp is not played on a timer -- it plays when something makes the screen leave. That is ui-settle-time.md's decode seen from the other side and observed in the running game rather than inferred from the file. A nested record keeps looping on its own clock throughout. This closes the 114-vs-120 gap, and it was my arithmetic rather than a discrepancy in the decode. The 2.231 units/frame was regressed over BUILD-IN events -- the only stretch in which the top-level clock advances -- and applied to a period measured over the settled dwell, where that clock is frozen and only the plate's own record is running. Two different clocks. The declared 120 was never in doubt from the calibration-free dark-fraction test. The 51.158-frame period is now confirmed by a second independent estimator: autocorrelation returns lag 51 with clean harmonics at 102 and 154. Its FIRST version failed its control, returning 48 for a period known to be 51.158, because it indexed by sample position where the log's frame numbers have gaps. Recorded, because the failure is the reason the second version can be trusted. Not settled: the sweeps' period. The same validated estimator disagrees between two dwells of one screen -- 515 vs 452 frames for the same family -- and a 14% disagreement within one screen is not a period. The +0x08 field cannot settle it either, since ptloop01/ptloop02 have zero slack. Blocker recorded in CONTAINER-NOTES: a single A press on the title faults the guest. Three menu-capture attempts, two ending in register dumps of 223 MB and 519 MB, against three no-input runs in the same session that all completed. And a guest fault writes an UNBOUNDED register dump to stdout on a filesystem at 91%, so any scripted button press needs a size guard. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
47faeaa7a9 |
re: RETRACT "the game never draws eff3" -- a batched draw merged two quads
The console draws all five title flashes. My claim that ptlogo_back2eff3 is never drawn was an instrument artefact, and I had reported it to the port with three alternative explanations "ruled out". A GPU draw can batch several quads -- indices=4 is one, indices=8 two, indices=24 six -- and the UI draw log dumps only the first 8 vertices. Taking min/max over a line's whole vertex list merges quads into one box. eff3 is batched with eff4, and because the wipe family is right-aligned, eff3 (788..1196) lies ENTIRELY INSIDE eff4 (447..1196). The union is exactly eff4's own extent, so the merged box matched eff4 to 1 px, eff3 vanished, and nothing looked wrong. Parsed per quad, all five fire in both title entries in the declared stagger: eff1 130-131, eff2 133, eff3 133-134, eff4 133-135, eff/eff5 134+, back2 136+; and 5953-5955 / 5955-5957 / 5957-5958 / 5957-5959 / 5958+ / 5962+ in entry 2. Frames 133 and 134 are t=60.1 and 62.3, inside eff3's declared t in (58,64). Also retracts "the developer splash is one composited quad" -- the same bug, which the port refuted by arithmetic first (a 259-tall box cannot contain three logos spanning y 164..585). It draws three logos and three glows as separate quads in one indices=24 call; the 525x259 was gamearts_eff merged with seta_eff. The 9-unit black hold is unaffected: those glows are the developer splash's first draw. The three "ruled out" explanations were all aimed at the wrong failure. In particular the invisible-draw check counted draws with NO geometry line, when the hiding place was draws with PARTIAL geometry. Refuting three wrong hypotheses is not evidence for a fourth, and a list of failure modes written by whoever built the instrument is the least likely to contain its blind spot. Recorded in METHOD.md, along with the tell that was present and explained away: a merged box carries the first quad's colour, which made one element's alpha read 255/127/254 on consecutive frames. New tool: tools/re-capture/quads_per_frame.py parses vertices in groups of four and warns when the logged quad count falls short of indices/4. Also guards a double-A-tap in ui_draw_capture.sh: the movie branch ignored that TARGET=menu had already tapped, so a run tapped A on the title at t=23s and again at t=27s on the transition; the guest faulted and Xenia dumped registers to stdout until the file reached 519 MB. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
69bc4cd1cd |
re: the game never draws ptlogo_back2eff3 -- reproduced, with three explanations
ruled out
Last iteration I recorded eff3's absence as unexplained after withdrawing a bad
explanation for it. The previous capture survived on disk with 6907 frames, and
the attract loop returns to the title, so it contains a SECOND build-in at
frames 5942..7025. eff3 is absent there too.
Three alternative explanations tested and failed:
* sampling phase -- eff3 is non-zero for t in (58,64), SIX units, against a
2.23-unit step. A window wider than the step cannot be missed; frames 133
(t=60.1) and 134 (t=62.3) sit inside it and draw eff2 and eff4 instead.
* a draw the log cannot see -- exactly 2 draws per frame carry no geometry,
on all 932 settled title frames, always the same full-screen-triangle
shader, and present on frames where no wipe element is active.
* a bad position guess -- dropping position entirely, ZERO quads anywhere on
screen in either build-in window have a width within +-30 of 408. The width
spectrum jumps straight from 262 to 748.
Draw counts across both entries: eff1 4, eff2 3, eff3 0, eff4 6, against ~5
expected each. The four are a right-aligned wipe (938+258, 788+408, 447+749,
64+1133, all ending at x~1196) -- a left-growing reveal in four widths, of
which the game draws three.
Why is NOT established: nothing in eff3's element record differs from its
neighbours. Classified measured, not decoded, and the port is told that
dropping eff3 means authoring a behaviour I cannot derive from the file.
Two further corrections, both to my own earlier claims:
* "frame 107 is the title composited once" was an over-read. It binds NO
texture and only 4 of its 27 draws log geometry. The second title entry
has no such frame.
* the two build-ins are NOT frame-identical. I had that from a coincidentally
aligned pair of rows; aligned properly only 4 of 46 frames match. They are
the same animation at different sampling phases -- which is precisely what
makes the eff3 result robust.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
|
||
|
sylph-decoder
|
311bd16ad8 |
re: withdraw the eff3 explanation and the flash advice; add a calibration-free
test that refutes 105 Two claims shipped this morning are withdrawn, and the port had already acted on one of them. WITHDRAWN 1: "eff3 was never drawn because a 2-unit flash peak is sub-frame." eff3's alpha is non-zero for t in (58,64), and the capture's frames 133 and 134 sit at t = 60.0 and 62.2 -- squarely inside that window, with eff2 and eff4 both drawn in the same frames. It should have been submitted and was not. The absence is real and UNEXPLAINED; it is not sampling phase. WITHDRAWN 2: "a port drawing all five flashes shows more sweep than the console". No evidence behind it. The port checked against its own renderer and found it draws them sequentially at their declared times, never more than two at once -- which is exactly what frames 131-135 show the game doing. The pile-up worth warning about was the rest() bug, now fixed. Kept, at the port's request: a frame-by-frame comparison of the build-in WILL disagree about which flash lands in which frame -- 2 units per submitted frame against this run's 2.231 units per presented frame -- and neither side is wrong. Without that stated, the discrepancy reads as a port defect. Added, and stronger than the argument it replaces: a calibration-free test of 105 vs 120. The glow's draw is omitted when its alpha reaches zero, and the smallest alpha actually submitted across 807 drawn frames is 1, so the culling threshold is read off the data rather than assumed. Measured dark fraction 17.7% (173 of 980 settled frames); a 120-unit cycle with its declared 15-unit hold predicts 14.4%; a 105-unit cycle predicts 2.2%. 105 is out by 8x and would need a threshold of alpha 11 out of a peak of 80, while the capture contains submitted draws at alpha 1..12. No frame rate, no pacing factor, no wall clock. Also recorded: a regression of five build-in events against their declared times (residuals <=0.9 frames) recovers t=0 at frame 106.1 when the composite spike, not in the fit, is frame 107 -- and that same slope makes the glow's period imply a 114-unit cycle against a declared 120, which is unexplained. And the vertex-alpha identity holds for the glow but does NOT generalise: eff4 reads 255/127/254 on consecutive frames. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
d98c8214cc |
re: the title's build-in measured in the guest's draw stream -- the flashes are real
The settle-time decode was confirmed only against a SETTLED frame, which shows the end state is right and says nothing about whether the five flashes ever happen. This runs the oracle: a draw capture armed before the title exists, so the window contains the frames in which the screen is built. The flashes fire in a six-frame window and are absent from all 155 other sampled frames. `ptlogo_back2eff1` is drawn in exactly two frames at t = 54.0 against a decoded peak of t54-56; `ptlogo1` first appears at t = 42.2 against a decoded t42. Units-per-frame was taken from the GLOW's period alone, a different element, so the timings are not circular. The two holders are continuous from frame 134. The plate glow's quad carries a per-vertex colour whose alpha IS the element's fade alpha, so the ramp is read straight out of the guest: observed range 0..80 against a decoded peak of 80, exact and unfitted; period 51.158 presented frames over 20 cycle starts. Fitting the decoded ramp gives RMS 13.16 alpha levels against 38.18 for the same ramp REVERSED -- if the shape carried no information those would be equal, so the asymmetry is real and correctly directed. Further controls: symmetric triangle 15.73, flat 31.13. `ptlogo_back2eff3` was never drawn, and that is expected rather than a miss: a 2-unit flash peak is 0.85 of a presented frame, so catching one is a matter of phase. A port drawing all five every time shows more sweep than the console. METHOD.md gains the trap this cost: a 2D draw's identity is its vertex geometry, not its bound texture. These sprites sample shared pages, and matching texture dimensions produced a false negative (no flash is ever drawn) and a false positive (the intro movie's 640x360 YUV planes read as `ptbase2`) in the same pass. Also records the top-level restriction on the settle window, which the port raised and which is verified here: top-level [160,236] width 76, including the `ptloop` leaves [269,540] width 271 -- an instant past the end of every top-level element's timeline. Evidence committed as a derived per-frame series, not the 7 MB raw log. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |