FastDOOM: a Doom port tuned for 386 and 486 hardware

A port aimed at the hardware Doom originally ran on

FastDOOM is a Doom port for DOS, based on PCDoom by @nukeykt. The project states its goal plainly: to make it as fast as possible for 386 and 486 personal computers. That framing decides almost everything else about the project, because a 386 or 486 is a machine with a few megabytes of usable RAM, an 8-bit VGA card and a CPU measured in tens of megahertz.

The port keeps the lineage of the original source. PCDoom is a cleaned up and modernised version of the Doom code, and FastDOOM extends that base rather than starting from scratch, which is why the feature list is mostly about what was added and removed rather than about a new engine.

The changes worth understanding first are the ones that remove work from the renderer. There is an option to render visplanes, the flat ceiling and floor surfaces, without textures. There is an option to render walls without textures. There is an option to render the sky as a flat fixed colour. Each of these turns a textured draw into a solid fill, which on an 8-bit card is the difference between copying a few hundred bytes per row and doing per-pixel work.

There is also a new detail level called Potato, which renders the full scene at a quarter width resolution, at most 80x200, and the README states plainly that it is much faster to render, especially on 386 CPUs and slow 8-bit VGA ISA cards. Combined with the option to show only objects that are not far away from the player, with all the enemies still rendered because they are considered important, this is a rendering budget you can dial down in two independent ways.

The trade is visible, of course. Flat visplanes and a flat sky are not the game as it looked in 1993. The point of the port is that you decide which visual features you can live without on the machine you have.

Spectre rendering options and the FPS viewer

One option deserves its own note because it comes in three different flavours. FastDOOM can render Spectres and invisible objects as real transparent objects, which the README describes as harder to see and a little faster to render. It can also render Spectres and invisible objects the way the Sega Saturn port did, and it can render them the way Heretic and Hexen did.

These are different rendering techniques inherited from different ports, and they are exposed as separate options rather than one unified path. That is a reasonable thing for a speed focused port to do: each technique has a different cost and a different visual result, and the user is the only one who knows what their monitor and their taste will accept.

The instrumentation around the renderer is what turns the options into a usable tool. The project added an FPS viewer in game and an FPS calculation after timedemo runs. Combined with the advanced benchmark support and the uncapped FPS mode with frame interpolation for more than 35 fps, you can measure what a given option actually costs on your machine.

That measurement capability is arguably more valuable than any single rendering option. A frame rate claim in a README is a claim about someone else's machine, and the demo table in the README is explicit about its hardware, including a FastDoom 0.8 live demo on a Texas Instruments 486DLC at 40 MHz with a Cirrus Logic GD-5422 ISA card. The in-game viewer lets you produce the same kind of number on your own hardware.

Other additions in the same spirit: a new detail level, a secrets completed counter on the automap, next and previous weapon keys, mouse buttons bound to different actions such as fire, move forward, strafe, use, speed and weapon selection, and VT100 terminal output support.

Sound support spanning three decades of hardware

The sound support list is the longest part of the feature set, and it tells you the kind of machine this port is expected to run on. The PC Speaker uses all the available sounds, and there is a new PC Speaker mode for digitised sound. The Disney Sound Source, the COVOX LPT DAC and the OPL2 PCM are supported, along with OPL2LPT and OPL3LPT, the Tandy 3-voice PCM using the SN76489, the Creative Music System and Game Blaster, the IBM PC Music Feature card, the ESS ESFM, Adlib Gold digital sound, and the Windows Sound System.

For music there is audio-CD music support, PCM music through the sound effects device, and native Roland MT-32 support with the GM set and display, plus Roland SC-55, Yamaha TG300, Yamaha MU80 and Adlib OPL2 LPT support, all with display support where the hardware has one.

The point of listing this much is not completeness for its own sake. Sound support on DOS was fragmented in a way that no other subsystem was, and a game that worked on one machine frequently produced silence or noise on another. A port that enumerates the adapters and picks the right one removes a class of problem that has nothing to do with performance.

One entry is explicitly marked as being for fun rather than function, which is fair, and one is a genuine reduction: mono sound support was added. On a machine with a mono output, playing stereo audio wastes a cycle that cannot be recovered anywhere else.

The repository carries a MT32GM.MID file at the root, which is the General MIDI style data used with the Roland support, and the HERCULES automap support adds the Hercules graphics card to the list of video hardware as well, so the port can draw its automap on that display.

What the port removed to get the speed

Three features are listed as removed, and they are worth taking seriously because two of them are load bearing for how people used to play.

Network gaming support is gone. Joystick support is gone. Y mouse movement is gone, meaning the forward and backward movement that a mouse could be used for in place of the keyboard.

For an online play or a joystick aiming setup, FastDOOM is simply the wrong tool, and no configuration option brings those back. That is a design decision rather than an oversight: joystick and network code cost memory and CPU time on a 386, and the port's stated priority is speed on that class of machine.

The fourth entry in that list is the one that can bite. The low memory limit was removed, with the parenthetical warning that this may cause crashes with low RAM. The low memory limit in DOS engines exists because the original code assumed a memory layout that was not guaranteed. Removing the limit lets the port use the full memory of the machine, and better use of system RAM is listed as a separate improvement, full memory allocation. On a machine with enough RAM that is a straight win. On a machine with very little, the README is warning you that the port can crash instead of degrading.

The other structural change is the executable format. DOS/4GW was replaced with DOS/32A, which the README says provides a good speedup, and the DOS/32 stub is added during the build. The port also added autorun support on the F12 key, which matters on a machine where running a batch file is otherwise part of the ritual.

Building from source with OpenWatcom on Linux or WSL2

The build is a source build, and the requirements are specified. You need Linux or WSL2 on Windows. The toolchain is OpenWatcom v2, NASM, GNU Make, which the README recommends because it significantly speeds up builds, a DOS emulator for adding the DOS/32 stub, either DOSEMU2 which is preferred, DOSBox-X or classic DOSBox, and 7-Zip but only for the packaging script.

The sequence is short. You source the environment script, then run the build script with a target and any combination of flags:

source fdenv.sh
./build.sh fdoom.exe -clean -stub

The flags are `-clean` to clean all generated object files before building, `-stub` to add the DOS/32 stub, which is the step that requires a DOS emulator, and `-debug` to generate a debug executable with symbols, traceable stack frames and a map file, with the note to adjust `dbgcfg.h` to your needs.

The supported targets are named in the README and include fdoom.exe, fdoomega.exe, fdoomt50.exe, fdm1024r.exe, fdsetup.exe and fdstart.exe, so the naming encodes the target class rather than being arbitrary.

There are three other entry points. `./buildall.sh` builds all the executables with automatic DOS/32 stubs. `./package.sh` generates a full release package as a ZIP, which is the step that needs 7-Zip. And the setup program has its own build, which the README gives as a separate pair of invocations for fdsetup.exe and fdstart.exe.

The repository layout supports this structure. FDSETUP/ and FDSTART/ hold the configuration programs, FASTDOOM/ holds the engine, DATA/ and WAD/ hold the game data and lumps, LEVELS/ holds the maps, BENCH/ the benchmark files, dos32a/ the stub sources, and SCRIPTS/ the auxiliary scripts. The .TCF files at the root are the configuration sets for the different games, including DOOM.TCF, DOOM2.TCF, PLUTONIA.TCF, TNT.TCF and the Ultimate Doom ones.

A new setup program is part of this: FDSetup 2.0, described as a fully open source toolchain, which replaces whatever came before.

The container image as an alternative to a local toolchain

Installing OpenWatcom v2 by hand on a modern Linux box is the friction point in the build instructions, and the repository ships a container image that removes it. The Dockerfile is a two stage build. The builder stage is based on Debian bookworm and installs git, clang, make, g++, cmake and dosbox, then clones the Open Watcom v2 repository and builds it twice, once for the host and once for the DOS target.

The interesting detail is the architecture split. The builder declares a TARGETARCH argument and, when it is amd64, sets OWTOOLS=GCC in the Watcom setup script, and for other architectures sets OWTOOLS=CLANG. So the same image serves both an x86 host and an ARM host such as a machine running under WSL2 on Apple silicon, by choosing a different compiler backend for the cross build.

The final stage is debian:bookworm-slim, copies the built Watcom tree to /opt/watcom, and points the WATCOM, PATH, EDDAT and INCLUDE environment variables at it. NASM, 7zip and python3 are installed there, and a verification step runs the 16-bit and 32-bit compilers to confirm the installation works.

The compose file offers two profiles over the same image. The builder profile mounts the project and a shared dist directory, then runs the environment script, the packaging script and copies the resulting archives out:

      command: /bin/bash -c -e "source fdenv.sh && ./package.sh && cp FastDoom_*.zip /app/dist"

The fdsetup profile instead works inside the FDSETUP directory, generates its data with a Python script and builds with the Watcom make tool before copying fdsetup.exe into the shared dist folder.

So there are two routes to a binary, and they differ in more than convenience. The local route gives you a compiler on your own machine, which is what you want if you are iterating on the source or debugging with the `-debug` flag. The container route gives you a reproducible package, which is what you want if you are distributing a build or reproducing a release.

Benchmark numbers, licence and release cadence

The README includes a demo table that compares the original Doom 1.9 with several FastDoom configurations, reporting frames per second and a gain percentage. The baseline of 19.56 fps for Doom 1.9 with audio rises to 22.44 for FastDoom 0.2 with audio, and the best listed configuration, FastDoom 0.2 without audio using flat visplanes and Sega Saturn transparency, reaches 29.05 fps, a stated gain of 148.52 percent over the baseline.

Read those numbers carefully. They are the project's own demo figures, they are labelled as FastDoom 0.2, and the current release is 1.3.0, so the table does not describe the version you would install today. It is also a comparison against a specific baseline configuration, on hardware the project names for the live demo video.

The release history is active: 1.2.1 on 2026-05-10, 1.2.2 on 2026-05-20 and 1.3.0 on 2026-07-01, with the last push on 2026-10-20. The repository is not archived, and the CHANGELOG.MD file at the root is where the per version detail lives.

FastDOOM is released under the terms of the GPLv2 license, and the LICENSE file is at the repository root. GPLv2 matters in a specific way for a port like this. The port is derived from the Doom source, and the licence obliges you to distribute the source and keep the licence when you redistribute the binary or a modified version. Building it for your own machine raises no obligation, but shipping a modified FastDOOM build to a distribution channel means shipping the corresponding source too. That is a licence question rather than a technical one, and the terms themselves are the reference.

One more detail for anyone who wants to contribute: the author states plainly that changes cannot be guaranteed to be accepted, and invites people to fork the repository and make changes as they see fit.

Editorial conclusion

Adopt FastDOOM when your goal is playable frame rates on real 386 or 486 hardware, or a fast DOSBox setup with modern video modes, and you are willing to build the source with OpenWatcom v2, NASM and GNU Make on Linux or WSL2. Do not adopt it for network play or joystick aiming, since the project removed both of those features outright. Verify first the machine you intend to run it on, because the removal of the low memory limit is stated as something that may cause crashes with low RAM, and check the demo benchmark table in the README against your own hardware before assuming the frame rates will hold. If you need a prebuilt binary with a maintained installer, this repository gives you source and a build script rather than a turnkey package.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. README
4. Releases
5. viti95/FastDoom on GitHub