# Release Notes for JonoF's Duke Nukem 3D Port

Release date: 8 February 2004

## New Features

- True-colour textures. See here for more information.
- ZIP file support. See here for more information.
- Basic joystick support.

## 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.
- When a joystick is connected, mouse aiming becomes twice as sensitive in the vertical direction when run mode is enabled. This problem will be fixed in the next release.
- A number of joystick configuration options are not accessable in the options menu in the game. Some work needs to be done to improve Duke's input handling code and when that is complete I will add these configuration menus.

## Hightile

This release features the debut of 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, or GIF formats. Hightile uses Ken Silverman's picture library to provide rapid picture file loading.

Here is an example .CON file (named EXTRA.CON for this exercise) demonstrating how to specify palette tints and texture replacements. To use this file, you would run Duke as "`DUKE3D.EXE /xEXTRA.CON`":

>     // Extra additions to the game

>     include GAME.CON

>     // These entries simulate full-palette tinting
>     //   definetint <pal#> <r> <g> <b>
>     //     pal# is the palette lookup
>     //     r/g/b are the colour component factors which tint true-colour textures

>     definetint 1 110 110 255
>     definetint 2 255 110 80
>     definetint 4 0 0 0
>     definetint 6 0 255 0
>     definetint 7 255 255 60
>     definetint 8 180 255 200

>     // These entries define texture replacements
>     //   definereplacement <pic#> <pal#> <centx> <centy> <sizx> <sizy> <filename>
>     //     pic# is the tile number to replace.
>     //     pal# is a specific palette number to replace. 0 replaces everything not
>     //           explicitly defined on its own.
>     //     centx/centy are the centering offsets for the replacement texture.
>     //     sizx/sizy specify the texture size in regular tile coordinates.
>     //           -1 says to use the size of the original tile.
>     //     filename is the picture file name.

>     definetexture FEMPIC6 0 0 0 -1 -1 newtextures/009.png
>     definetexture FEMPIC7 0 0 0 -1 -1 newtextures/rika.png

### 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. This means the sizx and sizy parameters in the example above are ignored, but won't be in a future version, so use -1 for those values for now.
- Like above, the centx and centy parameters are ignored at present but won't be in a future version.
- Hightile does not use texture compression yet. A future release will add this support for video cards that can handle compressed textures.
- Hightile does not precache textures yet. 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 now 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

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.