Jump to content
This Topic

Helion - C# (0.9.3.0 6/24 - Goodbye BSP tree rendering)


Recommended Posts

That chart is simply ridiculous.

 

"850 FPS isn't enough for you? No problem, we're 'bout to go W   A   R   P      S   P   E   E   D"

Share this post


Link to post

Ran a test on SoS Map 32 on my own PC.

 

PRBoom and GZDoom? less than 30FPS

 

Helion? 250FPS

 

Hooly crap, this port is not messing around. Good shit.

Share this post


Link to post
  On 10/7/2023 at 3:11 AM, Pickles said:

Ran a test on SoS Map 32 on my own PC.

 

PRBoom and GZDoom? less than 30FPS

 

Expand  

 

I find it amazing that today's computers are powerful enough to manage this with a traditional Doom map processing algorithm to get 30 fps at all. It's virtually a summary of "how not to design a Doom map".

Of course it is also a perfect test case to try out render optimizations - even better for that than Frozen Time.

 

About those 250 fps, is this with monsters being active and attacking the player or just looking at the empty map? Because when I play it the think time alone is enough to bring this down to below 100 fps after some time, even without any rendering at all.

 

Share this post


Link to post
  On 10/7/2023 at 7:13 AM, Graf Zahl said:

 

I find it amazing that today's computers are powerful enough to manage this with a traditional Doom map processing algorithm to get 30 fps at all. It's virtually a summary of "how not to design a Doom map". 

Of course it is also a perfect test case to try out render optimizations - even better for that than Frozen Time. 

Expand  

 

I wouldn't call it "how not to design a Doom map". Maps like this were a real motivation for Helion's existence. Sunder was first released in 2009 and even with over a decade of hardware tech Sunder was still suffering massively purely from a map rendering standpoint. I imagine mappers are still holding back a bit because they know their maps wouldn't be playable. Now the ceiling has been blown up, and even more ridiculous maps can exist.

Now with screens getting larger, 240hz becoming a thing, the demand for more FPS is only going to go up. I currently play with a 1440p 165hz GSync monitor so I want to keep a consistent and steady 200FPS cap. If it's a map with thousands of monsters I might increase it to 300FPS since the frame lows are noticeable, which is the problem with using frames per second as a measurement but that's another discussion.
 

  On 10/7/2023 at 7:13 AM, Graf Zahl said:

About those 250 fps, is this with monsters being active and attacking the player or just looking at the empty map? Because when I play it the think time alone is enough to bring this down to below 100 fps after some time, even without any rendering at all. 

 

Expand  


The monster count for SoS MAP32 isn't terribly high at 1106. I can't speak for Pickls hardware, but my AMD RX Vega 8 5000 gets about 216 FPS on SoS MAP32. Actually playing the map stays pretty consistently above 200 FPS, maybe with some dips into the 190s.

Share this post


Link to post

I discovered a wonderful opportunity to launch Helion with any wad as if it were iwad, if there is a palette (Helion.exe -iwad LEST.wad -file plypal.pk3). Even if all resources are not enough. Please leave this option. This makes collecting the standalone wads very simple. 

lest_pypl.zip

Share this post


Link to post
  On 10/7/2023 at 9:40 AM, hobomaster22 said:

I wouldn't call it "how not to design a Doom map". Maps like this were a real motivation for Helion's existence. Sunder was first released in 2009 and even with over a decade of hardware tech Sunder was still suffering massively purely from a map rendering standpoint. I imagine mappers are still holding back a bit because they know their maps wouldn't be playable.

 

Expand  

 

One does not negate the other. "How not to design a Doom map" essentially implies requiring an engine with different fundamentals. and that's precisely what we have here.

 

 

  On 10/7/2023 at 9:40 AM, hobomaster22 said:

Now the ceiling has been blown up, and even more ridiculous maps can exist.


Expand  

 

In a way this map is the ceiling, at least for the binary Doom map format this is right at the absolute technical limit of what's doable.

It sits at > 60000 linedefs, way over 90% being two-sided. With maps getting even larger than this you will first need UDMF and the bottlenecks will move elsewhere - no longer in the renderer but in the play code mainly - because with larger maps you will inevitably need more game elements that take up processing time and memory. All the outrageously oversised UDMF maps I have seen had most performance problems with the play code, but of course none looked like this where you could see everything all at once.

 

 

Share this post


Link to post
  On 10/7/2023 at 11:18 AM, Graf Zahl said:

In a way this map is the ceiling, at least for the binary Doom map format this is right at the absolute technical limit of what's doable.

It sits at > 60000 linedefs, way over 90% being two-sided. With maps getting even larger than this you will first need UDMF and the bottlenecks will move elsewhere - no longer in the renderer but in the play code mainly - because with larger maps you will inevitably need more game elements that take up processing time and memory. All the outrageously oversised UDMF maps I have seen had most performance problems with the play code, but of course none looked like this where you could see everything all at once. 

 

 

Expand  

Yes, UDMF is next on the list. And then we will solve more of the world simulation problems as they come up. There also isn't anything that says you need to add 10,000 monsters to a map just because the line/side count is high. Map designers can easily make large maps with cool scenery that is bursting with lines and have a relatively tame monster count. Pina Colada MAP15, as an extreme example, has over 64k sides but limited to 70 monsters.

Forgetting line/side limits, the great thing about the ceiling being lifted so high is that an extreme map like SoS MAP32 is playable on the majority of peoples hardware. My Ryzen/RTX 3070 couldn't render that scene above 30FPS in other ports. It's no longer a requirement to need expensive hardware to play these maps, and even worse get terrible performance anyway.

Share this post


Link to post
  On 10/6/2023 at 7:50 PM, hobomaster22 said:

Helion 0.9.2.0

 

There is a lot in this one. We now have release packages for Windows and Linux that are bundled with the runtime so .NET doesn't need to be installed separately.

Windows dependencies are removed so it should work in Linux now (will require installing fluidsynth). I don't have Linux installed on anything as I don't have a use for it, so if someone could let me know if there any issues it be appreciated.

Expand  

Looks like the Linux runtime version tries to use Windows filepaths when attempting to load the soundfont.
 

Log for you - first one is with an almost fresh config file (only changed some stuff like hud.showstats), second one is a successful launch after moving Default.sf2 out of the Soundfonts folder, into the base Helion folder, and renaming it to SoundFonts\Default.sf2.

 

Edit: Forgot to also add the original reason I came here to post. Got curious and decided to throw in on the Summer of Slaughter Map32 benchmark, which brings my laptop to a crippling 30 FPS when walking outside to see the supermassive pentagram at the start on DSDA-Doom's OpenGL renderer in 1080p, but stays strong at 390 FPS on Helion in the same resolution. Astounding difference.

Edited by Maribo

Share this post


Link to post
  On 10/7/2023 at 7:13 AM, Graf Zahl said:

 

I find it amazing that today's computers are powerful enough to manage this with a traditional Doom map processing algorithm to get 30 fps at all. It's virtually a summary of "how not to design a Doom map".

Of course it is also a perfect test case to try out render optimizations - even better for that than Frozen Time.

 

About those 250 fps, is this with monsters being active and attacking the player or just looking at the empty map? Because when I play it the think time alone is enough to bring this down to below 100 fps after some time, even without any rendering at all.

 

Expand  


In a way, for map makers its hard to know what are the limits of the engine, their hardware or someone else's hardware. Not everyone has the technical knowledge of what makes a certain port run well or what doesn't.

 

When I started mapping, the second map I was working on was a very ambitious project, which had a big coastline, with many explorable buildings and whatnot, huge lines of sight. Eventually, gzdoom performance prevented me from developing it further, since with my system at the time (fx6100, gtx950, 8gb) I wasn't getting good performance. Around 20 fps on many places. Because of this i had to learn how to optimize, i had to cut down many parts and deviate from my original vision, which eventually killed my motivation for making that map, and led to that project being dropped even after having spent around 2 years of work on it.

Edited by faad3e

Share this post


Link to post
  On 10/7/2023 at 4:10 PM, Maribo said:

Looks like the Linux runtime version tries to use Windows filepaths when attempting to load the soundfont.
 

Log for you - first one is with an almost fresh config file (only changed some stuff like hud.showstats), second one is a successful launch after moving Default.sf2 out of the Soundfonts folder, into the base Helion folder, and renaming it to SoundFonts\Default.sf2.

 

Edit: Forgot to also add the original reason I came here to post. Got curious and decided to throw in on the Summer of Slaughter Map32 benchmark, which brings my laptop to a crippling 30 FPS when walking outside to see the supermassive pentagram at the start on DSDA-Doom's OpenGL renderer in 1080p, but stays strong at 390 FPS on Helion in the same resolution. Astounding difference.

Expand  


Looks like a smoothed brained hard-coded path on my part. This version should fix it.

Was the only command required to get Helion working something like 'apt install fluidsynth'? I would like to have instructions for running it, even if most people that use Linux are pretty savvy and don't need it. Would you happen to know if the libfluidsynth.so (and maybe other dependencies) would be able to be pre-packaged and work across the different distributions? Admittedly, I am dumb when it comes to Linux stuff now. It used to be my main development OS but I left that job in 2010 and have been on Windows ever since.

Share this post


Link to post
  On 10/7/2023 at 4:16 PM, faad3e said:


In a way, for map makers its hard to know what are the limits of the engine, their hardware or someone else's hardware. Not everyone has the technical knowledge of what makes a certain port run well or what doesn't. 

 

When I started mapping, the second map I was working on was a very ambitious project, which had a big coastline, with many explorable buildings and whatnot, huge lines of sight. Eventually, gzdoom performance prevented me from developing it further, since with my system at the time (fx6100, gtx950, 8gb) I wasn't getting good performance. Around 20 fps on many places. Because of this i had to learn how to optimize, i had to cut down many parts and deviate from my original vision, which eventually killed my motivation for making that map, and led to that project being dropped even after having spent around 2 years of work on it. 

Expand  

 

The issue here is that there are no hard limits. A map like SoS MAP32 runs, after all, albeit slow on ports with a classic Doom-BSP based renderer. The main trick to avoid tanking performance is to limit the amount of geometry visible at a time.

As a rather old example for handling outside areas, check out Memento Mori 2 MAP27. It split its outside part into 3 sections with strategically well placed doors to avoid line of sight between two sections. Granted, for modern ports it would work without it but I think it still serves as a good example of how to address such things.

In the end, the Doom engine was never really made for arena style mapping and it says a lot that it took this long for a port to appear that tackles this specific kind of map.

 

Share this post


Link to post
  On 10/7/2023 at 5:27 PM, hobomaster22 said:

Was the only command required to get Helion working something like 'apt install fluidsynth'?

Expand  

I already had fluidsynth installed, so I believe that would be sufficient for most. I run Pop! OS and the fluidsynth-related packages I have installed are: libfluidsynth-dev, libfluidsynth3, libsdl2-mixer-dev, and libsdl2-mixer-2.0-0, though I doubt the latter two SDL-related packages are relevant since I haven't seen anyone mention SDL in this thread.

 

  On 10/7/2023 at 5:27 PM, hobomaster22 said:

Would you happen to know if the libfluidsynth.so (and maybe other dependencies) would be able to be pre-packaged and work across the different distributions?

Expand  

Not sure, my knowledge in regards to software on Linux falls into the range of "can compile things on my own and competently read/debug error messages, but am not really an active developer", so I wouldn't feel confident in answering that. I know Woof and Nugget use AppImages as their method of Linux distribution now, that might be something worth looking into for a simple "It Just Works" approach.

Share this post


Link to post
  On 10/7/2023 at 5:41 PM, Graf Zahl said:

 

The issue here is that there are no hard limits. A map like SoS MAP32 runs, after all, albeit slow on ports with a classic Doom-BSP based renderer. The main trick to avoid tanking performance is to limit the amount of geometry visible at a time.

As a rather old example for handling outside areas, check out Memento Mori 2 MAP27. It split its outside part into 3 sections with strategically well placed doors to avoid line of sight between two sections. Granted, for modern ports it would work without it but I think it still serves as a good example of how to address such things.

In the end, the Doom engine was never really made for arena style mapping and it says a lot that it took this long for a port to appear that tackles this specific kind of map.

 

Expand  

 

Yeah SoSMap32 runs on my gpu (6700) but its not playable since it barely runs at 19fps on gzdoom (23 on dsda) with my sistem, and thats on 1080p, not my actual 1440p res. Running something is one thing, another thing is for it to be playable.


And like i said previously, you will run onto situations as a creator where you have a vision that wont be able to realize without compromises, which you'll have to take due to the performance restrictions. Those compromises may or may not end up hurting your initial vision of your project.

 

Sunder wouldnt be sunder without the massive vistas or haunting landscapes it has.

Edited by faad3e

Share this post


Link to post

Ideally speaking, the hardware should be the limit, not the engine. Clearly other engines had important bottlenecks that didn't make sense given modern hardware.

 

 

 

Don't worry Graf, GZDoom still is my main way to play Doom, I need the mod support :P

Edited by Turin Turambar

Share this post


Link to post
  On 10/6/2023 at 7:50 PM, hobomaster22 said:



sos092.png.32254d95d9aed12a5918d6199d67affb.png

 

  Reveal hidden contents

 

 

 

Expand  

under what resolution, in what position, etc? I'd like to compare with my machine. With a normal rtx 3070 I have from 1170 to 1500 fps, flying+noclipping around. I have a rtx 4080 to test tomorrow, if you want the data point.

Edited by Turin Turambar

Share this post


Link to post
  On 10/7/2023 at 9:08 PM, Turin Turambar said:

under what resolution, in what position, etc? I'd like to compare with my machine. With a normal rtx 3070 I have from 1170 to 1500 fps, flying+noclipping around. I have a rtx 4080 to test tomorrow, if you want the data point.

Expand  

It’s in the benchmark spreadsheet here. Still waiting on one PC for the final 0.9.2.0 numbers. 

Share this post


Link to post
  On 10/7/2023 at 7:13 AM, Graf Zahl said:

About those 250 fps, is this with monsters being active and attacking the player or just looking at the empty map? Because when I play it the think time alone is enough to bring this down to below 100 fps after some time, even without any rendering at all.

 

Expand  

 

My tests were done flying above the main area after having shot, to try to cause as much strain as possible.

 

Did this on a GTX 1070 for those curious.

Share this post


Link to post
  On 10/7/2023 at 5:27 PM, hobomaster22 said:

Was the only command required to get Helion working something like 'apt install fluidsynth'? I would like to have instructions for running it, even if most people that use Linux are pretty savvy and don't need it. Would you happen to know if the libfluidsynth.so (and maybe other dependencies) would be able to be pre-packaged and work across the different distributions? Admittedly, I am dumb when it comes to Linux stuff now. It used to be my main development OS but I left that job in 2010 and have been on Windows ever since.

Expand  

You should probably be able to include the fluidsynth libs and have them just work. Like @Maribo said the most common way to do things these days for an all-in-one package is something like an AppImage, though this might take more work on your part if you can't find someone to maintain it. (I know almost nothing about AppImages.)

 

Most sourceports other than GZDoom need fluidsynth to play MIDI music at all anyhow, though I guess this isn't true if someone uses only AppImage versions.

 

Anyhow I did already have fluidsynth installed and the 0.9.2.1 update worked fine for me out of the box.

Edited by plums

Share this post


Link to post
  On 10/6/2023 at 7:50 PM, hobomaster22 said:

Helion 0.9.2.0

 

There is a lot in this one. We now have release packages for Windows and Linux that are bundled with the runtime so .NET doesn't need to be installed separately.

Windows dependencies are removed so it should work in Linux now (will require installing fluidsynth). I don't have Linux installed on anything as I don't have a use for it, so if someone could let me know if there any issues it be appreciated.

Included with a bunch of bug fixes are massive rendering speed increases. The main reason for the speed increase is the updated method for rendering flood filling. Not only is the new method faster, but it also allows us to calculate and update them at runtime. Still finalizing the benchmarks on 0.9.2.0 but here is the increase for Summer of Slaughter MAP32:

sos092.png.32254d95d9aed12a5918d6199d67affb.png

 

  Reveal hidden contents


 

Expand  

Amazing work, it seems to work like a charm, though using an ini file feels a little strange (this is not at all an issue of the program, especially a beta, i'm just not used to it anymore).
The only thing is that it seems to be capped at 120 fov for some reason, i use 150 cause im an insane person (why do you think i use linux and feel the need to make it everyone elses problem), not a big deal at all and this seems like it will be the premiere port for harder to run .wads in the future.

Edited by Theespressoman
mistake

Share this post


Link to post
  On 10/6/2023 at 7:50 PM, hobomaster22 said:
Expand  

Thought that I'd give this latest version a test drive, since it's been a while since I've checked out this port.

(Plus I thought it'd be fun to see how it dealt with some vanilla stuff with the most recent Hell Revealations WAD I put out).

 

I will say that since the last time I checked out the port, it's now able to do flat bleeds, which is really cool.

 

What I did notice however is that the port doesn't really understand how to render (or how it shouldn't render) self-referencing sectors. Hell Revealations (heavily inspired by Hell Revealed 1 + 2), tends to use alot of fake bridges, which use self-referencing sectors that instantly raise and lower. I noticed that the port will strangely render the floors/ceilings of the self-referencing (invisible) sectors even though it shouldn't. which can lead to interesting looking stuff:

 

Helion:

  Reveal hidden contents

 

DSDA Doom / Vanilla:

  Reveal hidden contents

 

I'll also mention that the port can't render midtex bleeds, but tbh most opengl ports don't do them either, so I didn't really much reason to mention it, even if there are many Vanilla wads such as this, and like Knee-Deep in Knee-Deep in ZDoom that utilise midtex bleeds as a sort of visual effect.

Edited by Arsinikk

Share this post


Link to post
  On 10/8/2023 at 2:46 AM, Arsinikk said:

What I did notice however is that the port doesn't really understand how to render (or how it shouldn't render) self-referencing sectors. Hell Revealations (heavily inspired by Hell Revealed 1 + 2), tends to use alot of fake bridges, which use self-referencing sectors that instantly raise and lower.

Expand  

Known issue. Emphasis mine:

 

  On 10/6/2023 at 7:50 PM, hobomaster22 said:

Optimized flood fill rendering. No longer uses stencil buffer and is significantly faster against all tested GPUs. Flood filling is now able to be changed and rendered in real time. Includes better emulation of vanilla flood filling cases. Note: flood filling hacks with lines that have the front/back sides as the same sector id are still not supported.

Expand  

 

Edited by Dark Pulse

Share this post


Link to post

Came across this one and of course had to test Sunder map 15 first thing and... well the images speak for themselves:

 

GZDoom:

GZDoom.png.7ed98c26bf5bf1fa4ff4cb04542f7264.png

 

 

Helion:

Helion.png.abfe199cfc5875ba35d14dbbf8194e4b.png

 

 

so that's like.... 20 times faster, lmao....

 

Ryzen 7 5800X3D + Radeon RX 6800 XT at 1440p

Share this post


Link to post

@hobomaster22

Woah it's so smooth! I love it! I've never played Doom so smoothly before. Good work!

 

Also, I can confirm it runs on Linux. I'm using Funtoo and Fluidsynth is already installed. I just used the latest version, 0.9.2.1 and it all works.

Share this post


Link to post

Finally gave this a try now that there's a Linux build. Ran out of the box on Fedora. I already had Fluidsynth installed; the relevant package would be fluidsynth-devel. Some truly impressive work you've done here; feels almost sinful to turn around in Poogers MAP35 without the game grinding to a halt.

 

Speaking of that map, I couldn't warp to that level with -warp or IDCLEV (though the latter did display "Changing level..."), which I assume is due to its map number being greater than 32. I had to use the console to load it. Not a big deal, but I thought I'd mention it in case it hadn't been noticed.

 

Another minor issue is that in D5DA3, the episode selection screen displays the first episode twice.

 

Lastly, I got a crash trying to play GOODWAD. The stack trace says it occurred while parsing the Dehacked, not sure if it's a bug or an unsupported feature:

System.Exception: Expected an integer but got 0
   at Helion.Dehacked.DehackedDefinition.GetIntProperty(SimpleParser parser, String property)
   at Helion.Dehacked.DehackedDefinition.ParseThing(SimpleParser parser)
   at Helion.Dehacked.DehackedDefinition.Parse(String data)
   at Helion.Resources.Definitions.DefinitionEntries.ParseEntry(Action`1 parseAction, Entry entry)
   at Helion.Resources.Definitions.DefinitionEntries.Track(Archive archive)
   at Helion.Resources.Archives.Collection.ArchiveCollection.ProcessAndIndexEntries(Archive iwadArchive, List`1 archives)
   at Helion.Resources.Archives.Collection.ArchiveCollection.Load(IEnumerable`1 files, String iwad, Boolean loadDefaultAssets, String dehackedPatch, Nullable`1 iwadTypeOverride)
   at Helion.Client.Client.LoadFiles()
   at Helion.Client.Client.Initialize()
   at Helion.Client.Client.Run()
   at Helion.Client.Client.Run(CommandLineArgs commandLineArgs)
   at Helion.Client.Client.RunRelease(CommandLineArgs commandLineArgs) 

 

Share this post


Link to post
  On 10/8/2023 at 11:27 AM, Shepardus said:

Lastly, I got a crash trying to play GOODWAD. The stack trace says it occurred while parsing the Dehacked, not sure if it's a bug or an unsupported feature: 

Expand  

It appears the culprit is "Dropped item = 0"

Share this post


Link to post
  On 10/8/2023 at 11:27 AM, Shepardus said:

Finally gave this a try now that there's a Linux build. Ran out of the box on Fedora. I already had Fluidsynth installed; the relevant package would be fluidsynth-devel. Some truly impressive work you've done here; feels almost sinful to turn around in Poogers MAP35 without the game grinding to a halt.

 

Speaking of that map, I couldn't warp to that level with -warp or IDCLEV (though the latter did display "Changing level..."), which I assume is due to its map number being greater than 32. I had to use the console to load it. Not a big deal, but I thought I'd mention it in case it hadn't been noticed.

 

Another minor issue is that in D5DA3, the episode selection screen displays the first episode twice.

 

Lastly, I got a crash trying to play GOODWAD. The stack trace says it occurred while parsing the Dehacked, not sure if it's a bug or an unsupported feature: 

System.Exception: Expected an integer but got 0
   at Helion.Dehacked.DehackedDefinition.GetIntProperty(SimpleParser parser, String property)
   at Helion.Dehacked.DehackedDefinition.ParseThing(SimpleParser parser)
   at Helion.Dehacked.DehackedDefinition.Parse(String data)
   at Helion.Resources.Definitions.DefinitionEntries.ParseEntry(Action`1 parseAction, Entry entry)
   at Helion.Resources.Definitions.DefinitionEntries.Track(Archive archive)
   at Helion.Resources.Archives.Collection.ArchiveCollection.ProcessAndIndexEntries(Archive iwadArchive, List`1 archives)
   at Helion.Resources.Archives.Collection.ArchiveCollection.Load(IEnumerable`1 files, String iwad, Boolean loadDefaultAssets, String dehackedPatch, Nullable`1 iwadTypeOverride)
   at Helion.Client.Client.LoadFiles()
   at Helion.Client.Client.Initialize()
   at Helion.Client.Client.Run()
   at Helion.Client.Client.Run(CommandLineArgs commandLineArgs)
   at Helion.Client.Client.RunRelease(CommandLineArgs commandLineArgs) 

 

Expand  

Thanks for the report, the dehacked thing is definitely a bug. There is garbage characters in the dehacked making a mess. The line with 'Dropped item = 0' has an invalid character before the 0. Probably going to require stripping the data down to valid ascii characters. I will take a look at the other things as well. Most of the bug fixes so far has been myself just playing random wads and dog-fooding Helion myself. I expect more of these to fall out as more people run Helion and throw random wads at it.

Edited by hobomaster22

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...