Jump to content

OBD:Instance file format: Difference between revisions

(→‎Backwards and garbage data: let's cut to the chase)
Line 9: Line 9:


==Backwards and garbage data==
==Backwards and garbage data==
During development, Oni had in-game editing tools. These tools presented a GUI for things like placing AIs and setting their attributes, editing particles, etc. When a developer saved his work, the contents of the level, stored in RAM, were written directly to disk. The structure of the .dat/.raw/.sep files reflects the way in which Bungie West chose to store levels in memory, and thus when when we read the data in the files with a hex editor, we can see eccentricities such as blank space and garbage data that represented various RAM contents from the developer's PC such as padding and pointers.
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 written directly to disk. The structure of the .dat/.raw/.sep files reflects the way in which Bungie West chose to store levels in memory, and thus when when we read the data in the files with a hex editor, we can see eccentricities such as blank space and garbage data that represent various RAM contents from the developer's PC such as padding and pointers.


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, which is backwards from how we typically write numbers. When Macs, which were big-endian at the time due to their PowerPC architecture, would read these files, they then had to flip each sequence of bytes in memory before they could be understood.
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.
 
An exception to this backwards-writing rule is when strings of ASCII characters were written to disk. These are not numbers and thus are not subject to endianness, so they retain their left-to-right order. However, four-character codes in the data are backwards, such as "13RV", which is meant to be read "VR31". That's because Oni stored them as a 32-bit integer, not a string, and thus they were written to disk in little-endian order.


==File limits==
==File limits==