DXX-Rebirth and the work of keeping a 1995 game source port alive

A source port stacked on three older codebases

DXX-Rebirth is based on the late D1X and D2X source ports, which in turn were based on the original Descent source and LDescent. The project states its aim plainly: the Rebirth Team has spent a lot of time improving the source code by fixing old bugs and adding improvements, while always staying true to the philosophy, Keep it Descent.

That lineage is the whole story of the project, and it explains its shape. This is not a new engine written from scratch, it is four generations of code, each generation a port of the one before, and the maintenance work is mostly about making the oldest layer build and run correctly on systems nobody had heard of when it was written.

The project opens its README with a plain ASCII banner, which is the only decoration in a document that is otherwise entirely about behaviour:

                         __________
__________/ DXX-Rebirth /

The stated goal follows directly. It is the goal of DXX-Rebirth to keep Descent 1 and 2 alive and well, updating them for modern PCs while also keeping them the same games you remember playing back in 1995.

The repository layout makes the generations visible. There is a d1x-rebirth directory and a d2x-rebirth directory, one per game, alongside a common directory for the shared engine, a contrib directory, a Documentation directory and a similar directory. The build uses SConstruct, the Python-based build system, rather than a Makefile, and there is a Brewfile, which is the macOS Homebrew dependency list, plus a script for building an ebuild snapshot. The COPYING.txt and GPL-3.txt files at the root carry the legal terms.

The primary language is C++, the topics are c-plus-plus and game-engine, the default branch is master, and the repository is not archived. The last push was on 2026-10-11. The tagged releases are old, 0.59.100 in December 2016 and 0.60.0-beta2 in April 2018, so the master branch has moved a long way past the last named build.

Compatibility with the original games is the headline feature

The feature list is long, and the first item is the one that defines the project: full compatibility with Descent and Descent 2, including all expansions and third-party levels.

That claim is specific and it is the hard part. A level from 1995 is a set of mine data, segment data and wall data in a particular binary format, and the renderer has to reproduce the original look closely enough that the level plays the same way. Anything that changes the geometry or the collision behaviour changes the game. So the port's job is to reproduce the original precisely, not to improve it, and the project says so several times over.

The same principle shows up in the file formats. Player files, savegames, demos and missions from the DOS versions of the games can freely be used in DXX-Rebirth. That is a compatibility promise in the other direction, and it is the kind of thing that is expensive to get right and cheap to break.

The demo recording system is the other place where fidelity matters and where the port claims an improvement. The ingame demo-recording system has been improved, with demos that are less glitchy and smaller while still being backwards-compatible to earlier versions of the games. Backwards compatibility for demos matters to a community that watches and shares them, so a smaller format with no loss of old playback is a real improvement rather than a cosmetic one.

One behavioural claim is about bug fixes in the physics rather than the presentation: higher game speed will not cause glitches such as unacceptable fast homing projectiles, incredible high damage caused by several collisions or the Fusion cannon. Descent is a game about moving fast in tight tunnels, so the projectile and collision behaviour at high speed is gameplay, and fixing it is a compatibility question as much as a quality one.

SDL and OpenGL replaced the DOS hardware assumptions

The list of modernisations is where the porting work shows.

Rendering is OpenGL, which the project credits with fast and smooth rendering even on low-end systems. Several effects are optional, including Transparency, Colored Lighting, Texture Filtering and FSAA, which is the right shape for a port: the default path is the one that works everywhere, and the extras are opt in.

Input moved to SDL, and the project credits that with supporting a wide variety of joysticks, and with letting you use more joysticks, buttons and axes than you can ever operate in your state of evolution. Joystick, keyboard and mouse can be used simultaneously, which the original DOS game could not do.

Display handling covers all resolutions and aspects supported by your monitor, including an option for VSync. Audio supports MIDI and CD-Audio, which is Redbook audio, and you can play your own custom music from your hard drive or a separate AddOn.

The AddOn concept is worth noting because it is how the port stays open. Both games can utilize special AddOn packs to replace or expand the original game content, which is the mechanism by which new levels, new missions and new music reach a game whose original data format has not changed. The philosophy and the architecture turn out to be the same thing: keep the original formats, and add to them rather than replace them.

Multiplayer is UDP with one default port and a NAT warning

Multiplayer is the feature with the most operational content in the README, and it is where a modern port has to make choices about the network.

DXX-Rebirth supports multiplayer over UDP/IP, which works over LAN and Internet. The transport choice is UDP, and the reason given is that it provides fast and easy-to-use LAN and online action, and that it includes reliable communication causing less glitches due to lost packets. In other words, reliability is implemented above UDP rather than being inherited from TCP, so the game gets datagram speed without TCP's head-of-line blocking.

By default, each game communicates over UDP port 42424, and this can be changed via the menus, a command line argument or .ini files. Three ports, three ways to set it, and the .ini file route is what a dedicated server or a scripted launch needs.

The port forwarding guidance is precise about when it is needed. If you host a game and players want to join your game online via direct IP connection, your specified game port should be forwarded on your router. If you host your game on the Online Tracker and other players join via this method, port forwarding should not be necessary. If you only want to join a game, or host a game on LAN rather than online, port forwarding should not be necessary either. The fallback advice for anyone who still has problems is to check your NAT settings and/or firewall.

The Online Tracker is doing real work here. It is the rendezvous path, and it is what makes direct connections optional. A host behind a typical home router can be reachable without touching the router configuration at all.

The source is old, so the installation is a separate document

The installation section of the README is a single line, and it points to another file: See INSTALL.markdown.

That is a reasonable thing for a project of this age to do, because the answer depends on the platform. The repository has a Brewfile, which is a macOS Homebrew dependency list, so there is at least a scriptable path for macOS, and the SConstruct file at the root is the build entry point for everything else. The source code can also be compiled on many other systems beyond the three officially supported ones, which are Linux and other Unix-likes, Mac OS X and Windows.

What the visible documentation does not give you is the actual dependency list or the exact commands, and that is the practical gap for anyone evaluating the project today. The build tooling is a Python-based SCons setup with a C++ codebase, and a 2018-era C++ project on a current toolchain is exactly the kind of thing where compiler warnings have become errors and standard library assumptions have shifted.

The Mac Command keys are working, which is a small example of the class of detail this project spends effort on: F1 Help documents it, and Command-Q works much like a normal Mac program. That kind of platform fidelity is what separates a port from a rebuild.

The other documentation entry points are the issue tracker, where the guidance is to use the GitHub issues tab to report a new issue and to add as much detail as possible in the template provided, and the Documentation directory in the repository.

Where DXX-Rebirth is the wrong choice

The first wrong case is anyone who wants a current game rather than the original one. This is a source port, and its entire value is fidelity to a 1995 game, including the original level formats, the original physics and the original shareware structure. The project even runs to a marketing line about preparing for Descent, and the emphasis on keeping it the same games you remember playing is the design constraint that makes it good and also makes it unsuitable as a base for something new.

The second wrong case is a team that needs a maintained engine with a release cadence. The tagged releases are 0.59.100 from December 2016 and 0.60.0-beta2 from April 2018, and while the last push was on 2026-10-11, the named builds are old. There is no 1.0, there is no supported release line, and the version numbers in the 0.60 beta range say what stage the project is at.

The third wrong case is a deployment on very modern hardware, particularly a discrete GPU and a high refresh display, where the original rendering model has nothing to say. The project claims fast and smooth rendering on low-end systems, which is the right target for the games, but a 1995 tunnel shooter running at native 4K on a modern card is not where the effort went.

The alternative worth naming is the original Descent and Descent 2 releases, in their commercial or shareware forms, running under a DOS emulator or a maintained source port, and the difference in approach is about where the fidelity work lives. The original games are the source of truth and the port is a reimplementation of their behaviour on new hardware, which is a continuous maintenance commitment that the original binaries do not require from you. If you want the games as they were, the original is simpler and exact. If you want them on a system with no DOS support, with modern controllers, modern displays and online play without an emulator, the port is the only route, and it is a route someone has been maintaining since the DOS era.

Licensing, the legal files and who to contact

The legal section of the README is two lines and two links: see COPYING.txt and GPL-3.txt. The project metadata lists the licence as a custom one that GitHub cannot classify, and those two files in the repository root are the authoritative text. A GPL-3 file at the root is a strong signal about the shape of the terms, and a copyleft licence on a game source port has consequences for a modified distribution, so the files themselves are what to read rather than any assumption.

The structure of the repository also tells you something about the provenance. The Descent and Descent 2 games themselves are commercial titles from Parallax Software, and the source ports in this lineage were made from source that the original developers released. A source port that ships the original game data and expands it with AddOn packs is working inside a licensing arrangement that the COPYING.txt file presumably records, and the fact that the project ships an AddOn mechanism and a third-party level compatibility promise is only coherent with that arrangement in place.

The contact section is a single GitHub link to the project repository, and the project issues a caveat about hosting games for others, which is a practical note: if you host a game and expect players to connect over the internet by direct IP, you need the port forwarded, and if you use the Online Tracker you do not.

The repository is not archived and the last push was on 2026-10-11, so somebody is still working on it. The primary language is C++, the topics are c-plus-plus and game-engine, and there is a Documentation directory for anything the README does not cover.

Editorial conclusion

DXX-Rebirth fits a player who wants the original Descent and Descent 2 experience including the expansions and third-party levels on a current machine, or a developer who wants to work on a game engine with a real history. It is the wrong choice if you want a maintained commercial game, and the wrong choice if you need the newest hardware paths, because the most recent tagged builds are from 2018 and the last push was on 2026-10-11 on an untagged master branch. Before you install, read INSTALL.markdown and COPYING.txt, and check the port number and the NAT requirements if you plan to host online.

Frequently asked questions

Official sources

1. dxx-rebirth/dxx-rebirth on GitHub
2. Issues
3. README
4. Releases