The first thing one must do is decode the colour palettes required by the various image files described below, because (with a few noted exceptions) the image files used by Daggerfall are paletted. This means they do not report their actual colour values, but instead report colour indexes. If one does not use the correct palette to decode the image data, one will not receive the correct picture.
Palette file formatEdit
Palette files each contain a contiguous list of Colour structures, defined below. Daggerfall images are palettized; this means the pixel data is actually an index to a specific palette. One cannot properly decode any Daggerfall image without a palette.
There are two types of palette files: PalFile (*.PAL) and ColFle (*.COL). Each has a similar structure and format, but there is a trivial difference between them.
The complete formats are described here.
Reading Palette FilesEdit
Since PalFile files always contain 768 bytes of data (256 Colours, 3 bytes per colour), PalFile files are identified by being 768 bytes in length. Likewise, ColFiles are always 776 bytes in length (ColHeader plus the PalFile's 768 bytes). This makes opening either a .COL or .PAL file trivial, since the specific type can be derived based on the file's length.
Since Colours do not encode an Alpha component/channel, the first entry is considered the "Transparent" colour (0 Alpha) and all other colours are considered opaque (255 Alpha).
Colour Translation file formatEdit
Colour Translation files are used by Daggerfall to permit what modern API's such as Direct3D or OpenGL call "fogging". They work by translating one palette index to another palette index, and thus there is no need for palettes with more than 256 colours, no need to swap palettes, nor any need to create multiple images differing only by palette. The SkyFiles make ample use of this, as do the light sources, and the "swimming under water" effect also uses Colour Translation files.
The complete format is described here.
RCI file formatEdit
RCI Files (*.RCI) each consist of a contiguous list of UncompressedPixelData structures, defined below. Each element of the list describes a single image. Since each image of an RCI File have the same dimensions, and since RCI Files store the image data in UncompressedPixelData format, reading the list of images is a trivial matter of reading x bytes at a time. x is derived by multiplying the image's Width by Height properties, listed below by filename. Ex: A 64x64 pixel image RCI File would imply each UncompressedPixelData structure to be exactly 4096 (64 × 64) bytes long, and the total file legnth would be an integer multiple of 4096.
The complete format for RCI files is described here.
Reading RCI FilesEdit
In essence, after one has determined the dimensions for the contained images, one then reads exactly this many bytes at a time until reaching the end of the file. Since the data is not compressed, each byte of data corresponds to a pixel of the image, with the value being an index to a palette.
SKY file formatEdit
The SKY*.DAT files found within the ARENA2 folder are used to draw the "skybox". This is the texture which is applied to the extent of the visible range within the environment. These textures include the "flat" mountains and trees which compose the horizon, as well as the sun rising and setting.
The complete format for SKY files is described here.
IMG file formatEdit
IMG files each contain a single ImgFile structure. An ImgFile structure (defined below) consists of an ImgHeader structure immediately followed by a PixelData structure. Since IMG files make use of an Rle to compress the actual pixel data, decoding the described image can require additional work for some IMG files.
The format for IMG files is described here.
Reading IMG FilesEdit
Since each IMG file contains one and only one image, one merely reads the entire file. The first 12 bytes define the ImgHeader, and the following ImgHeader.PixelDataLength bytes compose the image's data. Based on the ImgHeader.Compression field's value, one may need to decompress the data in order to generate the defined image.
CIF file formatEdit
CIF files are slightly more complicated than IMG files, because CIF files were designed to support multiple animated images. That is to say, each contained image is an animation of 1 or more frames. SHOK00C6.CIF, for example, contains a single 6-frame image. Most CIF files contain images of only a single frame.
The format for CIF Files is described here.
Reading CIF FilesEdit
Generally, a CIF file contains one or more images, each of which is an animation of one or more frames. Normally reading CIF files is straight-forward, excepting the FACES.CIF and WEAPON09.CIF files. The former is actually an RCI file, and the latter does not contain a root "wielded" image.
Texture file formatEdit
Texture files are all files in the ARENA2 game directory that match TEXTURE.??? where ??? is a 3-digit ASCII encoded number, ranging from "000" through "511", with some numbers missing for a total of 472 files.
The format for Texture files is described here.
Reading Texture FilesEdit
Texture files were dsigned to store multiple images, very similarly to CIF files. Each Texture file contains one or more images, some of which are animations and some which are not. Since there are a tremendous number of textures required by the game, these files include additional compression techniques which can complicate matters. When reading the images contained within a Texture file, the various headers will indicate which decoding algorithm one must use. There are 4 different decoding algorithms.