Call of Duty 4: FastFile Format: Difference between revisions

From COD Modding & Mapping Wiki
Jump to navigation Jump to search
mNo edit summary
No edit summary
Line 155: Line 155:


-->
-->
== Content ==
=== 00 00 00 04 ===
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...
Fourth byte either 0x00 or 0x01. Can be a length or a bool.
Then 0x10 bytes of more header.
FF FF FF FF
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...


--[[User:CoDEmanX|CoDEmanX]] 01:28, 4 November 2009 (UTC)
--[[User:CoDEmanX|CoDEmanX]] 01:28, 4 November 2009 (UTC)

Revision as of 15:50, 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:

  1. $victorybackdrop - mile_high_victory_screen.iwi (699,092 bytes)
  2. $defeatbackdrop - (none)
  3. $levelbriefing - loadscreen_mp_backlot.iwi (524,316 bytes)
-----------  [start of 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

  • 01 00 00 00 - physpreset
  • 02 00 00 00 - xanim
  • 03 00 00 00 - xmodel
  • 04 00 00 00 - material
  • 05 00 00 00 - shader / techset
  • 06 00 00 00 - image?
  • 0B 00 00 00 - map_ents (d3dbsp)
  • 0C 00 00 00 - related to col_map_mp (d3dbsp)
  • 0E 00 00 00 - related to game_map_mp (d3dbsp)
  • 10 00 00 00 - related to col_map_mp / gfx_map (d3dbsp)
  • 13 00 00 00 - font
  • 14 00 00 00 - menu
  • 16 00 00 00 - localized string asset
  • 17 00 00 00 - physpreset??
  • 19 00 00 00 - fx
  • 1F 00 00 00 - string / raw file / fastfile name
  • 20 00 00 00 - stringtable (comma separated list)


Content

00 00 00 04

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... Fourth byte either 0x00 or 0x01. Can be a length or a bool.

Then 0x10 bytes of more header.

FF FF FF FF

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...

--CoDEmanX 01:28, 4 November 2009 (UTC)

--Daevius 23:59, 1 November 2009 (UTC)