All Dogs Archive Format
|Hardware||CGA, EGA, TGA|
|Max tile count||65,535|
|Palette||Default EGA / Default CGA|
|Minimum tile size (pixels)||0×0|
|Maximum tile size (pixels)||131,070×65,535 (EGA), 262,140×65,535 (CGA)|
The archives of the Polarware game All Dogs Go To Heaven are an odd mix of archive files and tileset files. There are two sets of seven archive files with the names MRH_DOG?.DB#. The extension goes from DB0 to DB6. The base name of the archives ends on either C, for the CGA graphics, or E for the EGA and TGA graphics. The archives store both images and text, but can't really be treated purely as archives to extract files from; the images they contain can't be properly visualised without the filename of the archive, since nothing in their own structure indicates whether they are 2-bit CGA or 4-bit EGA graphics.
The file starts with a single UINT16LE
NrOfEntries giving the number of entries in the file.
This is followed by an index table of the actual entries. Each one is eight bytes long, and has the following structure:
|0x00||UINT16LE||DecompressedSize||Size of the entry when decompressed, in bytes.|
|0x02||UINT16LE||CompressedSize||Size of the entry in the file.|
|0x04||UINT32LE||DataStart||Offset in the file where this entry's data starts.|
The header's total size will be
2 + NrOfEntries * 8.
This header is followed by the actual data of the entries, at the offsets given in the table.
The entries may or may not be compressed. The game decides this by checking to see if the DecompressedSize is the same as the CompressedSize. Text entries are always uncompressed. The entries that are compressed are done so using All Dogs RLE Compression; a flag-based RLE compression with a 2-byte repeat value, giving a 4-byte block for each repeat command. This makes the compression really inefficient, since any range smaller than four bytes isn't worth compressing. Because of this, many entries, especially in the CGA images, are not compressed at all.
When compressed, the entire image entry needs to be decompressed before it can be interpreted. Once uncompressed, the image data starts with the following six-byte header:
|0x00||UINT16LE||Stride||Number of bytes on each row.|
|0x02||UINT16LE||Height||Amount of rows.|
|0x04||UINT16LE||TotalSize||Total size of the image, in bytes.|
This is followed by the actual image data, which is the size indicated in TotalSize.
TotalSize will always equal
Height * Stride, and will also always equal
DecompressedSize - 6. If this is not the case, you're probably dealing with a text entry.
The data is linear pixel data, and can be either CGA or EGA data, which are four or two pixels of data per byte respectively. The simplest way to determine which one is used is by looking at the file name of the archive. However, since this is a DOS 320×200 game, and all archives contain at least one full-screen image, an alternative approach, when loading the whole archive, is to check whether any images exceed a width of 320 pixels when loaded as CGA, and, in that case, load it as EGA instead.
The EGA data simply uses the default EGA palette. However, the CGA version of the game, when ran in a DOSBox setup configured to actually emulate CGA hardware, switches between different colour palettes, meaning you can't use one single palette for all graphics.
The CGA game consistently uses dark blue (index 1 on the full available 16-colour palette) as background colour, and mostly uses the bright version of CGA palette 0, ending up with palette [01,10,12,14]. Only the heaven minigame (MRH_DOGC.DB1; all frames except the first two) uses the dark version of CGA palette 1, resulting in the palette [01,03,05,07]. For more information how CGA colours work, see the CGA Palette article.
Some images have a corresponding 'mask' image used by the game to give the graphic transparency. In general, though, there doesn't seem to be a real rule for how transparency is handled in the images. Some (like those on the wheel of images in MRH_DOG?.DB2) might in fact be cut out mathematically by the game itself.
The text entries are generally stored in 50-byte chunks. These entries have no header of any kind, and simply consist a string of ASCII text, with the remainder of the size filled up with 0x00 bytes.
Despite the trailing zeroes, they are never compressed, obviously because these trailing zeroes don't contain any useful data.
The text entries themselves appear to be the strings used in the 'hangman' type minigame.
The following tools are able to work with files in this format.
|Name||Platform||View images in this format?||Convert/export to another file/format?||Import from another file/format?||Access hidden data?||Edit metadata?||Notes|
|Engie File Converter||Windows||Yes||Yes||Yes||No||N/A||Treats the archive as tileset, with 'empty' images for the text entries. Gives a text box on save where these 'empty' entries need to be filled in with a string and a save length. The data will be pre-filled when re-saving the original archive, giving a simple way to copy them from there. Allows any indexed format as input, and detects from the used indices on the images whether the file can be saved as CGA or EGA.|