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.
This commit is contained in:
@@ -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
|
||||
|
||||
@@ -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.
|
||||
Reference in New Issue
Block a user