Key features
- Descended from Simon "fraggle" Howard's SMMU and Lee Killough's MBF, preserving Boom and MBF demo compatibility as a primary design goal.
- EDF (Eternity Definition File): a text-based system for defining new thing types, weapons, sounds, and states without binary dehacked patching.
- Linked portal and line portal system enabling non-Euclidean room-over-room geometry within a Boom-compatible framework.
- Polyobject support for moving map geometry, extending a feature associated with Hexen-derived engines into the Boom-compatible space.
- ExtraData and EMAPINFO map metadata formats for defining sector and linedef specials beyond the Boom specification.
- Support for multiple IWADs including Doom, Doom II, and Heretic, with Hexen and Strife support in progress.
- Cross-platform portability: confirmed to run on Windows, Linux, and Mac OS X according to the official GitHub repository.
- CMake-based build system allowing compilation from source; pre-built binaries and development builds available for Windows and macOS.
What is Eternity Engine?
The Eternity Engine occupies a distinctive position in the Doom source-port landscape: it sits at the intersection of rigorous demo compatibility, expansive mapping capability, and a deep commitment to the Boom/MBF lineage from which it descends. Unlike ports that forked away from vanilla fidelity in pursuit of wholly new rendering architectures, Eternity carries the direct genetic inheritance of Simon “fraggle” Howard’s SMMU and, before that, Lee Killough’s Marine’s Best Friend (MBF) engine. That heritage shapes nearly every design decision the project has made over its long history.
Origins and Lineage
The path to Eternity runs through some of the most important engineering work in Doom’s open-source history. When id Software released the Doom source code in 1997, the community quickly forged a series of incremental improvements. Lee Killough’s Boom port introduced the compatibility and limit-removing features that became the de-facto standard for advanced mapping, and MBF built further on those foundations. Simon Howard’s SMMU (Smack My Marine Up) extended MBF with scripting capabilities and a more open architecture. It was from SMMU that James “Quasar” Haley developed the Eternity Engine, and the project has since grown far beyond any of those predecessors while remaining firmly rooted in their philosophy.
According to the official Eternity Wiki, the engine’s version history stretches back to the early 2000s. Early codenames drew from a mix of mythological traditions — Egyptian (Nekhbet, Sekhmet), Persian (Simorgh), and others — before the project settled into its now-familiar convention of Norse mythological identifiers (Forseti, Glitnir, Tyrfing, Nidhogg) starting in the early 2010s, a tradition that continues through its modern releases. The Doom Wiki notes that the port is currently maintained by Max Waine (Altazimuth) and Ioan Chera (printz), continuing the work that Haley began and carrying it toward a modern C++ codebase.
Design Philosophy
Eternity’s core philosophy can be summarised as: advance the Doom engine without abandoning compatibility. Where some ports in the modern tier treat vanilla or Boom behaviour as an optional legacy mode, Eternity treats compatibility as a primary concern. The engine supports Boom-compatible, MBF-compatible, and vanilla-compatible demo playback, making it a serious tool for speedrunners and demo verifiers who need precise engine behaviour.
At the same time, Eternity pushes well beyond those compatibility floors for mappers and modders willing to target it specifically. The engine has developed its own scripting language (EDF — Eternity Definition File) and supports advanced linedef and sector specials, portals, polyobjects inherited from Hexen-compatible engines, and other features that allow mappers to construct environments impossible under stock Boom. This dual commitment — preserve the past, extend the present — is what gives Eternity its particular appeal to a segment of the Doom community that wants both correctness and capability.
As one community discussion on Doomer Boards summarised it, Eternity uses limit-removing Boom compatibility while also offering extended features for mappers who wish to target the port exclusively — a balance that GZDoom-family ports approach from the opposite direction.
Key Technical Features
The engine’s feature set has accumulated over decades of active development. Among the most significant capabilities documented in official sources:
- Boom and MBF compatibility: Eternity maintains careful compatibility with the Boom and MBF specifications, enabling demo playback from those engines and ensuring that WADs designed for those standards run correctly.
- EDF (Eternity Definition File): A text-based definition system that allows modders to create new thing types, sounds, weapons, and states without requiring dehacked binary patching. EDF is one of Eternity’s most powerful exclusive features and is the basis for many WADs that target the engine specifically.
- Linked portals and line portals: Eternity’s portal system allows mappers to construct non-Euclidean geometry and seamless room-over-room layouts using a sector-based approach distinct from GZDoom’s portal implementation.
- Polyobjects: Moving geometry (doors, platforms, and other structures) implemented as polyobject lines, extending a feature originally associated with Hexen-derived engines into the Boom-compatible space.
- ExtraData and EMAPINFO: Extended map metadata formats that allow mappers to define sector and linedef specials beyond the Boom specification, again without binary patching.
- Heretic IWAD support: The engine supports Heretic as an additional id-family IWAD beyond Doom and Doom II. Hexen and Strife support is present but still listed as work-in-progress by the project.
- Cross-platform portability: As documented in the GitHub repository, Eternity runs on Windows (confirmed as low as XP through Windows 10), Linux, and Mac OS X, making it accessible across the major desktop platforms.
- CMake-based build system: The source can be compiled from the GitHub repository using CMake, with both release binaries and development builds available.
The SMMU and MBF Connection
Understanding Eternity’s lineage requires a brief look at its predecessors. Marine’s Best Friend (MBF) was authored by Lee Killough, one of the key engineers behind Boom. MBF introduced features such as helper dogs, a linedef special for changing a level’s sky texture, and a refined compatibility system. When Killough stepped back from active development, the community built upon MBF in several directions. Simon Howard’s SMMU was one such fork, adding an early scripting layer and other extensions.
James Haley’s work on Eternity took SMMU as its starting point and, over years of active development, substantially rewrote and extended it. The Eternity Wiki documents that when Lee Killough began the MBF project, Haley became a beta tester after emailing Killough with questions about early Doom alpha versions — a detail that illustrates how deeply embedded the Eternity project is in the Doom source community’s history. That personal connection to the MBF era is part of why Eternity has always treated MBF compatibility as a non-negotiable baseline rather than an optional mode.
The Exclusive-WAD Ecosystem
One of the most interesting aspects of Eternity’s community is the existence of WADs designed specifically for it — content that relies on engine features unavailable in other Boom-compatible ports. The Doomworld thread on Eternity-exclusive WADs illustrates how mappers have used EDF-defined monsters, linked portals, and ExtraData specials to produce content that pushes well beyond what vanilla Boom mappng allows. These WADs represent a creative niche: they are not targeted at GZDoom’s scripting-heavy ZScript ecosystem, nor are they generic Boom-compatible releases — they exist specifically because Eternity offers capabilities that no other Boom-lineage port provides.
This exclusive-WAD culture is relatively rare in the Doom community, where most mappers either target the widest possible compatibility (vanilla / Boom) or the widest possible feature set (GZDoom). Eternity’s middle position — advanced features within a Boom-compatible framework — attracts mappers who want to do more than Boom allows without completely abandoning the port-portable ethos.
Getting Eternity Running
The official source of downloads is the GitHub releases page, which hosts pre-built binaries for Windows and macOS alongside source archives. The Eternity Wiki also notes that development builds for Windows and macOS are available at DRDTeam’s website, which are recommended if users encounter serious bugs in a stable release. Linux users can build from source using the CMake build system documented in the repository.
Like all Doom-engine ports, Eternity requires an IWAD — the original game data from a retail or legally obtained copy of Doom, Doom II, or another supported game. The engine searches for IWADs automatically in common locations, and the Wiki notes that a Master Levels directory path may need to be specified for certain configurations. Because Eternity supports multiple IWADs (Doom, Doom II, Heretic, and others, with Hexen support still in progress), the specific IWAD needed depends on the content being played.
Comparison with Sibling Ports
Eternity’s closest relatives are other MBF-family ports. Woof! is also MBF-derived (via WinMBF), and DSDA-Doom comes from the PrBoom+ line. Eternity itself has no PrBoom in its ancestry, which runs Boom to MBF to SMMU to Eternity. DSDA-Doom has become the preferred tool for demo recording and verification in the speedrunning community. Eternity is the most feature-rich of the Boom-lineage ports, with EDF, portals, polyobjects, and ExtraData forming a modding platform that is genuinely distinct from what any of its siblings offer.
Against GZDoom-family ports, Eternity’s contrast is sharper still. GZDoom’s ZScript system, hardware-renderer-first design, and explicit abandonment of vanilla-bug faithfulness place it in a different category entirely. Mappers and players who want Boom-compatible demo playback, a software renderer as a first-class option, and a precise compatibility framework will find Eternity more appropriate than any GZDoom derivative.
Development and Maintainership
The Doom Wiki records that the port is currently maintained by Max Waine (Altazimuth) and Ioan Chera (printz). Development is tracked openly on GitHub under the team-eternity organisation, where the issue tracker, pull request history, and release notes are publicly accessible. The most recent stable release as of this writing is version 4.06.00, published in June 2026.
The project is licensed under the GNU General Public License v3.0, as documented in the repository’s COPYING file. This places it in the same copyleft tradition as the original Doom source release and the Boom/MBF ports from which it descends.
Why Eternity Still Matters
In a community now dominated by GZDoom for feature-heavy modding and by DSDA-Doom for competitive play, one might ask what role Eternity fills. The answer is that it occupies a specific and irreplaceable position: it is the only actively maintained Boom-lineage port that also functions as a genuine modding platform — one where EDF, linked portals, and ExtraData allow mappers to build experiences that go significantly beyond the Boom specification without requiring the full ZScript ecosystem or accepting GZDoom’s departure from compatibility.
For players, Eternity offers a way to experience a substantial body of WADs — including content that cannot be played correctly in any other port — while remaining within a familiar Doom-engine aesthetic. For mappers, it offers a toolkit that rewards deep engagement: EDF is not a simple point-and-click system, but for mappers willing to learn it, it enables monster and weapon definitions of a sophistication rare in the Boom-compatible tier. And for developers and historians, Eternity’s long lineage from MBF through SMMU to the present day makes it one of the most instructive codebases in the entire Doom source-port ecosystem — a living record of how the Boom philosophy has evolved over more than two decades of community development.
How to install Eternity Engine
// From zero to playing — step by stepObtain a supported IWAD
Eternity Engine requires the original game data (IWAD) from a supported title such as Doom, Doom II, or Heretic. Hexen is playable but its support is still considered work-in-progress by the project.
Download Eternity Engine
Visit the GitHub releases page and download the pre-built archive for your operating system. Windows and macOS binaries are provided; Linux users may build from source using CMake as documented in the repository. Development builds for Windows and macOS are also available at DRDTeam’s website if you need fixes not yet in a stable release.
Extract and configure
Extract the downloaded archive to a directory of your choice. Place your IWAD in the same directory as the Eternity executable, or configure the engine to find it in its existing location. Consult the Eternity Wiki for IWAD path configuration details, including setting a Master Levels directory if applicable.
Launch and play
Run the Eternity Engine executable. The engine will detect your IWAD and launch. To load additional WADs, use the -file command-line parameter or drag WAD files onto the executable on Windows. For Eternity-exclusive WADs that use EDF or ExtraData, follow the load order instructions provided with that specific WAD.
Eternity Engine system requirements
Eternity Engine vs other source ports
Need to pick between ports?
Short version: Eternity Engine handles most needs. For the full head-to-head and our ranked list, see the dedicated pages.
Frequently asked questions
What makes Eternity Engine different from other Boom-compatible ports?
Eternity Engine adds exclusive features — including EDF (Eternity Definition File) scripting, linked portals, polyobjects, and ExtraData map specials — that go well beyond the Boom specification while retaining Boom and MBF demo compatibility. No other actively maintained Boom-lineage port offers this combination.
Who currently maintains the Eternity Engine?
According to the Doom Wiki, the port is currently maintained by Max Waine (Altazimuth) and Ioan Chera (printz).
What IWAD do I need to run Eternity Engine?
Eternity Engine supports Doom, Doom II, Heretic, and Freedoom as complete IWADs, with Hexen (and Strife) support still under active development. The specific IWAD required depends on the content you want to play. For most Doom-community WADs, a copy of Doom II is most commonly needed.
Is Eternity Engine suitable for speedrunning and demo recording?
Yes. Eternity maintains careful compatibility with the Boom and MBF demo formats, making it a viable engine for demo playback and recording within those compatibility tiers. Its lineage from MBF means it inherits that engine’s precise behavioural specifications.
What license is Eternity Engine released under?
Eternity Engine is released under the GNU General Public License v3.0 (GPL-3.0), as documented in the COPYING file in the project repository.
Where can I find WADs designed specifically for Eternity Engine?
The Eternity Engine Exclusive WADs thread on Doomworld is a good starting point for content that targets Eternity’s unique features such as EDF-defined monsters and linked portals.
Sources
- EXT Eternity Engine — GitHub Repository github.com
- EXT Eternity Engine — Official Wiki eternity.youfailit.net
- EXT Eternity Engine — The Doom Wiki at DoomWiki.org doomwiki.org
- EXT GitHub Release 4.06.00 github.com
- EXT Eternity Engine Exclusive WADs — Doomworld www.doomworld.com