: Even if it's a memory image of sorts, if the data only requires 32-bit
: precision, wouldn't it be feasible to store it in a compact 32+32 format
: on the disc, and have the CPU (or perhaps GPU, really) unpack the data as
: it comes in? In addition to potentially saving disc space, I wouldn't be
: shocked if it reduced load times when there are large contiguous areas of
: data.

: Between the parallel processing capabilities of this hardware and the fact
: that these memory accesses would be highly patterned on a 68GB/s, I'd
: expect the HDD to be the bottleneck.

And texture data resides in the resource section of a map file, which isn't baked to be mapped to a specific memory address (and I'm not exactly sure what made you bring them up).

See "Cache files: Optimized resources for the Xbox" in http://nikon.bungie.org/misc/gdc2005_mnoguchi/

"When we build the final resource file, which we call a cache file, we simply dump all loaded tags into a giant buffer and write that out to a single file. At runtime, we just need to read that file into a fixed address before we start the level"

The tags, which are data structures, are where you would find pointers. Eg, the root of a render_model tag has a tag-block for the model's markers. That tag block, as of Halo4's tag system implementation, contains two pointers plus a 32-bit 'count' for the number of elements in the block. One of those pointers is the (fixed) memory address of the first element of that block (ie, the first marker).