Helion

A modern Doom engine written from the ground up with a focus on performance.

Helion uses static rendering with a state management system to reconcile dynamic map changes in Doom. In contrast to the typical BSP tree rendering that requires significant CPU processing, Helion is able to manage dynamic changes and optimally utilize the GPU resulting in dramatic performance increases.

Content creators have created maps that struggle to render at high framerates with even the latest and most expensive hardware. With Helion, Doom’s most complex maps are no longer stressful on modern GPUs and playable on old hardware that was previously impossible.

Minimum requirements are Windows 7 and an Open GL 3.3 capable GPU.

Images

Doom E1M1 - True Color Mode

Doom E1M1 - Palette Color Mode

Eviternity MAP26 - Automap Overlay

Knee-Deep in Knee-Deep in ZDoom Z1M1

PUSS X Summer of Slaughter MAP32 (SOS_BOOM.wad)

Sunlust MAP28

Eviternity II MAP32

Benchmarks

Full Benchmark Spreadsheet

Build Instructions

Windows

If using Visual Studio 2022+ or Rider, press Run and it will do everything.

Linux

Install dependencies first:

Debian/Ubuntu

sudo apt install dotnet-sdk-8.0 libopenal-dev

Then go to the "Command Line Build" section below.

Fedora

sudo dnf install dotnet-sdk-8.0 openal-devel

After installing dependencies, if you have an IDE that supports C# (like Rider), you can open Helion and build/run directly. You can also build from the command line, as described in the section below.

Note that we have provided copies of various binaries we depend upon. If you experience difficulties using the provided .so files, you may need to build your own. Symptoms may include nonfunctional music, or issues with controller input. Please see this document for help with native dependencies.

Mac

None of the developers have a Mac to test.

You likely can follow the Linux instructions to build.

Command Line Build

Once any platform-specific prerequisites are installed, you can build or publish using the dotnet commands available with the .NET SDK. By default, dotnet build will build an "any" binary that uses the installed version of the .NET runtime. However, you can also build versions with a prepackaged runtime for easy installation onto machines that do not have the .NET 8 runtime installed.

Note that it only makes sense to run the following from the Client subdirectory, as this is the only one that actually builds an executable (and can therefore be published).

Common Build Parameters

• -r <runtimeID>: Build an executable for the specific runtime. Tested choices include win-x64, win-x86, and linux-x64.

• --self-contained=true: Includes support files for the specified runtime, so that you do not need to install the .NET runtime onto the machine where you’re going to run this (helps to make installs more portable)

• -p:PublishSingleFile=true: Bundles all of the .NET dependencies into a single file, resulting in fewer files in the output directory. Can be combined with --self-contained=true.

• -p:EnableCompressionInSingleFile=true: When combined with single-file publish, this will also compress the resulting executable file. This can result in a much smaller file size, but may result in the app taking longer to start.

• -p:SelfContainedRelease=true: This will turn on all of the recommended single-file publish optimizations mentioned above.

Example (making a compressed, self-contained release build for Windows x64):

cd Client
dotnet publish -c Release -r win-x64 -p:SelfContainedRelease=true

In this example, the "published" output would end up in (repo root)\Publish\win-x64_SelfContained.