Release date: 3 June 2004
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 flexibilty 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.
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:
Complete reference on the DUKE3D.DEF file is here.
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 an imp by Cheb and Edmundo Bordeu. See here for more info on the model and of from where it came. I shall use this model to demonstrate how to replace the Liztroop character in Duke.
Here is the definition for the imp which is also included in the sample DUKE3D.DEF file.
definemodel "models/imp.md2" 2 4 definemodelanim "walk1" "walk4" 6 0 definemodelframe "walk1" 1680 1704 definemodelanim "atk1" "atk5" 16 1 definemodelframe "atk1" 1715 1717 definemodelframe "idle" 1720 1727 definemodelanim "pain1" "pain2" 8 0 definemodelframe "pain1" 1730 1730 definemodelanim "die1" "die6" 8 1 definemodelframe "die1" 1731 1734 definemodelframe "pain1" 1738 1738 definemodelframe "pain2" 1739 1740 definemodelframe "pain1" 1741 1741 definemodelframe "pain2" 1742 1742 definemodelframe "idle" 1744 1751 definemodelframe "idle" 1754 1755
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 preceeds 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 liztroop spans tiles 1680 to 1704. The model contains a four-frame walking animation which we play at six frames per second. The first line of the example specifies the "imp/imp.md2" model should be drawn at two times normal scale and be darkened by a shade offset of four. The first of the definemodelanim lines declares the four frame walking animation at 6fps which should loop (the 0 for the flags parameter says to loop). The definemodelframe line which follows it maps the ART tiles from 1680 through to 1704 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
These are the legal instructions that may be used in the DUKE3D.DEF file.
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.
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" commandline switch to specify the ZIP to load. eg. DUKE3D.EXE /gMYFILE.ZIP
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 abililty, 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).
This is a list of console commands and variables and their purpose:
This information is here for reference only. The networking feature is currently under redevelopment. Although the code in this release works, it fails with more than two players trying to join.
Because this feature is still experimental, setting up a network game is not the most streamlined of tasks, but it is achievable. First, some things to note:
So, knowing these particular nuances, this is how to configure a network game.
IMPORTANT: Place two or more blank lines at the end of the configuration files below or the game will start in singleplayer mode. This is a bug in my script loading code which I have not yet fixed.
A machine hosting a game needs to create a configuration file which contains the following information:
This can be placed in a text file (which for this demonstration I will name player-host.ini) like so:
[Network Game]
IPPort = 19014
Mode = "Host"
Players = 2
To then start the game and wait for players to join, either create a shortcut to DUKE3D.EXE and modify its properties to use a command line like the following, or type the following at a DOS prompt.
D:\Duke3D> duke3d.exe -net player-host.ini -name JonoF
The game will then start and wait for players to join.
A machine joining a game needs to create a configuration file which contains the following information:
This can be placed in a text file (which for this demonstration I will name player-join.ini) like so:
[Network Game]
IPPort = 19014
Mode = "Join"
Host = "asuka:19014"
To then start the game and wait until the rest of the players join, either create a shortcut to DUKE3D.EXE and modify its properties to use a command line like the following, or type the following at a DOS prompt.
D:\Duke3D> duke3d.exe -net player-join.ini -name FonoJ
The game will then start and wait until enough players have joined.
Happy Duke'ing!