5,389
edits
OBD:Instance file format: Difference between revisions
→Backwards and garbage data: mention/link about gaps
(→Instance descriptors: Filling in from ssg.oni2.net ; somebody please confirm that those bits are ignored.) |
(→Backwards and garbage data: mention/link about gaps) |
||
| 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 written 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 and garbage data that represent 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. 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 and garbage data that represent various RAM contents from the developer's PC such as padding and pointers. Somehow, although the level resource files are called '''level#_Final''', they were never truly finalized and packed together space-efficiently. [[OBD:Raw_and_separate_file_formats#Gaps|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. | ||