The Dink Network

Reply to How to read and unpack dir.ff files

If you don't have an account, just leave the password field blank.
Username:
Password:
Subject:
Antispam: Enter Dink Smallwood's last name (surname) below.
Formatting: :) :( ;( :P ;) :D >( : :s :O evil cat blood
Bold font Italic font hyperlink Code tags
Message:
 
 
December 13th 2014, 08:39 AM
peasantmb.gif
yeoldetoast
Peasant They/Them Australia
LOOK UPON MY DEFORMED FACE! 
I had a search of the forum and it seems that almost everyone has attempted to write a dir.ff unpacker but nobody has talked about how these files are set out. It's a most unhelpful trend of boasting which I am going to change. But first, a history lesson.

It was a common trend in the 90s to bundle all of a game's resources into one single gigantic file in order to keep them all together and to prevent people snooping and changing/stealing the graphics and other data. These formats were usually kept secret and sometimes used crappy encryption like XORing and/or specially-made compression algorithms. Dir.ff files are a relic of this era and apparently use a format created by Microsoft known as "FastFile". If you're a modder you'll probably know that these files contain all the BMPs in a particular location, so how does it store them all?

The first four bytes of the file are an integer containing the count of files present in the dir.ff file plus one. Then there are a corresponding amount of index fields as per the count, plus another blank one only containing an offset.
These index fields first contain a four byte integer value containing their offset from the start of the file, followed by a 13 byte field containing a standard 8.3 filename.
Many other games that use a similar format also provide a field containing the file's size but that's not the case here. To get the file's size you have to first get the offset of the file, and then the offset of the next file and subtract one from its offset in order to get the end of that file.

The offset for the last file is in the aforementioned final blank field (the file field is blank, not the offset).

The data that is read out is simply bog-standard bitmap data and it is not compressed at all despite the numerous suggestions that it is. All of the contained files are just concatenated together with no intermediary padding bytes.
Basically all of this may be represented as:
<COUNTER><INDEXES * COUNTER><FILE DATA * COUNTER - 1>

There is a dir.ff extractor in the FreeDink source (not compiled), and there's also a commercial program called Game Extractor that can also open them.