18,700
edits
OBD:Instance file format: Difference between revisions
m
wording
m (→Unnamed and empty resources: unnamed non-empty orphans) |
m (wording) |
||
| Line 11: | Line 11: | ||
{{TOClimit}} | {{TOClimit}} | ||
==Backwards and garbage data== | ==Backwards and garbage data== | ||
During development, Oni had an [[level0_Tools|in-game editor]] which presented a GUI for manipulating AIs, particles, etc. in a level. When a developer saved his work, the contents of the level, stored in RAM, were | During development, Oni had an [[level0_Tools|in-game editor]] which presented a GUI for manipulating AIs, particles, etc. in a level. When a developer saved his work, the contents of the level, stored in his PC's RAM, were flushed directly to disk. Thus the structure of the .dat/.raw/.sep files reflects the way in which Bungie West chose to store levels in memory. So when we read the data in the files with a hex editor, we can see eccentricities such as blank space (coming from unused fields and byte-alignment padding) and garbage data (such as now-meaningless pointer values). [[OBD:Raw_and_separate_file_formats#Gaps|These gaps]] between data chunks add up to about 25 MB for the whole game. | ||
Additionally, because the levels were built on Intel-based machines, which use a little-endian architecture, sequences of bytes which represent numbers were written from least-significant to most-significant byte. [[wikipedia:FourCC|FourCCs]] in the data are stored "backwards", such as "13RV" which is meant to be read "VR31", because Bungie defined those four bytes as a 32-bit integer, not a string, causing them to be written to disk in little-endian order. | Additionally, because the levels were built on Intel-based machines, which use a little-endian architecture, sequences of bytes which represent numbers were written from least-significant to most-significant byte. [[wikipedia:FourCC|FourCCs]] in the data are stored "backwards", such as "13RV" which is meant to be read "VR31", because Bungie defined those four bytes as a 32-bit integer, not a string, causing them to be written to disk in little-endian order. | ||
| Line 74: | Line 74: | ||
:0x'''04''' 00 00 00 - never used; appears to mean "big-endian" data | :0x'''04''' 00 00 00 - never used; appears to mean "big-endian" data | ||
:0x'''08''' 00 00 00 - shared | :0x'''08''' 00 00 00 - shared | ||
The following two bits systematically occur in the original .dat files but are ignored by the engine | The following two bits systematically occur in the original .dat files but are ignored by the engine: | ||
:0x00 00 '''10''' 00 - | :0x00 00 '''10''' 00 - non-empty | ||
:0x00 00 '''20''' 00 - | :0x00 00 '''20''' 00 - named | ||
}} | }} | ||
|} | |} | ||
| Line 85: | Line 85: | ||
You'll notice that the level file header lists fewer names (7,124) than instances (9,347). That's because there are 3 types of instance: | You'll notice that the level file header lists fewer names (7,124) than instances (9,347). That's because there are 3 types of instance: | ||
*Unnamed and not empty - they are only referenced by other instances in the same file, generally as child data (e.g., 3D geometry elements like ABNA are "contained" by AKEV, a level's environment). | *Unnamed and not empty - they are only referenced by other instances in the same file, generally as child data (e.g., 3D geometry elements like ABNA are "contained" by AKEV, a level's environment). | ||
*:In | *:In vanilla Oni .dats there are some rare occurrences of unnamed non-empty ''orphan'' instances (e.g., [[OBD:File_types/Named#TRCM|TRCM]]). These are a form of garbage and are discarded by OniSplit when unpacking a level. | ||
*Named and not empty - they can be referenced by other instances in any file and the engine can use their name or template tag to find them. | *Named and not empty - they can be referenced by other instances in any file and the engine can use their name or template tag to find them. | ||
*Named and empty - "empty" instances are used in level-specific instance files (i.e. not in level0_Final.dat) to associate an instance ID with a name. For every empty resource, there's another one with a matching name in level0_Final.dat that has data in it. The empty resource in the instance file is (usually) looked up by ID, then the engine searches all the loaded files for a non-empty instance with the same name, causing it to find the actual file in the global data in level0_Final.dat. | *Named and empty - "empty" instances are used in level-specific instance files (i.e. not in level0_Final.dat) to associate an instance ID with a name. For every empty resource, there's another one with a matching name in level0_Final.dat that has data in it. The empty resource in the instance file is (usually) looked up by ID, then the engine searches all the loaded files for a non-empty instance with the same name, causing it to find the actual file in the global data in level0_Final.dat. | ||