To create a DMO file start the game with the command line switch /r (and /l (level), /s (skill) etc.) and play as usual. If you press F10 the record (and the game) stops. You will find a file demo1.dmo in the current directory. To play it back just start the game and hide the menu by pressing ESC.
In Duke Nukem 3D 1.0 and 1.1 the skill value is a bit strange: To record a skill n (1<=n<=4) game note to use /sn+1. So /s2 is ``Peace of Cake'' and /s5 is ``Damn I'm Good''. The dn3dhelp.exe hint (/sn with 0<=n<=3) is totally wrong.
Multiplayer recordings have always the skill 0. Cooperative recordings won't play back properly.
It is impossible to record with version 1.0 more than one level. You can't even record the summary screen at the end of each level.
In version 1.1 it seems to be possible (I got it some times). Some other times I got only the recording of the last level.
A DMO file records all player actions. The monster movements, respawn positions etc. are totally deterministic. The messages during a multiplayer game (macros and RemoteRedicule (tm)) do not appear in the DMO.
A DMO file consists of a header with some organizational information and the data area with all the (compressed) game tics.
The term ``game tic'' comes originally from DOOM and denotes the smallest unit of time during the game. The duration of a game tic is 1/26s. To store a game tic in a file means to store all actions, like movement, open doors, fire weapons and so on, happened during this time.
Duke Nukem 3D 1.0 and 1.1 use a 9 byte main header:
| address | type | contents |
| 0x0000 | long | number of game tics times numberof players |
| 0x0004 | byte | episode (0-3) |
| 0x0005 | byte | map (0-8) |
| 0x0006 | byte | skill (0-4) |
| 0x0007 | word | player number |
The first entry in the header (number of game tics) may be zero in version 1.1 recordings. This should mean, that there is more than one level recorded.
All word or long values in DMO files are Intel ordered (lowest byte first, little endian).
Duke Nukem 3D 1.3D uses a 24 byte main header:
| address | type | contents |
| 0x0000 | long | number of game tics times number of players |
| 0x0004 | byte | volume - 1 (/v parameter - 1) |
| 0x0005 | byte | level - 1 (/l paramerer - 1) |
| 0x0006 | byte | skill (0 .. 4) (/s parameter) |
| 0x0007 | byte | MP mode (/c 1 = DukeMatch(spawn), 2 = Coop, 3 = Dukematch(no spawn)) |
| 0x0008 | short | player number (1..8) |
| 0x000A | short | 0x01 with /m (nomonsters), 0x00 else |
| 0x000C | long | 0x01 with /t1 (respawn monsters), 0x00 else |
| 0x0010 | long | 0x01 with /t2 (respawn items), 0x00 else |
| 0x0014 | long | 0x01 with /t3 (respawn inventory), 0x00 else |
Duke Nukem 3D 1.4 and 1.5 use a 674 (0x2a2) byte fixed header and player number additional bytes:
| address | type | contents |
| 0x0000 | long | number of game tics times number of players |
| 0x0004 | byte | version: 116 (0x74) is 1.4, 117 (0x75) is 1.5 |
| 0x0005 | byte | episode |
| 0x0006 | byte | map |
| 0x0007 | byte | skill (0...4) |
| 0x0008 | byte | Multi Player mode (/c parameter - 1) |
| 0x0009 | byte | m_ffire (might be friendly fire) |
| 0x000A | short | player number (1..16) |
| 0x000A | byte | player number (1..8) |
| 0x000C | short | 0x01 with /m (nomonsters), 0x00 else |
| 0x000E | long | 0x01 with /t1 (respawn monsters), 0x00 else |
| 0x0012 | long | 0x01 with /t2 (respawn items), 0x00 else |
| 0x0016 | long | 0x01 with /t3 (respawn inventory), 0x00 else |
| 0x001A | long | 0x01 with /a (player AI for fake players), 0x00 else |
| 0x001E | char[0x20] | name[0] |
| 0x003E | char[0x20] | name[1] |
| ... | ... | ... |
| 0x01CE | char[0x20] | name[14] |
| 0x01FE | char[0x20] | name[15] |
| 0x021E | long | 0x01 with auto_run, 0x00 else |
| 0x0222 | char[0x80] | board file name |
| 0x02a2 | byte | aim_mode[0] |
| ... | ... | ... |
| 0x02a2 + player_number - 1 | byte | aim_mode[player_number - 1] |
Redneck Rampage uses a 543 byte main header:
| address | type | contents |
| 0x0000 | long | number of game tics times number of players |
| 0x0004 | byte | 0x6C, it may be a version |
| 0x0005 | byte | 0x00, unknown |
| 0x0006 | byte | 0x00, unknown |
| 0x0007 | byte | skill (0...4) |
| 0x0008 | byte | MP mode (/c parameter - 1) |
| 0x0009 | byte | level (1..11) |
| 0x000A | byte | player number (1..8) |
| 0x000B | byte | 0x00, unknown |
| 0x000C | byte | 0x01 with /m (nomonsters), 0x00 else |
| 0x000D | byte | 0x00, unknown |
| 0x000E | long | 0x01 with /t1 (respawn monsters), 0x00 else |
| 0x0012 | long | 0x01 with /t2 (respawn items), 0x00 else |
| 0x0016 | long | 0x01 with /t3 (respawn inventory), 0x00 else |
| 0x001A | long | 0x01 with /a (player AI for fake players), 0x00 else |
| 0x001E | char[0x201] | -name parameter |
The episode (better: volume) number is one of the 0x00 bytes in the header.
The players name is a `\0' terminated string. The maximum number of characters for the name is 512.
The data starts in byte 0x0009 (old Duke Nukem 3D), 0x0018 (new Duke Nukem 3D) or 0x021F (Redneck Rampage) of the DMO file and is organized in several blocks.
Each block consists of a header with some organizational information and the compressed data.
A block header is:
| address | type | contents |
| 0x0000 | word | size of the following block in bytes |
| 0x0002 | word | size of the uncompressed data block in bytes |
| 0x0004 | word | biggest code for Lempel-Ziv decompression |
The compressed data starts in byte 0x0006 of the block. The block size (0x0000/0x0001) includes the rest of the header. This means there are only block size - 4 data bytes.
Duke Nukem 3D uses a modified Lempel-Ziv algorithm (similar to the UNIX command compress(1)) to compress the game tics. To reach an even better compression ratio not the game tic itself but the difference to the last one of the same player (difference per byte, without carry bits) will be compressed. This increases the number of 0 bytes enormously and allows long recording in short files.
In fact Steffen Winterfeldt changed the original compress.c until we could decompress a DMO file.
If you are really more interested in the compression/decompression routines look in the files lzw.c and unlzw.c included in LMPC, the Little Movie Processing Centre. You can get it from my Demo Specs page.
The published source (1.5) was needed to decompress 1.5 recordings. But LMPC still uses unlzw.c to decompress the 1.3D files.
The compression algorithm used in Redneck Rampage seems to be similar but I did not get lzw.c and unlzw.c to work with Redneck Rampage recordings.
Some blocks of data form a macro block. This has to do with both decompression and game tic difference storing. The first game tic in a macro block is the original game tic. All the following game tics are only the byte-per-byte difference game tics to its specific predecessors. There is no special code to signalize the end of a macro block. It is simply the number 2520/(player number) game tics, which makes a macro block. Note that 2520 is divisible by 1,2, ... ,8 without remainder. Only the last macro block may contain less game tics if the file ends before.
One game tic consists of the data from all players. The input for every player is listed below.
One game tic has 10 bytes per player:
The two moving parameters are the player's speed or the displacement vector in length units per game tic.
To calculate the absolute value of the player speed just calculate sqrt(x2+y2).
A standard speed is 1280 (with running 2560). The coordinate system used is like this:
|
|
|
------------+-----------> x
|
|
|
\|/
y
The turn parameter contains the current turning speed or the angle difference per game tic. A positive turning speed means right and a negative means left.
There are many ``use'' actions in Duke Nukem 3D. You can do all at once, because there is a single bit for each action. The apropriate bit is 1 as long as you press the corresponding key.
| bit | purpose | |
| 31 | Escape | |
| 30 | Inventory | |
| 29 | Open | |
| 28 | TurnAround | |
| 27 | Inventory_Right | |
| 26 | GameQuit | |
| 25 | Jetpack | |
| 24 | Holo_Duke | |
| 23 | Mouse_Aiming | new in 1.1 |
| 22 | Quick_Kick | |
| 21 | Pause | |
| 20 | Inventory_Left | |
| 19 | Holster_Weapon | |
| 18 | Center_View | |
| 17 | AutoRun | |
| 16 | MedKit | |
| 15 | NightVision | |
| 14 | Look_Down | |
| 13 | Look_Up | |
| 12 | Steroids | new in 1.1 |
| 8-11 | Weapon number | |
| 7 | Look Right | |
| 6 | Look Left | |
| 5 | Run | |
| 4 | Aim_Down | |
| 3 | Aim_Up | |
| 2 | Fire | |
| 1 | Crouch | |
| 0 | Jump |
First internal version (working paper); never announced.
Many thanks to Steffen Winterfeldt (Steffen.Winterfeldt@itp.uni-leipzig.de) for his reverse engineering and programming work.
First helpful documentation for further research on Duke Nukem 3D; never announced.
All header bytes decoded, never announced.
Minimal changes, some remarks to record properly.
New actions from version 1.1.
Multi-level recording from 1.1.
Reorganization of block/macro block description.
Redneck Rampage info included (incomplete).
Duke Nukem 3D 1.3D info included.
PlanetQuake is the new home.
SGML-Tools 1.0.5 used.
Duke Nukem 3D 1.4 and 1.5 header added.
Full list of actions listed.
Internal game tic structure for Duke Nukem 3D 1.3D and later added.
A Duke Nukem 3D game tic is 1/26s and not 1/30s. Thanks to jlennox@gmail.com for spotting this error.