Duke 1 Tileset Graphics

Duke Nukem uses this format to store all it's graphics, except for the full screen images. Tile graphics in are stored in the following files:

• ANIM*.DN?
• BACK*.DN?
• BORDER.DN?
• DROP*.DN?
• FONT*.DN?
• MAN*.DN?
• NUMBERS.DN?
• OBJECT*.DN?
• SOLID*.DN?

File Structure

All the files contain the following header (first 3 Bytes in the file):

Off.| Siz.| Description
----+-----+------------
 0  |  1  | count  (Number of Tiles in the file)
 1  |  1  | width  (in Bytes-per-line, multiply with 8 to get width in Pixels)
 2  |  1  | height (in Pixels)

This header is followed by at least 5*count*width*height Bytes of Byte-planar EGA data (plane order: M-B-G-R-I). The rest of the file is probably just padding(?), so that the file size can be divided by 64. This applies to all files, except for the backdrops.

In the backdrop files (DROP*.DN?), the header is filled with zero-values, and there is no padding after the end of the image data. Since all DROP*.DN? files are the same size, you can just assume the following values for reading the file:

count  = 130
width  =   2
height =  16

It is improtant to note that the game seems to ignore the header of all files in this format. You can set the entire header of any Tileset file to zero values and the game will still load them properly. This also means that you cannot use larger Tilesets without modifying the executable.

This is what the Byte-planar EGA data looks like on byte-level:

m0 b0 g0 r0 | i0 m1 b1 g1 | r1 i1 m2 ...

This means that the first Byte of image data is the mask bits for the first 8 Pixels, followed by blue, green, red and intensity. The sixth Byte contains the mask bits for the following 8 Pixels, which will still be in the first line if you are reading an image with a width of 16 or more Pixels.

Notes

If the mask bit for a Pixel is set, the Pixel will be solid, otherwise it will be transparent.

Format reverse engineered by K1n9_Duk3