COD Modding & Mapping Wiki - User contributions [en]

Call of Duty 4: FastFile Format

2009-12-08T23:15:43Z

Daevius: /* 00 00 00 06 (image) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The data block types (also called "index identifier") are written in big endian in this article, e.g. 00 00 00 1F is actually 1F 00 00 00 in ff, although ints and floats in the examples are kept little endian!

The global file layout starts with a header. After which you get a string list (model tag names, animation notetracks, maybe more; not always present). Followed by an index list. This list gives information about the rest of the file, which is a concatenation of compiled files (reinterpreted and linked data generated from source files like d3dbsp and stringtables, hereinafter referred to as data blocks).

* Header
* String list index
* String list
* Data block index
* Data blocks

Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== Header ==

''(Note: not up to date and not generalized)''

*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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> under re-investigation 

=== Example: smallest possible fastfile (mod.ff) ===

<pre>
29 00 00 00 decompressed fastfile size minus 44
00 00 00 00
1C 00 00 00 unknown

00 00 00 00 00 00 00 00 00 00 00 00

0D 00 00 00 data size in memory (?)

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

01 00 00 00 one index entry

FF FF FF FF 1F 00 00 00 a rawfile

FF FF FF FF index end

FF FF FF FF start separator
00 00 00 00 rawfile length (empty, no errors occured during compilation)
FF FF FF FF separator
6D 6F 64 00 fastfile name as rawfile name
00 rawfile string (empty)
</pre>

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

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

06 00 00 00 Number of records in index (6)

FF FF FF FF 05 00 00 00 1st: shader
FF FF FF FF 05 00 00 00 2nd: shader
FF FF FF FF 04 00 00 00 3rd: material
FF FF FF FF 04 00 00 00 4th: material
FF FF FF FF 04 00 00 00 5th: material
FF FF FF FF 1F 00 00 00 6th: rawfile

FF FF FF FF end separator (the following FF FF FF FF is the start seperator of the next data block!)

----------- [end of index]
</pre>

== Index ==

Starts with an int telling the number of dword couples. Such a couple is composed of 2 ints:

4 byte offset (FF FF FF FF = -1, meaning right after the previous block?) 
4 byte identifier (data block type)

Separator (FF FF FF FF) after last couple

=== 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 07 - soundalias (+audio data)
* 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

Since there is a FF FF FF FF separator in front of every block and none at the very end (after last 1F-block), we can assume that each block has a start separation and no end separation. Thus, any FF FF FF FFs you find after data blocks are actually the start separators of the next block. This means the index end separator is rather FFFFFFFF than FFFFFFFFFFFFFFFF!

=== 00 00 00 04 (material) ===

<pre>
----------- [block start]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [block end]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [block start]

36 pointers (0x90 bytes) (bytes 0x19 up to 0x22 say if we get any content at all?)
?? ?? .. 00 Then techset file name (0x00 termination) if pointer is 0xFFFFFFFF?

----------- [start of shader pack]

pointer
1 dword of some character-length options / flags?
3 pointers
1 dword of some character-length sizes
FF FF FF FF Separator
0x64 bytes of some short length options / flags? If the second pointer above is 0xFFFFFFFF

----------- [start of shader]

pointer, if not 0xFFFFFFFF, no filename is further on
pointer, often 00 00 00 00
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag?
?? ?? .. 00 String if first pointer is 0xFFFFFFFF, 0x00 terminated (name of shader source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff' (technique commands?)
41 10 AB A0 which ends with this (always?)
?? ?? .. 00 String, 0x00 terminated (technique file name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [block end]
</pre>

=== 00 00 00 06 (image) ===

Stores some information about the specified IWI in fastfile. Does not include the actual image data.
Length is 52 bytes + IWI name (+1 for string termination).

<pre>
----------- [block start]

03 00 00 00
FE FF FF FF separator?
00 00 00 00
00 00 00 00

70 55 01 00 IWI size minus 28 (0x1C)
70 55 01 00 same

00 01 00 01
01 00 03 00
FF FF FF FF separator?

73 70 .. 00 IWI name without file extension (string + termination, variable size)

00 00 00 01
00 01 01 00

44 58 54 35 00 00 00 00 fixed size char[] for type? (here: DXT5....)

----------- [block end]
</pre>

=== 00 00 00 16 (localized string asset) ===

A localized string asset consists of an alias name and a translated string. During compilation, it takes the given alias name (REFERENCE) from *.str file and prepands the *.str file's name in upper-case plus an underscore. Example:

'''example.str'''
<pre>VERSION "1"
CONFIG "C:\trees\cod3\cod3\bin\StringEd.cfg"
FILENOTES ""
//--------------------------------

REFERENCE MARINES_NAME
LANG_ENGLISH "US Airforce"

//--------------------------------
ENDMARKER</pre>

'''mod.ff'''
<pre>
ÿÿÿÿ
ÿÿÿÿ
EXAMPLE_MARINES_NAME.
US Airforce.
</pre>

Length is 8 bytes + string sizes (string count = 0-2, depends on the first two ints).

<pre>
----------- [block start]

FF FF FF FF either pointer or FFFFFFFF if the string wasn't used before
FF FF FF FF same. If two pointers are used here, then no strings will follow.
55 53 .. 00 alias name for the localized
53 54 .. 00 actual localized string

----------- [block end]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [block start]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [block end OR even end of file]
</pre>

=== 00 00 00 20 (stringtable) ===

A compiled stringtable (comma separated list, *.csv). Even values are stored as strings.

<pre>
----------- [block start]

05 00 00 00 (int) columns
02 00 00 00 (int) rows

FF FF FF FF separator
?? ?? .. 00 filename (path/*.csv) + string termination (0x00)

----------- [table cell description]

?? ?? ?? ?? columns * rows integers (5 * 2 * 4 = 40 bytes in total, 5 * 2 = 10 cells)
FF FF FF FF - if the string wasn't used before and follows after the cell description
?? ?? ?? 4? - if an identical string was already used (in another csv). It is some kind of memory offset (pointer). Base address calculation not figured out yet (0x40000072 ?)

----------- [cell content / strings]

?? ?? .. 00 string + termination (0x00)
Number of strings = amount of FF FF FF FFs in table cell description

----------- [block end]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 01:45, 8 December 2009 (UTC)

--[[User:Daevius|Daevius]] 23:00, 8 December 2009 (UTC)

[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-12-08T23:15:32Z

Daevius: /* 00 00 00 16 (localized string asset) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The data block types (also called "index identifier") are written in big endian in this article, e.g. 00 00 00 1F is actually 1F 00 00 00 in ff, although ints and floats in the examples are kept little endian!

The global file layout starts with a header. After which you get a string list (model tag names, animation notetracks, maybe more; not always present). Followed by an index list. This list gives information about the rest of the file, which is a concatenation of compiled files (reinterpreted and linked data generated from source files like d3dbsp and stringtables, hereinafter referred to as data blocks).

* Header
* String list index
* String list
* Data block index
* Data blocks

Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== Header ==

''(Note: not up to date and not generalized)''

*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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> under re-investigation 

=== Example: smallest possible fastfile (mod.ff) ===

<pre>
29 00 00 00 decompressed fastfile size minus 44
00 00 00 00
1C 00 00 00 unknown

00 00 00 00 00 00 00 00 00 00 00 00

0D 00 00 00 data size in memory (?)

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

01 00 00 00 one index entry

FF FF FF FF 1F 00 00 00 a rawfile

FF FF FF FF index end

FF FF FF FF start separator
00 00 00 00 rawfile length (empty, no errors occured during compilation)
FF FF FF FF separator
6D 6F 64 00 fastfile name as rawfile name
00 rawfile string (empty)
</pre>

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

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

06 00 00 00 Number of records in index (6)

FF FF FF FF 05 00 00 00 1st: shader
FF FF FF FF 05 00 00 00 2nd: shader
FF FF FF FF 04 00 00 00 3rd: material
FF FF FF FF 04 00 00 00 4th: material
FF FF FF FF 04 00 00 00 5th: material
FF FF FF FF 1F 00 00 00 6th: rawfile

FF FF FF FF end separator (the following FF FF FF FF is the start seperator of the next data block!)

----------- [end of index]
</pre>

== Index ==

Starts with an int telling the number of dword couples. Such a couple is composed of 2 ints:

4 byte offset (FF FF FF FF = -1, meaning right after the previous block?) 
4 byte identifier (data block type)

Separator (FF FF FF FF) after last couple

=== 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 07 - soundalias (+audio data)
* 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

Since there is a FF FF FF FF separator in front of every block and none at the very end (after last 1F-block), we can assume that each block has a start separation and no end separation. Thus, any FF FF FF FFs you find after data blocks are actually the start separators of the next block. This means the index end separator is rather FFFFFFFF than FFFFFFFFFFFFFFFF!

=== 00 00 00 04 (material) ===

<pre>
----------- [block start]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [block end]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [block start]

36 pointers (0x90 bytes) (bytes 0x19 up to 0x22 say if we get any content at all?)
?? ?? .. 00 Then techset file name (0x00 termination) if pointer is 0xFFFFFFFF?

----------- [start of shader pack]

pointer
1 dword of some character-length options / flags?
3 pointers
1 dword of some character-length sizes
FF FF FF FF Separator
0x64 bytes of some short length options / flags? If the second pointer above is 0xFFFFFFFF

----------- [start of shader]

pointer, if not 0xFFFFFFFF, no filename is further on
pointer, often 00 00 00 00
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag?
?? ?? .. 00 String if first pointer is 0xFFFFFFFF, 0x00 terminated (name of shader source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff' (technique commands?)
41 10 AB A0 which ends with this (always?)
?? ?? .. 00 String, 0x00 terminated (technique file name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [block end]
</pre>

=== 00 00 00 06 (image) ===

Stores some information about the specified IWI in fastfile. Does not include the actual image data.
Length is 52 bytes + IWI name (+1 for string termination).

<pre>
----------- [block start]
Note: obviously no start separator
03 00 00 00
FE FF FF FF separator?
00 00 00 00
00 00 00 00

70 55 01 00 IWI size minus 28 (0x1C)
70 55 01 00 same

00 01 00 01
01 00 03 00
FF FF FF FF separator?

73 70 .. 00 IWI name without file extension (string + termination, variable size)

00 00 00 01
00 01 01 00

44 58 54 35 00 00 00 00 fixed size char[] for type? (here: DXT5....)

----------- [block end]
</pre>

=== 00 00 00 16 (localized string asset) ===

A localized string asset consists of an alias name and a translated string. During compilation, it takes the given alias name (REFERENCE) from *.str file and prepands the *.str file's name in upper-case plus an underscore. Example:

'''example.str'''
<pre>VERSION "1"
CONFIG "C:\trees\cod3\cod3\bin\StringEd.cfg"
FILENOTES ""
//--------------------------------

REFERENCE MARINES_NAME
LANG_ENGLISH "US Airforce"

//--------------------------------
ENDMARKER</pre>

'''mod.ff'''
<pre>
ÿÿÿÿ
ÿÿÿÿ
EXAMPLE_MARINES_NAME.
US Airforce.
</pre>

Length is 8 bytes + string sizes (string count = 0-2, depends on the first two ints).

<pre>
----------- [block start]

FF FF FF FF either pointer or FFFFFFFF if the string wasn't used before
FF FF FF FF same. If two pointers are used here, then no strings will follow.
55 53 .. 00 alias name for the localized
53 54 .. 00 actual localized string

----------- [block end]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [block start]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [block end OR even end of file]
</pre>

=== 00 00 00 20 (stringtable) ===

A compiled stringtable (comma separated list, *.csv). Even values are stored as strings.

<pre>
----------- [block start]

05 00 00 00 (int) columns
02 00 00 00 (int) rows

FF FF FF FF separator
?? ?? .. 00 filename (path/*.csv) + string termination (0x00)

----------- [table cell description]

?? ?? ?? ?? columns * rows integers (5 * 2 * 4 = 40 bytes in total, 5 * 2 = 10 cells)
FF FF FF FF - if the string wasn't used before and follows after the cell description
?? ?? ?? 4? - if an identical string was already used (in another csv). It is some kind of memory offset (pointer). Base address calculation not figured out yet (0x40000072 ?)

----------- [cell content / strings]

?? ?? .. 00 string + termination (0x00)
Number of strings = amount of FF FF FF FFs in table cell description

----------- [block end]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 01:45, 8 December 2009 (UTC)

--[[User:Daevius|Daevius]] 23:00, 8 December 2009 (UTC)

[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-12-08T23:15:07Z

Daevius: /* 00 00 00 20 (stringtable) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The data block types (also called "index identifier") are written in big endian in this article, e.g. 00 00 00 1F is actually 1F 00 00 00 in ff, although ints and floats in the examples are kept little endian!

The global file layout starts with a header. After which you get a string list (model tag names, animation notetracks, maybe more; not always present). Followed by an index list. This list gives information about the rest of the file, which is a concatenation of compiled files (reinterpreted and linked data generated from source files like d3dbsp and stringtables, hereinafter referred to as data blocks).

* Header
* String list index
* String list
* Data block index
* Data blocks

Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== Header ==

''(Note: not up to date and not generalized)''

*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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> under re-investigation 

=== Example: smallest possible fastfile (mod.ff) ===

<pre>
29 00 00 00 decompressed fastfile size minus 44
00 00 00 00
1C 00 00 00 unknown

00 00 00 00 00 00 00 00 00 00 00 00

0D 00 00 00 data size in memory (?)

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

01 00 00 00 one index entry

FF FF FF FF 1F 00 00 00 a rawfile

FF FF FF FF index end

FF FF FF FF start separator
00 00 00 00 rawfile length (empty, no errors occured during compilation)
FF FF FF FF separator
6D 6F 64 00 fastfile name as rawfile name
00 rawfile string (empty)
</pre>

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

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

06 00 00 00 Number of records in index (6)

FF FF FF FF 05 00 00 00 1st: shader
FF FF FF FF 05 00 00 00 2nd: shader
FF FF FF FF 04 00 00 00 3rd: material
FF FF FF FF 04 00 00 00 4th: material
FF FF FF FF 04 00 00 00 5th: material
FF FF FF FF 1F 00 00 00 6th: rawfile

FF FF FF FF end separator (the following FF FF FF FF is the start seperator of the next data block!)

----------- [end of index]
</pre>

== Index ==

Starts with an int telling the number of dword couples. Such a couple is composed of 2 ints:

4 byte offset (FF FF FF FF = -1, meaning right after the previous block?) 
4 byte identifier (data block type)

Separator (FF FF FF FF) after last couple

=== 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 07 - soundalias (+audio data)
* 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

Since there is a FF FF FF FF separator in front of every block and none at the very end (after last 1F-block), we can assume that each block has a start separation and no end separation. Thus, any FF FF FF FFs you find after data blocks are actually the start separators of the next block. This means the index end separator is rather FFFFFFFF than FFFFFFFFFFFFFFFF!

=== 00 00 00 04 (material) ===

<pre>
----------- [block start]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [block end]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [block start]

36 pointers (0x90 bytes) (bytes 0x19 up to 0x22 say if we get any content at all?)
?? ?? .. 00 Then techset file name (0x00 termination) if pointer is 0xFFFFFFFF?

----------- [start of shader pack]

pointer
1 dword of some character-length options / flags?
3 pointers
1 dword of some character-length sizes
FF FF FF FF Separator
0x64 bytes of some short length options / flags? If the second pointer above is 0xFFFFFFFF

----------- [start of shader]

pointer, if not 0xFFFFFFFF, no filename is further on
pointer, often 00 00 00 00
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag?
?? ?? .. 00 String if first pointer is 0xFFFFFFFF, 0x00 terminated (name of shader source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff' (technique commands?)
41 10 AB A0 which ends with this (always?)
?? ?? .. 00 String, 0x00 terminated (technique file name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [block end]
</pre>

=== 00 00 00 06 (image) ===

Stores some information about the specified IWI in fastfile. Does not include the actual image data.
Length is 52 bytes + IWI name (+1 for string termination).

<pre>
----------- [block start]
Note: obviously no start separator
03 00 00 00
FE FF FF FF separator?
00 00 00 00
00 00 00 00

70 55 01 00 IWI size minus 28 (0x1C)
70 55 01 00 same

00 01 00 01
01 00 03 00
FF FF FF FF separator?

73 70 .. 00 IWI name without file extension (string + termination, variable size)

00 00 00 01
00 01 01 00

44 58 54 35 00 00 00 00 fixed size char[] for type? (here: DXT5....)

----------- [block end]
</pre>

=== 00 00 00 16 (localized string asset) ===

A localized string asset consists of an alias name and a translated string. During compilation, it takes the given alias name (REFERENCE) from *.str file and prepands the *.str file's name in upper-case plus an underscore. Example:

'''example.str'''
<pre>VERSION "1"
CONFIG "C:\trees\cod3\cod3\bin\StringEd.cfg"
FILENOTES ""
//--------------------------------

REFERENCE MARINES_NAME
LANG_ENGLISH "US Airforce"

//--------------------------------
ENDMARKER</pre>

'''mod.ff'''
<pre>
ÿÿÿÿ
ÿÿÿÿ
EXAMPLE_MARINES_NAME.
US Airforce.
</pre>

Length is 8 bytes + string sizes (string count = 0-2, depends on the first two ints).

<pre>
----------- [block start]
Note: no start separator!

FF FF FF FF either pointer or FFFFFFFF if the string wasn't used before
FF FF FF FF same. If two pointers are used here, then no strings will follow.
55 53 .. 00 alias name for the localized
53 54 .. 00 actual localized string

----------- [block end]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [block start]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [block end OR even end of file]
</pre>

=== 00 00 00 20 (stringtable) ===

A compiled stringtable (comma separated list, *.csv). Even values are stored as strings.

<pre>
----------- [block start]

05 00 00 00 (int) columns
02 00 00 00 (int) rows

FF FF FF FF separator
?? ?? .. 00 filename (path/*.csv) + string termination (0x00)

----------- [table cell description]

?? ?? ?? ?? columns * rows integers (5 * 2 * 4 = 40 bytes in total, 5 * 2 = 10 cells)
FF FF FF FF - if the string wasn't used before and follows after the cell description
?? ?? ?? 4? - if an identical string was already used (in another csv). It is some kind of memory offset (pointer). Base address calculation not figured out yet (0x40000072 ?)

----------- [cell content / strings]

?? ?? .. 00 string + termination (0x00)
Number of strings = amount of FF FF FF FFs in table cell description

----------- [block end]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 01:45, 8 December 2009 (UTC)

--[[User:Daevius|Daevius]] 23:00, 8 December 2009 (UTC)

[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-12-08T23:05:02Z

Daevius: /* 00 00 00 1F (rawfile) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The data block types (also called "index identifier") are written in big endian in this article, e.g. 00 00 00 1F is actually 1F 00 00 00 in ff, although ints and floats in the examples are kept little endian!

The global file layout starts with a header. After which you get a string list (model tag names, animation notetracks, maybe more; not always present). Followed by an index list. This list gives information about the rest of the file, which is a concatenation of compiled files (reinterpreted and linked data generated from source files like d3dbsp and stringtables, hereinafter referred to as data blocks).

* Header
* String list index
* String list
* Data block index
* Data blocks

Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== Header ==

''(Note: not up to date and not generalized)''

*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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> under re-investigation 

=== Example: smallest possible fastfile (mod.ff) ===

<pre>
29 00 00 00 decompressed fastfile size minus 44
00 00 00 00
1C 00 00 00 unknown

00 00 00 00 00 00 00 00 00 00 00 00

0D 00 00 00 data size in memory (?)

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

01 00 00 00 one index entry

FF FF FF FF 1F 00 00 00 a rawfile

FF FF FF FF index end

FF FF FF FF start separator
00 00 00 00 rawfile length (empty, no errors occured during compilation)
FF FF FF FF separator
6D 6F 64 00 fastfile name as rawfile name
00 rawfile string (empty)
</pre>

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

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

06 00 00 00 Number of records in index (6)

FF FF FF FF 05 00 00 00 1st: shader
FF FF FF FF 05 00 00 00 2nd: shader
FF FF FF FF 04 00 00 00 3rd: material
FF FF FF FF 04 00 00 00 4th: material
FF FF FF FF 04 00 00 00 5th: material
FF FF FF FF 1F 00 00 00 6th: rawfile

FF FF FF FF end separator (the following FF FF FF FF is the start seperator of the next data block!)

----------- [end of index]
</pre>

== Index ==

Starts with an int telling the number of dword couples. Such a couple is composed of 2 ints:

4 byte offset (FF FF FF FF = -1, meaning right after the previous block?) 
4 byte identifier (data block type)

Separator (FF FF FF FF) after last couple

=== 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 07 - soundalias (+audio data)
* 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

Since there is a FF FF FF FF separator in front of every block and none at the very end (after last 1F-block), we can assume that each block has a start separation and no end separation. Thus, any FF FF FF FFs you find after data blocks are actually the start separators of the next block. This means the index end separator is rather FFFFFFFF than FFFFFFFFFFFFFFFF!

=== 00 00 00 04 (material) ===

<pre>
----------- [block start]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [block end]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [block start]

36 pointers (0x90 bytes) (bytes 0x19 up to 0x22 say if we get any content at all?)
?? ?? .. 00 Then techset file name (0x00 termination) if pointer is 0xFFFFFFFF?

----------- [start of shader pack]

pointer
1 dword of some character-length options / flags?
3 pointers
1 dword of some character-length sizes
FF FF FF FF Separator
0x64 bytes of some short length options / flags? If the second pointer above is 0xFFFFFFFF

----------- [start of shader]

pointer, if not 0xFFFFFFFF, no filename is further on
pointer, often 00 00 00 00
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag?
?? ?? .. 00 String if first pointer is 0xFFFFFFFF, 0x00 terminated (name of shader source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff' (technique commands?)
41 10 AB A0 which ends with this (always?)
?? ?? .. 00 String, 0x00 terminated (technique file name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [block end]
</pre>

=== 00 00 00 06 (image) ===

Stores some information about the specified IWI in fastfile. Does not include the actual image data.
Length is 52 bytes + IWI name (+1 for string termination).

<pre>
----------- [block start]
Note: obviously no start separator
03 00 00 00
FE FF FF FF separator?
00 00 00 00
00 00 00 00

70 55 01 00 IWI size minus 28 (0x1C)
70 55 01 00 same

00 01 00 01
01 00 03 00
FF FF FF FF separator?

73 70 .. 00 IWI name without file extension (string + termination, variable size)

00 00 00 01
00 01 01 00

44 58 54 35 00 00 00 00 fixed size char[] for type? (here: DXT5....)

----------- [block end]
</pre>

=== 00 00 00 16 (localized string asset) ===

A localized string asset consists of an alias name and a translated string. During compilation, it takes the given alias name (REFERENCE) from *.str file and prepands the *.str file's name in upper-case plus an underscore. Example:

'''example.str'''
<pre>VERSION "1"
CONFIG "C:\trees\cod3\cod3\bin\StringEd.cfg"
FILENOTES ""
//--------------------------------

REFERENCE MARINES_NAME
LANG_ENGLISH "US Airforce"

//--------------------------------
ENDMARKER</pre>

'''mod.ff'''
<pre>
ÿÿÿÿ
ÿÿÿÿ
EXAMPLE_MARINES_NAME.
US Airforce.
</pre>

Length is 8 bytes + string sizes (string count = 0-2, depends on the first two ints).

<pre>
----------- [block start]
Note: no start separator!

FF FF FF FF either pointer or FFFFFFFF if the string wasn't used before
FF FF FF FF same. If two pointers are used here, then no strings will follow.
55 53 .. 00 alias name for the localized
53 54 .. 00 actual localized string

----------- [block end]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [block start]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [block end OR even end of file]
</pre>

=== 00 00 00 20 (stringtable) ===

A compiled stringtable (comma separated list, *.csv). Even values are stored as strings.

<pre>
----------- [block start]

FF FF FF FF start separation

05 00 00 00 (int) columns
02 00 00 00 (int) rows

FF FF FF FF separator
?? ?? .. 00 filename (path/*.csv) + string termination (0x00)

----------- [table cell description]

?? ?? ?? ?? columns * rows integers (5 * 2 * 4 = 40 bytes in total, 5 * 2 = 10 cells)
FF FF FF FF - if the string wasn't used before and follows after the cell description
?? ?? ?? 4? - if an identical string was already used (in another csv). It is some kind of memory offset (pointer). Base address calculation not figured out yet (0x40000072 ?)

----------- [cell content / strings]

?? ?? .. 00 string + termination (0x00)
Number of strings = amount of FF FF FF FFs in table cell description

----------- [block end]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 01:45, 8 December 2009 (UTC)

--[[User:Daevius|Daevius]] 23:00, 8 December 2009 (UTC)

[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-12-08T23:04:42Z

Daevius: /* 00 00 00 04 (material) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The data block types (also called "index identifier") are written in big endian in this article, e.g. 00 00 00 1F is actually 1F 00 00 00 in ff, although ints and floats in the examples are kept little endian!

The global file layout starts with a header. After which you get a string list (model tag names, animation notetracks, maybe more; not always present). Followed by an index list. This list gives information about the rest of the file, which is a concatenation of compiled files (reinterpreted and linked data generated from source files like d3dbsp and stringtables, hereinafter referred to as data blocks).

* Header
* String list index
* String list
* Data block index
* Data blocks

Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== Header ==

''(Note: not up to date and not generalized)''

*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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> under re-investigation 

=== Example: smallest possible fastfile (mod.ff) ===

<pre>
29 00 00 00 decompressed fastfile size minus 44
00 00 00 00
1C 00 00 00 unknown

00 00 00 00 00 00 00 00 00 00 00 00

0D 00 00 00 data size in memory (?)

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

01 00 00 00 one index entry

FF FF FF FF 1F 00 00 00 a rawfile

FF FF FF FF index end

FF FF FF FF start separator
00 00 00 00 rawfile length (empty, no errors occured during compilation)
FF FF FF FF separator
6D 6F 64 00 fastfile name as rawfile name
00 rawfile string (empty)
</pre>

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

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

06 00 00 00 Number of records in index (6)

FF FF FF FF 05 00 00 00 1st: shader
FF FF FF FF 05 00 00 00 2nd: shader
FF FF FF FF 04 00 00 00 3rd: material
FF FF FF FF 04 00 00 00 4th: material
FF FF FF FF 04 00 00 00 5th: material
FF FF FF FF 1F 00 00 00 6th: rawfile

FF FF FF FF end separator (the following FF FF FF FF is the start seperator of the next data block!)

----------- [end of index]
</pre>

== Index ==

Starts with an int telling the number of dword couples. Such a couple is composed of 2 ints:

4 byte offset (FF FF FF FF = -1, meaning right after the previous block?) 
4 byte identifier (data block type)

Separator (FF FF FF FF) after last couple

=== 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 07 - soundalias (+audio data)
* 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

Since there is a FF FF FF FF separator in front of every block and none at the very end (after last 1F-block), we can assume that each block has a start separation and no end separation. Thus, any FF FF FF FFs you find after data blocks are actually the start separators of the next block. This means the index end separator is rather FFFFFFFF than FFFFFFFFFFFFFFFF!

=== 00 00 00 04 (material) ===

<pre>
----------- [block start]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [block end]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [block start]

36 pointers (0x90 bytes) (bytes 0x19 up to 0x22 say if we get any content at all?)
?? ?? .. 00 Then techset file name (0x00 termination) if pointer is 0xFFFFFFFF?

----------- [start of shader pack]

pointer
1 dword of some character-length options / flags?
3 pointers
1 dword of some character-length sizes
FF FF FF FF Separator
0x64 bytes of some short length options / flags? If the second pointer above is 0xFFFFFFFF

----------- [start of shader]

pointer, if not 0xFFFFFFFF, no filename is further on
pointer, often 00 00 00 00
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag?
?? ?? .. 00 String if first pointer is 0xFFFFFFFF, 0x00 terminated (name of shader source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff' (technique commands?)
41 10 AB A0 which ends with this (always?)
?? ?? .. 00 String, 0x00 terminated (technique file name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [block end]
</pre>

=== 00 00 00 06 (image) ===

Stores some information about the specified IWI in fastfile. Does not include the actual image data.
Length is 52 bytes + IWI name (+1 for string termination).

<pre>
----------- [block start]
Note: obviously no start separator
03 00 00 00
FE FF FF FF separator?
00 00 00 00
00 00 00 00

70 55 01 00 IWI size minus 28 (0x1C)
70 55 01 00 same

00 01 00 01
01 00 03 00
FF FF FF FF separator?

73 70 .. 00 IWI name without file extension (string + termination, variable size)

00 00 00 01
00 01 01 00

44 58 54 35 00 00 00 00 fixed size char[] for type? (here: DXT5....)

----------- [block end]
</pre>

=== 00 00 00 16 (localized string asset) ===

A localized string asset consists of an alias name and a translated string. During compilation, it takes the given alias name (REFERENCE) from *.str file and prepands the *.str file's name in upper-case plus an underscore. Example:

'''example.str'''
<pre>VERSION "1"
CONFIG "C:\trees\cod3\cod3\bin\StringEd.cfg"
FILENOTES ""
//--------------------------------

REFERENCE MARINES_NAME
LANG_ENGLISH "US Airforce"

//--------------------------------
ENDMARKER</pre>

'''mod.ff'''
<pre>
ÿÿÿÿ
ÿÿÿÿ
EXAMPLE_MARINES_NAME.
US Airforce.
</pre>

Length is 8 bytes + string sizes (string count = 0-2, depends on the first two ints).

<pre>
----------- [block start]
Note: no start separator!

FF FF FF FF either pointer or FFFFFFFF if the string wasn't used before
FF FF FF FF same. If two pointers are used here, then no strings will follow.
55 53 .. 00 alias name for the localized
53 54 .. 00 actual localized string

----------- [block end]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [block start]

FF FF FF FF Start separation

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [block end OR even end of file]
</pre>

=== 00 00 00 20 (stringtable) ===

A compiled stringtable (comma separated list, *.csv). Even values are stored as strings.

<pre>
----------- [block start]

FF FF FF FF start separation

05 00 00 00 (int) columns
02 00 00 00 (int) rows

FF FF FF FF separator
?? ?? .. 00 filename (path/*.csv) + string termination (0x00)

----------- [table cell description]

?? ?? ?? ?? columns * rows integers (5 * 2 * 4 = 40 bytes in total, 5 * 2 = 10 cells)
FF FF FF FF - if the string wasn't used before and follows after the cell description
?? ?? ?? 4? - if an identical string was already used (in another csv). It is some kind of memory offset (pointer). Base address calculation not figured out yet (0x40000072 ?)

----------- [cell content / strings]

?? ?? .. 00 string + termination (0x00)
Number of strings = amount of FF FF FF FFs in table cell description

----------- [block end]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 01:45, 8 December 2009 (UTC)

--[[User:Daevius|Daevius]] 23:00, 8 December 2009 (UTC)

[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-12-08T23:04:33Z

Daevius: /* 00 00 00 05 (shader) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The data block types (also called "index identifier") are written in big endian in this article, e.g. 00 00 00 1F is actually 1F 00 00 00 in ff, although ints and floats in the examples are kept little endian!

The global file layout starts with a header. After which you get a string list (model tag names, animation notetracks, maybe more; not always present). Followed by an index list. This list gives information about the rest of the file, which is a concatenation of compiled files (reinterpreted and linked data generated from source files like d3dbsp and stringtables, hereinafter referred to as data blocks).

* Header
* String list index
* String list
* Data block index
* Data blocks

Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== Header ==

''(Note: not up to date and not generalized)''

*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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> under re-investigation 

=== Example: smallest possible fastfile (mod.ff) ===

<pre>
29 00 00 00 decompressed fastfile size minus 44
00 00 00 00
1C 00 00 00 unknown

00 00 00 00 00 00 00 00 00 00 00 00

0D 00 00 00 data size in memory (?)

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

01 00 00 00 one index entry

FF FF FF FF 1F 00 00 00 a rawfile

FF FF FF FF index end

FF FF FF FF start separator
00 00 00 00 rawfile length (empty, no errors occured during compilation)
FF FF FF FF separator
6D 6F 64 00 fastfile name as rawfile name
00 rawfile string (empty)
</pre>

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

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

06 00 00 00 Number of records in index (6)

FF FF FF FF 05 00 00 00 1st: shader
FF FF FF FF 05 00 00 00 2nd: shader
FF FF FF FF 04 00 00 00 3rd: material
FF FF FF FF 04 00 00 00 4th: material
FF FF FF FF 04 00 00 00 5th: material
FF FF FF FF 1F 00 00 00 6th: rawfile

FF FF FF FF end separator (the following FF FF FF FF is the start seperator of the next data block!)

----------- [end of index]
</pre>

== Index ==

Starts with an int telling the number of dword couples. Such a couple is composed of 2 ints:

4 byte offset (FF FF FF FF = -1, meaning right after the previous block?) 
4 byte identifier (data block type)

Separator (FF FF FF FF) after last couple

=== 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 07 - soundalias (+audio data)
* 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

Since there is a FF FF FF FF separator in front of every block and none at the very end (after last 1F-block), we can assume that each block has a start separation and no end separation. Thus, any FF FF FF FFs you find after data blocks are actually the start separators of the next block. This means the index end separator is rather FFFFFFFF than FFFFFFFFFFFFFFFF!

=== 00 00 00 04 (material) ===

<pre>
----------- [block start]

FF FF FF FF start separation

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [block end]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [block start]

36 pointers (0x90 bytes) (bytes 0x19 up to 0x22 say if we get any content at all?)
?? ?? .. 00 Then techset file name (0x00 termination) if pointer is 0xFFFFFFFF?

----------- [start of shader pack]

pointer
1 dword of some character-length options / flags?
3 pointers
1 dword of some character-length sizes
FF FF FF FF Separator
0x64 bytes of some short length options / flags? If the second pointer above is 0xFFFFFFFF

----------- [start of shader]

pointer, if not 0xFFFFFFFF, no filename is further on
pointer, often 00 00 00 00
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag?
?? ?? .. 00 String if first pointer is 0xFFFFFFFF, 0x00 terminated (name of shader source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff' (technique commands?)
41 10 AB A0 which ends with this (always?)
?? ?? .. 00 String, 0x00 terminated (technique file name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [block end]
</pre>

=== 00 00 00 06 (image) ===

Stores some information about the specified IWI in fastfile. Does not include the actual image data.
Length is 52 bytes + IWI name (+1 for string termination).

<pre>
----------- [block start]
Note: obviously no start separator
03 00 00 00
FE FF FF FF separator?
00 00 00 00
00 00 00 00

70 55 01 00 IWI size minus 28 (0x1C)
70 55 01 00 same

00 01 00 01
01 00 03 00
FF FF FF FF separator?

73 70 .. 00 IWI name without file extension (string + termination, variable size)

00 00 00 01
00 01 01 00

44 58 54 35 00 00 00 00 fixed size char[] for type? (here: DXT5....)

----------- [block end]
</pre>

=== 00 00 00 16 (localized string asset) ===

A localized string asset consists of an alias name and a translated string. During compilation, it takes the given alias name (REFERENCE) from *.str file and prepands the *.str file's name in upper-case plus an underscore. Example:

'''example.str'''
<pre>VERSION "1"
CONFIG "C:\trees\cod3\cod3\bin\StringEd.cfg"
FILENOTES ""
//--------------------------------

REFERENCE MARINES_NAME
LANG_ENGLISH "US Airforce"

//--------------------------------
ENDMARKER</pre>

'''mod.ff'''
<pre>
ÿÿÿÿ
ÿÿÿÿ
EXAMPLE_MARINES_NAME.
US Airforce.
</pre>

Length is 8 bytes + string sizes (string count = 0-2, depends on the first two ints).

<pre>
----------- [block start]
Note: no start separator!

FF FF FF FF either pointer or FFFFFFFF if the string wasn't used before
FF FF FF FF same. If two pointers are used here, then no strings will follow.
55 53 .. 00 alias name for the localized
53 54 .. 00 actual localized string

----------- [block end]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [block start]

FF FF FF FF Start separation

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [block end OR even end of file]
</pre>

=== 00 00 00 20 (stringtable) ===

A compiled stringtable (comma separated list, *.csv). Even values are stored as strings.

<pre>
----------- [block start]

FF FF FF FF start separation

05 00 00 00 (int) columns
02 00 00 00 (int) rows

FF FF FF FF separator
?? ?? .. 00 filename (path/*.csv) + string termination (0x00)

----------- [table cell description]

?? ?? ?? ?? columns * rows integers (5 * 2 * 4 = 40 bytes in total, 5 * 2 = 10 cells)
FF FF FF FF - if the string wasn't used before and follows after the cell description
?? ?? ?? 4? - if an identical string was already used (in another csv). It is some kind of memory offset (pointer). Base address calculation not figured out yet (0x40000072 ?)

----------- [cell content / strings]

?? ?? .. 00 string + termination (0x00)
Number of strings = amount of FF FF FF FFs in table cell description

----------- [block end]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 01:45, 8 December 2009 (UTC)

--[[User:Daevius|Daevius]] 23:00, 8 December 2009 (UTC)

[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-12-08T23:00:28Z

Daevius:

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The data block types (also called "index identifier") are written in big endian in this article, e.g. 00 00 00 1F is actually 1F 00 00 00 in ff, although ints and floats in the examples are kept little endian!

The global file layout starts with a header. After which you get a string list (model tag names, animation notetracks, maybe more; not always present). Followed by an index list. This list gives information about the rest of the file, which is a concatenation of compiled files (reinterpreted and linked data generated from source files like d3dbsp and stringtables, hereinafter referred to as data blocks).

* Header
* String list index
* String list
* Data block index
* Data blocks

Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== Header ==

''(Note: not up to date and not generalized)''

*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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> under re-investigation 

=== Example: smallest possible fastfile (mod.ff) ===

<pre>
29 00 00 00 decompressed fastfile size minus 44
00 00 00 00
1C 00 00 00 unknown

00 00 00 00 00 00 00 00 00 00 00 00

0D 00 00 00 data size in memory (?)

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

01 00 00 00 one index entry

FF FF FF FF 1F 00 00 00 a rawfile

FF FF FF FF index end

FF FF FF FF start separator
00 00 00 00 rawfile length (empty, no errors occured during compilation)
FF FF FF FF separator
6D 6F 64 00 fastfile name as rawfile name
00 rawfile string (empty)
</pre>

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

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

06 00 00 00 Number of records in index (6)

FF FF FF FF 05 00 00 00 1st: shader
FF FF FF FF 05 00 00 00 2nd: shader
FF FF FF FF 04 00 00 00 3rd: material
FF FF FF FF 04 00 00 00 4th: material
FF FF FF FF 04 00 00 00 5th: material
FF FF FF FF 1F 00 00 00 6th: rawfile

FF FF FF FF end separator (the following FF FF FF FF is the start seperator of the next data block!)

----------- [end of index]
</pre>

== Index ==

Starts with an int telling the number of dword couples. Such a couple is composed of 2 ints:

4 byte offset (FF FF FF FF = -1, meaning right after the previous block?) 
4 byte identifier (data block type)

Separator (FF FF FF FF) after last couple

=== 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 07 - soundalias (+audio data)
* 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

Since there is a FF FF FF FF separator in front of every block and none at the very end (after last 1F-block), we can assume that each block has a start separation and no end separation. Thus, any FF FF FF FFs you find after data blocks are actually the start separators of the next block. This means the index end separator is rather FFFFFFFF than FFFFFFFFFFFFFFFF!

=== 00 00 00 04 (material) ===

<pre>
----------- [block start]

FF FF FF FF start separation

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [block end]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [block start]

FF FF FF FF Start separation

36 pointers (0x90 bytes) (bytes 0x19 up to 0x22 say if we get any content at all?)
?? ?? .. 00 Then techset file name (0x00 termination) if pointer is 0xFFFFFFFF?

----------- [start of shader pack]

pointer
1 dword of some character-length options / flags?
3 pointers
1 dword of some character-length sizes
FF FF FF FF Separator
0x64 bytes of some short length options / flags? If the second pointer above is 0xFFFFFFFF

----------- [start of shader]

pointer, if not 0xFFFFFFFF, no filename is further on
pointer, often 00 00 00 00
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag?
?? ?? .. 00 String if first pointer is 0xFFFFFFFF, 0x00 terminated (name of shader source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff' (technique commands?)
41 10 AB A0 which ends with this (always?)
?? ?? .. 00 String, 0x00 terminated (technique file name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [block end]
</pre>

=== 00 00 00 06 (image) ===

Stores some information about the specified IWI in fastfile. Does not include the actual image data.
Length is 52 bytes + IWI name (+1 for string termination).

<pre>
----------- [block start]
Note: obviously no start separator
03 00 00 00
FE FF FF FF separator?
00 00 00 00
00 00 00 00

70 55 01 00 IWI size minus 28 (0x1C)
70 55 01 00 same

00 01 00 01
01 00 03 00
FF FF FF FF separator?

73 70 .. 00 IWI name without file extension (string + termination, variable size)

00 00 00 01
00 01 01 00

44 58 54 35 00 00 00 00 fixed size char[] for type? (here: DXT5....)

----------- [block end]
</pre>

=== 00 00 00 16 (localized string asset) ===

A localized string asset consists of an alias name and a translated string. During compilation, it takes the given alias name (REFERENCE) from *.str file and prepands the *.str file's name in upper-case plus an underscore. Example:

'''example.str'''
<pre>VERSION "1"
CONFIG "C:\trees\cod3\cod3\bin\StringEd.cfg"
FILENOTES ""
//--------------------------------

REFERENCE MARINES_NAME
LANG_ENGLISH "US Airforce"

//--------------------------------
ENDMARKER</pre>

'''mod.ff'''
<pre>
ÿÿÿÿ
ÿÿÿÿ
EXAMPLE_MARINES_NAME.
US Airforce.
</pre>

Length is 8 bytes + string sizes (string count = 0-2, depends on the first two ints).

<pre>
----------- [block start]
Note: no start separator!

FF FF FF FF either pointer or FFFFFFFF if the string wasn't used before
FF FF FF FF same. If two pointers are used here, then no strings will follow.
55 53 .. 00 alias name for the localized
53 54 .. 00 actual localized string

----------- [block end]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [block start]

FF FF FF FF Start separation

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [block end OR even end of file]
</pre>

=== 00 00 00 20 (stringtable) ===

A compiled stringtable (comma separated list, *.csv). Even values are stored as strings.

<pre>
----------- [block start]

FF FF FF FF start separation

05 00 00 00 (int) columns
02 00 00 00 (int) rows

FF FF FF FF separator
?? ?? .. 00 filename (path/*.csv) + string termination (0x00)

----------- [table cell description]

?? ?? ?? ?? columns * rows integers (5 * 2 * 4 = 40 bytes in total, 5 * 2 = 10 cells)
FF FF FF FF - if the string wasn't used before and follows after the cell description
?? ?? ?? 4? - if an identical string was already used (in another csv). It is some kind of memory offset (pointer). Base address calculation not figured out yet (0x40000072 ?)

----------- [cell content / strings]

?? ?? .. 00 string + termination (0x00)
Number of strings = amount of FF FF FF FFs in table cell description

----------- [block end]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 01:45, 8 December 2009 (UTC)

--[[User:Daevius|Daevius]] 23:00, 8 December 2009 (UTC)

[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-12-08T20:19:27Z

Daevius: /* 00 00 00 05 (shader) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The data block types (also called "index identifier") are written in big endian in this article, e.g. 00 00 00 1F is actually 1F 00 00 00 in ff, although ints and floats in the examples are kept little endian!

The global file layout starts with a header. After which you get a string list (model tag names, animation notetracks, maybe more; not always present). Followed by an index list. This list gives information about the rest of the file, which is a concatenation of compiled files (reinterpreted and linked data generated from source files like d3dbsp and stringtables, hereinafter referred to as data blocks).

* Header
* String list index
* String list
* Data block index
* Data blocks

Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== Header ==

''(Note: not up to date and not generalized)''

*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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> under re-investigation 

=== Example: smallest possible fastfile (mod.ff) ===

<pre>
29 00 00 00 decompressed fastfile size minus 44
00 00 00 00
1C 00 00 00 unknown

00 00 00 00 00 00 00 00 00 00 00 00

0D 00 00 00 data size in memory (?)

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

01 00 00 00 one index entry

FF FF FF FF 1F 00 00 00 a rawfile

FF FF FF FF index end

FF FF FF FF start separator
00 00 00 00 rawfile length (empty, no errors occured during compilation)
FF FF FF FF separator
6D 6F 64 00 fastfile name as rawfile name
00 rawfile string (empty)
</pre>

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

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

06 00 00 00 Number of records in index (6)

FF FF FF FF 05 00 00 00 1st: shader
FF FF FF FF 05 00 00 00 2nd: shader
FF FF FF FF 04 00 00 00 3rd: material
FF FF FF FF 04 00 00 00 4th: material
FF FF FF FF 04 00 00 00 5th: material
FF FF FF FF 1F 00 00 00 6th: rawfile

FF FF FF FF end separator (the following FF FF FF FF is the start seperator of the next data block!)

----------- [end of index]
</pre>

== Index ==

Starts with an int telling the number of dword couples. Such a couple is composed of 2 ints:

4 byte offset (FF FF FF FF = -1, meaning right after the previous block?) 
4 byte identifier (data block type)

Separator (FF FF FF FF) after last couple

=== 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 07 - soundalias (+audio data)
* 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

Since there is a FF FF FF FF separator in front of every block and none at the very end (after last 1F-block), we can assume that each block has a start separation and no end separation. Thus, any FF FF FF FFs you find after data blocks are actually the start separators of the next block. This means the index end separator is rather FFFFFFFF than FFFFFFFFFFFFFFFF!

=== 00 00 00 04 (material) ===

<pre>
----------- [block start]

FF FF FF FF start separation

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [block end]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [block start]

FF FF FF FF Start separation

36 pointers (0x90 bytes) (bytes 0x19 up to 0x22 say if we get any content at all?)
?? ?? .. 00 Then techset file name (0x00 termination) if pointer is 0xFFFFFFFF?

----------- [start of shader pack]

pointer
1 dword of some character-length options / flags?
3 pointers
1 dword of some character-length sizes
FF FF FF FF Separator
0x64 bytes of some short length options / flags? If the second pointer above is 0xFFFFFFFF

----------- [start of shader]

pointer, if not 0xFFFFFFFF, no filename is further on
pointer, often 00 00 00 00
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag?
?? ?? .. 00 String if first pointer is 0xFFFFFFFF, 0x00 terminated (name of shader source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff' (technique commands?)
41 10 AB A0 which ends with this (always?)
?? ?? .. 00 String, 0x00 terminated (technique file name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [block end]
</pre>

=== 00 00 00 06 (image) ===

Stores some information about the specified IWI in fastfile. Does not include the actual image data.
Length is 52 bytes + IWI name (+1 for string termination).

<pre>
----------- [block start]
Note: obviously no start separator
03 00 00 00
FE FF FF FF separator?
00 00 00 00
00 00 00 00

70 55 01 00 IWI size minus 28 (0x1C)
70 55 01 00 same

00 01 00 01
01 00 03 00
FF FF FF FF separator?

73 70 .. 00 IWI name without file extension (string + termination, variable size)

00 00 00 01
00 01 01 00

44 58 54 35 00 00 00 00 fixed size char[] for type? (here: DXT5....)

----------- [block end]
</pre>

=== 00 00 00 16 (localized string asset) ===

A localized string asset consists of an alias name and a translated string. During compilation, it takes the given alias name (REFERENCE) from *.str file and prepands the *.str file's name in upper-case plus an underscore. Example:

'''example.str'''
<pre>VERSION "1"
CONFIG "C:\trees\cod3\cod3\bin\StringEd.cfg"
FILENOTES ""
//--------------------------------

REFERENCE MARINES_NAME
LANG_ENGLISH "US Airforce"

//--------------------------------
ENDMARKER</pre>

'''mod.ff'''
<pre>
ÿÿÿÿ
ÿÿÿÿ
EXAMPLE_MARINES_NAME.
US Airforce.
</pre>

Length is 8 bytes + string sizes (string count = 0-2, depends on the first two ints).

<pre>
----------- [block start]
Note: no start separator!

FF FF FF FF either pointer or FFFFFFFF if the string wasn't used before
FF FF FF FF same. If two pointers are used here, then no strings will follow.
55 53 .. 00 alias name for the localized
53 54 .. 00 actual localized string

----------- [block end]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [block start]

FF FF FF FF Start separation

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [block end OR even end of file]
</pre>

=== 00 00 00 20 (stringtable) ===

A compiled stringtable (comma separated list, *.csv). Even values are stored as strings.

<pre>
----------- [block start]

FF FF FF FF start separation

05 00 00 00 (int) columns
02 00 00 00 (int) rows

FF FF FF FF separator
?? ?? .. 00 filename (path/*.csv) + string termination (0x00)

----------- [table cell description]

?? ?? ?? ?? columns * rows integers (5 * 2 * 4 = 40 bytes in total, 5 * 2 = 10 cells)
FF FF FF FF - if the string wasn't used before and follows after the cell description
?? ?? ?? 4? - if an identical string was already used (in another csv). It is some kind of memory offset (pointer). Base address calculation not figured out yet (0x40000072 ?)

----------- [cell content / strings]

?? ?? .. 00 string + termination (0x00)
Number of strings = amount of FF FF FF FFs in table cell description

----------- [block end]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 01:45, 8 December 2009 (UTC)

--[[User:Daevius|Daevius]] 14:24, 5 November 2009 (UTC)

[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-12-08T20:17:37Z

Daevius: /* 00 00 00 05 (shader) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The data block types (also called "index identifier") are written in big endian in this article, e.g. 00 00 00 1F is actually 1F 00 00 00 in ff, although ints and floats in the examples are kept little endian!

The global file layout starts with a header. After which you get a string list (model tag names, animation notetracks, maybe more; not always present). Followed by an index list. This list gives information about the rest of the file, which is a concatenation of compiled files (reinterpreted and linked data generated from source files like d3dbsp and stringtables, hereinafter referred to as data blocks).

* Header
* String list index
* String list
* Data block index
* Data blocks

Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== Header ==

''(Note: not up to date and not generalized)''

*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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> under re-investigation 

=== Example: smallest possible fastfile (mod.ff) ===

<pre>
29 00 00 00 decompressed fastfile size minus 44
00 00 00 00
1C 00 00 00 unknown

00 00 00 00 00 00 00 00 00 00 00 00

0D 00 00 00 data size in memory (?)

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

01 00 00 00 one index entry

FF FF FF FF 1F 00 00 00 a rawfile

FF FF FF FF index end

FF FF FF FF start separator
00 00 00 00 rawfile length (empty, no errors occured during compilation)
FF FF FF FF separator
6D 6F 64 00 fastfile name as rawfile name
00 rawfile string (empty)
</pre>

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

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

06 00 00 00 Number of records in index (6)

FF FF FF FF 05 00 00 00 1st: shader
FF FF FF FF 05 00 00 00 2nd: shader
FF FF FF FF 04 00 00 00 3rd: material
FF FF FF FF 04 00 00 00 4th: material
FF FF FF FF 04 00 00 00 5th: material
FF FF FF FF 1F 00 00 00 6th: rawfile

FF FF FF FF end separator (the following FF FF FF FF is the start seperator of the next data block!)

----------- [end of index]
</pre>

== Index ==

Starts with an int telling the number of dword couples. Such a couple is composed of 2 ints:

4 byte offset (FF FF FF FF = -1, meaning right after the previous block?) 
4 byte identifier (data block type)

Separator (FF FF FF FF) after last couple

=== 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 07 - soundalias (+audio data)
* 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

Since there is a FF FF FF FF separator in front of every block and none at the very end (after last 1F-block), we can assume that each block has a start separation and no end separation. Thus, any FF FF FF FFs you find after data blocks are actually the start separators of the next block. This means the index end separator is rather FFFFFFFF than FFFFFFFFFFFFFFFF!

=== 00 00 00 04 (material) ===

<pre>
----------- [block start]

FF FF FF FF start separation

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [block end]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [block start]

FF FF FF FF Start separation


36 pointers (0x90 bytes)
?? ?? .. 00 Then techset file name (0x00 termination) if pointer is 0xFFFFFFFF?

----------- [start of shader pack]

pointer
1 dword of some character-length options / flags?
3 pointers
1 dword of some character-length sizes
FF FF FF FF Separator
0x64 bytes of some short length options / flags? If the second pointer above is 0xFFFFFFFF

----------- [start of shader]

pointer, if not 0xFFFFFFFF, no filename is further on
pointer, often 00 00 00 00
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag?
?? ?? .. 00 String if first pointer is 0xFFFFFFFF, 0x00 terminated (name of shader source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff' (technique commands?)
41 10 AB A0 which ends with this (always?)
?? ?? .. 00 String, 0x00 terminated (technique file name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [block end]
</pre>

=== 00 00 00 06 (image) ===

Stores some information about the specified IWI in fastfile. Does not include the actual image data.
Length is 52 bytes + IWI name (+1 for string termination).

<pre>
----------- [block start]
Note: obviously no start separator
03 00 00 00
FE FF FF FF separator?
00 00 00 00
00 00 00 00

70 55 01 00 IWI size minus 28 (0x1C)
70 55 01 00 same

00 01 00 01
01 00 03 00
FF FF FF FF separator?

73 70 .. 00 IWI name without file extension (string + termination, variable size)

00 00 00 01
00 01 01 00

44 58 54 35 00 00 00 00 fixed size char[] for type? (here: DXT5....)

----------- [block end]
</pre>

=== 00 00 00 16 (localized string asset) ===

A localized string asset consists of an alias name and a translated string. During compilation, it takes the given alias name (REFERENCE) from *.str file and prepands the *.str file's name in upper-case plus an underscore. Example:

'''example.str'''
<pre>VERSION "1"
CONFIG "C:\trees\cod3\cod3\bin\StringEd.cfg"
FILENOTES ""
//--------------------------------

REFERENCE MARINES_NAME
LANG_ENGLISH "US Airforce"

//--------------------------------
ENDMARKER</pre>

'''mod.ff'''
<pre>
ÿÿÿÿ
ÿÿÿÿ
EXAMPLE_MARINES_NAME.
US Airforce.
</pre>

Length is 8 bytes + string sizes (string count = 0-2, depends on the first two ints).

<pre>
----------- [block start]
Note: no start separator!

FF FF FF FF either pointer or FFFFFFFF if the string wasn't used before
FF FF FF FF same. If two pointers are used here, then no strings will follow.
55 53 .. 00 alias name for the localized
53 54 .. 00 actual localized string

----------- [block end]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [block start]

FF FF FF FF Start separation

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [block end OR even end of file]
</pre>

=== 00 00 00 20 (stringtable) ===

A compiled stringtable (comma separated list, *.csv). Even values are stored as strings.

<pre>
----------- [block start]

FF FF FF FF start separation

05 00 00 00 (int) columns
02 00 00 00 (int) rows

FF FF FF FF separator
?? ?? .. 00 filename (path/*.csv) + string termination (0x00)

----------- [table cell description]

?? ?? ?? ?? columns * rows integers (5 * 2 * 4 = 40 bytes in total, 5 * 2 = 10 cells)
FF FF FF FF - if the string wasn't used before and follows after the cell description
?? ?? ?? 4? - if an identical string was already used (in another csv). It is some kind of memory offset (pointer). Base address calculation not figured out yet (0x40000072 ?)

----------- [cell content / strings]

?? ?? .. 00 string + termination (0x00)
Number of strings = amount of FF FF FF FFs in table cell description

----------- [block end]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 01:45, 8 December 2009 (UTC)

--[[User:Daevius|Daevius]] 14:24, 5 November 2009 (UTC)

[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-12-08T20:07:21Z

Daevius: /* 00 00 00 05 (shader) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The data block types (also called "index identifier") are written in big endian in this article, e.g. 00 00 00 1F is actually 1F 00 00 00 in ff, although ints and floats in the examples are kept little endian!

The global file layout starts with a header. After which you get a string list (model tag names, animation notetracks, maybe more; not always present). Followed by an index list. This list gives information about the rest of the file, which is a concatenation of compiled files (reinterpreted and linked data generated from source files like d3dbsp and stringtables, hereinafter referred to as data blocks).

* Header
* String list index
* String list
* Data block index
* Data blocks

Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== Header ==

''(Note: not up to date and not generalized)''

*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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> under re-investigation 

=== Example: smallest possible fastfile (mod.ff) ===

<pre>
29 00 00 00 decompressed fastfile size minus 44
00 00 00 00
1C 00 00 00 unknown

00 00 00 00 00 00 00 00 00 00 00 00

0D 00 00 00 data size in memory (?)

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

01 00 00 00 one index entry

FF FF FF FF 1F 00 00 00 a rawfile

FF FF FF FF index end

FF FF FF FF start separator
00 00 00 00 rawfile length (empty, no errors occured during compilation)
FF FF FF FF separator
6D 6F 64 00 fastfile name as rawfile name
00 rawfile string (empty)
</pre>

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

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

06 00 00 00 Number of records in index (6)

FF FF FF FF 05 00 00 00 1st: shader
FF FF FF FF 05 00 00 00 2nd: shader
FF FF FF FF 04 00 00 00 3rd: material
FF FF FF FF 04 00 00 00 4th: material
FF FF FF FF 04 00 00 00 5th: material
FF FF FF FF 1F 00 00 00 6th: rawfile

FF FF FF FF end separator (the following FF FF FF FF is the start seperator of the next data block!)

----------- [end of index]
</pre>

== Index ==

Starts with an int telling the number of dword couples. Such a couple is composed of 2 ints:

4 byte offset (FF FF FF FF = -1, meaning right after the previous block?) 
4 byte identifier (data block type)

Separator (FF FF FF FF) after last couple

=== 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 07 - soundalias (+audio data)
* 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

Since there is a FF FF FF FF separator in front of every block and none at the very end (after last 1F-block), we can assume that each block has a start separation and no end separation. Thus, any FF FF FF FFs you find after data blocks are actually the start separators of the next block. This means the index end separator is rather FFFFFFFF than FFFFFFFFFFFFFFFF!

=== 00 00 00 04 (material) ===

<pre>
----------- [block start]

FF FF FF FF start separation

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [block end]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [block start]

FF FF FF FF Start separation

00 00 00 00 0x18 bytes of 0x00
FF FF FF FF Or 0x00000000 (if no content further on)
00 00 00 00 0x74 bytes which are often 0x00
?? ?? .. 00 Then techset file name (0x00 termination) if pointer is 0xFFFFFFFF?

----------- [start of shader pack]

pointer
1 dword of some character-length options / flags?
3 pointers
1 dword of some character-length sizes
FF FF FF FF Separator
0x64 bytes of some short length options / flags? If the second pointer above is 0xFFFFFFFF

----------- [start of shader]

pointer, if not 0xFFFFFFFF, no filename is further on
pointer, often 00 00 00 00
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag?
?? ?? .. 00 String if first pointer is 0xFFFFFFFF, 0x00 terminated (name of shader source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff' (technique commands?)
41 10 AB A0 which ends with this (always?)
?? ?? .. 00 String, 0x00 terminated (technique file name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [block end]
</pre>

=== 00 00 00 06 (image) ===

Stores some information about the specified IWI in fastfile. Does not include the actual image data.
Length is 52 bytes + IWI name (+1 for string termination).

<pre>
----------- [block start]
Note: obviously no start separator
03 00 00 00
FE FF FF FF separator?
00 00 00 00
00 00 00 00

70 55 01 00 IWI size minus 28 (0x1C)
70 55 01 00 same

00 01 00 01
01 00 03 00
FF FF FF FF separator?

73 70 .. 00 IWI name without file extension (string + termination, variable size)

00 00 00 01
00 01 01 00

44 58 54 35 00 00 00 00 fixed size char[] for type? (here: DXT5....)

----------- [block end]
</pre>

=== 00 00 00 16 (localized string asset) ===

A localized string asset consists of an alias name and a translated string. During compilation, it takes the given alias name (REFERENCE) from *.str file and prepands the *.str file's name in upper-case plus an underscore. Example:

'''example.str'''
<pre>VERSION "1"
CONFIG "C:\trees\cod3\cod3\bin\StringEd.cfg"
FILENOTES ""
//--------------------------------

REFERENCE MARINES_NAME
LANG_ENGLISH "US Airforce"

//--------------------------------
ENDMARKER</pre>

'''mod.ff'''
<pre>
ÿÿÿÿ
ÿÿÿÿ
EXAMPLE_MARINES_NAME.
US Airforce.
</pre>

Length is 8 bytes + string sizes (string count = 0-2, depends on the first two ints).

<pre>
----------- [block start]
Note: no start separator!

FF FF FF FF either pointer or FFFFFFFF if the string wasn't used before
FF FF FF FF same. If two pointers are used here, then no strings will follow.
55 53 .. 00 alias name for the localized
53 54 .. 00 actual localized string

----------- [block end]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [block start]

FF FF FF FF Start separation

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [block end OR even end of file]
</pre>

=== 00 00 00 20 (stringtable) ===

A compiled stringtable (comma separated list, *.csv). Even values are stored as strings.

<pre>
----------- [block start]

FF FF FF FF start separation

05 00 00 00 (int) columns
02 00 00 00 (int) rows

FF FF FF FF separator
?? ?? .. 00 filename (path/*.csv) + string termination (0x00)

----------- [table cell description]

?? ?? ?? ?? columns * rows integers (5 * 2 * 4 = 40 bytes in total, 5 * 2 = 10 cells)
FF FF FF FF - if the string wasn't used before and follows after the cell description
?? ?? ?? 4? - if an identical string was already used (in another csv). It is some kind of memory offset (pointer). Base address calculation not figured out yet (0x40000072 ?)

----------- [cell content / strings]

?? ?? .. 00 string + termination (0x00)
Number of strings = amount of FF FF FF FFs in table cell description

----------- [block end]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 01:45, 8 December 2009 (UTC)

--[[User:Daevius|Daevius]] 14:24, 5 November 2009 (UTC)

[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-12-08T20:06:01Z

Daevius: /* 00 00 00 05 (shader) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The data block types (also called "index identifier") are written in big endian in this article, e.g. 00 00 00 1F is actually 1F 00 00 00 in ff, although ints and floats in the examples are kept little endian!

The global file layout starts with a header. After which you get a string list (model tag names, animation notetracks, maybe more; not always present). Followed by an index list. This list gives information about the rest of the file, which is a concatenation of compiled files (reinterpreted and linked data generated from source files like d3dbsp and stringtables, hereinafter referred to as data blocks).

* Header
* String list index
* String list
* Data block index
* Data blocks

Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== Header ==

''(Note: not up to date and not generalized)''

*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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> under re-investigation 

=== Example: smallest possible fastfile (mod.ff) ===

<pre>
29 00 00 00 decompressed fastfile size minus 44
00 00 00 00
1C 00 00 00 unknown

00 00 00 00 00 00 00 00 00 00 00 00

0D 00 00 00 data size in memory (?)

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

01 00 00 00 one index entry

FF FF FF FF 1F 00 00 00 a rawfile

FF FF FF FF index end

FF FF FF FF start separator
00 00 00 00 rawfile length (empty, no errors occured during compilation)
FF FF FF FF separator
6D 6F 64 00 fastfile name as rawfile name
00 rawfile string (empty)
</pre>

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

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

06 00 00 00 Number of records in index (6)

FF FF FF FF 05 00 00 00 1st: shader
FF FF FF FF 05 00 00 00 2nd: shader
FF FF FF FF 04 00 00 00 3rd: material
FF FF FF FF 04 00 00 00 4th: material
FF FF FF FF 04 00 00 00 5th: material
FF FF FF FF 1F 00 00 00 6th: rawfile

FF FF FF FF end separator (the following FF FF FF FF is the start seperator of the next data block!)

----------- [end of index]
</pre>

== Index ==

Starts with an int telling the number of dword couples. Such a couple is composed of 2 ints:

4 byte offset (FF FF FF FF = -1, meaning right after the previous block?) 
4 byte identifier (data block type)

Separator (FF FF FF FF) after last couple

=== 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 07 - soundalias (+audio data)
* 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

Since there is a FF FF FF FF separator in front of every block and none at the very end (after last 1F-block), we can assume that each block has a start separation and no end separation. Thus, any FF FF FF FFs you find after data blocks are actually the start separators of the next block. This means the index end separator is rather FFFFFFFF than FFFFFFFFFFFFFFFF!

=== 00 00 00 04 (material) ===

<pre>
----------- [block start]

FF FF FF FF start separation

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [block end]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [block start]

FF FF FF FF Start separation

FF FF FF FF pointer
00 00 00 00 0x18 bytes of 0x00
FF FF FF FF Or 0x00000000 (if no content further on)
00 00 00 00 0x74 bytes which are often 0x00
?? ?? .. 00 Then techset file name (0x00 termination) if pointer is 0xFFFFFFFF?

----------- [start of shader pack]

pointer
1 dword of some character-length options / flags?
3 pointers
1 dword of some character-length sizes
FF FF FF FF Separator
0x64 bytes of some short length options / flags? If the second pointer above is 0xFFFFFFFF

----------- [start of shader]

pointer, if not 0xFFFFFFFF, no filename is further on
pointer, often 00 00 00 00
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag?
?? ?? .. 00 String if first pointer is 0xFFFFFFFF, 0x00 terminated (name of shader source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff' (technique commands?)
41 10 AB A0 which ends with this (always?)
?? ?? .. 00 String, 0x00 terminated (technique file name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [block end]
</pre>

=== 00 00 00 06 (image) ===

Stores some information about the specified IWI in fastfile. Does not include the actual image data.
Length is 52 bytes + IWI name (+1 for string termination).

<pre>
----------- [block start]
Note: obviously no start separator
03 00 00 00
FE FF FF FF separator?
00 00 00 00
00 00 00 00

70 55 01 00 IWI size minus 28 (0x1C)
70 55 01 00 same

00 01 00 01
01 00 03 00
FF FF FF FF separator?

73 70 .. 00 IWI name without file extension (string + termination, variable size)

00 00 00 01
00 01 01 00

44 58 54 35 00 00 00 00 fixed size char[] for type? (here: DXT5....)

----------- [block end]
</pre>

=== 00 00 00 16 (localized string asset) ===

A localized string asset consists of an alias name and a translated string. During compilation, it takes the given alias name (REFERENCE) from *.str file and prepands the *.str file's name in upper-case plus an underscore. Example:

'''example.str'''
<pre>VERSION "1"
CONFIG "C:\trees\cod3\cod3\bin\StringEd.cfg"
FILENOTES ""
//--------------------------------

REFERENCE MARINES_NAME
LANG_ENGLISH "US Airforce"

//--------------------------------
ENDMARKER</pre>

'''mod.ff'''
<pre>
ÿÿÿÿ
ÿÿÿÿ
EXAMPLE_MARINES_NAME.
US Airforce.
</pre>

Length is 8 bytes + string sizes (string count = 0-2, depends on the first two ints).

<pre>
----------- [block start]
Note: no start separator!

FF FF FF FF either pointer or FFFFFFFF if the string wasn't used before
FF FF FF FF same. If two pointers are used here, then no strings will follow.
55 53 .. 00 alias name for the localized
53 54 .. 00 actual localized string

----------- [block end]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [block start]

FF FF FF FF Start separation

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [block end OR even end of file]
</pre>

=== 00 00 00 20 (stringtable) ===

A compiled stringtable (comma separated list, *.csv). Even values are stored as strings.

<pre>
----------- [block start]

FF FF FF FF start separation

05 00 00 00 (int) columns
02 00 00 00 (int) rows

FF FF FF FF separator
?? ?? .. 00 filename (path/*.csv) + string termination (0x00)

----------- [table cell description]

?? ?? ?? ?? columns * rows integers (5 * 2 * 4 = 40 bytes in total, 5 * 2 = 10 cells)
FF FF FF FF - if the string wasn't used before and follows after the cell description
?? ?? ?? 4? - if an identical string was already used (in another csv). It is some kind of memory offset (pointer). Base address calculation not figured out yet (0x40000072 ?)

----------- [cell content / strings]

?? ?? .. 00 string + termination (0x00)
Number of strings = amount of FF FF FF FFs in table cell description

----------- [block end]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 01:45, 8 December 2009 (UTC)

--[[User:Daevius|Daevius]] 14:24, 5 November 2009 (UTC)

[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-12-08T19:55:24Z

Daevius: /* 00 00 00 05 (shader) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The data block types (also called "index identifier") are written in big endian in this article, e.g. 00 00 00 1F is actually 1F 00 00 00 in ff, although ints and floats in the examples are kept little endian!

The global file layout starts with a header. After which you get a string list (model tag names, animation notetracks, maybe more; not always present). Followed by an index list. This list gives information about the rest of the file, which is a concatenation of compiled files (reinterpreted and linked data generated from source files like d3dbsp and stringtables, hereinafter referred to as data blocks).

* Header
* String list index
* String list
* Data block index
* Data blocks

Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== Header ==

''(Note: not up to date and not generalized)''

*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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> under re-investigation 

=== Example: smallest possible fastfile (mod.ff) ===

<pre>
29 00 00 00 decompressed fastfile size minus 44
00 00 00 00
1C 00 00 00 unknown

00 00 00 00 00 00 00 00 00 00 00 00

0D 00 00 00 data size in memory (?)

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

01 00 00 00 one index entry

FF FF FF FF 1F 00 00 00 a rawfile

FF FF FF FF index end

FF FF FF FF start separator
00 00 00 00 rawfile length (empty, no errors occured during compilation)
FF FF FF FF separator
6D 6F 64 00 fastfile name as rawfile name
00 rawfile string (empty)
</pre>

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

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

06 00 00 00 Number of records in index (6)

FF FF FF FF 05 00 00 00 1st: shader
FF FF FF FF 05 00 00 00 2nd: shader
FF FF FF FF 04 00 00 00 3rd: material
FF FF FF FF 04 00 00 00 4th: material
FF FF FF FF 04 00 00 00 5th: material
FF FF FF FF 1F 00 00 00 6th: rawfile

FF FF FF FF end separator (the following FF FF FF FF is the start seperator of the next data block!)

----------- [end of index]
</pre>

== Index ==

Starts with an int telling the number of dword couples. Such a couple is composed of 2 ints:

4 byte offset (FF FF FF FF = -1, meaning right after the previous block?) 
4 byte identifier (data block type)

Separator (FF FF FF FF) after last couple

=== 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 07 - soundalias (+audio data)
* 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

Since there is a FF FF FF FF separator in front of every block and none at the very end (after last 1F-block), we can assume that each block has a start separation and no end separation. Thus, any FF FF FF FFs you find after data blocks are actually the start separators of the next block. This means the index end separator is rather FFFFFFFF than FFFFFFFFFFFFFFFF!

=== 00 00 00 04 (material) ===

<pre>
----------- [block start]

FF FF FF FF start separation

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [block end]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [block start]

FF FF FF FF Start separation

FF FF FF FF pointer
00 00 00 00 0x18 bytes of 0x00
FF FF FF FF Or 0x00000000 (if no content further on)
00 00 00 00 0x74 bytes which are often 0x00
?? ?? .. 00 Then techset file name (0x00 termination) if pointer is 0xFFFFFFFF?

----------- [start of shader pack]

pointer
1 dword of some character-length options / flags?
3 pointers
1 dword of some character-length sizes
FF FF FF FF Separator
0x64 bytes of some short length options / flags? For the first 05 entry? Or if the references above are 0xFFFFFFFF?

----------- [start of shader]

pointer, if not FF FF FF FF, no filename is further on
pointer, often 00 00 00 00
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag?
?? ?? .. 00 String if first pointer is FF FF FF FF, 0x00 terminated (name of shader source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff' (technique commands?)
41 10 AB A0 which ends with this (always?)
?? ?? .. 00 String, 0x00 terminated (technique file name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [block end]
</pre>

=== 00 00 00 06 (image) ===

Stores some information about the specified IWI in fastfile. Does not include the actual image data.
Length is 52 bytes + IWI name (+1 for string termination).

<pre>
----------- [block start]
Note: obviously no start separator
03 00 00 00
FE FF FF FF separator?
00 00 00 00
00 00 00 00

70 55 01 00 IWI size minus 28 (0x1C)
70 55 01 00 same

00 01 00 01
01 00 03 00
FF FF FF FF separator?

73 70 .. 00 IWI name without file extension (string + termination, variable size)

00 00 00 01
00 01 01 00

44 58 54 35 00 00 00 00 fixed size char[] for type? (here: DXT5....)

----------- [block end]
</pre>

=== 00 00 00 16 (localized string asset) ===

A localized string asset consists of an alias name and a translated string. During compilation, it takes the given alias name (REFERENCE) from *.str file and prepands the *.str file's name in upper-case plus an underscore. Example:

'''example.str'''
<pre>VERSION "1"
CONFIG "C:\trees\cod3\cod3\bin\StringEd.cfg"
FILENOTES ""
//--------------------------------

REFERENCE MARINES_NAME
LANG_ENGLISH "US Airforce"

//--------------------------------
ENDMARKER</pre>

'''mod.ff'''
<pre>
ÿÿÿÿ
ÿÿÿÿ
EXAMPLE_MARINES_NAME.
US Airforce.
</pre>

Length is 8 bytes + string sizes (string count = 0-2, depends on the first two ints).

<pre>
----------- [block start]
Note: no start separator!

FF FF FF FF either pointer or FFFFFFFF if the string wasn't used before
FF FF FF FF same. If two pointers are used here, then no strings will follow.
55 53 .. 00 alias name for the localized
53 54 .. 00 actual localized string

----------- [block end]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [block start]

FF FF FF FF Start separation

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [block end OR even end of file]
</pre>

=== 00 00 00 20 (stringtable) ===

A compiled stringtable (comma separated list, *.csv). Even values are stored as strings.

<pre>
----------- [block start]

FF FF FF FF start separation

05 00 00 00 (int) columns
02 00 00 00 (int) rows

FF FF FF FF separator
?? ?? .. 00 filename (path/*.csv) + string termination (0x00)

----------- [table cell description]

?? ?? ?? ?? columns * rows integers (5 * 2 * 4 = 40 bytes in total, 5 * 2 = 10 cells)
FF FF FF FF - if the string wasn't used before and follows after the cell description
?? ?? ?? 4? - if an identical string was already used (in another csv). It is some kind of memory offset (pointer). Base address calculation not figured out yet (0x40000072 ?)

----------- [cell content / strings]

?? ?? .. 00 string + termination (0x00)
Number of strings = amount of FF FF FF FFs in table cell description

----------- [block end]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 01:45, 8 December 2009 (UTC)

--[[User:Daevius|Daevius]] 14:24, 5 November 2009 (UTC)

[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-12-08T19:52:32Z

Daevius: /* 00 00 00 05 (shader) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The data block types (also called "index identifier") are written in big endian in this article, e.g. 00 00 00 1F is actually 1F 00 00 00 in ff, although ints and floats in the examples are kept little endian!

The global file layout starts with a header. After which you get a string list (model tag names, animation notetracks, maybe more; not always present). Followed by an index list. This list gives information about the rest of the file, which is a concatenation of compiled files (reinterpreted and linked data generated from source files like d3dbsp and stringtables, hereinafter referred to as data blocks).

* Header
* String list index
* String list
* Data block index
* Data blocks

Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== Header ==

''(Note: not up to date and not generalized)''

*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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> under re-investigation 

=== Example: smallest possible fastfile (mod.ff) ===

<pre>
29 00 00 00 decompressed fastfile size minus 44
00 00 00 00
1C 00 00 00 unknown

00 00 00 00 00 00 00 00 00 00 00 00

0D 00 00 00 data size in memory (?)

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

01 00 00 00 one index entry

FF FF FF FF 1F 00 00 00 a rawfile

FF FF FF FF index end

FF FF FF FF start separator
00 00 00 00 rawfile length (empty, no errors occured during compilation)
FF FF FF FF separator
6D 6F 64 00 fastfile name as rawfile name
00 rawfile string (empty)
</pre>

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

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

06 00 00 00 Number of records in index (6)

FF FF FF FF 05 00 00 00 1st: shader
FF FF FF FF 05 00 00 00 2nd: shader
FF FF FF FF 04 00 00 00 3rd: material
FF FF FF FF 04 00 00 00 4th: material
FF FF FF FF 04 00 00 00 5th: material
FF FF FF FF 1F 00 00 00 6th: rawfile

FF FF FF FF end separator (the following FF FF FF FF is the start seperator of the next data block!)

----------- [end of index]
</pre>

== Index ==

Starts with an int telling the number of dword couples. Such a couple is composed of 2 ints:

4 byte offset (FF FF FF FF = -1, meaning right after the previous block?) 
4 byte identifier (data block type)

Separator (FF FF FF FF) after last couple

=== 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 07 - soundalias (+audio data)
* 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

Since there is a FF FF FF FF separator in front of every block and none at the very end (after last 1F-block), we can assume that each block has a start separation and no end separation. Thus, any FF FF FF FFs you find after data blocks are actually the start separators of the next block. This means the index end separator is rather FFFFFFFF than FFFFFFFFFFFFFFFF!

=== 00 00 00 04 (material) ===

<pre>
----------- [block start]

FF FF FF FF start separation

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [block end]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [block start]

FF FF FF FF Start separation

FF FF FF FF ID/reference? First is always 0xFFFFFFFF, later on you can also see 0x??????40
00 00 00 00 0x18 bytes of 0x00
FF FF FF FF Or 0x00000000 (if no content further on)
00 00 00 00 0x74 bytes which are often 0x00
?? ?? .. 00 Then techset file name (0x00 termination) if fist dword is 0xFFFFFFFF?

----------- [start of shader pack]

1 dword of ID/reference?
1 dword of some character-length options / flags?
3 dwords of ID/references?
1 dword of some character-length sizes
FF FF FF FF Separator
0x64 bytes of some short length options / flags? For the first 05 entry? Or if the references above are 0xFFFFFFFF?

----------- [start of shader]

1 pointer, if not FF FF FF FF, no filename is further on
1 pointer, often 00 00 00 00
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag?
?? ?? .. 00 String if first pointer is FF FF FF FF, 0x00 terminated (name of shader source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff' ('technique' commands?)
41 10 AB A0 which ends with this (always?)
?? ?? .. 00 String, 0x00 terminated (technique file name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [block end]
</pre>

=== 00 00 00 06 (image) ===

Stores some information about the specified IWI in fastfile. Does not include the actual image data.
Length is 52 bytes + IWI name (+1 for string termination).

<pre>
----------- [block start]
Note: obviously no start separator
03 00 00 00
FE FF FF FF separator?
00 00 00 00
00 00 00 00

70 55 01 00 IWI size minus 28 (0x1C)
70 55 01 00 same

00 01 00 01
01 00 03 00
FF FF FF FF separator?

73 70 .. 00 IWI name without file extension (string + termination, variable size)

00 00 00 01
00 01 01 00

44 58 54 35 00 00 00 00 fixed size char[] for type? (here: DXT5....)

----------- [block end]
</pre>

=== 00 00 00 16 (localized string asset) ===

A localized string asset consists of an alias name and a translated string. During compilation, it takes the given alias name (REFERENCE) from *.str file and prepands the *.str file's name in upper-case plus an underscore. Example:

'''example.str'''
<pre>VERSION "1"
CONFIG "C:\trees\cod3\cod3\bin\StringEd.cfg"
FILENOTES ""
//--------------------------------

REFERENCE MARINES_NAME
LANG_ENGLISH "US Airforce"

//--------------------------------
ENDMARKER</pre>

'''mod.ff'''
<pre>
ÿÿÿÿ
ÿÿÿÿ
EXAMPLE_MARINES_NAME.
US Airforce.
</pre>

Length is 8 bytes + string sizes (string count = 0-2, depends on the first two ints).

<pre>
----------- [block start]
Note: no start separator!

FF FF FF FF either pointer or FFFFFFFF if the string wasn't used before
FF FF FF FF same. If two pointers are used here, then no strings will follow.
55 53 .. 00 alias name for the localized
53 54 .. 00 actual localized string

----------- [block end]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [block start]

FF FF FF FF Start separation

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [block end OR even end of file]
</pre>

=== 00 00 00 20 (stringtable) ===

A compiled stringtable (comma separated list, *.csv). Even values are stored as strings.

<pre>
----------- [block start]

FF FF FF FF start separation

05 00 00 00 (int) columns
02 00 00 00 (int) rows

FF FF FF FF separator
?? ?? .. 00 filename (path/*.csv) + string termination (0x00)

----------- [table cell description]

?? ?? ?? ?? columns * rows integers (5 * 2 * 4 = 40 bytes in total, 5 * 2 = 10 cells)
FF FF FF FF - if the string wasn't used before and follows after the cell description
?? ?? ?? 4? - if an identical string was already used (in another csv). It is some kind of memory offset (pointer). Base address calculation not figured out yet (0x40000072 ?)

----------- [cell content / strings]

?? ?? .. 00 string + termination (0x00)
Number of strings = amount of FF FF FF FFs in table cell description

----------- [block end]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 01:45, 8 December 2009 (UTC)

--[[User:Daevius|Daevius]] 14:24, 5 November 2009 (UTC)

[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-09T14:49:13Z

Daevius: /* 00 00 00 05 (shader) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The global file layout starts with a header. After which you get a list a model tag names, after which you get an index list. This list gives information about the rest of the file, which is a concatenation of files, most of which are reinterpreted. Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

06 00 00 00 Number of records in index (6)

FF FF FF FF 05 00 00 00 1st: shader
FF FF FF FF 05 00 00 00 2nd: shader
FF FF FF FF 04 00 00 00 3rd: material
FF FF FF FF 04 00 00 00 4th: material
FF FF FF FF 04 00 00 00 5th: material
FF FF FF FF 1F 00 00 00 6th: rawfile

----------- [end of index]
</pre>

== 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

=== 00 00 00 04 ===

<pre>
----------- [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [end separation]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [start separation]

FF FF FF FF ID/reference? First is always 0xFFFFFFFF, later on you can also see 0x??????40
00 00 00 00 0x18 bytes of 0x00
FF FF FF FF Or 0x00000000 (if no content further on)
00 00 00 00 0x74 bytes which are often 0x00
?? ?? .. 00 Then techset file name (0x00 termination) if fist dword is 0xFFFFFFFF?

----------- [start of shader pack]

1 dword of ID/reference?
1 dword of some character-length options / flags?
3 dwords of ID/references?
1 dword of some character-length sizes
FF FF FF FF Separator
0x64 bytes of some short length options / flags? For the first 05 entry? Or if the references above are 0xFFFFFFFF?

----------- [start of shader]

2 dwords of references
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag? When set no string follows?
?? ?? .. 00 String if previous second short is 00 00, 0x00 terminated (name of shader source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff'
41 10 AB A0 which ends with this (always?)
?? ?? .. 00 String, 0x00 terminated (technique file name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [end separation]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [end separation OR end of file]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:24, 5 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-09T14:04:07Z

Daevius: /* Example: mp_backlot_load.ff */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The global file layout starts with a header. After which you get a list a model tag names, after which you get an index list. This list gives information about the rest of the file, which is a concatenation of files, most of which are reinterpreted. Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

06 00 00 00 Number of records in index (6)

FF FF FF FF 05 00 00 00 1st: shader
FF FF FF FF 05 00 00 00 2nd: shader
FF FF FF FF 04 00 00 00 3rd: material
FF FF FF FF 04 00 00 00 4th: material
FF FF FF FF 04 00 00 00 5th: material
FF FF FF FF 1F 00 00 00 6th: rawfile

----------- [end of index]
</pre>

== 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

=== 00 00 00 04 ===

<pre>
----------- [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [end separation]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [start separation]

00 00 00 00 0x24 dwords of 0x00000000 and sometimes 0xFFFFFFFF (looks like 3x 0x30 in length)
?? ?? .. 00 Then techset file name (0x00 termination)

----------- [start of shader pack]

1 dword of reference?
1 dword of some character-length options / flags?
3 dwords of references?
1 dword of some character-length sizes
FF FF FF FF Separator
0x64 bytes of some short length options / flags? For the first 05 entry? Or if the references above are 0xFFFFFFFF?

----------- [start of shader]

2 dwords of references
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag? When set no string follows?
?? ?? .. 00 String if previous second short is 00 00, 0x00 terminated (name of shader source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff', looks like it's of length of the 'character-length sizes' added to each other in the header of a shader pack multiplied by 8
?? ?? .. 00 String, 0x00 terminated (technique file name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [end separation]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [end separation OR end of file]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:24, 5 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-08T14:50:52Z

Daevius: /* 00 00 00 05 (shader) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The global file layout starts with a header. After which you get a list a model tag names, after which you get an index list. This list gives information about the rest of the file, which is a concatenation of files, most of which are reinterpreted. Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

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: rawfile
FF FF FF FF Separator

----------- [end of index]
</pre>

== 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

=== 00 00 00 04 ===

<pre>
----------- [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [end separation]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [start separation]

00 00 00 00 0x24 dwords of 0x00000000 and sometimes 0xFFFFFFFF (looks like 3x 0x30 in length)
?? ?? .. 00 Then techset file name (0x00 termination)

----------- [start of shader pack]

1 dword of reference?
1 dword of some character-length options / flags?
3 dwords of references?
1 dword of some character-length sizes
FF FF FF FF Separator
0x64 bytes of some short length options / flags? For the first 05 entry? Or if the references above are 0xFFFFFFFF?

----------- [start of shader]

2 dwords of references
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag? When set no string follows?
?? ?? .. 00 String if previous second short is 00 00, 0x00 terminated (name of shader source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff', looks like it's of length of the 'character-length sizes' added to each other in the header of a shader pack multiplied by 8
?? ?? .. 00 String, 0x00 terminated (technique file name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [end separation]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [end separation OR end of file]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:24, 5 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-08T14:40:52Z

Daevius: /* 00 00 00 05 (shader) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The global file layout starts with a header. After which you get a list a model tag names, after which you get an index list. This list gives information about the rest of the file, which is a concatenation of files, most of which are reinterpreted. Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

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: rawfile
FF FF FF FF Separator

----------- [end of index]
</pre>

== 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

=== 00 00 00 04 ===

<pre>
----------- [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [end separation]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [start separation]

00 00 00 00 0x24 dwords of 0x00000000 and sometimes 0xFFFFFFFF (looks like 3x 0x30 in length)
?? ?? .. 00 Then techset file name (0x00 termination)

----------- [start of shader pack]

1 dword of reference?
1 dword of some character-length options / flags?
3 dwords of references?
1 dword of some character-length sizes
FF FF FF FF Separator
0x64 bytes of some short length options / flags? For the first 05 entry? Or if the references above are 0xFFFFFFFF?

----------- [start of shader]

2 dwords of references
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag? When set no string follows?
?? ?? .. 00 String if previous second short is 00 00, 0x00 terminated (name of source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff', looks like it's of length of the 'character-length sizes' added to each other in the header of a shader pack multiplied by 8
?? ?? .. 00 String, 0x00 terminated (probably in-game usage name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [end separation]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [end separation OR end of file]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:24, 5 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-08T14:25:23Z

Daevius: /* 00 00 00 05 (shader) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The global file layout starts with a header. After which you get a list a model tag names, after which you get an index list. This list gives information about the rest of the file, which is a concatenation of files, most of which are reinterpreted. Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

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: rawfile
FF FF FF FF Separator

----------- [end of index]
</pre>

== 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

=== 00 00 00 04 ===

<pre>
----------- [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [end separation]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [start separation]

00 00 00 00 0x24 dwords of 0x00000000 and sometimes 0xFFFFFFFF (looks like 3x 0x30 in length)
?? ?? .. 00 Then (file) name (0x00 termination)

----------- [start of shader pack]

1 dword of reference?
1 dword of some character-length options / flags?
3 dwords of references?
1 dword of some character-length sizes
FF FF FF FF Separator
0x64 bytes of some short length options / flags? For the first 05 entry? Or if the references above are 0xFFFFFFFF?

----------- [start of shader]

2 dwords of references
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag? When set no string follows?
?? ?? .. 00 String if previous second short is 00 00, 0x00 terminated (name of source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff', looks like it's of length of the 'character-length sizes' added to each other in the header of a shader pack multiplied by 8
?? ?? .. 00 String, 0x00 terminated (probably in-game usage name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [end separation]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [end separation OR end of file]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:24, 5 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-08T14:07:51Z

Daevius: /* 00 00 00 05 (shader) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The global file layout starts with a header. After which you get a list a model tag names, after which you get an index list. This list gives information about the rest of the file, which is a concatenation of files, most of which are reinterpreted. Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

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: rawfile
FF FF FF FF Separator

----------- [end of index]
</pre>

== 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

=== 00 00 00 04 ===

<pre>
----------- [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [end separation]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [start separation]

00 00 00 00 0x24 dwords of 0x00000000 and sometimes 0xFFFFFFFF (looks like 3x 0x30 in length)
?? ?? .. 00 Then (file) name (0x00 termination)

----------- [start of shader pack]

1 dword of reference?
1 dword of some character-length options / flags?
3 dwords of references?
1 dword of some character-length sizes
FF FF FF FF Separator
0x19 dwords of some short length options / flags? For the first 05 entry? Or if the references above are 0xFFFFFFFF?
FF FF FF FF Separator for the first 05 entry? Or if the references above are 0xFFFFFFFF?

----------- [start of shader]

2 dwords of references
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag? When set no string follows?
?? ?? .. 00 String if previous second short is 00 00, 0x00 terminated (name of source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff', looks like it's of length of the 'character-length sizes' added to each other in the header of a shader pack multiplied by 8
?? ?? .. 00 String, 0x00 terminated (probably in-game usage name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [end separation]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [end separation OR end of file]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:24, 5 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-08T13:37:17Z

Daevius: /* 00 00 00 05 (shader) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The global file layout starts with a header. After which you get a list a model tag names, after which you get an index list. This list gives information about the rest of the file, which is a concatenation of files, most of which are reinterpreted. Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

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: rawfile
FF FF FF FF Separator

----------- [end of index]
</pre>

== 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

=== 00 00 00 04 ===

<pre>
----------- [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [end separation]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [start separation]

00 00 00 00 0x24 dwords of 0x00000000 and sometimes 0xFFFFFFFF (looks like 3x 0x30 in length)
?? ?? .. 00 Then (file) name (0x00 termination)

----------- [start of shader pack]

1 dword of reference? (sometimes 2)
1 dword of some character length options / flags?
3 dwords of references?
1 dword of some character length options / flags?
FF FF FF FF Separator
0x19 dwords of some short length options / flags? For the first 05 entry? Or if the references above are 0xFFFFFFFF?
FF FF FF FF Separator for the first 05 entry? Or if the references above are 0xFFFFFFFF?

----------- [start of shader]

2 dwords of references
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag? When set no string follows?
?? ?? .. 00 String if previous second short is 00 00, 0x00 terminated (name of source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff' (often 0x08 (last shader pack) or 0x64 in length)
?? ?? .. 00 String, 0x00 terminated (probably in-game usage name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [end separation]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [end separation OR end of file]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:24, 5 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-08T13:33:53Z

Daevius: /* 00 00 00 05 (shader) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The global file layout starts with a header. After which you get a list a model tag names, after which you get an index list. This list gives information about the rest of the file, which is a concatenation of files, most of which are reinterpreted. Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

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: rawfile
FF FF FF FF Separator

----------- [end of index]
</pre>

== 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

=== 00 00 00 04 ===

<pre>
----------- [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [end separation]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [start separation]

00 00 00 00 0x24 dwords of 0x00000000 and sometimes 0xFFFFFFFF (looks like 3x 0x30 in length)
?? ?? .. 00 Then (file) name (0x00 termination)

----------- [start of shader pack]

1 dword of reference? (sometimes 2)
1 dword of some character length options / flags?
3 dwords of references?
1 dword of some character length options / flags?
FF FF FF FF Separator
0x19 dwords of some short length options / flags? For the first 05 entry? Or if the references above are 0xFFFFFFFF?
FF FF FF FF Separator for the first 05 entry? Or if the references above are 0xFFFFFFFF?

----------- [start of shader]

2 dwords of references
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag? When set no string follows?
?? ?? .. 00 String if previous second short is 00 00, 0x00 terminated (name of source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff'
?? ?? .. 00 String, 0x00 terminated (probably in-game usage name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [end separation]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [end separation OR end of file]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:24, 5 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-07T13:05:11Z

Daevius: /* 00 00 00 05 (shader) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The global file layout starts with a header. After which you get a list a model tag names, after which you get an index list. This list gives information about the rest of the file, which is a concatenation of files, most of which are reinterpreted. Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

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: rawfile
FF FF FF FF Separator

----------- [end of index]
</pre>

== 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

=== 00 00 00 04 ===

<pre>
----------- [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [end separation]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [start separation]

00 00 00 00 0x24 dwords of 0x00000000 and sometimes 0xFFFFFFFF (looks like 3x 0x30 in length)
?? ?? .. 00 Then (file) name (0x00 termination)

----------- [start of shader pack]

1 dword of reference?
1 dword of some character length options / flags?
3 dwords of references?
1 dword of some character length options / flags?
FF FF FF FF Separator
0x19 dwords of some short length options / flags? For the first 05 entry? Or if the references above are 0xFFFFFFFF?
FF FF FF FF Separator for the first 05 entry? Or if the references above are 0xFFFFFFFF?

----------- [start of shader]

2 dwords of references
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag? When set no string follows?
?? ?? .. 00 String if previous second short is 00 00, 0x00 terminated (name of source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff'
?? ?? .. 00 String, 0x00 terminated (probably in-game usage name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [end separation]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [end separation OR end of file]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:24, 5 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-07T13:00:41Z

Daevius: /* 00 00 00 05 (shader) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The global file layout starts with a header. After which you get a list a model tag names, after which you get an index list. This list gives information about the rest of the file, which is a concatenation of files, most of which are reinterpreted. Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

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: rawfile
FF FF FF FF Separator

----------- [end of index]
</pre>

== 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

=== 00 00 00 04 ===

<pre>
----------- [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [end separation]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [start separation]

00 00 00 00 0x24 dwords of 0x00000000 and sometimes 0xFFFFFFFF (looks like 3x 0x30 in length)
?? ?? .. 00 Then (file) name (0x00 termination)

----------- [start of shader pack]

1 dword of reference?
1 dword of some character length options / flags?
3 dwords of references?
1 dword of some character length options / flags?
FF FF FF FF Separator
0x19 dwords of some short length options / flags? for the first 05 entry?
FF FF FF FF Separator for the first 05 entry?

----------- [start of shader]

2 dwords of references
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag? When set no string follows?
?? ?? .. 00 String if previous second short is 00 00, 0x00 terminated (name of source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff'
?? ?? .. 00 String, 0x00 terminated (probably in-game usage name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [end separation]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [end separation OR end of file]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:24, 5 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-07T12:58:39Z

Daevius: /* 00 00 00 05 (shader) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The global file layout starts with a header. After which you get a list a model tag names, after which you get an index list. This list gives information about the rest of the file, which is a concatenation of files, most of which are reinterpreted. Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

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: rawfile
FF FF FF FF Separator

----------- [end of index]
</pre>

== 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

=== 00 00 00 04 ===

<pre>
----------- [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [end separation]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [start separation]

00 00 00 00 0x24 dwords of 0x00000000 and sometimes 0xFFFFFFFF (looks like 3x 0x30 in length)
?? ?? .. 00 Then (file) name (0x00 termination)

----------- [start of shader pack]

1 dword of reference?
1 dword of some character length options / flags?
3 dwords of references?
1 dword of some character length options / flags?
FF FF FF FF Separator
0x19 dwords of some short length options / flags?
FF FF FF FF Separator

----------- [start of shader]

2 dwords of references
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag? When set no string follows?
?? ?? .. 00 String if previous second short is 00 00, 0x00 terminated (name of source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff'
?? ?? .. 00 String, 0x00 terminated (probably in-game usage name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [end separation]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [end separation OR end of file]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:24, 5 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-07T12:54:16Z

Daevius:

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Preface ==

Be aware, FF files are little endian, so swap those bytes 'round!

The global file layout starts with a header. After which you get a list a model tag names, after which you get an index list. This list gives information about the rest of the file, which is a concatenation of files, most of which are reinterpreted. Each file is separated by the separation key: 0xFFFFFFFF. But be aware, each file itself can also contain such a sequence which is not meant to be the separation key! So it is necessary to understand each data type in the FF file.

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [start of file and header]

71 03 00 00 Decompressed file size - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00 Size of both IWI's 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 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
E5 00 00 00 Size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown
00 00 00 00 Unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 Unknown, is sometimes FF FF FF FF

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: rawfile
FF FF FF FF Separator

----------- [end of index]
</pre>

== 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

=== 00 00 00 04 ===

<pre>
----------- [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

----------- [end separation]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
----------- [start separation]

00 00 00 00 0x24 dwords of 0x00000000 and sometimes 0xFFFFFFFF (looks like 3x 0x30 in length)
?? ?? .. 00 Then (file) name (0x00 termination)

----------- [start of shader pack]

1 dword of reference?
1 dword of some character length options / flags?
3 dwords of references?
1 dword of some character length options / flags?
FF FF FF FF Separator
0x19 dwords of some short length options / flags?

----------- [start of shader]

2 dwords of references
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag? When set no string follows?
?? ?? .. 00 String if previous second short is 00 00, 0x00 terminated (name of source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff'
?? ?? .. 00 String, 0x00 terminated (probably in-game usage name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

----------- [end separation]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
----------- [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF Separator

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

----------- [end separation OR end of file]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:24, 5 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-07T12:48:00Z

Daevius: /* Example: mp_backlot_load.ff */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

Be aware, FF files are little endian, so swap those bytes 'round!

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [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 unknown
00 00 00 00 unknown
00 00 00 00 unknown
E5 00 00 00 size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 unknown, is sometimes FF FF FF FF

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: rawfile
FF FF FF FF separator

----------- [end of index]
</pre>

== 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

=== 00 00 00 04 ===

<pre>
FF FF FF FF [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

FF FF FF FF [end separation]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
FF FF FF FF [start separation]

00 00 00 00 0x24 dwords of 0x00000000 and sometimes 0xFFFFFFFF (looks like 3x 0x30 in length)
?? ?? .. 00 Then (file) name (0x00 termination)

----------- [start of shader pack]

1 dword of reference?
1 dword of some character length options / flags?
3 dwords of references?
1 dword of some character length options / flags?
FF FF FF FF Separator
0x19 dwords of some short length options / flags?

----------- [start of shader]

2 dwords of references
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag? When set no string follows?
?? ?? .. 00 String if previous second short is 00 00, 0x00 terminated (name of source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff'
?? ?? .. 00 String, 0x00 terminated (probably in-game usage name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

FF FF FF FF [end separation]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
FF FF FF FF [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF [separator]

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

FF FF FF FF [end separation OR end of file]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:24, 5 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-07T12:45:01Z

Daevius: /* 00 00 00 05 (shader) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

Be aware, FF files are little endian, so swap those bytes 'round!

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [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 unknown
00 00 00 00 unknown
00 00 00 00 unknown
E5 00 00 00 size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 unknown, is sometimes FF FF FF FF

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]
</pre>

== 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

=== 00 00 00 04 ===

<pre>
FF FF FF FF [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

FF FF FF FF [end separation]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
FF FF FF FF [start separation]

00 00 00 00 0x24 dwords of 0x00000000 and sometimes 0xFFFFFFFF (looks like 3x 0x30 in length)
?? ?? .. 00 Then (file) name (0x00 termination)

----------- [start of shader pack]

1 dword of reference?
1 dword of some character length options / flags?
3 dwords of references?
1 dword of some character length options / flags?
FF FF FF FF Separator
0x19 dwords of some short length options / flags?

----------- [start of shader]

2 dwords of references
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag? When set no string follows?
?? ?? .. 00 String if previous second short is 00 00, 0x00 terminated (name of source file)
Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff'
?? ?? .. 00 String, 0x00 terminated (probably in-game usage name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

FF FF FF FF [end separation]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
FF FF FF FF [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF [separator]

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

FF FF FF FF [end separation OR end of file]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:24, 5 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-07T12:43:49Z

Daevius: /* 00 00 00 05 (shader) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

Be aware, FF files are little endian, so swap those bytes 'round!

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [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 unknown
00 00 00 00 unknown
00 00 00 00 unknown
E5 00 00 00 size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 unknown, is sometimes FF FF FF FF

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]
</pre>

== 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

=== 00 00 00 04 ===

<pre>
FF FF FF FF [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

FF FF FF FF [end separation]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
FF FF FF FF [start separation]

00 00 00 00 0x24 dwords of 0x00000000 and sometimes 0xFFFFFFFF (looks like 3x 0x30 in length)
?? ?? .. 00 Then (file) name (0x00 termination)

----------- [start of shader pack]

1 dword of reference?
1 dword of some character length options / flags?
3 dwords of references?
1 dword of some character length options / flags?
FF FF FF FF Separator
0x19 dwords of some short length options / flags?

----------- [start of shader]

2 dwords of references
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag? When set no string follows?
?? ?? .. 00 String if previous second short is 00 00, 0x00 terminated (name of source file)

----------- [start of shader data]

Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader data]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff'
?? ?? .. 00 String, 0x00 terminated (probably in-game usage name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

FF FF FF FF [end separation]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
FF FF FF FF [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF [separator]

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

FF FF FF FF [end separation OR end of file]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:24, 5 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-07T12:34:25Z

Daevius: /* 00 00 00 05 (shader) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

Be aware, FF files are little endian, so swap those bytes 'round!

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [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 unknown
00 00 00 00 unknown
00 00 00 00 unknown
E5 00 00 00 size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 unknown, is sometimes FF FF FF FF

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]
</pre>

== 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

=== 00 00 00 04 ===

<pre>
FF FF FF FF [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

FF FF FF FF [end separation]
</pre>

=== 00 00 00 05 (shader) ===

A shader consists of 3 levels. One, the top level, consists of a header (with a name inside). Then the next level is a pack of shaders, it has a header, shaders and at the end a name. Then the bottom level is the shader itself, it has a header (containing a name of the source file and the length of the data) and the raw shader data.

<pre>
FF FF FF FF [start separation]

00 00 00 00 0x24 dwords of 0x00000000 and sometimes 0xFFFFFFFF (looks like 3x 0x30 in length)
?? ?? .. 00 Then (file) name (0x00 termination)

----------- [start of shader pack]

1 dword of reference?
1 dword of some character length options / flags?
3 dwords of references?
1 dword of some character length options / flags?
FF FF FF FF Separator
0x19 dwords of some short length options / flags?

----------- [start of shader]

2 dwords of references
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag? When set no string follows?
?? ?? .. 00 String if previous second short is 00 00, 0x00 terminated (name of source file)

----------- [start of shader data]

Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 which ends with this (always?)

----------- [end of shader data]

Can either have more shaders (go back to [start of shader]) or shaders have ended

Variable length of 'stuff'
?? ?? .. 00 String, 0x00 terminated (probably in-game usage name)

----------- [end of shader pack]

Can either have more shader packs (go back to [start of shader pack]) or shader packs have ended

FF FF FF FF [end separation]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
FF FF FF FF [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF [separator]

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

FF FF FF FF [end separation OR end of file]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:24, 5 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-05T21:23:08Z

Daevius: /* 00 00 00 05 (shader) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

Be aware, FF files are little endian, so swap those bytes 'round!

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [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 unknown
00 00 00 00 unknown
00 00 00 00 unknown
E5 00 00 00 size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 unknown, is sometimes FF FF FF FF

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]
</pre>

== 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

=== 00 00 00 04 ===

<pre>
FF FF FF FF [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

FF FF FF FF [end separation]
</pre>

=== 00 00 00 05 (shader) ===

<pre>
FF FF FF FF [start separation]

00 00 00 00 0x22 times 0x00000000 and sometimes 0xFFFFFFFF
?? ?? .. 00 Then (file) name (0x00 termination)
0x18 bytes of references (4 bytes per reference)?
FF FF FF FF Separator
Variable length

----------- [start of shader data]

At least 2 dwords, something to do with references / offsets? (first entry had: FFFFFFFF00000000; second entry had: C100004000000000)
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag? When set no string follows?
?? ?? .. 00 String if previous second short is 00 00, 0x00 terminated.

Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 End of shader file (always?)

Can either have more shaders (go back to [start of shader data]) or shader data has ended

----------- [end of shader data]

0x18 bytes of more data
?? ?? .. 00 String, 0x00 terminated

FF FF FF FF [end separation]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
FF FF FF FF [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF [separator]

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

FF FF FF FF [end separation OR end of file]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:24, 5 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-05T14:24:33Z

Daevius:

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

Be aware, FF files are little endian, so swap those bytes 'round!

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [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 unknown
00 00 00 00 unknown
00 00 00 00 unknown
E5 00 00 00 size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 unknown, is sometimes FF FF FF FF

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]
</pre>

== 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

=== 00 00 00 04 ===

<pre>
FF FF FF FF [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

FF FF FF FF [end separation]
</pre>

=== 00 00 00 05 (shader) ===

<pre>
FF FF FF FF [start separation]

00 00 00 00 0x22 times 0x00000000 and sometimes 0xFFFFFFFF
?? ?? .. 00 Then (file) name (0x00 termination)
0x18 bytes of references (4 bytes per reference)?
FF FF FF FF Separator
Variable length
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag? When set no string follows?
?? ?? .. 00 String if previous second short is 00 00, 0x00 terminated.

Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 End of shader file (always?)
0x18 bytes of more data
?? ?? .. 00 String, 0x00 terminated

FF FF FF FF [end separation]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
FF FF FF FF [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF [separator]

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

FF FF FF FF [end separation OR end of file]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:24, 5 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-05T14:23:52Z

Daevius:

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

Be aware, FF files are little endian, so swap those bytes 'round!

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [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 unknown
00 00 00 00 unknown
00 00 00 00 unknown
E5 00 00 00 size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 unknown, is sometimes FF FF FF FF

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]
</pre>

== 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

=== 00 00 00 04 ===

<pre>
FF FF FF FF [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

FF FF FF FF [end separation]
</pre>

=== 00 00 00 05 (shader) ===

<pre>
FF FF FF FF [start separation]

00 00 00 00 0x22 times 0x00000000 and sometimes 0xFFFFFFFF
?? ?? .. 00 Then (file) name (0x00 termination)
0x18 bytes of references (4 bytes per reference)?
FF FF FF FF Separator
Variable length
FF FF FF FF Separator
?? ?? 00 00 2 shorts, first short multiplied by 4 gives the length of the shader, second is a flag? When set no string follows?
?? ?? .. 00 String if previous second short is 00 00, 0x00 terminated.

Raw shader file (except the first 4 bytes, which, in the shader file, denotes the length of the file)
FF FF 00 00 End of shader file (always?)
0x18 bytes of more data
?? ?? .. 00 String, 0x00 terminated

FF FF FF FF [end separation]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
FF FF FF FF [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF [separator]

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

FF FF FF FF [end separation OR end of file]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:32, 4 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-05T12:37:06Z

Daevius: /* Example: mp_backlot_load.ff */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

Be aware, FF files are little endian, so swap those bytes 'round!

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [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 unknown
00 00 00 00 unknown
00 00 00 00 unknown
E5 00 00 00 size of fastfile in memory (that is at least without header and separators, and maybe more)
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 unknown, is sometimes FF FF FF FF

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]
</pre>

== 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

=== 00 00 00 04 ===

<pre>
FF FF FF FF [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

FF FF FF FF [end separation]
</pre>

=== 00 00 00 05 ===

<pre>
FF FF FF FF [start separation]

00 00 00 00 0x90 times 0x00
Then filename (0x00 termination)

FF FF FF FF [end separation]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
FF FF FF FF [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF [separator]

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

FF FF FF FF [end separation OR end of file]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:32, 4 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-05T12:07:30Z

Daevius: /* 00 00 00 04 */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

Be aware, FF files are little endian, so swap those bytes 'round!

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [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 unknown
00 00 00 00 unknown
00 00 00 00 unknown
E5 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 unknown, is sometimes FF FF FF FF

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]
</pre>

== 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

=== 00 00 00 04 ===

<pre>
FF FF FF FF [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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...
02 00 0E E0 Often ends with this

FF FF FF FF [end separation]
</pre>

=== 00 00 00 05 ===

<pre>
FF FF FF FF [start separation]

00 00 00 00 0x90 times 0x00
Then filename (0x00 termination)

FF FF FF FF [end separation]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
FF FF FF FF [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF [separator]

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

FF FF FF FF [end separation OR end of file]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:32, 4 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-05T11:45:35Z

Daevius: /* Types */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

Be aware, FF files are little endian, so swap those bytes 'round!

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [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 unknown
00 00 00 00 unknown
00 00 00 00 unknown
E5 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 unknown, is sometimes FF FF FF FF

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]
</pre>

== 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 - raw file
* 00 00 00 20 - stringtable (comma separated list)

== Content ==

=== 00 00 00 04 ===

<pre>
FF FF FF FF [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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]
</pre>

=== 00 00 00 05 ===

<pre>
FF FF FF FF [start separation]

00 00 00 00 0x90 times 0x00
Then filename (0x00 termination)

FF FF FF FF [end separation]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
FF FF FF FF [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF [separator]

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

FF FF FF FF [end separation OR end of file]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:32, 4 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-05T11:45:11Z

Daevius: /* 00 00 00 1F (rawfile) */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

Be aware, FF files are little endian, so swap those bytes 'round!

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [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 unknown
00 00 00 00 unknown
00 00 00 00 unknown
E5 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 unknown, is sometimes FF FF FF FF

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]
</pre>

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

<pre>
FF FF FF FF [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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]
</pre>

=== 00 00 00 05 ===

<pre>
FF FF FF FF [start separation]

00 00 00 00 0x90 times 0x00
Then filename (0x00 termination)

FF FF FF FF [end separation]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
FF FF FF FF [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF [separator]

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)
?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

FF FF FF FF [end separation OR end of file]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:32, 4 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-05T11:44:58Z

Daevius: /* 00 00 00 1F */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

Be aware, FF files are little endian, so swap those bytes 'round!

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [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 unknown
00 00 00 00 unknown
00 00 00 00 unknown
E5 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 unknown, is sometimes FF FF FF FF

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]
</pre>

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

<pre>
FF FF FF FF [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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]
</pre>

=== 00 00 00 05 ===

<pre>
FF FF FF FF [start separation]

00 00 00 00 0x90 times 0x00
Then filename (0x00 termination)

FF FF FF FF [end separation]
</pre>

=== 00 00 00 1F (rawfile) ===

A rawfile. Often a rawfile named right after the fastfile's name is implicitly added. It contains the errors thrown when it was compiling / linking.

<pre>
FF FF FF FF [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF [separator]

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)

?? ?? .. 00 Plain text content of length above (string, terminated by 0x00)

FF FF FF FF [end separation OR end of file]
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:32, 4 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-05T11:30:43Z

Daevius: /* 00 00 00 1F */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

Be aware, FF files are little endian, so swap those bytes 'round!

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [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 unknown
00 00 00 00 unknown
00 00 00 00 unknown
E5 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 unknown, is sometimes FF FF FF FF

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]
</pre>

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

<pre>
FF FF FF FF [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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]
</pre>

=== 00 00 00 05 ===

<pre>
FF FF FF FF [start separation]

00 00 00 00 0x90 times 0x00
Then filename (0x00 termination)

FF FF FF FF [end separation]
</pre>

=== 00 00 00 1F ===

Often at the end of a FastFile, also used for GSC scripts and other plaintext files. Compiled into FF by use of rawfile,PATH/FILE.EXT in zone file.

<pre>
FF FF FF FF [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF [separator]

6D 6F 64 00 File name or if it's the last 1F-block FastFile name (example: mod.)

?? ?? .. 00 Plain text content (string, terminated by 0x00),
If at the end of the FF file, then it contains errors and warnings generated by the compiler/linker
Else it's empty (thus only the string termination character)
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:32, 4 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-05T11:30:21Z

Daevius: /* 00 00 00 1F */

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

Be aware, FF files are little endian, so swap those bytes 'round!

== 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-23: ''unknown''
*Byte 24-27: somehow related to ff size?
*Byte 28-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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [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 unknown
00 00 00 00 unknown
00 00 00 00 unknown
E5 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 unknown, is sometimes FF FF FF FF

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]
</pre>

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

<pre>
FF FF FF FF [start separation]

00 2B 01 01 First 4 bytes seem to be 4 (unsigned) char's.
1st byte is so far always 0x00 (perhaps it's a short together with the second byte).
2nd byte so far either 0x2B or 0x00, I think this is a length.
3rd byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
4th 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]
</pre>

=== 00 00 00 05 ===

<pre>
FF FF FF FF [start separation]

00 00 00 00 0x90 times 0x00
Then filename (0x00 termination)

FF FF FF FF [end separation]
</pre>

=== 00 00 00 1F ===

Often at the end of a FastFile, also used for GSC scripts and other plaintext files. Compiled into FF by use of rawfile,PATH/FILE.EXT in zone file.

<pre>
FF FF FF FF [start separation]

64 00 00 00 Length of the file's content (example: decimal 100; does not count the string termination!)

FF FF FF FF [separator]

6D 6F 64 00 file name or if it's the last 1F-block FastFile name (example: mod.)

?? ?? .. 00 Plain text content (string, terminated by 0x00),
If at the end of the FF file, then it contains errors and warnings generated by the compiler/linker
Else it's empty (thus only the string termination character)
</pre>

--[[User:CoDEmanX|CoDEmanX]] 22:09, 4 November 2009 (UTC)

--[[User:Daevius|Daevius]] 14:32, 4 November 2009 (UTC)



[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-04T14:33:56Z

Daevius:

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

Be aware, FF files are little endian, so swap those bytes 'round!

== 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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [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 unknown
00 00 00 00 unknown
00 00 00 00 unknown
E5 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 unknown, is sometimes FF FF FF FF

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]
</pre>

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

<pre>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]</pre>

=== 00 00 00 05 ===

<pre>FF FF FF FF [start separation]

00 00 00 00 0x90 times 0x00
Then filename (0x00 termination)

FF FF FF FF [end separation]</pre>

=== 00 00 00 1F ===

Often at the end of the FF file.

<pre>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]</pre>

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

--[[User:Daevius|Daevius]] 14:32, 4 November 2009 (UTC)

[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-04T14:32:42Z

Daevius:

[[Image:Under Construction Small.png‎]] '''*** 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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [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 unknown
00 00 00 00 unknown
00 00 00 00 unknown
E5 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 unknown, is sometimes FF FF FF FF

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]
</pre>

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

<pre>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]</pre>

=== 00 00 00 05 ===

<pre>FF FF FF FF [start separation]

00 00 00 00 0x90 times 0x00
Then filename (0x00 termination)

FF FF FF FF [end separation]</pre>

=== 00 00 00 1F ===

Often at the end of the FF file.

<pre>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]</pre>

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

--[[User:Daevius|Daevius]] 14:32, 4 November 2009 (UTC)

[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-04T14:27:39Z

Daevius: /* Example: mp_backlot_load.ff */

[[Image:Under Construction Small.png‎]] '''*** 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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [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 unknown
00 00 00 00 unknown
00 00 00 00 unknown
E5 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown
00 00 00 00 unknown

----------- [end of header] (44 bytes), [start of index]

00 00 00 00 unknown, is sometimes FF FF FF FF

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]
</pre>

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

<pre>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]</pre>

=== 00 00 00 05 ===

<pre>FF FF FF FF [start separation]

00 00 00 00 0x90 times 0x00
Then filename (0x00 termination)

FF FF FF FF [end separation]</pre>

=== 00 00 00 1F ===

Often at the end of the FF file.

<pre>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]</pre>

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

--[[User:Daevius|Daevius]] 23:59, 1 November 2009 (UTC)

[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-04T14:24:33Z

Daevius:

[[Image:Under Construction Small.png‎]] '''*** 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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [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]
</pre>

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

<pre>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]</pre>

=== 00 00 00 05 ===

<pre>FF FF FF FF [start separation]

00 00 00 00 0x90 times 0x00
Then filename (0x00 termination)

FF FF FF FF [end separation]</pre>

=== 00 00 00 1F ===

Often at the end of the FF file.

<pre>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]</pre>

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

--[[User:Daevius|Daevius]] 23:59, 1 November 2009 (UTC)

[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-04T14:21:14Z

Daevius: /* Content */

[[Image:Under Construction Small.png‎]] '''*** 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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [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]
</pre>

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

<pre>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]</pre>

=== 00 00 00 05 ===

<pre>FF FF FF FF [start separation]

00 00 00 00 0x90 times 0x00
Then filename (0x00 termination)

FF FF FF FF [end separation]</pre>

=== 00 00 00 1F ===

Often at the end of the FF file.

<pre>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]</pre>

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

--[[User:Daevius|Daevius]] 23:59, 1 November 2009 (UTC)

[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-04T14:18:31Z

Daevius: /* Content */

[[Image:Under Construction Small.png‎]] '''*** 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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [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]
</pre>

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

<pre>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]</pre>

=== 00 00 00 05 ===

<pre>FF FF FF FF [start separation]

00 00 00 00 0x90 times 0x00

Then filename (0x00 termination)

FF FF FF FF [end separation]</pre>

=== 00 00 00 1F ===

Often at the end of the FF file.

<pre>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]</pre>

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

--[[User:Daevius|Daevius]] 23:59, 1 November 2009 (UTC)

[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-04T14:12:34Z

Daevius: /* 00 00 00 04 */

[[Image:Under Construction Small.png‎]] '''*** 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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [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]
</pre>

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

<pre>----------- [start of header]

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

----------- [end of index]</pre>

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

--[[User:Daevius|Daevius]] 23:59, 1 November 2009 (UTC)

[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-04T12:53:40Z

Daevius:

[[Image:Under Construction Small.png‎]] '''*** 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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [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]
</pre>

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

<pre>----------- [start of header]

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

----------- [end of index]</pre>

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

--[[User:Daevius|Daevius]] 23:59, 1 November 2009 (UTC)

[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-04T12:50:54Z

Daevius:

[[Image:Under Construction Small.png‎]] '''*** 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)*

<nowiki>*</nowiki> 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)

<pre>
----------- [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]
</pre>

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

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

--[[User:Daevius|Daevius]] 23:59, 1 November 2009 (UTC)

[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-02T21:13:05Z

Daevius:

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Header ==

*Byte 0-3: decompressed fastfile size minus 44 (0x2C)
*Byte 4-47: ''unknown''
*Byte 48-51: separator? (FF FF FF FF)
*Byte 52-55: number of records*
*Byte 56-63: separator? (FF FF FF FF FF FF FF FF)
*Byte 64-x: string list (xmodelsurfs?)

<nowiki>*</nowiki> If a file was missing on ff compile, it does not count but the error message is added to the end of the file. There are usually more index entries than the number of records in the header. The given number of records is not equal to the entries in the assetinfo or assetlist file, it's usually higher.

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

Example:

<pre>
1F 00 00 00 FF FF FF FF rawfile (plaintext)
05 00 00 00 FF FF FF FF shader
03 00 00 00 FF FF FF FF related to xmodel
1F 00 00 00 FF FF FF FF xmodel data

FF FF FF FF separator

4A 06 00 00 rawfile length

FF FF FF FF separator

6D 61 70 73 2F 6D 70 2F filename:
5F 72 65 70 75 6C 73 65 maps/mp/_repulse.gsc
2E 67 73 63 00 followed by plaintext:
69 6E 69 74 28 29 0D 0A init()..
7B 0D 0A 09 74 68 72 65 {...thre
61 64 20 70 6C 61 79 65 ad playe
72 63 6F 6E 6E 65 63 74 rconnect
28 29 3B 0D 0A ... ();..}.

FF FF FF FF separator

... shader (binary data)

... xmodel related data

... xmodel data (similar to original xmodel file, but nonetheless different)
</pre>

=== Shaders ===

50 00 00 00 or
40 00 00 00

<pre>FF FF FF FF
00 00 00 00
FF FF FF FF
9F 00 00 00 size after filename

filename ended with 0x00

(size * 4) bytes of shader data, seems to end with FF FF 00 00
might contain more data

FF FF FF FF
</pre>

or

<pre>FF FF FF FF
00 00 00 00

filename starts with ','

FF FF FF FF
</pre>

--[[User:CoDEmanX|CoDEmanX]] 17:27, 16 May 2009 (UTC)

--[[User:Daevius|Daevius]] 23:59, 1 November 2009 (UTC)

[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]

Call of Duty 4: FastFile Format

2009-11-01T23:59:53Z

Daevius:

[[Image:Under Construction Small.png‎]] '''*** Article and investigation in early progress ***'''

== Header ==

*Byte 0-3: decompressed fastfile size minus 44 (0x2C)
*Byte 4-47: ''unknown''
*Byte 48-51: separator? (FF FF FF FF)
*Byte 52-55: number of records*
*Byte 56-63: separator? (FF FF FF FF FF FF FF FF)
*Byte 64-x: string list (xmodelsurfs?)

<nowiki>*</nowiki> If a file was missing on ff compile, it does not count but the error message is added to the end of the file. There are usually more index entries than the number of records in the header. The given number of records is not equal to the entries in the assetinfo or assetlist file, it's usually higher.

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

Example:

<pre>
1F 00 00 00 FF FF FF FF rawfile (plaintext)
05 00 00 00 FF FF FF FF shader
03 00 00 00 FF FF FF FF related to xmodel
1F 00 00 00 FF FF FF FF xmodel data

FF FF FF FF separator

4A 06 00 00 rawfile length

FF FF FF FF separator

6D 61 70 73 2F 6D 70 2F filename:
5F 72 65 70 75 6C 73 65 maps/mp/_repulse.gsc
2E 67 73 63 00 followed by plaintext:
69 6E 69 74 28 29 0D 0A init()..
7B 0D 0A 09 74 68 72 65 {...thre
61 64 20 70 6C 61 79 65 ad playe
72 63 6F 6E 6E 65 63 74 rconnect
28 29 3B 0D 0A ... ();..}.

FF FF FF FF separator

... shader (binary data)

... xmodel related data

... xmodel data (similar to original xmodel file, but nonetheless different)
</pre>

=== Shaders ===

<pre>FF FF FF FF
00 00 00 00
FF FF FF FF
9F 00 00 00 size after filename

filename ended with 0x00

(size * 4) bytes of shader data, seems to end with FF FF 00 00
might contain more data
</pre>

--[[User:CoDEmanX|CoDEmanX]] 17:27, 16 May 2009 (UTC)

--[[User:Daevius|Daevius]] 23:59, 1 November 2009 (UTC)

[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:File formats]]