Call of Duty 4: d3dbsp: Difference between revisions
(New page: The .d3dbsp structure, Call of Duty 4's variant on the well-known BSP format, is rather difficult to decipher. Since it's a binary file you can't simply read it. A hexadecimal editor is th...) |
No edit summary |
||
| Line 1: | Line 1: | ||
The .d3dbsp structure, Call of Duty 4's variant on the well-known BSP format, is rather difficult to decipher. Since it's a binary file you can't simply read it. A hexadecimal editor is the best tool in this case. | The .d3dbsp structure, Call of Duty 4's variant on the well-known BSP format, is rather difficult to decipher. Since it's a binary file you can't simply read it. A hexadecimal editor is the best tool in this case. | ||
I am still deciphering it myself, I will post anything I happen to get known of regarding the file format. | I am still deciphering it myself, I will post anything I happen to get known of regarding the file format. | ||
Be sure to read http://www.geocities.com/cofrdrbob/bspformat.html and http://en.wikipedia.org/wiki/BSP_(file_extension) before you even try to decipher it. Knowing what the technique is that BSP formatted maps use, could be handy as well. | Be sure to read [http://www.geocities.com/cofrdrbob/bspformat.html here] and [http://en.wikipedia.org/wiki/BSP_(file_extension) here] before you even try to decipher it. Knowing what the technique is that BSP formatted maps use, could be handy as well. | ||
Every number ending with an 'h' indicates its a number using the hexadecimal count system. For other numbers one can assume the decimal count system is used. | Every number ending with an 'h' indicates its a number using the hexadecimal count system. For other numbers one can assume the decimal count system is used. | ||
Revision as of 00:13, 16 October 2008
The .d3dbsp structure, Call of Duty 4's variant on the well-known BSP format, is rather difficult to decipher. Since it's a binary file you can't simply read it. A hexadecimal editor is the best tool in this case.
I am still deciphering it myself, I will post anything I happen to get known of regarding the file format.
Be sure to read here and here before you even try to decipher it. Knowing what the technique is that BSP formatted maps use, could be handy as well.
Every number ending with an 'h' indicates its a number using the hexadecimal count system. For other numbers one can assume the decimal count system is used.
Header
The file starts with 3 DWORDS: the header 'IBSP' indicating this is a BSP file originally designed by ID software, the version number 24 (16h) (the one CoD4 uses (which is different from CoD2)) and the number of lumps (varies from 37 (a real map) 24 (18h) or 23 (17h) if you don't compile light (test maps)).
Then there is an array of the length the 3rd DWORD in the header describes, filled with DWORD pairs, indicating the lump's offset and length respectively. The offset seems to be redundant, since each lump is connected and one can determine the offset by taking the previous lump's offset + length. The first lump's offset is (3 + ((number of lumps) * 2) * 4).
Note: there can be a difference of number of lumps per map. If a map has a leak (no solid skybox or not everything is IN the skybox) the bsp only has 24 lumps (or even 23 if light is not compiled). The bsp description yet only supports the 37-lumps version (a valid map).
Lump[0] texture filename + flags
Texture information is 72 bytes long per texture. The first 64 bytes are used for the texture name. Then we have an DWORD for flags, and another DWORD for content flags.
Lump[29] entities
The entities lump is readable and stored the same way I describe in the .MAP file structure.
