Helion: a modern Doom engine written in C# around static rendering

The problem is maps that outgrow a BSP tree

Helion is described as a modern Doom engine written from the ground up with a focus on performance, and the README is specific about the problem it targets. Content creators have made maps that struggle to render at high frame rates even on the latest and most expensive hardware, and the claim for Helion is that Doom's most complex maps are no longer stressful on modern GPUs and are playable on old hardware that was previously impossible.

That framing matters because it says what kind of user the project is for. This is a source port for people who care about frame rate on elaborate community maps, not a reimplementation for people who want to study the original code.

The technology choices follow from that. The primary language is C#, and the build is a .NET project with a global.json pinning the SDK, a Directory.Build.props and Directory.Build.targets, and a solution file in the newer slnx format.

The requirements are stated just as plainly. Minimum requirements are Windows 7 on x64, Linux on x64, or macOS on ARM64, and an OpenGL 3.3 compatible GPU or IGPU. The macOS support is ARM64 only, which in practice means Apple Silicon, and the OpenGL 3.3 floor is the thing to check first against a machine you are unsure about.

Static rendering plus state reconciliation, instead of a BSP tree

The architectural claim is the second paragraph of the README, and it is the most interesting technical statement in the project.

Helion uses static rendering with a state management system to reconcile dynamic map changes in Doom. The contrast it draws is with the typical BSP tree rendering, which requires significant CPU processing, and the claim is that Helion can manage dynamic changes and optimally utilise the GPU, which results in dramatic performance increases.

The reasoning is worth unpacking, because it is a design trade rather than a free lunch. A BSP tree is a precomputed spatial partition of the level, and it is efficient precisely because it is static. Doom however is not static: doors open, lifts move, sectors change height, and monsters are not in the tree at all. A BSP engine handles those cases with runtime processing on the CPU.

Static rendering pushes the work to the GPU instead. The geometry that does not change is rendered once, and the state management system exists to reconcile the parts that do change, so a dynamic sector is handled by updating state rather than by rebuilding a tree. The result is that the CPU cost of a complicated map moves onto hardware that has more headroom for it, and the price is an engine whose dynamic behaviour is implemented through a system that did not exist in the engines it replaces.

The Doomworld thread linked from the README is titled with the phrase goodbye BSP tree rendering, which tells you the project presents this as a deliberate break with the lineage rather than an incremental improvement.

WAD formats from vanilla to ID24, with UDMF only partial

Helion supports WADs targeting vanilla, Boom, MBF, MBF21, UDMF with partial support, and ID24. That list is the compatibility contract, and two entries deserve attention.

UDMF is the one marked partial. UDMF is the map format that most modern community mapping depends on, because it allows arbitrary scripting behaviour in a map rather than only the fixed Boom and MBF trigger set. The word partial is doing real work in that sentence, and the project keeps a separate document for it, UDMF.md, alongside ACS.md for ACS support. If your map depends on UDMF features outside the supported set, that document is the place to find out what works.

The other two documents are there for the same reason, ACS.md and UDMF.md, and the game documentation lives under Assets/Documentation, with the README pointing at a bundled README.md for setting up and playing.

The format coverage otherwise is broad. Vanilla is base Doom, Boom and MBF are the earlier ports, MBF21 is a later variant, and ID24 is the recent format used by the modern community releases. A port that supports ID24 is aimed at current content rather than at the original release era, which is a reasonable summary of where the project sits.

Install a self contained release, and bring your own IWAD

There is no install command, and the README is direct about why. The project publishes prebuilt binaries and tells you to download the latest stable release from the GitHub releases page, with nightly experimental builds available separately and a warning that they may contain additional bugs or half-finished features.

Two practical points follow. First, the platform split is explicit: Windows on x86-64, Linux on x86-64, and MacOS on ARM 64-bit for M-series devices only. Second, the release carries its own runtime, so you are not installing the Microsoft .NET SDK to play the game; the SDK is only needed if you compile it yourself.

On Linux there are two system libraries to check for, libsndfile and mpg123, which the README says generally are present on most desktop distributions. That is the dependency footprint of the audio stack, and it is the only extra thing a Linux user has to verify.

The game data is the other requirement. You need to provide an IWAD, and the project states plainly that it does not distribute these. The README points at three legitimate sources: Doom and Doom II on Steam, the Doom shareware collection, and Freedoom, which is a freeware-compatible data set.

That is the correct position for a source port, and it is also the step where a new user stalls if they assume the download includes the game.

Building from source, and the Justfile next to the solution

If you want to compile, the README points at INSTALL.adoc, which it says covers all three supported platforms. Beyond that, the repository layout tells you the shape of the build.

The solution is Helion.slnx, with a Client directory and a Core directory as the two main pieces, an Assets directory for game resources and documentation, a Tests directory, a BenchmarkSuite directory and a Scripts directory. The build is driven through a Justfile rather than a shell script or a Makefile, and global.json pins the .NET SDK version so a build machine does not drift. There is a nuget.config, so package sources are controlled by the repository, and Directory.Build.props plus Directory.Build.targets hold the shared build settings.

There is also a RELEASENOTES.md at the root, which is where a user should look to understand what changed between the 1.0.0.0 release of 2026-07-25 and 1.1.0.0 of 2026-10-03.

The BenchmarkSuite directory is worth a note, because the README's benchmarks section links to a full benchmark spreadsheet rather than quoting numbers, and the screenshots in the README are of specific maps such as Sunder MAP15 and Summer of Slaughter MAP32. A project that ships a benchmark suite and a spreadsheet of results is making a performance claim you can actually check, which is more than most engine projects offer.

A young 1.x line and a nightly tag that predates the releases

The release history needs reading carefully, because one of the three tags is confusing.

The tags are nightly, dated 2024-10-21, and then 1.1.0.0 from 2026-10-03 and 1.0.0.0 from 2026-07-25. So the versioned line is young, one minor release old, and the project has moved to a 1.x scheme with four-part version numbers, which is the.NET assembly version convention rather than a semver line.

The nightly tag is the odd one. It carries a date more than a year before the numbered releases, and the README still describes nightly builds as available and as potentially containing additional bugs or half-finished features. Whether that tag is stale, or whether the nightly channel is produced under a different tag name now, is not explained in the README, and it is exactly the kind of thing to check before you rely on a nightly build for anything.

The default branch is dev, which is the usual arrangement for a project that promotes dev to tagged releases. The last push was on 2026-10-21, two days before the current date, so the branch is being worked on continuously, and the project is not archived.

The licence is GPL-3.0 with a LICENSE file at the root, which is the standard choice for a game engine and the reason the project can require the same of anyone who distributes a modified binary.

Community is organised around a Discord server and the Doomworld thread, and bug reports go to GitHub issues or to that thread.

Editorial conclusion

Adopt Helion if you play Doom source ports and the maps you care about are the ones that other engines cannot hold frame rate on, or if you want to work on a Doom engine in C# rather than in C. Do not adopt it if you need a stable release you can pin for a long time, because the version line is young, 1.0.0.0 and 1.1.0.0, and the nightly tag carries a 2024 date that does not match the branch, so you should check what a build actually contains. Verify first that your GPU meets the OpenGL 3.3 requirement, that you have a legitimate IWAD since the project does not distribute game data, and that the format you need is supported, remembering that UDMF support is only partial.

Frequently asked questions

Official sources

1. Helion-Engine/Helion on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases