[HN Gopher] Helion: A modern fast paced Doom FPS engine in C#
___________________________________________________________________
Helion: A modern fast paced Doom FPS engine in C#
Author : klaussilveira
Score : 180 points
Date : 2025-06-10 22:56 UTC (3 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| yodon wrote:
| Impressive C# performance!
| dax_ wrote:
| Microsoft has really been putting a lot of focus on improving
| it with each release. I love reading through the blog articles
| for each major release, that outline all the performance
| improvements that were done:
| https://devblogs.microsoft.com/dotnet/performance-improvemen...
| runevault wrote:
| A warning for those not in the know, the performance
| improvement posts famously give mobile browsers trouble
| because they are so massive. All because the extent of the
| improvements is so great (along with the amount of detail the
| posts go into about the improvements).
| ddingus wrote:
| I just viewed the one linked above, and the coupla second
| render delay at first aside, the post displayed nicely, at
| full frame rate.
|
| Old Note 9, Chrome and Firefox.
|
| Non flagship mobile devices could very well choke on one of
| those pages, but most newer devices should display these
| pages with little grief.
| runevault wrote:
| Interesting, I thought I saw the usual complaints even in
| the past year.
| qingcharles wrote:
| And if you look at the PRs for the core, there are Intel
| people hacking away at the low-level routines too; to make it
| run better on their latest server CPUs.
| animal531 wrote:
| Go and have a look at Bepu Physics v2:
| https://github.com/bepu/bepuphysics2
|
| It can be quite performant these days, sadly I'm stuck
| developing in Unity Mono C# which is quite a bit behind.
| Cieric wrote:
| This looks interesting and I'm going to take a look later. Just a
| minor nitpick up front though, I think the performance graph
| should be a bar graph instead of a line graph. Mainly since the
| in-between states don't have much meaning as you can't be half
| way between 2 different gpus.
| kevingadd wrote:
| Might make sense to use a logarithmic scale for the graphs too,
| it's hard to tell what speed the other ones are since they're
| compressed so far down.
| atmavatar wrote:
| Even just updating the graphs would be helpful. There appear to
| have been several releases since 0.9.2.0, including a bump from
| .NET 7 to .NET 8 (and a bump to .NET 9 in dev).
|
| The more recent .NET versions by themselves are likely to have
| some impact on the performance, let alone any changes in Helion
| code between versions.
| ogurechny wrote:
| Those discussions are a bit misleading. Original Doom updates
| its state only 35 times a second, and ports that need to remain
| compatible must follow that (though interpolation and
| prediction tricks are possible for visual smoothing of the
| movement). Rendering engine is also completely orthogonal to
| polygon-based 3D accelerators, so all their power is unused
| (apart from, perhaps, image buffers in fast memory and hardware
| compositing operations). Performance on giant maps therefore
| depends on CPU speed. The point of this project is making the
| accelerator do its job with a new rendering process.
|
| Though I wonder how sprites, which are a different problem
| orthogonal to polygonal rendering, are handled. So, cough
| cough, Doxylamine Moon benchmarks?
| kfuse wrote:
| "Rendering engine is also completely orthogonal to polygon-
| based 3D accelerators"
|
| Software rendering engine, yes (and even then you can
| parallelize it). But there is really no reason why doom maps
| can't be broken down in polygons. Proper sprite rendering is
| a problem, though.
| ogurechny wrote:
| Sure, that has been done since the late '90s release of the
| source code, both by converting visible objects to
| triangles to be drawn by the accelerator (glDoom, DoomGL),
| or by transplanting game data and mechanics code into an
| existing 3D engine (Vavoom used recently open-sourced
| Quake).
|
| However, proper recreation of the original graphics would
| require shaders and much more modern extensive and
| programmable pipelines, while the relaxed artistic attitude
| (or just contemporary technical limitations) unfortunately
| resulted in trashy y2k amateur 3D shooter look. Leaving
| certain parts to software meant that CPU had to do most of
| the same things once again. Also, 3D engines were seen as a
| base for exciting new features (arbitrary 3D models,
| complex lighting, free camera, post-processing effects,
| etc.), so the focus shifted in that direction.
|
| In general, CPU performance growth meant that most PCs
| could run most Doom levels without any help from the video
| card. (Obviously, map makers rarely wanted to work on
| something that was too heavy for their systems, so the
| complexity was also limited by practical reasons.) 3D
| rendering performance (in non-GZDoom ports) was boosted
| occasionally to enable some complex geometry or mapping
| tricks in popular releases, but there was little real
| pressure to use acceleration. On the other hand, the linear
| growth of single core performance has stopped long ago,
| while the urges of map makers haven't, so there might be
| some need for "real" complete GPU-based rendering.
| kfuse wrote:
| As I said, traditional doom bsp-walker software renderer
| is quite parallelizable. You can split the screen
| vertically into several subscreens and render them
| separately (does wonders for epic maps). The game logic,
| or at least most of it, can probably be run in parallel
| with the rendering.
|
| And I don't think any of the above is necessary. Even
| according to their graphs popular doom ports can render
| huge maps at sufficiently high fps on reasonably modern
| hardware. The goal of this project, as stated in the
| doomworld thread, is to be able to run epic maps on a
| potato.
| bee_rider wrote:
| Finally I can play Doom on my 2khz monitor.
| dataflow wrote:
| 2 kHz monitor? Is that a joke, or a typo, or real?
| bee_rider wrote:
| A joke.
|
| Although actually now that you ask, monitor speeds are
| getting pretty crazy, so I guess it isn't implausible enough!
| nartho wrote:
| Well TCL unveiled the first khz monitor so my guess is
| they'll get there soon
| nottorp wrote:
| Real or advertised monitor speeds? :)
| thomasqbrady wrote:
| How does licensing work, here... could you use this to develop an
| indie game and sell it?
| kasajian wrote:
| Not sure what the question is. The License is clearly stated.
| gcr wrote:
| No, it's GPL3, so your game must be open-source.
|
| If the authors wanted to protect engine development while
| allowing indies to sell games made on it, they would have
| picked LGPL or a more permissive license.
| detaro wrote:
| since when do people not sell GPL games?
| energywut wrote:
| You are _technically_ correct, and I believe the GPL doesn
| 't cover the assets for the game (levels, art, audio,
| etc.), but I suspect there aren't many GPL licensed games
| out there for sale that have sold enough copies to make
| developing them worthwhile financially.
|
| I'd _love_ to be wrong, so if you have a few examples, I 'm
| all ears.
| nailer wrote:
| Remember the GPL only applies to the code you can make a
| great game with beautiful artwork and distribute the
| source code to anyone who wants it. Nobody playing the
| game will have much fun without the artwork.
| energywut wrote:
| That's literally the first sentence I wrote in my
| comment. ;)
| nailer wrote:
| Sorry, you're right. I somehow missed that. There's some
| indie boomer shooters using the Doom engine that are
| commercially licensed IIRC.
| nottorp wrote:
| Carmack has a post from ages ago wondering why no one
| does that with the ID engines they open sourced, which
| were pretty current back then. He was talking about the
| quake (2?) source code dumps i think.
|
| Edit: ohh i found it:
|
| http://www.gamespy.com/articles/641/641662p6.html
|
| The GPL license will allow people to take the Quake 3
| engine and even go so far as to release a commercial
| product with it - provided that the source code is
| published alongside. Nobody has done this with any of the
| Quake engine games yet, but he hopes to see it happen
| someday.
| mjr00 wrote:
| Probably not much in the AA/AAA space, but plenty of
| indies. The Doom engine (and GZDoom, which is the most
| common Doom engine derivative) is GPL and there have been
| multiple commercially successful games released using it.
| I know at least Hedon[0] and Hands of Necromancy[1] sold
| enough copies to warrant a sequel.
|
| GPL vs LGPL definitely isn't a blocker for a commercial
| game, in any case.
|
| [0] https://github.com/madame-rachelle/hgzdoom https://st
| ore.steampowered.com/app/1072150/Hedon_Bloodrite/
|
| [1] https://store.steampowered.com/app/1898610/Hands_of_N
| ecroman...
| rimunroe wrote:
| Plus the truly excellent Selaco!
| https://store.steampowered.com/app/1592280/Selaco/
| whizzter wrote:
| You can sell them on PC, but any dream of console releases
| are dead in the water as Sony,etc forbids distribution or
| even code using their SDK's to be shared publicly.
| gr4vityWall wrote:
| Yes. Only requirement is that your game code is Free Software
| (GPLv3).
| energywut wrote:
| I wonder if it can play through MyHouse.wad. Which, if you
| haven't seen before, is an _incredible_ art piece.
|
| https://www.youtube.com/watch?v=5wAo54DHDY0
|
| If you've read House of Leaves, do yourself a favor and check it
| out.
| tines wrote:
| Oh man, House of Leaves is amazing. Danielewski has my respect.
| low_tech_love wrote:
| He used Eviternity 2 as an example, my personal GOTY for 2024.
| Check it out if you haven't!
| wiseowise wrote:
| I'm also curious about this.
| BLKNSLVR wrote:
| Thank you for the, so far, half-day rabbit hole...
|
| Agreed, it is an incredible art piece, and now I want to go
| find a copy of House of Leaves.
| uncircle wrote:
| If you talk about myhouse.wad, you must link the video of John
| Romero himself playing it:
| https://youtu.be/gIl_TqFJNO8?si=H4o6m-RbH2rpX2FG
| bob1029 wrote:
| I am curious if the author considered use of the built-in
| numerics library over hand-rolling types like Vector4F.
|
| All of the methods defined here:
|
| https://github.com/Helion-Engine/Helion/blob/20300d89ee4091c...
|
| Are available in the kitchen sink:
|
| https://learn.microsoft.com/en-us/dotnet/api/system.numerics...
|
| Same idea applies to methods like GetProjection, which could be
| replaced with methods like:
|
| https://learn.microsoft.com/en-us/dotnet/api/system.numerics...
|
| Advantages of using this library are that it is uses intrinsics
| (SIMD) to accelerate operations. There is a lot of Microsoft
| money & time that has been invested into these code piles.
| jabart wrote:
| It looks like these types were code-gen from something else.
|
| https://github.com/Helion-Engine/Helion/commit/e6affd9abff14...
| accoil wrote:
| Further down in the commit there's a Generators project that
| has the VectorGenerator class.
| Disposal8433 wrote:
| > [a diff with] +4620 -1454 [lines]
|
| Someone should learn some CS and then how to make proper
| commits.
| tester756 wrote:
| This is pull requests, there are commits
|
| Additionally this is generated code.
| golergka wrote:
| Computer science has literally nothing to do with good
| commit habits.
| qingcharles wrote:
| I also see the guys from Intel constantly stabbing at all these
| low-level types to optimize them too. There are optimizations
| in .NET 10 for processors that aren't even released yet.
| marhee wrote:
| I suspect it's part of the fun? A way to really learn
| something?
|
| There's also another hint:
|
| // THIS FILE WAS AUTO-GENERATED. // CHANGES WILL NOT BE
| PROPAGATED. // ------------------------------------------------
| ----------------------------
|
| (Of course this could be a result of something having nothing
| to do with the contents of the file, but maybe the author has
| to meta library that can generate the types in different
| languages).
|
| There seems to be fixed-precision variants of the vector types
| as well which seems to be not available in the .NET framework.
|
| Plus, of course, you can't add your specifics needs to library
| types (like the fixed precision). They are closed to
| modification.
|
| I am just guessing, of course.
|
| That being said, it would also make total sense to use the .NET
| types.
| materialpoint wrote:
| Historically the .NET and XNA vector types have been seriously
| lacking for real graphics development, and they still don't
| even provide swizzling. It's likely that this project predates
| .NET numerics by many years, and anyone who has had a pet
| project for long enough will learn to avoid becoming too
| dependent on libraries and platforms that will die out.
| animal531 wrote:
| I posted further down about Bepu Physics v2:
| https://github.com/bepu/bepuphysics2
|
| It heavily uses numerics and the performance is amazing.
| patrick4urcloud wrote:
| i will give a try.
| _0ffh wrote:
| It's a Doom engine, and they missed the opportunity to call it
| "Hellion"??
| bigbuppo wrote:
| And with the name Hellion they could also go down the Judas
| Priest rabbit hole.
| ngrilly wrote:
| Finally, a good example of a modern C# code base that is open
| source, and that doesn't look like the equivalent of J2EE in C#.
| tester756 wrote:
| I wanted to provide link to Ryujinx repo, but I've found that
| Nintendo threaten them and they had to close the project :(
| necrosyne wrote:
| Allegedly, Nintendo chose to buy them off with millions of
| dollars to suspend development instead of pursuing legal
| action.
| lrae wrote:
| Is there any source on that?
|
| All I'm seeing is they got their hands on the domain, which
| can be (and was in the past) just part of whatever
| settlement they agreed on, and the game press spinned that
| into "Nintendo bought Ryujinx".
| aeonik wrote:
| Thanks for your comment, made me want to check it out, and yea
| it's really clean code.
| mawadev wrote:
| The Benchmarks look a bit sketchy... is the frame uncapped for
| all the other engines and has vsync been disabled? It's a very
| odd graph to look at, but great performance regardless
| c-hendricks wrote:
| There's a link to a spreadsheet with the actual numbers, and
| there doesn't appear to be any capping:
| https://docs.google.com/spreadsheets/u/0/d/19INwMjrppDO-n90H...
| neuroelectron wrote:
| FPSes aught to update the screen every millisecond. Why isn't
| this more common?
| imbusy111 wrote:
| That would require a 1000Hz screen to even be able to output.
| 144Hz is the high-end today. It seems to be pointless to push
| beyond that.
| c-hendricks wrote:
| 240/360/480/540hz monitors all exist. 144hz is not that high
| a bar anymore, and kind of the odd one out given that it's
| not a multiple of 60.
| theblazehen wrote:
| Because you quickly get into diminishing returns, while
| significantly scaling the hardware required?
| dimitropoulos wrote:
| the Doom in TypeScript types project wouldn't have been possible
| without Nick and Helion - I owe Nick a huge thanks! He helped
| with some of the more obscure parts of the engine and also helped
| make a super small WAD that is what the game eventually ran in.
|
| Legend.
| LoganDark wrote:
| Doom in TypeScript types is amazing. Thank you for losing your
| mind for the rest of us :)
| reverseblade2 wrote:
| I have seen some use case for MemoryStream, why not use
| RecyclableMemorysStream instead?
___________________________________________________________________
(page generated 2025-06-13 23:02 UTC)