fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: looking closer at the frame-rate word weakened it, and that is the result

Browse Source 
The 16.16 reading of +0x04 rested on twelve bundles at 30.0. They are not twelve
witnesses: they are TWO bundles - pghud_range_main_em/emeff and
pghud_range_nose_em/emeff, both dur 30 - repeated across six language PAKs. A
30-frame flash is equally consistent with 0.5 s at 60 and 1 s at 30, so the
observation that "30.0 bundles are shorter" says almost nothing.

Worse for the clean fixed-point reading: the four bundles at 0x3C0001 would be
60.0000152 fps, which nobody authors. They are py_ranking_jump/py_ranking_next
dialogs, all dur 60. So the better reading is <rate:16>.<flag:16> - a rate-like
number in the high half and a small low field that is 0 on 2843 bundles and 1 on
four, meaning unknown.

Also stated: nothing in this container can settle it by timing, because the
emulator runs on software Vulkan far from real time - a stopwatch would measure
lavapipe rather than the game.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
This commit is contained in:
Sylpheed RE agent
2026-08-24 07:34:56 +00:00
parent f3612b982b
commit a40a0b7b01
2 changed files with 37 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
docs/re/structures/ui-rat-layout.md
View File

@@ -575,7 +575,25 @@ that `+0x08` is the animation's **length in the same unit as the keyframe `time`
field**. That the unit is *frames* still rests on the values themselves
(30 / 60 / 120 / 1200) and on the 16.16 reading of `+0x04`.
🟡 **`+0x04` stays amber.** The one new piece of evidence is weak but points the
right way: the twelve bundles whose rate word is `0x1E0000` (30.0) have a largest
`+0x08` of **30**, while the 2 843 at `0x3C0000` (60.0) go up to **1 440**. Twelve
bundles is not a demonstration, and nothing here measures a wall-clock duration.
🟡 **`+0x04` stays amber, and looking closer WEAKENED it.** The twelve bundles at
`0x1E0000` are not twelve witnesses: they are **two** bundles repeated across six
language PAKs —
```
pghud_range_main_em.t32 + pghud_range_main_emeff.t32 dur 30
pghud_range_nose_em.t32 + pghud_range_nose_emeff.t32 dur 30
```
— so the whole "30.0 bundles are shorter" observation rests on two authored
assets, and a 30-frame flash is equally consistent with 0.5 s at 60 and 1 s at 30.
🔴 **And the four `0x3C0001` bundles argue against a clean 16.16 value.** As
fixed-point that is 60.0000152 fps, which nobody authors; the four are
`py_ranking_jump`/`py_ranking_next` dialogs in `GP_DIALOG.pak`, all with
`dur = 60`. The better reading is **`<rate:16>.<flag:16>`** — a rate-like number
in the high half (60 or 30) and a small field in the low half that is 0 on 2 843
bundles and 1 on four. What that low field means is ❔.
Nothing here measures a wall-clock duration, and **nothing in this container
can**: the emulator runs on software Vulkan far from real time, so timing an
animation would measure lavapipe, not the game.