Difference between revisions of "Sims 3:DBPF"
| Line 30: | Line 30: | ||
<!--I found this isn't true. I know for sure the last dword can not come from the header - when my code tried it, the game didn't recognize the index. For obvious reasons the same probably goes for the offset. And realistically both sizes as well. Only the first 4 (3?) fields could realistically come from the header. (Tiger)--> | <!--I found this isn't true. I know for sure the last dword can not come from the header - when my code tried it, the game didn't recognize the index. For obvious reasons the same probably goes for the offset. And realistically both sizes as well. Only the first 4 (3?) fields could realistically come from the header. (Tiger)--> | ||
<!-- Agreed that the only observed values are the first three (four in Spore) fields but the rule holds true that far... (PLJ) --> | <!-- Agreed that the only observed values are the first three (four in Spore) fields but the rule holds true that far... (PLJ) --> | ||
| − | <!-- I know it looks nice and clean to say it extends all the way, and I wanted to say that as soon as I realized it was just a bitfield as well. But I have observed reaction to at least the 8th bit (Should be compression following the the rule) and the game didn't try to load anything out of the file like that. | + | <!-- I know it looks nice and clean to say it extends all the way, and I wanted to say that as soon as I realized it was just a bitfield as well. But I have observed reaction to at least the 8th bit (Should be compression following the the rule) and the game didn't try to load anything out of the file like that. (Tiger) --> |
{| class="wikitable" border="1" | {| class="wikitable" border="1" | ||
|- | |- | ||
Revision as of 10:01, 21 June 2009
Package Header
96 bytes: "standard" DBPF 2.0 format; DBBF not seen; DBPP is encrypted.
DWORD magic ;; "DBPF" DWORD major ;; 2 DWORD minor ;; 0 BYTE[24] unknown1 DWORD ;; number of index entries - if zero, size and position also zero BYTE[4] unknown2 DWORD ;; size of index on disk in bytes BYTE[12] unknown3 DWORD index_version ;; always 3 DWORD ;; position of index (absolute) BYTE[28] unknown4
The Index
If position is not zero, at that position:
DWORD ;; Index type
The count of set bits in the index type is the number of additional DWORD entries in index header:
DWORD[(for each bit in Index type)]
The number of DWORDs in an actual index entry is 8. The entry is stored in two parts - the index header and then the entry on disk. The header provides the data that is constant to all entries, essentially a kind of compression.
- For each index entry on disk:
DWORD[(8 - number of bits in Index type)]
Each DWORD in an actual index entry can either come from the header or from the index entry on disk, depending on the bits set in the index type. The order of the DWORDs in an index entry is (with matching bit number):
| 0 | ResourceType | |
| 1 | ResourceGroup | |
| 2 | InstanceHi | |
| 3 | InstanceLo | |
| 4 | Chunkoffset | Absolute location in package |
| 5 | Filesize (lo 31bits) , Unknown1 (hi bit) | Length of data in package |
| 6 | Memsize | Length of uncompressed data |
| 7 | Compressed(lo WORD) , Unknown2(hi WORD) | Compressed is 0x0000 or 0xFFFF |
(That's a total of 32 bytes per entry.)
(Possibly confusingly, in my implementation, I actually store the index type along with the entries - keeps the data structure simpler..!)
Chunk Compression
TBC
Above documented by Peter Jones
Based on Spore package format
