Call of Duty 5: FastFile Format - Revision history

CoDEmanX at 13:10, 29 July 2009

2009-07-29T13:10:20Z

← Older revision		Revision as of 13:10, 29 July 2009
Line 144:		Line 144:
	[[Category:Call of Duty 5]]		[[Category:Call of Duty 5]]
	[[Category:Technical Reference]]		[[Category:Technical Reference]]
			[[Category:File formats]]

CoDEmanX at 11:59, 10 July 2009

2009-07-10T11:59:39Z

@@ Line 11: / Line 11: @@
 IW   Infinity Ward
 ff   FastFile
-u100 version 1.00?
+u    compression
 </pre>
@@ Line 76: / Line 82: @@
 *'''01 00 00 00, 02 00 00 00, 07 00 00 00, 11 00 00 00, 0C 00 00 00, 0D 00 00 00, 0F 00 00 00''': D3DBSP (db layout per lump?)

CoDEmanX at 17:27, 16 May 2009

2009-05-16T17:27:15Z

← Older revision		Revision as of 17:27, 16 May 2009
Line 2:		Line 2:


	== Decompression ==		= Decompression =
	Remove the header (12 bytes)		Remove the header (12 bytes) using a hex editor like [http://mh-nexus.de/en/hxd/ HxD]

	<pre>		<pre>
Line 14:		Line 14:
	</pre>		</pre>

	Decompress the ~~rest~~ using ZLIB algorithm (e.~~g. SimplyZip)~~		Decompress the shortened file using [http://www.paehl.de/english.php SimplyZip] or any other application that supports the ZLIB algorithm.


	== Structure ==		= Structure =
	~~The first 4 bytes (unsigned int?) of the decompressed~~ fastfile ~~are assumed as file size, counted from the 37th byte to the very end.~~		A fastfile can be divided into 3 sections:
			#Header
			#Index
			#Content

	~~Byte 8: <code>h</code> (hex: 0x68)~~

	~~Byte 40-43~~: ~~<code>ÿÿÿÿ</code>~~		== Header ==
			'''Size:''' 48 bytes

	~~The bytes from 44 to 47 correspond to the files in the fastfile minus 1 (unsigned int?)~~

	~~Last entry~~: ~~name of~~ the fastfile ~~--> the missing file?~~		Byte 0-3: (unsigned int?) correlates to the fastfile's size after decompression minus 36 bytes (24h)

	~~At byte 48 starts a block of 336 <code>ÿ</code> (hex~~: ~~0x255), but not always~~		Byte 4-15: ''unknown''

			Byte 16-23: empty?

	~~Files are~~ (~~often~~) ~~separated by~~ the ~~following~~ byte ~~sequence~~: [~~needs fix~~]		Byte 24-27: somehow related to the filesize, but smaller value
	~~<pre style="overflow:auto;">~~
	~~ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ~~..~~......ÿÿÿÿ....~~		Byte 28-35: ''unknown''
	~~FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF~~ FF FF FF FF 00 00 00 ~~00 00 00 00 00~~ FF FF FF FF 00 00 00 00
	</~~pre~~>		Byte 36-39: might indicate where the index record starts, calculation unknown

			Byte 40-43: separator <code>ÿÿÿÿ</code>

			Byte 44-47: (unsigned int) number of records


			At byte 48 starts either the index record with an entry size of 8 bytes each, or there's additional content (sort if entities?). At this moment it's unknown, how the offset of the index record can be found if it doesn't start byte 48, but it starts at byte 30 if the bytes 36-39 are 00 00 00 00.


			== Index ==
			'''Size:''' Number of records [byte 44-47] * 8 bytes


			Each entry is a pair of 4 bytes, e.g. <code>FF FF FF FF 17 00 00 00</code>

			* <code>FF FF FF FF</code> appears to be a separator

			* <code>17 00 00 00</code> indicates the filetype of the actual data, called "identifier" in this article


			===Identifier===

			*'''00 00 00 00''': ?

	~~== Identifier ==~~		*'''00 00 00 04''': ?

	*'''xx xx xx 8x''': At the beginning of the EntData lump there are the		*'''xx xx xx 8x''': At the beginning of the EntData lump there are the
	**length of the entity string and the		**length of the entity string and the
	**ff identifier (?) is 8x in the last byte (80 = mp, 81 = sp, 82 = coop ?)		**ff identifier (?) is 8x in the last byte (80 = mp, 81 = sp, 82 = coop ?)

			*'''17 00 00 00''': rawfile

	*'''20 00 00 00''': GSC		*'''20 00 00 00''': GSC
Line 51:		Line 78:


	== ~~Files in FastFile~~ ==		== Content ==
			'''Size:''' variable, total size [byte 0-4] - 36 bytes<br>
			The length of the content (the actual data) is at least sometimes stored in front of the data block ( <code>INDEX ... SIZE ÿÿÿÿ DATA</code> )


	Most files build into a fastfile differ from the source files (compare [[Call_of_Duty_4:_d3dbsp#BSP_data_in_FastFile\|BSP data in FastFile]]). The linker re-interprets the data of the files and saves it more compact. One could think of an optimization process, but there are indications for a database-like data handling. Important advantage are the fast accessibility and the possibility of using data references (relations).		Most files build into a fastfile differ from the source files (compare [[Call_of_Duty_4:_d3dbsp#BSP_data_in_FastFile\|BSP data in FastFile]]). The linker re-interprets the data of the files and saves it more compact. One could think of an optimization process, but there are indications for a database-like data handling. Important advantage are the fast accessibility and the possibility of using data references (relations).


	--[[User:CoDEmanX\|CoDEmanX]] 23:32, ~~5 April~~ 2009 (UTC)		Last entry: name of the fastfile (not always present!) and compiler errors & warnings for this ff


			--[[User:CoDEmanX\|CoDEmanX]] 17:27, 16 May 2009 (UTC)

	[[Category:Call of Duty 5]]		[[Category:Call of Duty 5]]
	[[Category:Technical Reference]]		[[Category:Technical Reference]]

CoDEmanX at 01:52, 10 April 2009

2009-04-10T01:52:38Z

← Older revision		Revision as of 01:52, 10 April 2009
Line 26:		Line 26:
	The bytes from 44 to 47 correspond to the files in the fastfile minus 1 (unsigned int?)		The bytes from 44 to 47 correspond to the files in the fastfile minus 1 (unsigned int?)

	~~At byte 48 starts a block~~ of ~~336 <code~~>~~ÿ</code> (hex: 0x255)~~		Last entry: name of the fastfile --> the missing file?

			At byte 48 starts a block of 336 <code>ÿ</code> (hex: 0x255), but not always

	Files are (often) separated by the following byte sequence:
			Files are (often) separated by the following byte sequence: [needs fix]
	<pre style="overflow:auto;">		<pre style="overflow:auto;">
	ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ........ÿÿÿÿ....		ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ........ÿÿÿÿ....
	FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 00 00 00 00 00 00 00 FF FF FF FF 00 00 00 00		FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 00 00 00 00 00 00 00 FF FF FF FF 00 00 00 00
	</pre>		</pre>


			== Identifier ==

			*'''xx xx xx 8x''': At the beginning of the EntData lump there are the
			**length of the entity string and the
			**ff identifier (?) is 8x in the last byte (80 = mp, 81 = sp, 82 = coop ?)

			*'''20 00 00 00''': GSC

			*'''21 00 00 00''': CSV

			*'''01 00 00 00, 02 00 00 00, 07 00 00 00, 11 00 00 00, 0C 00 00 00, 0D 00 00 00, 0F 00 00 00''': D3DBSP (db layout per lump?)

CoDEmanX: New page: Image:Under Construction Small.png‎ '''*** Article and investigation in early progress ***''' == Decompression == Remove the header (12 bytes)

 IWffu100ƒ... 49 57 66 66 75 3...

2009-04-05T23:32:06Z

New page: Image:Under Construction Small.png‎ '''*** Article and investigation in early progress ***''' == Decompression == Remove the header (12 bytes) <pre> IWffu100ƒ... 49 57 66 66 75 3...

New page

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

== Decompression ==
Remove the header (12 bytes)

<pre>
IWffu100ƒ...
49 57 66 66 75 31 30 30 83 01 00 00

IW Infinity Ward
ff FastFile
u100 version 1.00?
</pre>

Decompress the rest using ZLIB algorithm (e.g. SimplyZip)

== Structure ==
The first 4 bytes (unsigned int?) of the decompressed fastfile are assumed as file size, counted from the 37th byte to the very end.

Byte 8: <code>h</code> (hex: 0x68)

Byte 40-43: <code>ÿÿÿÿ</code>

The bytes from 44 to 47 correspond to the files in the fastfile minus 1 (unsigned int?)

At byte 48 starts a block of 336 <code>ÿ</code> (hex: 0x255)

Files are (often) separated by the following byte sequence:
<pre style="overflow:auto;">
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ........ÿÿÿÿ....
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 00 00 00 00 00 00 00 FF FF FF FF 00 00 00 00
</pre>

== Files in FastFile ==
Most files build into a fastfile differ from the source files (compare [[Call_of_Duty_4:_d3dbsp#BSP_data_in_FastFile|BSP data in FastFile]]). The linker re-interprets the data of the files and saves it more compact. One could think of an optimization process, but there are indications for a database-like data handling. Important advantage are the fast accessibility and the possibility of using data references (relations).

--[[User:CoDEmanX|CoDEmanX]] 23:32, 5 April 2009 (UTC)

[[Category:Call of Duty 5]]
[[Category:Technical Reference]]