Call of Duty 4: FastFile Format: Difference between revisions
Jump to navigation
Jump to search
Line 31: | Line 31: | ||
<pre> | <pre> | ||
----------- [start of header] | ----------- [start of file and header] | ||
71 03 00 00 decompressed filesize - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925) | 71 03 00 00 decompressed filesize - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925) | ||
Line 72: | Line 72: | ||
=== Types === | === Types === | ||
* | * 00 00 00 01 - physpreset | ||
* | * 00 00 00 02 - xanim | ||
* | * 00 00 00 03 - xmodel | ||
* | * 00 00 00 04 - material | ||
* | * 00 00 00 05 - shader / techset | ||
* | * 00 00 00 06 - image? | ||
* | * 00 00 00 0B - map_ents (d3dbsp) | ||
* | * 00 00 00 0C - related to col_map_mp (d3dbsp) | ||
* | * 00 00 00 0E - related to game_map_mp (d3dbsp) | ||
* | * 00 00 00 10 - related to col_map_mp / gfx_map (d3dbsp) | ||
* | * 00 00 00 13 - font | ||
* | * 00 00 00 14 - menu | ||
* | * 00 00 00 16 - localized string asset | ||
* | * 00 00 00 17 - physpreset?? | ||
* | * 00 00 00 19 - fx | ||
* | * 00 00 00 1F - string / raw file / fastfile name | ||
* | * 00 00 00 20 - stringtable (comma separated list) | ||
Line 167: | Line 167: | ||
Third byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination) | Third byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination) | ||
Fourth byte either 0x00 or 0x01. Can be a length or a bool. | Fourth byte either 0x00 or 0x01. Can be a length or a bool. | ||
Then 0x10 bytes of more header. | Then 0x10 bytes of more header. | ||
FF FF FF FF Separator | FF FF FF FF Separator | ||
00 When fourth byte is 01, there's a 0x00 following? | |||
00 When fourth byte is 01, there's a 0x00 following? | |||
Then there's garbage (0xFF) and some shorts it looks of length in the second byte. | Then there's garbage (0xFF) and some shorts it looks of length in the second byte. | ||
Then more information... | Then more information... | ||
Line 185: | Line 180: | ||
00 00 00 00 0x90 times 0x00 | 00 00 00 00 0x90 times 0x00 | ||
Then filename (0x00 termination) | Then filename (0x00 termination) | ||
Line 198: | Line 192: | ||
00 00 00 00 | 00 00 00 00 | ||
FF FF FF FF | FF FF FF FF | ||
Then filename (0x00 termination) | |||
Then filename (0x00 termination) | |||
00 Another termination, of the FF file? Or padding? | 00 Another termination, of the FF file? Or padding? | ||
Revision as of 17:21, 4 November 2009
*** Article and investigation in early progress ***
Header
- Byte 0-3: decompressed fastfile size minus 44 (0x2C)
- Byte 4-7: about the total size of referenced data, e.g. the required memory for IWI textures if material files are in the ff
- Byte 8-11: unknown, might be a flag
- Byte 12-43: unknown
- Byte 44-47: equal to number of entries in "1st index" and amount of (model tag/joint/notetrack) strings (times 4 for index length)
- Byte 48-51: separator? (FF FF FF FF)
- Byte 52-55: number of records* ("2nd index", times 8 for index length)
- Byte 56-63: separator? (FF FF FF FF FF FF FF FF)
- Byte 64-x: string list (xmodelsurfs?) --> not always, depends on the content (required offsets are in the FF header)*
* under re-investigation
Example: mp_backlot_load.ff
Contains:
- 2x shaders
- 3x materials
- (1x fastfile name)
Materials:
- $victorybackdrop - mile_high_victory_screen.iwi (699,092 bytes)
- $defeatbackdrop - (none)
- $levelbriefing - loadscreen_mp_backlot.iwi (524,316 bytes)
----------- [start of file and header] 71 03 00 00 decompressed filesize - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925) B8 AA 12 00 size of both IWIs the materials in FF point to - 56 (2x28, 28 bytes = IWI header) 0x12AAB8 = 1,223,352 699,092 + 524,316 = 1,223,408 difference: 56 A4 00 00 00 might be a flag 00 00 00 00 ... empty? E5 00 00 00 unknown 00 00 00 00 ... empty? ----------- [end of header] (44 bytes), [start of index] 00 00 00 00 ... empty? 06 00 00 00 number of records in index (6) FF FF FF FF separator 05 00 00 00 FF FF FF FF 1st: shader 05 00 00 00 FF FF FF FF 2nd: shader 04 00 00 00 FF FF FF FF 3rd: material 04 00 00 00 FF FF FF FF 4th: material 04 00 00 00 FF FF FF FF 5th: material 1F 00 00 00 FF FF FF FF 6th: ff name FF FF FF FF 00 00 00 00 separator / termination ----------- [end of index]
Index
4 byte identifier (fastfile entry type), 4 byte offset (FF FF FF FF = -1, meaning right after the previous block?)
Separator (FF FF FF FF) after last 4-byte couple + 00 00 00 00 ?
Types
- 00 00 00 01 - physpreset
- 00 00 00 02 - xanim
- 00 00 00 03 - xmodel
- 00 00 00 04 - material
- 00 00 00 05 - shader / techset
- 00 00 00 06 - image?
- 00 00 00 0B - map_ents (d3dbsp)
- 00 00 00 0C - related to col_map_mp (d3dbsp)
- 00 00 00 0E - related to game_map_mp (d3dbsp)
- 00 00 00 10 - related to col_map_mp / gfx_map (d3dbsp)
- 00 00 00 13 - font
- 00 00 00 14 - menu
- 00 00 00 16 - localized string asset
- 00 00 00 17 - physpreset??
- 00 00 00 19 - fx
- 00 00 00 1F - string / raw file / fastfile name
- 00 00 00 20 - stringtable (comma separated list)
Content
00 00 00 04
FF FF FF FF [start separation] 00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's. First byte is so far always 0x00 (perhaps it's a short together with the second byte). Second byte so far either 0x2B or 0x00, I think this is a length. Third byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination) Fourth byte either 0x00 or 0x01. Can be a length or a bool. Then 0x10 bytes of more header. FF FF FF FF Separator 00 When fourth byte is 01, there's a 0x00 following? Then there's garbage (0xFF) and some shorts it looks of length in the second byte. Then more information... FF FF FF FF [end separation]
00 00 00 05
FF FF FF FF [start separation] 00 00 00 00 0x90 times 0x00 Then filename (0x00 termination) FF FF FF FF [end separation]
00 00 00 1F
Often at the end of the FF file.
FF FF FF FF [start separation] 00 00 00 00 FF FF FF FF Then filename (0x00 termination) 00 Another termination, of the FF file? Or padding? [end of file]
--CoDEmanX 01:28, 4 November 2009 (UTC)
--Daevius 23:59, 1 November 2009 (UTC)