Rule out GS packet framing in tie, with a control that nearly fooled me
Range measured: level 0, the 73 tie span bodies (bytes +0x40 onward), 2585856 bytes pooled. Per-position distinct counts, an autocorrelation scan against a shuffled control, and a GS GIF tag test. Result 1: the bodies are dense. Every one of the 16 slot positions takes 245 to 256 distinct values, byte 15 zero on 81.3% and byte 7 zero on 78.8%. The best stride peak is 48 at +0.097, barely above 16 at +0.095 -- no period. Result 2: no GS GIF framing at 16-byte alignment. Testing whether byte 15's low three bits fall in 0..4, the GS tag range, gives 97.0%. That looked like a strong hit until the control was done properly. A uniform shuffle gives 62.6%, exactly 5/8, what a random byte predicts -- so the naive comparison reads as a 34-point excess. The distribution-matched null is 97.0%, identical to the observation. The whole excess was that byte 15 is 81% zero and (0 & 7) <= 4 is always true. Recomputed per alignment the null tracks the observation everywhere: align 0 97.0% align 4 75.7% align 8 96.7% align 2 75.5% align 12 89.3% This is the control rule earning its place a second time. A uniform shuffle is not a matched control when the data is skewed, and AGENTS.md already says so; the near-miss was reading 62.6% as a baseline without checking what the data's own distribution predicts. The tie bytes concentrate on 0, 1, 2, 3 and 63 -- suggestive in isolation -- and still carry no framing. What this rules out: the tie bodies are not GS GIF packet streams at 16-byte alignment and carry no measurable periodicity. With every slot position taking ~256 distinct values they are dense data -- fat vertices, as the roadmap expects -- and locating the vertex layout needs a reference for this game's instanced geometry format, not another stride scan.
This commit is contained in:
@@ -1445,3 +1445,44 @@ and the value set is quantised. The bounding-box reading does not survive.
|
|||||||
|
|
||||||
**Not decoded:** what the three floats are, what `0x100` at `+0x00` counts,
|
**Not decoded:** what the three floats are, what `0x100` at `+0x00` counts,
|
||||||
and what the 83 values at `+0x0c` are.
|
and what the 83 values at `+0x0c` are.
|
||||||
|
|
||||||
|
## Tie geometry: no GS packet framing, and a control that nearly fooled me
|
||||||
|
|
||||||
|
**Range measured:** level 0, the 73 tie span bodies (bytes `+0x40` onward),
|
||||||
|
**2,585,856 bytes** pooled. Per-position distinct counts, an autocorrelation
|
||||||
|
scan against a shuffled control, and a GS GIF tag test.
|
||||||
|
|
||||||
|
**Result 1 -- the bodies are dense.** Every one of the 16 slot positions takes
|
||||||
|
245 to 256 distinct values, with byte 15 zero on 81.3% and byte 7 zero on 78.8%.
|
||||||
|
The best stride peak is 48 at +0.097, barely above 16 at +0.095 -- no period.
|
||||||
|
|
||||||
|
**Result 2 -- no GS GIF framing at 16-byte alignment.** Testing whether byte 15's
|
||||||
|
low three bits fall in 0..4, the GS tag range, gives **97.0%**.
|
||||||
|
|
||||||
|
That looked like a strong hit until the control was done properly. A uniform
|
||||||
|
shuffle gives **62.6%** -- which is exactly 5/8, what a random byte predicts --
|
||||||
|
so the naive comparison reads as a 34-point excess.
|
||||||
|
|
||||||
|
**The distribution-matched null is 97.0%, identical to the observation.** The
|
||||||
|
whole "excess" was that byte 15 is 81% zero, and `(0 & 7) <= 4` is always true.
|
||||||
|
Recomputed per alignment, the null tracks the observation everywhere:
|
||||||
|
|
||||||
|
| align | matched null |
|
||||||
|
|---|---|
|
||||||
|
| 0 | 97.0% |
|
||||||
|
| 2 | 75.5% |
|
||||||
|
| 4 | 75.7% |
|
||||||
|
| 8 | 96.7% |
|
||||||
|
| 12 | 89.3% |
|
||||||
|
|
||||||
|
**This is the control rule earning its place a second time.** A uniform shuffle
|
||||||
|
is not a matched control when the data is skewed, and `AGENTS.md` already says
|
||||||
|
so; the near-miss here was reading the 62.6% as a baseline without checking
|
||||||
|
what the data's own distribution predicts. The tie bytes are concentrated on
|
||||||
|
0, 1, 2, 3 and 63 -- suggestive in isolation -- and still carry no framing.
|
||||||
|
|
||||||
|
**What this rules out.** The tie bodies are not GS GIF packet streams at 16-byte
|
||||||
|
alignment, and they carry no measurable periodicity. With every slot position
|
||||||
|
taking ~256 distinct values they are dense data -- fat vertices, as the roadmap
|
||||||
|
expects -- and locating the vertex layout inside them needs a reference for this
|
||||||
|
game's instanced-geometry format, not another stride scan.
|
||||||
|
|||||||
Reference in New Issue
Block a user