This is an old revision of the document!
The Doomsday Engine is an enhanced Doom source port for the Windows, macOS, and Linux platforms. It is based on the source code of id_software's doom and raven_software's heretic and hexen. The Doomsday Engine and the associated ports of Doom, Heretic and Hexen have been under development since 1999. The first versions were released in late 1999 and early 2000. Most of the development work has been done by Jaakko Keränen (skyjake).
The purpose of the project is to create versions of Doom, Heretic and Hexen that feel the same as the original games but are implemented using modern techniques such as 3D graphics and client/server networking. A lot of emphasis is placed on good-looking graphics.
The engine uses a modular structure to separate game logic from the renderer, sound, network and other such subsystems. This allows the engine to be used with different game logic modules. The currently available ones are ports of vanilla Doom, Heretic and Hexen. A secondary goal of the project is to make it possible to write new game logic modules with minimal effort, either completely from scratch or based on the existing modules.
The Doomsday Engine has been written in C and C++. It uses open_gl to render graphics with 3D objects, particle effects and dynamic lights. It supports DirectSound3D and for 3D sound effects and environmental effects, and FMOD for playing MP3/OGG music. It has client/server networking where players may join games already in progress.
The Doomsday project was begun in May 1999 by Jaakko Keränen. The only goal was to create an OpenGL-enhanced port of Hexen. Thus the starting point of the project, named JHexen, was the original Hexen source code, released earlier by raven_software. The code was for MS-DOS and the Watcom compiler, and there were numerous places where the computer hardware was being accessed directly, for instance the graphics rendering code. Since Win32 was going to be the project's new platform, the incompatible low-level code was replaced with routines from the Allegro game programming library.
The first subsystem to be completely rewritten was the renderer. During the summer of 1999, new texture handling and player view rendering code was written. Much of this code remains even today, but the rendering algorithm has reached a point where future additions like advanced GL techniques (e.g., bump mapping) are difficult to implement without making dramatic changes.
The first version of JHexen was released in the autumn of 1999. All dependencies on Allegro had been removed. DirectX was used for playing sound effects, getting input from game controllers and low-level network code. The majority of all improvements were technical: gameplay remained the same as in the original Hexen, with of course the addition of mouse look. The console, a Quake-style runtime CLI, was also included, and has seen very little improvement since. This means the source code of the console is rather clunky and lacks a coherent style.
Being a fan of Doom and Heretic as well as Hexen, skyjake started looking into the possibility of somehow utilizing the existing JHexen code to produce ports of those two games. During the spring of 2000, the JHexen project changed focus and became the Doomsday Engine. After studying the Doom and Heretic source code and finding them to be very similar to each other, it was decided to extract the common parts of all the three games and create a game-independent engine out of them. This took a couple of months to get working. In retrospect, too much of the code in the game modules and the engine became little more than a collection of subsystems: graphics, sound, input and low-level networking. Since then, a major trend in the development of the engine has been to further unify the code bases and move common code into the engine.
The source code of the Doomsday project is a combination of the original Doom, Heretic and Hexen sources and my own code. Due to the large size of the code bases, little effort has been spent on unifying the code stylistically. This means the modules of the project do not share a common style.