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.
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
Install dependencies first:
sudo apt install dotnet-sdk-8.0 libopenal-devThen go to the "Command Line Build" section below.
sudo dnf install dotnet-sdk-8.0 openal-develAfter 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, notably including [GLFW](https://github.com/glfw/glfw), [ZMusic](https://github.com/ZDoom/ZMusic), and [FluidSynth](https://github.com/FluidSynth/fluidsynth). If you experience difficulties using the provided .so files, you may need to build your own. These were built on Ubuntu 22.04 x64, and may not work on older Linux distributions.
Helion’s native bindings currently require a version of FluidSynth with ABI version 3 (we currently distribute version 2.4.0) and version 1.1.14 of ZMusic.
If you choose to build your own versions of these native libraries, you can either overwrite the .so files in the Helion output directory, or install them on your system (e.g. 'make install') and simply delete the ones provided with Helion.
None of the developers have a Mac to test.
You likely can follow the Linux instructions to 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).
-
-r <runtimeID>: Build an executable for the specific runtime. Tested choices includewin-x64,win-x86, andlinux-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=trueIn this example, the "published" output would end up in (repo root)\Publish\win-x64_SelfContained.
