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

docs/port/HANDOFF.md

@@ -2026,3 +2026,51 @@ generalise. Read the same way, `eff4` gives 255 / 127 / 254 on frames 133 / 134
 135 — non-monotonic. The glow's exact agreement is evidence about the glow, not a
 decoded rule about vertex colour.
 
+## 2026-08-29 — `ptlogo_back2eff3` is declared on the disc and never drawn by the game
+
+✅ **measured**, and this one is actionable: **you draw `eff3` at t=60–62 and the
+console does not.**
+
+Last time I called `eff3`'s absence unexplained and withdrew a bad explanation for
+it. Re-examined against the **second** title build-in in the same capture — the
+attract loop returns, so one run contains two — it is absent there too, and three
+alternative explanations now fail:
+
+* **Sampling phase.** `eff3` is non-zero for t ∈ (58, 64) — **six units** — against
+  a step of **2.23 units per presented frame**. 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`, not `eff3`.
+* **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. `eff3` is not among them.
+* **A bad position guess on my side.** Dropping position entirely: across both
+  build-in windows, **zero** quads anywhere on screen 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 (`eff2` 938+258, `eff3` 788+408, `eff4` 447+749,
+`eff5` 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 distinguishes it
+from its neighbours: same kind `0x0`, same keyframe shape, same `u4`/`u8`, same
+scale. So this is *measured*, not decoded — if you drop `eff3` you are authoring a
+behaviour I cannot derive from the file, and you should know that.
+
+⚠️ **Two corrections to what I sent you before**, both mine and both found by
+following up my own claims:
+
+* **"Frame 107 is the title composited once" was an over-read.** It is a 27-draw
+  spike between the movie's last frame and the title's first, it binds **no
+  texture**, and only 4 of its 27 draws log geometry. I do not know what it is. The
+  second title entry has no such frame at all.
+* **The two build-ins are NOT frame-identical.** I had that impression from a
+  coincidentally aligned pair of rows. Aligned properly, only **4 of 46** frames
+  match. They are the same animation sampled at different phases — which is the
+  reason the `eff3` result is robust rather than a coincidence.
+
+Detail and the ruled-out explanations:
+[`docs/re/structures/ui-title-buildin-measured.md`](../re/structures/ui-title-buildin-measured.md).
+

docs/re/INDEX.md

@@ -171,4 +171,4 @@ files, which is how the same ground got covered twice.
 | [`structures/ui-tie-break-cost-at-settle.md`](structures/ui-tie-break-cost-at-settle.md) | What the unknown paint-order tie-break costs, in pixels | ✅ **decoded**, closing the open half of Q3: at the settled instant the tie-break costs **at most 1 px at Δ1**, on the **Japanese title only** (`ptlogo2`×`ptlogo_tm`, 5 px shared ink); **exactly 0 px on all five port screens**. The earlier 24-pair bound was a `rest()` count — and 10 of the title's 11 tied pairs are between `ptlogo_back2eff1`…`eff5`, five transient flashes that are **transparent** on the settled screen ([`ui-settle-time.md`](structures/ui-settle-time.md)). Live pairs at settle: entry 4 → **1**, entry 7 → **2**, the four loading bundles → **0**. ✅ Not a knife-edge — sweeping every keyframe time and midpoint, the count is **flat across the whole settle window**, and the loading bundles' tie is live only at t17–t33. ✅ Controls: an overlapping *different*-key swap moves 25 310 / 268 698 / ~765 000 px on the entries reporting zero; zeros are explained by shared-ink counts (the `ptframe` pairs share **0 px** of ink). ⚠️ Entries 0/1/12/15 have **no live control** — their zeros rest on keyframe data, not a render. 🟡 Refutation attempt on the corpus's "24 pairs": **survives** as a rest-pose bound, 16/16 on entry 7. ❔ *Why* ties order as they do is still unknown — and now worth one pixel |
 | [`structures/ui-record-loop-length.md`](structures/ui-record-loop-length.md) | Where a looping record's cycle restarts — and the `PRESS Ⓐ` plate's real period | ✅ **decoded**: a nested record is itself a RATC bundle and its header **`+0x08` is the loop length**; its keyframes need not fill it, and the slack is a hold at the final pose. Disc-wide over **1 781** timed nested records: 92.3 % declare exactly their last keyframe time, **7.7 % declare more**, and **0 declare less** — the falsifier (a cycle cannot restart before its own last pose) never fires. 🔴 **The plate's `ptbtn00f` is 105 units of ramp inside a 120-unit cycle, so it holds dark for 15 units** — the port was shipping **105**, and the answer is **120**. ✅ Falsification test against the running game, using a pacing factor measured *independently* on the focus ring (declared 120 → **2.177 s**, factor **1.0885**): to reach the corpus's measured 2.12–2.34 s, 105 units needs a factor of **1.211–1.337** (🔴 excludes the ring's) while 120 needs **1.060–1.170** (✅ contains it). Different elements, different bundles, separate runs — tied only by both declaring 120. ⚠️ Says where a cycle *ends*, not which records cycle. ❔ the **top-level** `+0x08` (300 on every `GP_TITLE` entry, elements ending at 244–269) is a different question, untouched |
 | [`structures/ui-focus-record-pulse-census.md`](structures/ui-focus-record-pulse-census.md) | Every focus record whose glow pulses, and where `rest()` puts it | ✅ **decoded**, disc-wide: **1 130** focus records, **2 664** timed elements, **210 with a varying alpha** — of which **202** have `rest()` == the **peak** (burns bright forever) and **8** land **mid-ramp**. By pak: `PILOTLOG` 116, `MOVIE_THEATER` 54, `HANGAR_ARSENAL` 30, `LEADERBOARD` 8, **`GP_TITLE` 2**. 🟡 Bounds rather than refutes the port's "34 in the export, 2 varying, nothing to fix" — correct, and correct *because* `GP_TITLE` has 2; the pathology sits in the screens a wider port needs next. 🔴 The 8 mid-ramp ones are the worse mode: `py_ranking_btn01f` swings 255→127→255 and `rest()` returns **244**, neither extreme, which looks entirely plausible and nothing reports it. ✅ Control: `ptbtn01f` is genuinely constant (255 throughout) and is **not** flagged; two hits verified keyframe by keyframe. ⚠️ A pulsing element has no resting pose — the question is malformed, not mis-answered; `pose_at(t)` inside the record's declared cycle ([`ui-record-loop-length.md`](structures/ui-record-loop-length.md)) is the only well-formed query. ⚠️ 210 is a **floor**: focus records are matched by the `Xf.rat` name rule, and varying scale/rotation/position is not counted |
-| [`structures/ui-title-buildin-measured.md`](structures/ui-title-buildin-measured.md) | The title's build-in and the plate glow, read out of the guest's own draw stream | ✅ **measured** (Canary, `ARM=early` draw capture): the decoded *mechanism* is observed, not just its end state. **The five flashes fire in a six-frame window and are absent from all 155 other sampled frames**; `ptlogo_back2eff1` is drawn in exactly 2 frames at **t = 54.0** against a decoded peak of **t54–56**, and `ptlogo1` first appears at **t = 42.2** against a decoded **t42** — with units/frame taken from the **glow's period alone**, a different element. The two holders (`ptlogo_back2eff`, `ptlogo_back2`) are continuous from frame 134. ✅ The glow's per-vertex colour alpha IS its fade alpha: **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** against **38.18 reversed** (2.9×), so the asymmetry is real and correctly directed. Structure: frame **107** is a **27-draw composite**, the settled title is 10–11 draws naming no sprite — which is why arming at the title sees nothing. 🔴 **Two claims here were WITHDRAWN the same day**: `eff3`'s absence is **unexplained**, not a sub-frame phase effect (frames 133/134 sit at t=60.0/62.2, inside its t(58,64) window, with `eff2` and `eff4` drawn alongside); and the advice that a port drawing all five "shows more sweep than the console" had no evidence behind it. ⚠️ What a frame-by-frame build-in comparison *will* show is disagreement about which flash lands in which frame — 2 units/submitted frame against this run's 2.231 units/presented frame — and neither side is wrong. 🔴 **Trap:** matching a bound texture's dimensions to a sprite fails both ways — it missed every flash *and* read the intro movie's 640×360 YUV planes as `ptbase2`. ✅ A regression of five events' observed frames against their declared times (residuals ≤0.9 frames) recovers the intercept at frame **106.1** when the composite spike, not in the fit, is frame **107**. ⚠️ Per-vertex alpha = fade alpha holds for the **glow** and does not generalise — `eff4` reads 255/127/254 on consecutive frames. ❔ Frame rate not recorded, so nothing is in seconds; the glow's period implies a **114**-unit cycle against a declared 120, unexplained; `eff5` vs `ptlogo_back2eff` not separated |
+| [`structures/ui-title-buildin-measured.md`](structures/ui-title-buildin-measured.md) | The title's build-in and the plate glow, read out of the guest's own draw stream | ✅ **measured** (Canary, `ARM=early` draw capture): the decoded *mechanism* is observed, not just its end state. **The five flashes fire in a six-frame window and are absent from all 155 other sampled frames**; `ptlogo_back2eff1` is drawn in exactly 2 frames at **t = 54.0** against a decoded peak of **t54–56**, and `ptlogo1` first appears at **t = 42.2** against a decoded **t42** — with units/frame taken from the **glow's period alone**, a different element. The two holders (`ptlogo_back2eff`, `ptlogo_back2`) are continuous from frame 134. ✅ The glow's per-vertex colour alpha IS its fade alpha: **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** against **38.18 reversed** (2.9×), so the asymmetry is real and correctly directed. Structure: the settled title is 10–11 draws naming no sprite — which is why arming at the title sees nothing. ⚠️ Frame **107** is a 27-draw spike between the movie's last frame and the title's first; calling it "the composite" 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 entries are the same animation at **different sampling phases** (only 4 of 46 aligned frames match), which is what makes the `eff3` result robust. 🔴 **The game does not draw `ptlogo_back2eff3` at all** — reproduced over **two** title entries 5 800 frames apart, and three alternative explanations tested and failed: *phase* (its window is **6 units** against a **2.23-unit** step, so it cannot be missed — frames 133/134 sit at t=60.1/62.3 inside it and draw `eff2` and `eff4` instead), *an unlogged draw* (exactly 2 blind draws/frame, always the same full-screen-triangle shader, present when no wipe is active), and *a bad position guess* (dropping position entirely, **zero** quads anywhere have a width within ±30 of 408; the spectrum jumps 262 → 748). Draw counts across both entries: eff1 **4**, eff2 **3**, eff3 **0**, eff4 **6**. 🔴 **The port draws `eff3` at t=60–62 and the console does not.** ❔ Why is not established — nothing in its element record differs from its neighbours. ⚠️ An earlier "sub-frame phase" explanation and the advice that drawing all five "shows more sweep than the console" are both **withdrawn**. ⚠️ What a frame-by-frame build-in comparison *will* show is disagreement about which flash lands in which frame — 2 units/submitted frame against this run's 2.231 units/presented frame — and neither side is wrong. 🔴 **Trap:** matching a bound texture's dimensions to a sprite fails both ways — it missed every flash *and* read the intro movie's 640×360 YUV planes as `ptbase2`. ✅ A regression of five events' observed frames against their declared times (residuals ≤0.9 frames) recovers the intercept at frame **106.1** when the composite spike, not in the fit, is frame **107**. ⚠️ Per-vertex alpha = fade alpha holds for the **glow** and does not generalise — `eff4` reads 255/127/254 on consecutive frames. ❔ Frame rate not recorded, so nothing is in seconds; the glow's period implies a **114**-unit cycle against a declared 120, unexplained; `eff5` vs `ptlogo_back2eff` not separated |

docs/re/structures/ui-title-buildin-measured.md

@@ -43,14 +43,21 @@ rects, everything appears.
 | frames | draws/frame | what |
 |---|---|---|
 | 2–105 | 3–5 | splashes, then the intro movie |
-| **107** | **27** | 🔴 the title **composited**, once |
+| **107** | **27** | a transition frame — see the caveat below |
 | 109–167 | 6 → 14 | the build-in |
 | 168–1217 | 10–11 | the settled title |
 | 1218– | 4–5 | back to the attract loop |
 
-The settled screen is 10–11 draws that never name a sprite; the composite happens
-in a single 27-draw frame. **A capture armed at the title therefore sees nothing** —
-which is why `ARM=early` exists.
+The settled screen is 10–11 draws that never name a sprite. **A capture armed at
+the title therefore sees nothing** — which is why `ARM=early` exists.
+
+⚠️ **What frame 107 is, is NOT established.** An earlier version of this page called
+it "the title composited, once". It is a 27-draw spike sitting between the movie's
+last frame (105) and the title's first (109), it **binds no texture at all**, and
+only 4 of its 27 draws log any geometry. It marks the transition; calling it the
+composite was an over-read. (The regression below independently puts t=0 at frame
+106.1, which is consistent with the title's clock starting here — but that is a fit
+landing nearby, not evidence about what the 27 draws do.)
 
 ## The flashes are real, and they are transient
 
@@ -72,12 +79,46 @@ a different element**, taking the composite spike (frame 107) as t=0:
 other 155 frames sampled.** The two holders are present continuously from frame
 134 onward. That is the decoded mechanism, observed.
 
-🔴 **`eff3` was never drawn, and I do not know why. An earlier version of this
-page said it was a sub-frame phase effect. That is WITHDRAWN.** `eff3`'s alpha is
-non-zero for t ∈ (58, 64), and frames 133 and 134 sit at t = 60.0 and 62.2 —
-squarely inside it, with `eff2` and `eff4` both drawn in those same frames. It
-should have been submitted and was not. Whatever the reason, it is not sampling
-phase.
+## 🔴 The game does not draw `ptlogo_back2eff3`
+
+**Reproduced over two title entries, 5 800 frames apart, in one run.** The disc
+declares `ptlogo_back2eff3` — alpha 0 at t58, **255 at t60–62**, 0 at t64, at
+(788, 117), sprite 408×203 — and the running game never submits it.
+
+The wipe family is right-aligned: `eff2` 938+258, `eff3` 788+408, `eff4` 447+749,
+`eff5` 64+1133 all end at x≈1196. It is a left-growing wipe in four widths, and
+**the game draws three of them.**
+
+| element | width | draws across both build-ins | expected at ~2.23 units/frame |
+|---|---|---|---|
+| `eff1` | 167 | 4 | ~5 |
+| `eff2` | 258 | 3 | ~5 |
+| **`eff3`** | **408** | **0** | **~5** |
+| `eff4` | 749 | 6 | ~5 |
+
+⚠️ An earlier version of this page called this a **sub-frame phase effect**. That
+was wrong and is withdrawn. Three explanations were tested and all fail:
+
+* **Sampling phase.** `eff3`'s non-zero window is t ∈ (58, 64) — **six units**,
+  against a step of **2.23 units per presented frame**. A window wider than the
+  step *cannot* be missed: at least two frames must land inside it, and frames 133
+  (t = 60.1) and 134 (t = 62.3) do. Both draw `eff2` and `eff4`; neither draws
+  `eff3`.
+* **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
+  (`prim=8 indices=3`, `vs=0x72CBCAA6A7984111`), present on frames where no wipe
+  element is active at all. `eff3` cannot be one of them.
+* **A bad position guess on my side.** Dropping the position entirely and
+  searching *every* quad submitted anywhere on screen during both build-in
+  windows: **zero** have a width within ±30 of 408. The width spectrum jumps
+  straight from 262 to 748.
+
+❔ **Why the game skips it is not established.** Nothing in its element record
+distinguishes it — same kind (`0x0`), same keyframe shape, same `u4`/`u8`, same
+scale, as `eff2` and `eff4` either side of it.
+
+🔴 **For the port: you draw `eff3` at t=60–62 and the console does not.** That is
+one extra frame of wipe, at the widest-but-one step. It is small, and it is real.
 
 🔴 **A second thing this page previously claimed, also withdrawn: that a port
 drawing all five flashes shows "more sweep than the console".** There is no
@@ -130,6 +171,20 @@ decoded direction.
 detected at the first frame with a non-zero alpha, and the decoded curve leaves
 zero part-way through a frame.
 
+## Two entries, different phases
+
+The attract loop returns to the title, so one capture contains **two** build-ins
+(frames 119–1220 and 5942–7025). They are the same animation and are **not**
+frame-aligned: aligning them on `eff1`'s first frame, only **4 of 46** frames have
+an identical quad list, and the draw-count sequences drift by a frame partway
+through.
+
+That is what makes the `eff3` result robust rather than weaker. Two independent
+samplings of the same animation, at different phases, both miss it.
+
+⚠️ Only the **first** entry has the 27-draw frame; the second goes straight from
+3–6 draws into the build-in. Whatever frame 107 is, the re-entry does not repeat it.
+
 ## Reach and what is not settled
 
 ⚠️ **One run, one machine.** ~2.23 units per presented frame is *this run's*