18,700
edits
OBD:Instance file format: Difference between revisions
m
→Data table: wording
(→Header: wording) |
m (→Data table: wording) |
||
| Line 128: | Line 128: | ||
==Data table== | ==Data table== | ||
The data table stores all the instance data. We peeked at this before when we looked at the instance descriptor for SUBTsubtitles. | The data table stores all the instance data (or points to its actual location in a raw/separate file). We peeked at this before when we looked at the instance descriptor for SUBTsubtitles. | ||
The start of each instance's record, the ID number, is always 32 byte-aligned. Thus, even though the template descriptors ended at 0x03BC9C, there are four empty bytes here so that the data table can begin at 0x03BCA0, which divides evenly by 32. This alignment also means that the instance-specific data will always be found at an offset like 0x0008, 0x0028, 0x0148 etc. | The start of each instance's record, the ID number, is always 32 byte-aligned. Thus, even though the template descriptors ended at 0x03BC9C, there are four empty bytes here so that the data table can begin at 0x03BCA0, which divides evenly by 32. This alignment also means that the instance-specific data will always be found at an offset like 0x0008, 0x0028, 0x0148 etc. | ||
| Line 143: | Line 143: | ||
The '''instance's ID''' is computed as: | The '''instance's ID''' is computed as: | ||
(instance_descriptor_index << 8) <nowiki>|</nowiki> 1 | (instance_descriptor_index << 8) <nowiki>|</nowiki> 1 | ||
The 1 allows the engine to know which IDs have already been converted to pointers ( | The 1 allows the engine to know which IDs have already been converted to pointers (an instance pointer will always be 8 byte-aligned, so it will never have the zero bit already set). | ||
The '''file ID''' is computed from the name of the instance file. For "_Final" files the file ID is computed as: | The '''file ID''' is computed from the name of the instance file. For "_Final" files the file ID is computed as: | ||
| Line 149: | Line 149: | ||
Again, the 1 allows the engine to know which file IDs have already been converted to pointers. | Again, the 1 allows the engine to know which file IDs have already been converted to pointers. | ||
As you can see, after the header, the size of the actual instance data can be almost anything. Thus, we cannot compute the end of the data table in any simple way. That's why the instance file header explicitly gives us the address of the name table. | As you can see, after the header, the size of the actual instance data can be almost anything. Thus, we cannot compute the end of the data table in any simple way. That's why the instance file header explicitly gives us the address of the name table that comes after this. | ||
By the way, how do we know which resource's data we're looking at in the data table? Let's look at the very first data, at 0x03BCA0. Noting that the first two numbers, the instance and file ID, do not count as data, there must be a resource with a data offset of 0x08, the lowest offset possible into the table. We can find this offset listed right at the start of the instance descriptor array: | By the way, how do we know which resource's data we're looking at in the data table? Let's look at the very first data, at 0x03BCA0. Noting that the first two numbers, the instance and file ID, do not count as data, there must be a resource with a data offset of 0x08, the lowest offset possible into the table. We can find this offset listed right at the start of the instance descriptor array: | ||