| 1 | ======================
|
|---|
| 2 | Dune 2 SHP file format
|
|---|
| 3 | ======================
|
|---|
| 4 | Sourced from Red Horizon Utilities by Emanuel Rabina
|
|---|
| 5 | http://www.ultraq.net.nz/redhorizon/
|
|---|
| 6 |
|
|---|
| 7 | The Dune 2 SHP file, is a multiple image filetype, where each image can have
|
|---|
| 8 | it's own set of dimensions. The file is structured as follows:
|
|---|
| 9 |
|
|---|
| 10 | File header:
|
|---|
| 11 | NumImages (2 bytes) - the number of images in the file
|
|---|
| 12 | Offsets[NumImages + 1] - offset to the image header for an image. The last
|
|---|
| 13 | (2 or 4 bytes each) offset points to the end of the file. The offsets
|
|---|
| 14 | don't take into account the NumImages bytes at the
|
|---|
| 15 | beginning, so add 2 bytes to the offset value to
|
|---|
| 16 | get the actual position of an image header in the
|
|---|
| 17 | file
|
|---|
| 18 |
|
|---|
| 19 | The size of the offsets can be either 2 or 4 bytes. There is no simple way
|
|---|
| 20 | to determine which it will be, but checking the file's 4th byte to see if
|
|---|
| 21 | it's 0, seems to be a commonly accepted practice amongst existing Dune 2 SHP
|
|---|
| 22 | file readers:
|
|---|
| 23 |
|
|---|
| 24 | eg: A 2-byte offset file: 01 00 06 00 EC 00 45 0A ...
|
|---|
| 25 | A 4-byte offset file: 01 00 08 00 00 00 EC 00 ...
|
|---|
| 26 | ^^
|
|---|
| 27 | The marked byte will be 0 in 4-byte offset files, non 0 in 2-byte offset
|
|---|
| 28 | files.
|
|---|
| 29 | Lastly, like C&C SHP files, there is an extra offset, pointing to the end of
|
|---|
| 30 | the file (or what would have been the position of another image header/data
|
|---|
| 31 | pair).
|
|---|
| 32 |
|
|---|
| 33 | Following the file header, are a series of image header & image data pairs.
|
|---|
| 34 | The image header is structured as follows:
|
|---|
| 35 |
|
|---|
| 36 | Image header:
|
|---|
| 37 | Flags (2 bytes) - flags to identify the type of data following the
|
|---|
| 38 | Datasize field, and/or the compression schemes used
|
|---|
| 39 | Slices (1 byte) - number of Format2 slices used to encode the image
|
|---|
| 40 | data. Often this is the same as the height of the
|
|---|
| 41 | image
|
|---|
| 42 | Width (2 bytes) - width of the image
|
|---|
| 43 | Height (1 byte) - height of the image
|
|---|
| 44 | Filesize (2 bytes) - size of the image data in the file
|
|---|
| 45 | Datasize (2 bytes) - size of the image data when Format2 encoded/compressed
|
|---|
| 46 |
|
|---|
| 47 | Regarding the flags, there seem to be 4 values:
|
|---|
| 48 | - 00000000 (0) = Decompress with Format80, then Format2
|
|---|
| 49 | - 00000001 (1) = (see 3)
|
|---|
| 50 | - 00000010 (2) = Decompress with Format2
|
|---|
| 51 | - 00000011 (3) = A small 16-byte lookup table follows, and the image data
|
|---|
| 52 | should be decompressed with Format80 then Format2.
|
|---|
| 53 | - 00000101 (5) = The first byte gives the size of the lookup table that
|
|---|
| 54 | follows, and the image data should be decompressed with
|
|---|
| 55 | Format80 then Format2.
|
|---|
| 56 |
|
|---|
| 57 | And after this image header is the image data.
|
|---|