Release Notes for JFDuke3D

Release date: 28 February 2005 (multiplayer test release update)

New Features

Multiplayer capability. See here for more information.

Known Issues

This version should be considered test-quality only! There are still things left to do before the port can be given a full official release. Keep that in mind when you come to making modifications that work with this version because certain elements of the mod support will change.
The network code does not display any status information during the joining phase. The game may look as though it has locked up if it is waiting for something. You will have to kill the game in Windows Task Manager if you want to abort the launch. This will become much cleaner and nicer in the near future.
You may have instances where the game goes out of sync. The master can often restart the game from the menu without everyone having to restart the game from scratch, and things should be fine.
A future version will include my new sound code that supports OggVorbis and other sound formats. For now, the existing AudioLib code is in use.

Multiplayer games

Multiplayer games are started via command-line parameters passed to DUKE3D.EXE. This is a short guide to getting a multiplayer game running between these three hypothetical computers:

Host name	IP address
faye	192.168.1.2
asuka	192.168.1.5
kaoru	192.168.1.6

Keep in mind that the networking features are still being refined and there are certain issues and caveats to be aware of when using it. The basic syntax of the network command line is like so: DUKE3D (normal game parameters) /net (network parameters)

Network parameters
/nx:y	Game comm type. x = 0 for master/slave or 1 for peer-to-peer. If unspecified, y defaults to 2. For more than two players in a master-slave game, you have to indicate the number on the master. eg: /n0 or /n0:4
/px	Overrides the default port (23513) with x being the new port value.
address:port	An address of a machine. See the items below for more information.

Master/Slave mode

This mode is the easiest mode for use with Internet play since it requires only the address of the master of the game (the person hosting the game) be specified by each slave who joins. Here are example command lines each machine must run to join the game hosted by the machine named 'asuka':

asuka	`DUKE3D.EXE /net /n0:3`
faye	`DUKE3D.EXE /net /n0 192.168.1.5`
kaoru	`DUKE3D.EXE /net /n0 192.168.1.5`

Peer-to-peer mode

This mode is often useful for playing on a LAN where it is easier to coordinate and organise the order of peers in the game. This mode will become simpler to set up in the future but for now this is how to do it. Peer-to-peer mode requires each machine specify the addresses of each other machine in the game in the same order, but indicating its own position in the sequence with the /n1 option.

asuka	`DUKE3D.EXE /net /n1 192.168.1.2 192.168.1.6`
faye	`DUKE3D.EXE /net 192.168.1.5 /n1 192.168.1.6`
kaoru	`DUKE3D.EXE /net 192.168.1.5 192.168.1.2 /n1`

Addresses and ports

The networking code is capable of resolving WINS host names (on Windows) and DNS names to their corresponding addresses, so if your network is configured with such services, instead of having to specify raw IP addresses, you can give the computer's WINS host name or a DNS host name.

The default port the game communicates on is 23513. Some users may find it necessary to set up a forward through their Internet firewall in order to get games working when playing across the Internet. You can override the default port via the /p??? switch where ??? is the new port number. If a master is running a game on a port other than the default, the slaves will have to specify the alternative port with address:port notation, eg. 192.168.1.5:20000

3D Models

Polymost uses the Quake II MD2 model format for 3D models. You can replace any wall-aligned or face sprite in the game with a 3D model using a declaration in the DUKE3D.DEF file. For more information on the specifics of the DEF-file commands for 3D models, see here.

Included in this release is a model of the Pig Cop by Parkar, and the skin by Motionblur. Visit this thread on the 3D Realms forum for more model information. I shall use this model to demonstrate how to replace the Pig Cop character in Duke.

Here is the definition for the pig cop which is also included in the sample DUKE3D.DEF file.

   //New syntax:
model "models/pigcop.md2"
{
   scale 1.30 shade 0
   skin { pal 0 file "models/pigcop.jpg" }
   anim { frame0 "walk0" frame1 "walk13" fps 20 flags 0 }
   frame { name "walk0" tile0 2000 tile1 2019 }

   anim { frame0 "pump0" frame1 "pump2" fps 10 flags 1 }
   frame { name "pump0" tile0 2025 tile1 2027 }

   frame { name "stand" tile0 2030 tile1 2034 }

   anim { frame0 "shoot0" frame1 "shoot2" fps 10 flags 1 }
   frame { name "shoot0" tile0 2035 tile1 2037 }

   anim { frame0 "dive0" frame1 "dive3" fps 8 flags 1 }
   frame { name "dive0" tile0 2040 tile1 2044 }
   frame { name "dive3" tile0 2045 tile1 2049 }

   anim { frame0 "dshoot0" frame1 "dshoot2" fps 10 flags 1 }
   frame { name "dshoot0" tile0 2050 tile1 2052 }

   frame { name "die0" tile 2055 }
   anim { frame0 "die1" frame1 "dead" fps 13 flags 1 }
   frame { name "die1" tile0 2056 tile1 2059 }
   frame { name "dead" tile 2060 }
}


   //Old syntax:
definemodel "models/pigcop.md2" 1.30 0
definemodelskin 0 "models/pigcop.jpg"

definemodelanim "walk0" "walk13" 20 0
definemodelframe "walk0" 2000 2019

definemodelanim "pump0" "pump2" 10 1
definemodelframe "pump0" 2025 2027

definemodelframe "stand" 2030 2034

definemodelanim "shoot0" "shoot2" 10 1
definemodelframe "shoot0" 2035 2037

definemodelanim "dive0" "dive3" 8 1
definemodelframe "dive0" 2040 2044
definemodelframe "dive3" 2045 2049

definemodelanim "dshoot0" "dshoot2" 10 1
definemodelframe "dshoot0" 2050 2052

definemodelframe "die0" 2055 2055
definemodelanim "die1" "dead" 13 1
definemodelframe "die1" 2056 2059
definemodelframe "dead" 2060 2060

Without going through every line of the example, here is the basis of how the definitions work. You must put a definemodel line before any other definemodelframe or definemodelanim lines. The frame and anim lines refer the the definemodel line which precedes them. You can define frames and animations in any order, ie. the animations do not need to be given before the frames, but it is a good convention to keep them together for clarity.

The walking loop for the pig cop spans tiles 2000 to 2019. The model contains a fourteen frame walking animation which we play at 20 frames per second. The first line of the example specifies the "models/pigcop.md2" model should be drawn at 1.3 times its normal scale and be left undarkened or lightened. The definemodelskin line specifies the skin to use for palette 0 for all the definemodelframe lines that follow it. The first of the definemodelanim lines declares the fourteen frame walking animation at 20fps which should loop (the 0 for the flags parameter says to loop). The definemodelframe line which follows it maps the ART tiles from 2000 through to 2019 to play the walking animation. Because the name in the definemodelframe line matches the first frame of the definemodelanim line, the animation will automatically play.

Quake II is a registered trademark of id Software

DEF-file Language

These are the legal instructions that may be used in the DUKE3D.DEF file. Comments can be used by prefixing the text with a double forward-slash (C++ style), //, or surrounding the text with /* (comment here) */ (C style).

include filename #include filename

Processes the script commands in filename at the point of the "include" call.

define label integer-value #define label integer-value

Declares label to represent the numeric value integer-value. integer-value can be a label, in which case the value of the label given is used.
NOTE: You may find it convenient to include DEFS.CON or NAMES.H to predefine many of the tile names in the art file.

model filename { ... }

Please be aware that we plan to modify certain elements of this model definition syntax in ways that are likely to break existing DEF files written to use this new syntax, so be prepared to update your DEF files once things settle down. However, we do encourage you to experiment with the new style of model definition. Defines an MD2-format model file to replace certain sprites in the game when running in OpenGL Polymost mode. The brace-enclosed block may contain these directives:

scale scale

scale is a (possibly fractional) value specifying a scaling factor for the model when it is rendered, eg. 1.5 for one-and-a-half times as big.

shade shade-offset

shade-offset is an integer value specifying how much to bias the sprite's shade value by. A negative value for this makes the model brighter. Conversely, a positive value makes it darker.

skin { ... }

Defines a skin to be used on the model for all frames declared after this command. The brace-enclosed block may contain these directives:

pal palnum: Specifies which palette this skin maps to.
file filename: IMPORTANT: If your model exists in a subdirectory (ie. the model filename includes a path to the .md2) you will need to give the same path to filename if the skin is in the same directory.

anim { ... }

Defines an animation from a group of frames in the model. The brace-enclosed block may contain these directives:

frame0 framename frame1 framename: Specifies the names of the start (frame0) and end (frame1) frames of the animation.
fps fps: Specifies the framerate at which the animation should play. This value may be fractional.
flags flags: Specifies any special properties the animation should have, the values of which should be added together to combine multiple options. Valid options are: 0 = none (looping animation), 1 = one-shot (plays beginning to end once and stops on the last frame).

frame { ... }

Defines a range of ART-file tiles to correspond with the given frame of the model. The brace-enclosed block may contain these directives:

frame framename name framename: If framename is identical to the starting frame of an animation, the engine will play that animation, otherwise the replacement will be static. You can choose to use the 'frame' or 'name' versions of this directive as both are identical.
tile tilenum tile0 tilenum tile1 tilenum: Use the tile directive to specify an ART-file tile which this model should replace. Use the tile0 and tile1 directives together to specify a range of ART-file tiles. If you use tile0, you must also have a tile1. You may not use the same directive twice to specify multiple ranges.

hud { ... }

Defines a range of ART-file tiles to use with a heads-up-display. The brace-enclosed block may contain these directives:

tile tilenum tile0 tilenum tile1 tilenum: Tile0 and tile1 together specify a range of ART-file tiles which this model frame should replace when rendered as part of the HUD. You can specify individual tiles using a single tile command.
xadd offset yadd offset zadd offset angadd offset: Use these offsets to fine-tune the location of the model placement. Xadd, yadd, and zadd are position offsets relative to the viewer's orienation. You can use floating point values with them. Angadd is a Build angle offset. (512 = 90 degrees, 1024 = 180 degrees, etc...).
hide: Some weapons use multiple ART tiles for constructing the gun or animation. Use this option to hide parts that you don't need in your replacement.
nobob: By default, the HUD model offset is affected by the player bobbing offset when Duke is walking. Use this option to disable that.
flipped: Use this option to apply the settings inside the hud block only if the object is normally rendered x-flipped (mirror image). Some weapons, such as the devastator, are rendered in 2 pieces, the left devastator is actually a mirror image of the right.
nodepth: Use this to render a HUD model without the use of the depth buffer. Normally, you should avoid this. The one exception where this is useful is for the spinning nuke menu pointer because it should always be in front - and it just happens to be convex ... which is the one case that is safe with the depth buffer disabled ... a rather fortunate coincidence :)

Here are some HUD examples:


   // A pistol model that was posted a long time ago...
model "models/m9.md2"
{
   scale 50 shade 4
   anim { frame0 "idle1" frame1 "idle12" fps 5 flags 0 }
   frame { frame "idle1" tile 2524 }
   anim { frame0 "frame13" frame1 "frame45" fps 24 flags 0 }
   frame { frame "frame13" tile0 2525 tile1 2526 }
   anim { frame0 "reload1" frame1 "reload34" fps 24 flags 0 }
   frame { frame "reload1" tile0 2528 tile1 2529 }

   hud { tile0 2524 tile1 2529 xadd -1.2 yadd -1.0 zadd -1.0 angadd 1536 }

   frame { frame "reload1" tile0 2530 tile1 2532 } //consume tiles with dummy frames
   hud { tile0 2530 tile1 2532 hide } //Make it not draw 2D hands during reload
}

   // A devastator weapon model that was posted a long time ago...
model "models/hud_devastator.md2"
{
   scale 12
   skin { pal 0 file "models/hud_devastator.pcx" }
   frame { frame "Frame 1" tile0 2510 tile1 2511 }
   hud { tile0 2510 tile1 2511 xadd -8.5 yadd +1.83 zadd +10.0 angadd 1024 flipped } //left devastator
   hud { tile0 2510 tile1 2511 xadd +8.5 yadd +5.90 zadd +10.0 angadd 1024 } //right devastator
}

   // fearpi's activated tripbomb (wall mine)
model "models/a_tripbomb.md2"
{
   scale 8
   anim { frame0 "frame1" frame1 "frame1" fps 1 flags 0 }
   frame { frame "frame1" tile 2566 }
   hud { tile 2566 yadd +0.35 zadd 1.2 angadd 1024 }
}

   // spinning icon (by Killd a ton)
model "models/spinnuke.md2"
{
   scale 0.25 shade 0

      //when rendered as respawn timer:
   skin { pal 0 file "models/spinnuke.png" }
   anim { frame0 "spin00" frame1 "spin19" fps 17 flags 0 }
   frame { frame "spin00" tile0 2813 tile1 2819 }
   frame { frame "spin00" tile0 3190 tile1 3196 }
   skin { pal 0 file "models/spinnukeyellow.png" }
   frame { frame "spin00" tile0 3200 tile1 3206 }
   skin { pal 0 file "models/spinnukegreen.png" }
   frame { frame "spin00" tile0 3210 tile1 3216 }

      //when rendered as menu icon:
   hud { tile0 2813 tile1 2819 xadd 0.01 yadd -.02 zadd 1.05 nodepth }
}

voxel filename { ... }

Defines a voxel to replace sprites in the game when running in 8-bit classic rendering mode. filename is the name of the .KVX file containing the voxel. The brace-enclosed block may contain these directives:

tile tilenum: Maps the single tile tilenum to be rendered as a voxel.
tile0 tilenum tile1 tilenum: These two directives together define a range of tiles to be rendered as voxels. The 'tile0' directive should appear before the 'tile1' directive to define a correct range.
scale scale: scale is a (possibly fractional) value specifying a scaling factor for the voxel when it is rendered, eg. 1.5 for one-and-a-half times as big.

skybox { ... }

Defines a skybox that overrides a parallaxing floor or ceiling in OpenGL Polymost rendering mode. The brace-enclosed block may contain these directives:

tile tilenum

Specifies the ART file tile to override.

pal palnum

Specifies the palette number the skybox should happen for.

*facename* filename

Defines a single face of the skybox where facename may be any of these keywords appropriate for the face in question:

Front	Right	Back	Left	Top	Bottom
ft	rt	bk	lf	up	dn
front	right	back	left	top	bottom
forward			lt	ceiling	floor
				ceil	down

NOTE: All six faces are required to be specified.

tint { ... }

Defines a Hightile texture tint to simulate palette effects normally used on ART-file tiles. The brace-enclosed block may contain these directives:

pal palnum

The palette number the tint applies to.

red value green value blue value r value g value b value

Specifies a colour component value, in the range of 0 to 255. Unspecified components are assumed to be 255 and any out of range values are clamped to the maximum or minimum as appropriate.

flags flags

Specifies any special processing effects to use for the tint. The value of flags may be the sum of any of these values:

1	convert to greyscale
2	invert colours

Deprecated DEF file directives

The use of these directives is discouraged for new content.

definetexture pic-number palette-number x-centre y-centre x-size y-size filename: Defines a Hightile texture to replace an ART-file picture. pic-number may be an number, or a defined label. Use a value of 0 for x-centre and y-centre and a value of -1 for x-size and y-size for now until these values are actually used. filename may be any PNG, JPG, TGA, BMP, GIF or PCX file.
definetint palette-number red green blue effects: Defines a Hightile texture tint to simulate palette effects normally used on ART-file tiles. red, green, and blue are numbers in the range 0 to 255 which specify the colour the tint should look like. effects specifies any processing effects to use. Valid values are: 0 = no effects, 1 = greyscale image, 2 = invert image. These values can be added together to produce a combination of effects.
defineskybox pic-number palette-number reserved front-face-filename right-face-filename back-face-filename left-face-filename top-face-filename bottom-face-filename: Defines a sky-box composed of six images mapped onto the faces of a cube to be used when pic-number is set as parallaxing in GL Polymost mode. For information on generating sky box images, see here. NOTE: reserved should be 0 for now until its meaning is fully conceived.
definemodel filename scale shade-offset: Defines an MD2-format model file to replace certain sprites in the game. See "definemodelframe" and "definemodelanim" for details on how to specify the ART-file tiles to replace. filename is the name of the MD2 model. scale is a (possibly fractional) value specifying a scaling factor for the model when it is rendered, eg. 1.5 for one-and-a-half times as big. shade-offset is an integer value specifying how much to bias the sprite's shade value by. A negative value for this makes the model brighter. Conversely, a positive value makes it darker.
definemodelskin palette-number filename: Defines a skin to be used on the model for all frames declared after this command, when the sprite palette is equal to palette-number. (This makes more sense when given a demonstration.) IMPORTANT: If your model exists in a subdirectory (ie. definemodel includes a path to the .md2) you will need to give the same path to filename if the skin is in the same directory.
definemodelanim start-frame end-frame frame-rate flags: Defines an animation from a group of frames in the model given by the last preceding "definemodel" instruction. start-frame and end-frame specify the names of the starting and ending frames of the animation. frame-rate is the frame rate at which the animation should play. This value can be fractional. flags specifies any special properties the animation should have. Valid options are: 0 = none (looping animation), 1 = one-shot (plays beginning to end once and stops on the last frame).
definemodelframe frame-name first-tile last-tile: Defines a range of ART-file tiles to correspond with the given frame of the model specified in the last preceding "definemodel" instruction. frame-name is the name of the frame, which if identical to the starting frame of a "definemodelanim" animation will play that animation. If the frame name is not corresponding with an animation, the replacement will be static. first-tile and last-tile specify a range of ART-file tiles which this model frame should replace.
definevoxel filename: Defines a voxel to replace sprites in the game. See "definevoxeltiles" for details on how to specify the ART-file tiles to replace. filename is the name of the .KVX file containing the voxel.
definevoxeltiles first-tile last-tile: Defines the range of ART-file tiles to replace with the voxel given in the last preceding "definevoxel" instruction.

A note about skyboxes

Ken has some utilities on his website that can assist you in converting your favourite skybox format to Polymost format. (http://advsys.net/ken/kube/kube.htm) If your skybox is in Mercator projection, then you'll need to run MERC2KUB.EXE first. Once you have your 6 face textures, you can use KUBE.EXE to convert it to Polymost format using the /split option. The face textures can be in almost any configuration - KUBE has fancy autodetection code. For example, typing "kube globe.mov /split" will generate the 6 face textures in the order and orientation that Polymost expects. The output files will be called SPLITCAP0.PNG, SPLITCAP1.PNG, ..., SPLITCAP5.PNG. After conversion, I suggest you rename the files and compress them using PNGOUT or similar utility.

Map Hack scripts

"Map Hack" scripts are files that override certain aspects of a map file when it is rendered in OpenGL Polymost mode. Currently they allow for angle adjustment on sprites, and the ability to prevent particular sprites from being drawn as a model. These are useful for making small corrections to ornamental sprites in a way that doesn't require modifying the original map.

The game will automatically load a map hack script whenever a map is loaded. The script should have the same base name as the original .MAP file, but with an .MHK extension. The map hack language is described below. It uses the same parser as DEF files, so you can use comments in the same way.

sprite number

Begins a sprite definition. number is the sprite number to affect. You can find this in the Build editor by highlighting the sprite in 2D mode and pressing Control+Tab. The next group of commands describe the changes to make to the sprite.

notmd2: Prevents the sprite from being drawn as a model. It gets drawn as a regular sprite instead.
angleoff angle angoff angle: Adds angle to the angle of the sprite just before it is rendered. This is good for fixing up things like toilet sprites that are facing the wrong way. angoff is a synonym for angleoff.

Here is an example map hack script:

// Map hack file for JFDuke3D
// Level: E1L2.MAP (Original Atomic Edition version)
// Prepared by jonof@edgenetwork.org

// Invisible switch behind hand dryer in toilet of porn shop
sprite 191 notmd2

// Invisible switches on telephones near billiards room in club
sprite 254 notmd2
sprite 517 notmd2

// Toilet in restroom in club
sprite 478 angoff -512

Hightile

This release features the "Hightile" texturing improvements to Polymost. Hightile allows Polymost to use true-colour textures instead of the artwork in the game's usual .ART file.

Replacement textures can be saved as JPEG, PNG (alpha channel supported), TGA, BMP, CEL, GIF, and PCX formats. Hightile uses Ken Silverman's picture library to provide rapid picture file loading.

Hightile textures are defined in the DUKE3D.DEF file. See the DEF-file language reference for information on how to specify Hightile textures.

Limitations to Hightile in this release

Hightile will squash or stretch the replacement to fit in the dimensions of the original tile it replaces. Artists should keep their replacements in the same ratio as the original tile for the art to not look distorted.
Duke does not precache textures yet with a great level of sophistication, so be aware that you will notice a small delay on occasion as a texture is loaded into memory when it is first seen.

ZIP file support

Duke (and Build games in general) can load game resources from a ZIP file.

ZIP files are used in Duke in the same manner as extra GRP files are specified. Use the "/g" command-line switch to specify the ZIP to load. eg. DUKE3D.EXE /gMYFILE.ZIP

Polymost

Polymost is a full 3D implementation of the Build engine renderer, with hardware acceleration capability, and perspective in six degrees of freedom. In Ken's own words (copied from POLYMOST.C in my Build engine source distribution):

"POLYMOST" code written by Ken Silverman
Ken Silverman's official web site: http://www.advsys.net/ken

Motivation:
When 3D Realms released the Duke Nukem 3D source code, I thought somebody would do a OpenGL or
Direct3D port. Well, after a few months passed, I saw no sign of somebody working on a true
hardware-accelerated port of Build, just people saying it wasn't possible. Eventually, I realized
the only way this was going to happen was for me to do it myself. First, I needed to port Build to
Windows. I could have done it myself, but instead I thought I'd ask my Australian buddy, Jonathon
Fowler, if he would upgrade his Windows port to my favorite compiler (MSVC) - which he did. Once
that was done, I was ready to start the "POLYMOST" project.

About:
This source file is basically a complete rewrite of the entire rendering part of the Build engine.
There are small pieces in ENGINE.C to activate this code, and other minor hacks in other source
files, but most of it is in here. If you're looking for polymost-related code in the other source
files, you should find most of them by searching for either "polymost" or "rendmode". Speaking of
rendmode, there are now 4 rendering modes in Build:

rendmode 0: The original code I wrote from 1993-1997
rendmode 1: Solid-color rendering: my debug code before I did texture mapping
rendmode 2: Software rendering before I started the OpenGL code (Note: this is just a quick
hack to make testing easier - it's not optimized to my usual standards!)
rendmode 3: The OpenGL code

The original Build engine did hidden surface removal by using a vertical span buffer on the tops
and bottoms of walls. This worked nice back in the day, but it it's not suitable for a polygon
engine. So I decided to write a brand new hidden surface removal algorithm - using the same idea
as the original Build - but one that worked with vectors instead of already rasterized data.

Polymost is the default renderer choice for any video mode with a colour depth greater than 256 colours.

NOTE: If your computer does not have an OpenGL graphics card, Polymost in OpenGL mode will most likely use the default Windows OpenGL rasterising facility which does all rendering in software. This may be extremely slow. If your Windows installation doesn't have any form of OpenGL rendering ability, Polymost will probably crash.

NOTE 2: OpenGL Polymost has been tested on an nVidia Riva TNT 16MB, an nVidia GeForce2 GTS 32MB, an nVidia GeForce4 Ti4600 128MB, an ATi Radeon Mobility 9000 64MB, and a 3D-Labs Oxygen GVX420 128MB (minor texturing issues).

Console Commands

This is a list of console commands and variables and their purpose:

changelevel <episode> <level>

Warps to a new level.

dumpbuildinfo

Displays the compilation information for the game when it was built.

echo <text...>

Displays to the console what is passed as parameters to the command.

fileinfo <filename>

Displays some information about a given file, eg. size, CRC-32 checksum.

glinfo

Displays some information about the OpenGL driver.

gltextureanisotropy <level>

Sets the OpenGL anisotropic filtering level.

gltexturemode <mode-number>

Sets the OpenGL texturing mode. Valid values are:

0	GL_NEAREST (looks rather like the original software renderer)
1	GL_LINEAR
2	GL_NEAREST_MIPMAP_NEAREST
3	GL_LINEAR_MIPMAP_NEAREST (bilinear)
4	GL_NEAREST_MIPMAP_LINEAR
5	GL_LINEAR_MIPMAP_LINEAR (trilinear)

god

Enables God mode.

help <name>

Displays a help message for a particular console variable or command.

listsymbols

Displays the names of all commands and variables available in the console.

map <mapname>

Loads a user map.

noclip

Disables player collisions with world objects.

quit

Exits the game.

restartvid

Resets the video system, reinitialising the video mode.

setrendermode <mode>

Sets the current Polymost render mode.

setstatusbarscale <percent>

Sets the size of the status bar as a percentage of its original full-width size. Minimum size is 10%, maximum 100%.

vidmode [xres yres] [bpp]

Changes the current video mode. You may pass either a new resolution (eg 640 480), a new colour depth (eg 32), or both a resolution and colour depth (eg 640 480 32).

bpp <colourdepth>

Sets the colour depth. Does not apply it immediately though. You need to use 'restartvid' after setting this if you want to apply the change.

glusecds <0 or 1>

Enables the use of the ChangeDisplaySettings() Windows function to switch the current screen mode. Some video cards require this be set in order for OpenGL to work properly. Intel and Matrox users are in this category.

glusetexcompr <0 or 1>

Enables or disables the use of OpenGL texture compression for hightile textures. You need to use 'restartvid' to apply any changes to this value.

novoxmips <0 or 1>

Disables or enables the use of voxel mipmaps to improve voxel visual quality.

osdrows <num>

Sets the number of visible lines of the console when it is open.

screencaptureformat <0 or 1>

0 = Targa, 1 = PCX

showcoords <0 or 1>

Same as typing "DNCOORDS" cheat.

showfps <0 or 1>

Shows/hides the framerate counter. Same as typing "DNRATE" cheat.

usemodels <0 or 1>

Disables or enables the use of 3D models in GL Polymost mode if any are defined.

usevoxels <0 or 1>

Disables or enables the use of voxels in the classic renderer if any are defined.

glredbluemode <0 or 1>

Enables or disables the red-blue stereovision mode in OpenGL. This mode is experimental at this time. We know the flicker is nasty and the menu background will mix into the screen. To avoid the menu bug, run the game in fullscreen mode and type "glredbluemode 1" AFTER beginning the game. Sorry, there is no way to change parallax or separation. Do not contact us about bugs with this mode... if you do, we'll think twice about documenting hidden features in future releases. :P

Historical Documentation

The content in this section is here for historical reference purposes.

A quick word before we get to 3D Models

Before I explain the new 3D model support, I need to explain the changes which have been made to how the Hightile enhancements, 3D models, and voxels are described to the game.

Users of previous releases of the port would be familiar with the "definetexture" instruction in the CON language which is used to declare Hightile replacement textures. Typically, you would have an extra CON file, often named EXTRA.CON, which you would use to declare textures and whatnot. This file would be passed to the game using a "/x" switch to override the default GAME.CON from executing. In order to provide more generic flexibility so that the enhancements are not tied to the CON language, I have created a new script loader as a service of the engine which is now used to read a file containing those same definitions which CONs once provided. This script file is named DUKE3D.DEF and its syntax is similar to the CON language.

The benefits to come from this change to a separate file arrangement is that the new engine features now work in the Build editor as well as the game. Plus, the script reader is a reusable component of the engine which means any future games, or any modifications based on the engine will have the option of using this feature for themselves.

Converting EXTRA.CON to DUKE3D.DEF

Since the port now uses the DUKE3D.DEF file to specify replacements and whatnot, the CON features have been disabled and a warning written to the console put in their place, something like:

!!! BEGIN NOTICE !!!
CON-file definition of Hightile textures has been removed in
favour of DUKE3D.DEF declarations. Please refer to the release
notes for details on how to convert your CON definitions into
DUKE3D.DEF equivalents.
!!! END NOTICE !!!

Since DUKE3D.DEF has a syntax much like the CON language, conversion is not a difficult task. Refer below to the details on the instructions and their parameters for specifics, but here is the basic changes which you would need to make to an EXTRA.CON file to create DUKE3D.DEF:

If you include GAME.CON in the EXTRA.CON file, you will want to change this to include DEFS.CON instead.
If there are "definetint" lines, they must be checked to be sure to show five parameters. If there are only four parameters (which would be palette number, red, green, and blue values), add a 0 to the end (which is the effects parameter that was option in the CON language).
If any of the "definetexture" lines have filenames that contain whitespace, double quotes need to be placed around the filename. It is best to put quotes around all strings, but for strings with no embedded whitespace, quotes are not mandatory.

Complete reference on the DUKE3D.DEF file is here.

Happy Duke'ing!
Jonathon Fowler (jonof@edgenetwork.org)