Release Notes for JonoF's Duke Nukem 3D Port

Release date: 18 January 2004

New Features

• Ken Silverman's Polymost 3D renderer. See here for more information.
• Experimental network code. See here for more information.
• Options menus have been reorganised.
• Mirrors work in all renderers.

Known Issues

• Multiplayer code is only really usable on a fast LAN with fast computers, and even then sometimes it's not reliable, but for the most part quite stable. Slow machines and connections over the Internet are prone to failure. See here for information on using the network features.
• This release contains an improved version of Ken Silverman's "Polymost" renderer for Build. This new renderer supports full 3D rendering of the world, and also includes an OpenGL implementation. See the Polymost section of this document on using this renderer.
• Software polymost has a bug in the rendering of mirrors.

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.

Brief history:
04/01/2003: 3D Realms releases Duke Nukem 3D source code
10/04/2003: Jonathon Fowler gets his Windows port working in Visual C
10/04/2003: I start writing POLYMOST.BAS, a new hidden surface removal algorithm for Build that
            works on a polygon level instead of spans.
10/16/2003: Ported POLYMOST.BAS to C inside JonoF KenBuild's ENGINE.C; later this code was split
            out of ENGINE.C and put in this file, POLYMOST.C.
12/10/2003: Started OpenGL code for POLYMOST (rendmode 3)
12/23/2003: 1st public release
01/01/2004: 2nd public release: fixed stray lines, status bar, mirrors, sky, and lots of other bugs.
		

Polymost can be enabled in the setup program, or via the new "Video Options" menu which exists under the normal "Options" main menu selection. You will see at the bottom of the Video Options menu a "Renderer" option, which normally reads "Classic". Press Enter on that option to cycle through to "Polygon" which is Polymost with software rendering, and once more to "OpenGL" which is Polymost with hardware acceleration.

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).

Network Games

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:

1. Slow computers will fail to negotiate a connection with the game. I do not know where exactly the cut-off lies, but basically, machines which have worked are anywhere from a Pentium 3 1000MHz and upwards, while a Pentium 233MMX failed to achieve synchronisation. If you choose to test the game, your mileage may vary.
2. Slow or laggy networks may prove to be a problem. This means no Internet play because the game quickly goes to crap soon after negotiating the connection, if it even manages that.
3. I have noticed that sometimes at the end of a map, the game jams up at the intermission screen showing the player scores.
4. If the game seems to be stuck waiting, try holding Escape for at least four seconds and hopefully the game will kill itself. If this fails to work, you may have to kill the game using Windows' Task Manager.

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.

Hosting a game

A machine hosting a game needs to create a configuration file which contains the following information:

• The port to communicate on (if omitted, defaults to 19014)
• The number of players to wait for
• An indication of whether to host or join a game (in this case, host)

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 = 3

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.

Joining a game

A machine joining a game needs to create a configuration file which contains the following information:

• The port to communicate on (if omitted, defaults to 19014)
• The address (and port) of the computer hosting the game
• An indication of whether to join or host the game (in this case, join)

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.