2145691586
Attempted to refute sylpheed-port's leaf table by measuring it against the disc. It SURVIVES to the digit: ptloop01 -> pteff03, cycle span 600, x track -639..1521, scale (100, 600); ptloop02 -> pteff03a, span 720, x -839..1721, scale (100, 800). The existing ptloop_leaf_sweep_at.rs samples only t=340..540 -- a window chosen to compare two competing fits -- so it could never have shown the extent. That gap is what let my "ptloop01/02 do not free-run" claim stand: measured over the parent's 200x90 pivot rect, which a leaf travelling -639..1521 is almost never inside. ptloop_leaf_extent.rs sweeps the whole cycle instead. New fact neither of us had: the leaves are IDENTICAL on entries 4, 5 AND 7 -- the title, the main menu and the JP title. Same leaf names, spans, x tracks, scales and parent rest position. So the menu declares exactly the same sweep as the title, and the still-open menu question is about the game's behaviour rather than a different declaration. The quad is 400 px wide at scale_x 100 % -- not widened -- and scale_y 600/800 % makes it 1080/1440 px tall, taller than the screen. A full-height strip crossing the frame and going off both sides, which is why a phase-to-phase diff covers the union of two positions and looks frame-wide. And my own "centre running x~921->1041" was a 30-unit window of a 600-unit cycle whose centre spans -439..1721. A sub-range is not an extent -- the same caution as a pivot not being a bounding box, one level up, and I made both errors within a day. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2.8 KiB
2.8 KiB