ReaperOfVeriod
8b98d388f7
Printing the region table next to the header fields makes the gap visible without having to remember to consult core_layout, and it paid for itself immediately. On level 0 the collision region comes out 6216960 bytes, from 2615232 to the first moby class at 8832192. Collision's own header declares a payload of 903,248. So roughly 6.2 MB sits between the collision header and the first moby class, and almost none of it is collision. The successor rule is correct -- a region does end where the next one begins -- but "the next" is not yet known there. collision..moby is really collision + <something unnamed> .. moby. The name is wrong, not the bound. Candidates for the space, rough order of likelihood: moby and tie model animation data, which is what moby_anim would need, then volumes, then per-class runtime structures. Tfrag texture texels are already placed and sit earlier in the lump. Worth resolving before starting moby_anim, since that format is the most likely tenant. Until then, any probe reading between the collision header and the first moby class is reading something the region table does not describe.
3.3 KiB
core_data region bounds
How a level's core_data lump divides up, and how each region is bounded.
The rule
A region's end is the next region's start, never core_data.len(). The
last region in a layout is the exception, and when its successor is unknown the
end is None rather than a guess.
This exists because region bounds were being re-derived per format during probing, usually by running from one known offset to the next with the last span running to the end of the lump. On level 0 that made the final shrub class a 925,008-byte span absorbing most of the lump's tail. Every aggregate computed over it -- record counts, value distributions, "this data looks random" -- was silently wrong, and nothing errored.
gc_formats::regions::core_layout computes these once. Callers use it rather
than inventing their own.
Layout
| region | start | end |
|---|---|---|
tfrags |
0 | occlusion |
occlusion |
occlusion |
sky |
sky |
sky |
collision |
collision |
collision |
first moby class |
moby |
first moby | first tie class |
tie |
first tie | first shrub class |
shrub |
first shrub | unknown |
Class regions start at the lowest non-zero geometry offset in their class table. A zero entry means absent, not position zero -- the same trap the occlusion and collision headers each fell into separately.
Not every level has every region: level 10 has no occlusion and no shrub.
Open: where shrub ends
The offset ending the shrub region is not in the core index.
Texture texels do not bound it. They sit before moby, not after shrub: on level 0 the texel range is 3539328..5326208 while the last shrub class starts at 16044288, leaving ~925 KB of real, non-zero data after the last shrub class that nothing yet accounts for.
core_layout reports end: None for shrub on the 24 levels that have one, and
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
Adding the region table to gc-extract probe made the gap visible
immediately, which is the point of printing it.
On level 0:
collision 2615232 .. 8832192 6216960 bytes
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.
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.
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.