Back

Developer Network
  File Specs
  Source codes
  Tables
  Mailing lists
  Knowledge Base

Other Games

 

 

Descent Developer Network
Descent 1/2

*.RDL specs

Introduction

A Descent level is encoded in a file called an RDL (Registered Descent Level) file. This document describes in some detail the format of an RDL file, and what each section and structure in the file is.

This document was written by Jon Hylands.

eMail author: Jon Hylands
RL2 specs - Descent 2 Level format

 

Basic Structure

An RDL file is composed of three main parts:

  • Header information
  • Mine structures
  • Objects
We will now examine each of these three parts in detail.

 

Header Information

char[4] signature;
long version;
long mineDataOffset;
long objectsOffset;
long fileSize;

Every Descent RDL file starts with a four-bye signature string, which is the ascii string "LVLP". The following four bytes is the version of the RDL file, which, for Descent 1 is 1.

Following are two offsets into the RDL file, the first being the offset of the mine structures, and the second being the offset of the objects. Each is a four-byte long integer. If the RDL is part of a HOG file, the offsets are relative to the position of the RDL file within the HOG file.

Mine Structures

short vertexCount;
short cubeCount;
Vertex verticies[vertexCount];
Cube cubes[cubeCount];

The mine structures are the verticies and cubes that make up the structural portion of a level. It starts with two integers, one the number of verticies, and one the number of cubes in the level.

Following the two counts is the vertex data. A vertex is defined as:

fixed x, y, z;

Thus, each vertex takes 12 bytes. Each coordinate of a vertex is a 32-bit fixed point number, in 16:16 format.

Following the vertex data are the cubes. A cube is a significantly more complex structure, and is variable sized depending on a number of factors.

Each cube starts with a 8-bit mask, that defines for each side whether or not it has a neighbor (attached) cube, and also whether or not the cube is an energy center.

cube neighbor bitmask:
bit 0: 1 if another cube attached to left side
bit 1: 1 if another cube attached to top (*)
bit 2: 1 if another cube attached to right (*)
bit 3: 1 if another cube attached to bottom (*)
bit 4: 1 if another cube attached to back (*)
bit 5: 1 if another cube attached to front
bit 6: 1 if the cube is an energy center
bit 7: <unused>

For bits 0-5 in the bitmask, if the bit is one, there is a corresponding short (16 bit) value following the bitmask in the file with the id of the cube that is attached on that side. For example, if bit 5 = 1, the 2 bytes following the bitmask make up an integer which is the id of the cube attached to this cube's left side. If the value of the neighbor id is -2, that side of the cube is the special "end wall", placed at the end of the exit tunnel.

Thus there can be anywhere from zero to six shorts following the bitmask, describing the id of the cube's neighbors. Note that the ordering is very important here - it goes (left, top, right, bottom, back, front).

For example, let's say cube #15 has three neighbor cubes. On its left is cube #17, on its right is cube #20, and below it is cube #25. The children bitmask would look like this:
00001101

Following this would be three shorts:

17, 20, 25

The cube is defined in space by its eight verticies, which are in a specific order. The verticies for each cube are specified by providing an index into the above vertex structure for each one. Thus following the neighbor information are eight shorts, specifying verticies 0 through 7 for the cube. The order of the verticies is defined by their position in the cube, which is summarized in the following table:

  • 0 - left, front, top
  • 1 - left, front, bottom
  • 2 - right, front, bottom
  • 3 - right, front, top
  • 4 - left, back, top
  • 5 - left, back, bottom
  • 6 - right, back, bottom
  • 7 - right, back, top

Bit 6 in the bitmask is set to one if the cube is part of an energy
center. If this is the case, following the vertex values are three
values describing the energy center. They are defined as follows:

ubyte special;
byte energyCenterNumber;
short value;

Next comes the cube's static light value, which is stored as a short fixed-point. A short fixed-point is a 16-bit number, in 4:12 format.

Next comes the walls bitmask. Bits 0-5 are once again set if the corresponding side is a wall (which includes doors). For each bit set, there is an unsigned byte value following with the id of the wall. If the value is 255, it is considered to be -1, which means no wall.

Finally, for each side of the cube that doesn't have a neighbor, or does have a switch, there follows the texture information for that side. This consists of the primary texture, optionally the secondary texture, and the UVL's for the side.

The primary texture is a ushort, with the lower 15 bits being used as the texture number. The high bit is set if this side has a secondary texture associated with it. If it does have a secondary texture, the secondary texture value (a 16-bit short) follows the primary texture value.

The UVL structure defines, for each vertex on the side, the offset of the texture, and the light value of that vertex on the side. UV is the texture offset at that corner, and L is the light value for that corner. The texture offset is a pair of short fixed point values, which define how the texture is stretched.

 

Objects

Unfortunately Jon Hylands never finished this section of the document. However they are quite similar to RL2's Object section:

RL2 specs - Descent 2 Level format

 

 

All pages (C) 1996-2000 Descent Network Team
Everything taken from the Descent, FreeSpace, Red Faction and Summoner series games are
Copyright Interplay Productions , THQ Inc. , Parallax Software , Volition Inc. and/or Outrage Entertainment