re: three angle fields found in the keyframe -- and they are not the

title's rotation

Looking for where the rotated quads come from, the obvious candidates
were the three keyframe words at +4, +8 and +12 that ui_layout.rs
documents as zero.

They are not zero. Across 72287 keyframe blocks disc-wide they are
non-zero in 4.81, 4.56 and 15.82 percent of blocks, and read as signed
values clustering on 180, -180, 90, -90, 120 and 22 -- degrees. Three of
them, so plausibly rotation about three axes. I have marked that amber
because it is the shape of the numbers and nothing more; no observed
rotation has been tied to a value. The doc comment is corrected
regardless: "0 on every frame seen" was an artefact of the sample.

And they do not explain the screen I was chasing. Every element of
GP_TITLE build 4 has all three at zero, element by element, while the
game demonstrably submits rotated parallelograms there. So the title's
rotation comes from outside the keyframe data and is still unidentified.

One correction to my own last write-up, flagged rather than left: I
stated that the skewed draw IS the swoosh. It is the only skewed geometry
in the capture and the swoosh is the only diagonal element on the screen,
so the inference is reasonable -- but I never confirmed it by matching
the draw's texture or screen position to that element, and I should have
said so the first time.

crates/sylpheed-formats/src/ui_layout.rs

@@ -59,9 +59,9 @@ const DESIGN_H: u32 = 720;
 ///
 /// ```text
 /// +0   u32  ARGB fade colour — alpha ramps 0x00 → 0x80 → 0xd5 … over the group
-/// +4   u32  0
-/// +8   u32  0
-/// +12  u32  0
+/// +4   i32  ⚠️ NOT always 0 — see below
+/// +8   i32  ⚠️ NOT always 0 — see below
+/// +12  i32  ⚠️ NOT always 0 — see below
 /// +16  u32  scale X, percent
 /// +20  u32  scale Y, percent
 /// +24  u32  tint (0xffff_ffff on every frame seen)
@@ -69,6 +69,19 @@ const DESIGN_H: u32 = 720;
 /// +32  i32  Y   ← signed
 /// +36  u32  time
 /// ```
+///
+/// ## `+4` / `+8` / `+12` are **angles**, not zeroes (2026-08-28)
+///
+/// These were documented as `0` from a sample that happened to contain none.
+/// Over **72 287** keyframe blocks disc-wide they are non-zero in **4.81 %**,
+/// **4.56 %** and **15.82 %** of blocks, and read as **signed** values clustering
+/// on `180`, `−180`, `90`, `−90`, `120`, `22` — degrees. 🟡 Three of them, so
+/// plausibly rotation about three axes; **not tied to an observed rotation yet**,
+/// and this crate does not use them.
+///
+/// ⚠️ They do **not** explain the title screen: every element of `GP_TITLE`
+/// build 4 has all three at zero, while the game demonstrably submits rotated
+/// quads there. See `docs/re/ui-title-build-map.md`.
 #[derive(Debug, Clone, Copy, PartialEq, Eq)]
 pub struct Keyframe {
     /// The fade colour, ARGB. Its alpha is what ramps an element in.

docs/re/REFUTED.md

@@ -35,6 +35,12 @@ neighbourhood, not just the line.
 
 ## Screens, classes and RTTI
 
+* "the keyframe words at `+4`/`+8`/`+12` are always zero" → they are non-zero in
+  4.81 %, 4.56 % and 15.82 % of 72 287 blocks disc-wide, reading as **degrees**
+  (±180, ±90, 120). The original note was a sample artefact.
+* "those angle fields are where the title's rotated quads come from" → **no** —
+  every `GP_TITLE` build 4 element has all three at zero.
+  [`ui-title-build-map.md`](ui-title-build-map.md)
 * "the game passes a pink per-vertex colour for the title swoosh" → **refuted by
   draw capture.** Every vertex colour in the capture is `<alpha>FFFFFF`, white RGB.
 * "the swoosh discrepancy is undecodable" → **solved**: the game submits it as two

docs/re/ui-title-build-map.md

@@ -642,4 +642,35 @@ keyframes. That is the open question this leaves.
 ⚠️ **The "pink versus white" reading is now suspect.** It was a visual comparison
 of two differently-*shaped* renderings. Whether any colour difference survives
 correct geometry is **untested**, and should be re-checked rather than carried
-forward as a separate defect.
+forward as a separate defect.
+
+## 🟡 Three angle fields found — and they are NOT the title's rotation
+
+The obvious place to look for the rotation was the keyframe block's three words
+at `+4`, `+8`, `+12`, which `ui_layout.rs` documented as `0`.
+
+**They are not zero.** Over **72 287** keyframe blocks disc-wide:
+
+| word | non-zero | commonest values (signed) |
+|---|---|---|
+| `+4` | **4.81 %** | `180`, `−180`, `22`, `90` |
+| `+8` | **4.56 %** | `180`, `90`, `−180`, `178` |
+| `+12` | **15.82 %** | `90`, `−90`, `120`, `−58` |
+
+Values clustering on ±180, ±90, 120 read as **degrees**, and three of them suggests
+rotation about three axes. 🟡 That reading is **not tied to an observed rotation** —
+it is the shape of the numbers, nothing more. The doc comment is corrected either
+way: "0 on every frame seen" was a sample artefact.
+
+### 🔴 But they do not explain this screen
+
+**Every element of `GP_TITLE` build 4 has all three at zero** — checked
+element by element. The game still submits rotated parallelograms there. So the
+title's rotation comes from **outside the keyframe data**, and remains
+unidentified.
+
+⚠️ **One thing I should not have stated flatly:** that the skewed draw *is* the
+swoosh. It is the only skewed geometry in the capture and the swoosh is the only
+diagonal element on the screen, so the inference is reasonable — but it was not
+confirmed by matching the draw's texture or screen position to that element, and
+should be.