ReaperOfVeriod/Going-Commando
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Correct: the gap between collision and moby is texture data

Browse Source 
The previous commit claimed ~6.2 MB of unidentified data sat between the
collision header and the first moby class, and speculated it might be
moby_anim. That was wrong, and it came from quoting a size before bounding
the thing it measured.

Looking at the bytes rather than only the offsets: the range is dominated by
8-bit indexed texture data. Byte-value concentration distinguishes them
cleanly -- a texture block draws on a small palette, code and collision data
does not. 18 of 21 sampled 4 KB blocks fall under 200 distinct byte values,
against 249 for tfrags and 209 for collision.

The real layout on level 0:

  collision  2615232 .. 3518544   (header plus its declared 903,248 payload)
  textures   3518848 .. ~8832192
  moby       8832192 ..

The texture table's data_offset values stop at 5326208, which is what made
the gap look genuine. Mip chains extend well past the last entry's offset,
so sizing a region from a table of first-level offsets understates the data
it points at.

Three of the 21 blocks are not texture-like, so something is mixed in that
is still unidentified. It is not 6.2 MB of moby_anim.

This is the third number this session that looked load-bearing and turned
out to rest on an unbounded measurement. The pattern is consistent enough
to be worth stating plainly: sizes derived from tables or offsets are not
evidence until the bytes underneath have been looked at.
This commit is contained in:
ReaperOfVeriod
2026-10-11 03:05:07 +02:00
parent 8b98d388f7
commit db414b3d5f
1 changed files with 23 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/formats/core-data-regions.md
+23 -12
View File
@@ -49,7 +49,7 @@ that nothing yet accounts for.
the disc test asserts it, so the gap stays visible rather than being papered
over by clamping to the end of the lump.
## Found by printing it: an unnamed region between collision and moby
## Correction: it is mostly texture data, not an unnamed region
Adding the region table to `gc-extract probe` made the gap visible
immediately, which is the point of printing it.
@@ -64,16 +64,27 @@ but collision's own header declares a payload of 903,248 bytes. So the range
between the collision header and the first moby class is **6.2 MB**, and
almost none of it is collision.
The successor rule is right -- a region does end where the next begins -- but
"the next" is not yet known here. `collision..moby` is really
`collision + <something unnamed> .. moby`. The name is wrong, not the bound.
The first conclusion drawn from this -- that ~6.2 MB of unidentified data sat
between collision and moby, possibly `moby_anim` -- **was wrong**, and it was
wrong because of the same failure that produced the other two bad numbers this
session: quoting a figure before bounding it.
Candidate homes for those 6.2 MB, in rough order of likelihood: the moby and
tie model *animation* data that `moby_anim` would need, volume data, or
per-class runtime structures. The tfrag texture texels are already accounted
for and sit earlier in the lump.
Checking the bytes rather than just the sizes: the range is dominated by 8-bit
indexed texture data. Byte-value concentration (a texture block uses a small
palette; code and collision data does not) puts 18 of 21 sampled 4 KB blocks
under 200 distinct byte values, against 249 for tfrags and 209 for collision.
Until that region is named, any per-format probe reading between the collision
header and the first moby class is reading something this table does not
describe. Worth resolving before starting `moby_anim`, since that format is the
most likely tenant of the space.
So the real layout is:
| region | start | end |
|------------|----------|------------------|
| collision | 2615232 | 3518544 |
| textures | 3518848 | ~8832192 |
| moby | 8832192 | first tie class |
The texture table's `data_offset` values only reach 5326208, which is why the
gap looked real: mip chains extend well past the last entry's offset. A region
sized from a table of first-level offsets understates the data it points at.
Three of the 21 sampled blocks are not texture-like, so something is mixed in
and is not yet identified, but it is not 6.2 MB of `moby_anim`.