How to read and unpack dir.ff files
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.
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.
Thanks for the info and history lesson. Just standard bitmap data, that's pretty funny.
I use WinDinkEdit+2 to unpack dir.ff files.
I use WinDinkEdit+2 to unpack dir.ff files.
I had a look for some additional history and I found some info for Microsoft Fastfile on a ROM hacking site. The Fastfile format source was included with DirectX 5 primarily for game developers. It seems the main advantage was improved loading times (hence the name) and reduced disk usage when implemented as intended. The format does not appear to have been used for many games though.
However, the intended method of use was to include every data file into a fastfile package, but RTSoft were lazy and made individual files for each graphics path which means that the benefits were never realised. In fact Seth could have used a dir.ff file for all the scripts instead of wasting time implementing the encoding for .d files.
Seth's included ffcreate.exe was apparently buggy which is why FFCreate 2 was developed by Redink. As a result there seems to be problems with certain dir.ff files such as the one in Mystery Island; unpacking it results in around 250MB of files using my self-made unpacker. Seth wised up when creating Mystery Island and decided to implement FastFile properly and as a result made sure to pack all of the graphics in a "newer" FastFile format that allowed for subdirs and proper file paths as originally intended. I doubt it helped make downloading any faster though
Funnily enough iOS Dink uses a standard zip file named "Dink.pak" in order to store graphics, map data and scripts meaning Seth eventually did get around to archiving the data properly.
However, the intended method of use was to include every data file into a fastfile package, but RTSoft were lazy and made individual files for each graphics path which means that the benefits were never realised. In fact Seth could have used a dir.ff file for all the scripts instead of wasting time implementing the encoding for .d files.
Seth's included ffcreate.exe was apparently buggy which is why FFCreate 2 was developed by Redink. As a result there seems to be problems with certain dir.ff files such as the one in Mystery Island; unpacking it results in around 250MB of files using my self-made unpacker. Seth wised up when creating Mystery Island and decided to implement FastFile properly and as a result made sure to pack all of the graphics in a "newer" FastFile format that allowed for subdirs and proper file paths as originally intended. I doubt it helped make downloading any faster though
Funnily enough iOS Dink uses a standard zip file named "Dink.pak" in order to store graphics, map data and scripts meaning Seth eventually did get around to archiving the data properly.
Most interesting... A very nice tidbit of information.
So in theory we could cut .dmod filesize if the graphics and scripts were encoded correctly, at a guess?
So in theory we could cut .dmod filesize if the graphics and scripts were encoded correctly, at a guess?
The file size reduction is designed to apply to the target disk after the files are installed. If you look in the link I posted, it talks about cluster size and how even little files take up a certain minimal amount on the disk. For example Dink's STORY collection takes up 1.57MB on my disk despite only being 286KB in size.
The savings for .dmod files would be negligible. The bz2 compression algorithm for .dmod files is already quite thorough, although 7z is usually better. The changes would have to be made to the actual data files themselves by compressing sound files to ogg, and tiles and other graphics to jpg or png (which only work in freedink and not very well) if you were really looking to cut down.
The savings for .dmod files would be negligible. The bz2 compression algorithm for .dmod files is already quite thorough, although 7z is usually better. The changes would have to be made to the actual data files themselves by compressing sound files to ogg, and tiles and other graphics to jpg or png (which only work in freedink and not very well) if you were really looking to cut down.
> There is a dir.ff extractor in the FreeDink source (not
> compiled)
Just for reference, this is ffrextract.c (I searched the forum for ffrextract.c and found nothing, so am adding it to this message).
I'm trying to create maps, so I've converted these bitmaps into transparent PNGs and uploaded them to:
https://github.com/barrycarter/bcapps/tree/master/DINK/PNG
> compiled)
Just for reference, this is ffrextract.c (I searched the forum for ffrextract.c and found nothing, so am adding it to this message).
I'm trying to create maps, so I've converted these bitmaps into transparent PNGs and uploaded them to:
https://github.com/barrycarter/bcapps/tree/master/DINK/PNG
They're all available on the RTSoft site or here as BMPs. You don't need to bother unpacking the main game's data.
http://www.rtsoft.com/dink/dinkgraphics.zip
http://www.rtsoft.com/dink/dinkgraphics.zip
They're also available here. Well, Dink's sword-idle frames at least.
...one of them. Might need to resize it a wee bit before it can be used, though.
...one of them. Might need to resize it a wee bit before it can be used, though.
Reminds me of Advice Dink I made that time.
