re(ui): rotation is not nested-only, and the pivot-anchored scale is measured
Two corrections and one new confirmation, all from finishing the sweep I left running last iteration. Refuted, by my own sweep, within the hour: "rotation appears to live only in nested .rat leaf records". That held for GP_TITLE, GP_BUNK and GP_CHALLENGE -- the three archives the sweep had reached when I wrote it -- and fails on GP_DIALOG and GP_DEBRIEFING_PILOTLOG, which rotate top-level elements. Scoping the claim made it cheap to withdraw, but the sentence should have waited for the sweep. Those top-level cases are the best evidence on the disc, and they show up in `screen info --geometry` without a hex dump. GP_DIALOG build 0: pceff03/pceff04 ramp r = 90 -> 30 -> 10 -> 3 -> 0 while alpha ramps 0 -> 255 and they slide into place -- a swing-in settling upright. Build 6: pzeff02 ramps 43 -> 61 -> 75 -> 90 while scaling 112% -> 200% and fading to 0 -- a spin-out. Rows committed as reference data. New: the pivot-anchored scale term in blit, kf.x - pivot*(scale-100)/100, was implemented and reasoned about but never measured, because every element previously examined sits at 100% scale where the term is exactly zero. The ptloop pair scale 600% and 800%, where it is worth 450 and 630 px. Formula predicts centre y = 360.0 for both; capture measures 359.1 and 360.0. Top-left anchoring predicts 810 and 990. Horizontally it makes t-from-position agree with t-from-alpha to 0.33 / 0.65 units against ~8 without it. That agreement does NOT prove linear interpolation -- both fields were inverted through the same linear map, so a shared easing curve cancels. It shows position and alpha ride one shared parameter. Recorded as such. The disc-wide sweep is still running; the count is incomplete, the existence is settled.
This commit is contained in:
@@ -59,6 +59,17 @@ neighbourhood, not just the line.
|
||||
* "a keyframe-block scanner may assume 4-byte alignment" → refuted; it found
|
||||
**0/3** of its own control blocks and under-counted the corpus by 16 341
|
||||
blocks. Nested `RATC` blobs start at odd offsets (`0xbb5966`).
|
||||
* "keyframe rotation lives only in **nested** `.rat` leaf records" → **mine, and
|
||||
refuted within the hour by my own sweep.** It held for the three archives I had
|
||||
checked (`GP_TITLE`, `GP_BUNK`, `GP_CHALLENGE`) and failed on the next:
|
||||
`GP_DIALOG` and `GP_DEBRIEFING_PILOTLOG` rotate **top-level** elements, and
|
||||
those are the clearest examples on the disc.
|
||||
[`ui-keyframe-rotation.md`](structures/ui-keyframe-rotation.md)
|
||||
* "the pivot-anchored scale formula `kf.x − pivot·(scale−100)/100` is our
|
||||
renderer's reading, not a measurement" → **now measured.** At the `ptloop`
|
||||
pair's 600 %/800 % scale it predicts both quad centres at y = 360.0 against a
|
||||
captured 359.1/360.0, where top-left anchoring predicts 810/990.
|
||||
[`ui-keyframe-rotation.md`](structures/ui-keyframe-rotation.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
|
||||
|
||||
Reference in New Issue
Block a user