Contents

Technical Documentation - Dungeon Master Nexus File formats

Unless explicitly specified, words and dwords use big endian format.

SMAPxx.BIN

Overview

These files contain the images of the maps of each level in the dungeon displayed as automap in the game.
Each file contain a tilemap, a tileset and a color palette.

Format

Offset Size  Description
0000      4  dword  Block ID 'LVMP'
0004      4  dword  Block size (= file size)
0008      4  dword  00000020h (Same value in all files)
                    Offset in bytes of the tilemap in the block
000C      4  dword  00002F80h (Same value in all files)
                    Size of the tilemap in bytes
0010      4  dword  00002FA0h (Same value in all files)
                    Offset in bytes of the color palette in the block
0014      4  dword  00000200h (Same value in all files)
                    Size of the color palette in bytes
0018      4  dword  000031A0h (Same value in all files)
                    Offset in bytes of the tileset in the block
001C      4  dword  Size of tileset in bytes
0020  12160         Tilemap. 1 word for each tile in a grid of 80x76 tiles,
                    from left to right and then top to bottom.
                    In each word:
                      Bit 15: Horizontal flip
                      Bit 14: Vertical flip
                      Bits 1-13: Tile index
                      Bit 0: Unknown / Unused. Always 0.
2FA0    512         Palette of 256 colors. 1 word for each color:
                      Bit 15: Always 1
                      Bits 10-14: Blue component
                      Bits 5-9: Green component
                      Bits 0-4: Red component
31A0      n         Tileset. Each tile is 8x8 pixels, 1 byte per pixel, 
                    from left to right and then top to bottom.

FACE.BIN

Overview

This file contains the images of the 20 champion portraits. Each image is 56x56 pixels.

Format

Offset Size  Description
0000      4  dword  Block ID 'FACE'
0004      4  dword  Block size (= file size)
0008      2  word   Number of items in the file
000A      2  word   Unknown: 0000h
000C      4  dword  Unknown: 00000010h
0010     40         Offsets of items in the file. One word per item.
0038  45048         Items data, one after the other.

Each item consists of a 64 colors palette (128 bytes) followed by a PRS3 block containing the compressed image.
The image data uncompressed from the PRS3 block is a tileset of 49 tiles of 8x8 pixels, 1 byte per pixel. Tiles are stored from left to right and then top to bottom so that there is no need for a tilemap. In each tile, pixels are stored from left to right and then top to bottom. Byte values range from 0 to 3Fh (63) and are indices in the 64 colors palette stored before the PRS3 block.

TITLE.CG

Overview

This file contains a tileset to be used with tilemaps and a color palette stored in TITLE.BIN.
The tiles are used to build the full screen images displayed briefly during the title sequence showing each of 5 the letters in the word 'NEXUS'.
The file extensions 'CG' stands for 'character generator'. In the Sega Saturn terminology, a tile is called a character.

Format

The file has no header and contains a tileset of 5249 tiles of 8x8 pixels, 4 bits per pixel.
Inside each tile (32 bytes), pixels are stored from left to right and then top to bottom. In each byte, the most significant nibble contains the first pixel and the least significant nibble contains the second pixel.

PRS3 compression

Overview

PRS3 is the name of a compression algorithm used to store some images in the following files: DM.BIN, FACE.BIN and MENU.BPK.
This section describes how to uncompress PRS3 compressed data.

Format

Offset Size  Description
0000      4  dword  Block ID 'PRS3'
0004      4  dword  Always 00000001h
0008      4  dword  Uncompressed data size
000C      4  dword  Compressed data size
0010      n         Compressed data.

The size of the compressed data must be a multiple of 4 bytes. Additional bytes are padded at the end if necessary. In FACE.BIN and DM.BIN, there are between 0 and 3 padding bytes of value 00h. In MENU.BPK, there are between 1 and 4 padding bytes with various values.

Details

Algorithm

Here is how to uncompress the compressed data:

  1. Read a control byte from the input compressed data.
  2. For each bit in the control byte (starting with the least significant bit):
    • If bit = 1, read one byte from the input compressed data. Output this byte directly to the uncompressed data.
    • If bit = 0, read two bytes from the input compressed data. These two bytes encode a copy operation where 3 to 18 bytes of previously uncompressed data are copied to the output (see below for details).
  3. If number of uncompressed bytes < Uncompressed data size, loop to step 1
Copy operations

For each '0' bit in a control byte, two bytes are read from input compressed data: Byte0 and Byte1.
These two bytes represent an offset (12 bits) and a number of pixels (4 bits).
The number of pixels ranges from 3 to 18:
Number of pixels = 3 + (Bits 0-3 of Byte1)

The offset value ranges from -18 to 4077:
Bits 4-7 of Byte1 contain the 4 most significant bits of the offset value.
Byte0 contains the 8 least significant bits of the offset value.
The 12 bit offset value is encoded like this:

Raw value = FDCh = 4060 -> Offset = -18
...
Raw value = FEDh = 4077 -> Offset = -1
Raw value = FEEh = 4078 -> Offset = 0
...
Raw value = FFFh = 4095 -> Offset = 17
Raw value = 000h =    0 -> Offset = 18
...
Raw value = FDBh = 4059 -> Offset = 4077

This offset is relative. Here is how to convert this relative offset to an absolute offset:

While Current position in Uncompressed data - Offset > 4095
Offset = Offset + 4096
End while

Offset is now an absolute offset value referring to a byte in the output uncompressed data.

Copy the specified number of bytes starting from this offset. Bytes are read from the already uncompressed output data and added to the current position in output data.

Note that at the beginning of the process, the value of the resulting absolute offset may be negative. In that case, output a 00 byte instead of copying a byte of data. This is done until the offset becomes positive. For example, a copy operation of 5 bytes starting from absolute offset -2 will produce two 00 bytes and then copy the first 3 bytes of uncompressed data.

OTHER


Powered by Drupal   Valid XHTML 1.0 Strict