Call of Duty 4: FastFile Format

From COD Modding & Mapping Wiki
Revision as of 17:24, 4 November 2009 by Daevius (talk | contribs)
Jump to navigation Jump to search

*** 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:

  1. $victorybackdrop - mile_high_victory_screen.iwi (699,092 bytes)
  2. $defeatbackdrop - (none)
  3. $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  separator

-----------  [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)