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

[hobomaster22]

2 hours ago, Darkcrafter07 said:

I got the very same specs laptop, eager to test

 

In the beginning it's around 208 fps

 

When monsters wake up it dips to 33 and goes to 45 and later to 50 and when it settles down to 80. Even with 80fps it has some microstutters and feels like 40 but playable.

 

I can't lower resolution and disable multisampling, maybe that could help it to gain some speed.

 

Btw, I noticed the same behavior as in gzdoom, it slows down dramatically when you look up and down, maybe it's up to the frustrum algorithm.

 

In the totally separated secret location it still lags as if no visibility checks were made at all.

 

Maybe you'd need to get some culling techniques other than bsp anyway like geometry occluders.

Nuts3 is currently one the worst cases for Helion. There are a few reasons but it's mostly due to how crippling monster movement is right now. I suspect it's because of cache locality problems with blockmap traversal and blocking checks, but I haven't had a chance to really deep dive into it. Boom ports are going to handle this one better because their cache performance is just that much better. One of those things we probably should have started first with performance in mind, but it's on the list of things to look at soon.

To lower the resolution in fullscreen you would need to use render.virtual.enable = true and set render.virtual.dimension to whatever dimensions you want in config.ini.

We don't really have frustum culling at the moment, we were working on it but had trouble working out the bugs and currently it just does a lazy dot product to cull out stuff from behind depending on the view pitch.

Some usual maps that are performance killers but should mostly play quite nicely on that machine off the top of my head are: Frozen Time, Sunder MAP15, The Given, Planisphere 2, Dance on the Water MAP04, Eviternity MAP26/MAP29. Helion can cheat a lot with Sunder MAP15 because we detect if something is in a monster closet and run dumbed down AI routines.

Some other edge cases like Nuts (but for different reasons) are Saturnine Chapel and Micro-Slaughter Community Project MAP02. Both of these have so many light change effects that it will smash the CPU with processing and then GPU with a ton of uploads. This is one of those cases where things are 'free' with BSP traversal because the changes are irrelevant but suck for Helion because we actually have to process them. We have ideas to handle this but is going to require upping the minimum from OpenGL 3.3 to 4.3.


 

[Bauul]

I got a new upgrade recently and decided to test Helion to see what kind of FPS I can get.

 

Is there a reason why FPS might top out at 500, regardless of map?  I have maxfps set to 10,000 and vsync off, but it seems to steadfastly refuse to go any higher than 500.  Are there any other settings I should be looking at?

[hobomaster22]

6 hours ago, Bauul said:

I got a new upgrade recently and decided to test Helion to see what kind of FPS I can get.

 

Is there a reason why FPS might top out at 500, regardless of map?  I have maxfps set to 10,000 and vsync off, but it seems to steadfastly refuse to go any higher than 500.  Are there any other settings I should be looking at? 

You have to hit maxfps to 0. I think otherwise it gets capped to the OpenTK render frequency which is probably 500.

[Bauul]

16 hours ago, hobomaster22 said:

You have to hit maxfps to 0. I think otherwise it gets capped to the OpenTK render frequency which is probably 500.

 

That did the trick, thanks!  I get a nice 2000 FPS on Sunder Map15, 2500 FPS on MSCP Map02, and 5000 FPS on Doom 2 Map01.

[Turin Turambar]

3 hours ago, Bauul said:

 

That did the trick, thanks!  I get a nice 2000 FPS on Sunder Map15, 2500 FPS on MSCP Map02, and 5000 FPS on Doom 2 Map01.

Unlimited power in the hand of mappers!

[CBM]

I have been trying to use decorate to add custom monsters to a map for use in helion but they never appear, also any mod I tried that uses decorate to replace standard doom 2 monsters doesnt work

 

how do I utilize decorate in helion? does anyone have an example wad I can try?

 

also, is it supposed to make it possible to combine boom and decorate in the same wad

and does ultimate doom builder support that?

 

thanks in advance for any help, I think I could grow to really like this port

Edited September 1, 2023 by CBM

[Bauul]

4 minutes ago, CBM said:

how do I utilize decorate in helion? does anyone have an example wad I can try?

 

AFAIK Decorate isn't supported in Helion. Think of it closer to an alternative to DSDA rather than any ZDoom-family ports.

[hobomaster22]

12 minutes ago, CBM said:

I have been trying to use decorate to add custom monsters to a map for use in helion but they never appear, also any mod I tried that uses decorate to replace standard doom 2 monsters doesnt work

 

how do I utilize decorate in helion? does anyone have an example wad I can try?

 

also, is it supposed to make it possible to combine boom and decorate in the same wad

and does ultimate doom builder support that?

 

thanks in advance for any help, I think I could grow to really like this port

Helion does support decorate but it's pretty barebones. My honest recommendation is to use dehacked with DECOHack because this will give you the most amount of ports that will be able to run your mod. You can write decorate like code for your mod and let DECOHack translate to dehacked for you. This is the most stable path for Helion as well.

Edited September 1, 2023 by hobomaster22

[hobomaster22]

https://github.com/Helion-Engine/Helion/releases/tag/0.9.1.5

Lots of bug fixes. More speed. Big changes for rendering include interpolation for sector movement instead of being processed every frame. All runtime allocations have been tracked down and removed so that the .NET garbage collector never does any work saving CPU and potential stutters.
 

Spoiler

Implemented transfer heights blocking line of sight.
Included check for \n in UMAPINFO intertext/intertextsecret to add newlines.
Moving sectors are now interpolated instead of being processed every frame. Results in higher FPS when maps have large amounts of moving sectors and cleaner code.
Cached OpenGL textures for sprite rotations to fix random stutter.
Fixed font alignment on HUD that caused certain fonts to be offset incorrectly.
Added sector friction flag check to allow change of sector friction. with Boom's 223 special.
Implemented wall bouncing for icy floors.
Fixed serialization for friction in saves.
Fixed weapon switch with A_CheckReload.
Moved player attack press check to A_WeaponReady so weapon firing is not potentially missed when A_WeaponReady is called less than every tick.
Render episode name text from mapinfo if no image is specified.
Render skill name text from mapinfo if no image is specificed.
Added configuration for rendering null textures (render.nulltexture) defaulted to false.
Fixed rendering issue with scrolling textures that have transparent pixels.
Fixed inverted sky rendering.
Fixed clamping check with moving sectors to match Doom's bugged behavior when shorting out when hitting a blocking line.
Removed all runtime allocations created during runtime. Improves performance to prevent garbage collection.
Input processing only processes on the game tick instead of every frame. Saves CPU when running at very high FPS values.
Fixed weapon switching when using mousewheel for upgraded OpenTK.
Render author from mapinfo on the intermission screen.
Fixed light level rendering for transfer heights sectors.
Fixed static render cache calculations when loading a game that was incorrectly using the player's current position.
Fixed setting a things Z when loading a game that could be incorrectly changed when linking to the world.
Refactored all code referencing System.Drawing to move towards linux compilation.
Added missing chain gunner lookups when processing dehacked.
Fixed destination offset for teleport line reverse boom special.
Fixed A_HealChase to correctly call A_Chase on failure.

 

[Darkcrafter07]

Here is a couple of things I have noticed:

- it's better to set "render.maxfps" to 0 (disable fps cap) and set it in nvidia control panel settings per app (helion.exe), not sure if that would work with non-nvidia cards, otherwise framerate dips down more;

- death gibs and death animations speed aren't randomized;

- still no viewport push up when hud is shown;

- keys aren't picked up when already having those (maybe this should never get fixed!).

Edited September 4, 2023 by Darkcrafter07

[hobomaster22]

3 hours ago, Darkcrafter07 said:

Here is a couple of things I have noticed:

- it's better to set "render.maxfps" to 0 (disable fps cap) and set it in nvidia control panel settings per app (helion.exe), not sure if that would work with non-nvidia cards, otherwise framerate dips down more;

- death gibs and death animations speed aren't randomized;

- still no viewport push up when hud is shown;

- keys aren't picked up when already having those (maybe this should never get fixed!).

I haven't tried setting in the nvidia control panel, I will try that out. I usually turn vsync off and maxfps to 200.

Good call with the death animations not being randomized. Didn't notice this myself. I will likely have to fix the key thing. I'm sure there is at least one wad that is dependent on being able to pick up the same key multiple times :)

I just found one that is dependent on transfer heights blocking line of sight checks and is required to complete the map. It's also dependent on the twitching corpse that is set to a height of 16 in info.c but ZDoom ports including Helion set it taller otherwise you could work over it. Leave it to Doom mods to intentionally or unintentionally be dependent on things like this!

[camper]

Hi! Will there be support for the railgun through dehacked functions, because it seems that it does not exist, at least in mod "doom in space" (http://www.geocities.ws/doomkid/dmdnspce.wad) it does not work.

[hobomaster22]

16 minutes ago, camper said:

Hi! Will there be support for the railgun through dehacked functions, because it seems that it does not exist, at least in mod "doom in space" (http://www.geocities.ws/doomkid/dmdnspce.wad) it does not work.

I didn't know the railgun was added to dehacked. I can look at adding it in the next version.

[Doomy__Doom]

2 minutes ago, hobomaster22 said:

I didn't know the railgun was added to dehacked.

I believe it's a skulltag-ism that migrated to z-family?.. Or maybe some other way around, but either way reference for that is somewhere in z-adjacent rather than -complevel land.

[hobomaster22]

55 minutes ago, Doomy__Doom said:

I believe it's a skulltag-ism that migrated to z-family?.. Or maybe some other way around, but either way reference for that is somewhere in z-adjacent rather than -complevel land. 

Looks like it was added to ZDoom in 1999 and included an optional bex patch. I vaguely remember it was it's own weapon in Skulltag but was a replacement weapon in other ports to access the functions.
https://zdoom.org/wiki/ZDoom_version_history#1.17

[camper]

Yes, the skulltag had an additional weapon:
https://wiki.zandronum.com/SkullTag_Weapons

In Odamex, the railgun is now working. I don't know about other weapons. Decorate is not supported in Odamex.

[cacomonkey]

Was telling the author earlier in Msg that it would be nice to have a source port for Doom that runs as fast as Ironwail does for Quake (which technically in terms of sheer speed and smoothness has been a peak experience for me in playing first-person shooters).  Will be watching development of this closely.

Edited September 9, 2023 by cacomonkey

[cacomonkey]

Was trying to test this with a wad called Temple of the Lizard Men 2 that becomes unplayable on all the other source ports at 4K (including latest GZDoom) but can't get it to load with Helion.  Is there a certain command line?  Is it not compatible with that wad possibly?

Edited September 11, 2023 by cacomonkey

[hobomaster22]

55 minutes ago, cacomonkey said:

Was trying to test this with a wad called Temple of the Lizard Men 2 that becomes unplayable on all the other source ports at 4K (including latest GZDoom) but can't get it to load with Helion.  Is there a certain command line?  Is it not compatible with that wad possibly?

It’s not compatible. Helion doesn’t support GZDoom features. It currently supports a subset of ZDoom features so that we have Boom and MBF21 compatibility. 

[cacomonkey]

1 hour ago, hobomaster22 said:

It’s not compatible. Helion doesn’t support GZDoom features. It currently supports a subset of ZDoom features so that we have Boom and MBF21 compatibility. 

 

Ah, okay.  I remember you mentioning it supporting a subset of zdoom features and I might have misinterpreted it to mean gzdoom too.  Temple of the Lizard Men 2 plays really odd on my system.  When you first appear on the beach, you get the full 120 FPS framerate.  Then a minute later without doing anything it slowly drops to below 30, even without leaving the beach.  Weird.  Might be a driver issue. No other wad I tested does this.

Edited September 11, 2023 by cacomonkey

[Amiga Angel]

On 9/11/2023 at 9:47 PM, hobomaster22 said:

It’s not compatible. Helion doesn’t support GZDoom features. It currently supports a subset of ZDoom features so that we have Boom and MBF21 compatibility. 

is there a complete list somewhere that lists the zdoom, boom and mbf features that are supported?

 

also what decorate is supported and are there examples of it? also are you planning on adding full decorate support?

[Doomy__Doom]

On 9/11/2023 at 10:47 PM, hobomaster22 said:

so that we have Boom and MBF21 compatibility. 

Speaking of, here's a bug:

Boom's "bouncy walls" trick from Wormwood EU (scrollers apply to projectiles if they are below 242-transferred fake floor height, see map 1 fight with cyber in the north of the map) doesn't work in Helion.

Edited September 16, 2023 by Doomy__Doom

[hobomaster22]

7 hours ago, Amiga Angel said:

is there a complete list somewhere that lists the zdoom, boom and mbf features that are supported?

 

also what decorate is supported and are there examples of it? also are you planning on adding full decorate support?

There is not at the moment. Boom and MBF is fully supported except for colored sectors ad the door light special.

The original intention was to fully support decorate but things have changed as the engine has been developed. Fully implementing decorate is too much and not on the table right now. The current goal is to support vanilla, Boom and MBF21 to the fullest extent that we can. Like I explained above, the best path would be to use DECOHack to write decorate like code that gets translated to dehacked. Using DECOHack would ensure the features being used are supported by Helion and would work in other MBF21 ports like dsda-doom.

[hobomaster22]

7 hours ago, Doomy__Doom said:

Speaking of, here's a bug:

Boom's "bouncy walls" trick from Wormwood EU (scrollers apply to projectiles if they are below 242-transferred fake floor height, see map 1 fight with cyber in the north of the map) doesn't work in Helion.

Thanks, I have not heard of this one. Do you know if this is an intended feature or some side effect? Sounds very strange. I'm going to have to research the code to see exactly how/why this works.

[Doomy__Doom]

10 hours ago, hobomaster22 said:

Thanks, I have not heard of this one. Do you know if this is an intended feature or some side effect? Sounds very strange. I'm going to have to research the code to see exactly how/why this works.

I believe it's intended use is to allow "underwater currents" in boom. Relevant code

Edited September 17, 2023 by Doomy__Doom

[hobomaster22]

Helion 0.9.1.6

Benchmarks
 

An exciting update. We have removed the lighting update bottleneck! This was a difficult problem to solve and was previously very expensive to deal with. Given Doom's nature of changing things at runtime in no predictable way and Boom maps that use scripted closets that change light levels all the time. Previously processing a sector light change involved touching all vertex data with the sector and uploading it back to the GPU. Maps like Micro Slaughter Community Project MAP02 @Bauul suffered huge FPS drops and would feel choppy because it would update roughly 6,000 sectors per game tick. Helion would spend about 20% of CPU time just calculating light updates on a Ryzen5900HS. With Helion 0.9.1.6 it now spends less than 0.5% CPU processing light updates, and the expensive uploads the GPU are gone. This is huge because it now brings even more maps into the playable FPS range on slower GPUs, and fast GPUs won't experience a choppy feeling even though the average FPS may be very high.

 

The technical details with the light update: Each vertex gets mapped to a light index. We maintain an array of light values that get updated each tick and then upload that one array to the GPU. The shader will fetch that index to use as the render light level. With our benchmarking tests it is practically free (more on that below).

 

We have done some benchmarking collecting average FPS values on various test systems with Helion 0.9.1.6, dsda-doom 0.26.2 and GZDoom 4.10.0. We wanted to get some hard numbers down to see where everything stands on various hardware. Each sheet is the test system and labeled by it's GPU. The slowest system is a laptop from 2013 running an AMD Radeon HD 8400. This updates puts two of the benchmark maps into the easily playable range (Micro Slaughter Community Project MAP02 at 122 FPS and Dance on the Water MAP01 at 74 FPS).

 

One of the most interesting points we discovered is the Radeon 6700 suffers massively with dsda-doom and GZDoom using OpenGL. Most are aware of AMDs terrible OpenGL support. What was really surprising here is that Helion didn't appear to suffer any loss even though we are using OpenGL 3.3. Helion's numbers for the Radeon 6700 fall between the RTX 3070 Ti and Mobile RTX 3070 which is in line with the relative performance of the GPUs. Switching GZDoom to Vulkan increases it's performance on the 6700 and puts it line as well.

Another interesting one is Occula RC MAP31.  This maps seems to crush dsda-doom and GZDoom especially hard and I'm not sure why. It does have a significant number of visible sectors and lines but has half the line count of SoS Boom MAP32 which saw better performance. While both get high performance Helion the opposite is true where Occula Map31 performed significantly better than SoS Boom MAP32, which makes sense purely from a perspective of map complexity in terms of line/vertex counts.
 

Spoiler

Implemented optimized rendering for light level changes.
Added compatibility options and set through mapinfo. Support compatibility options with this update are:
    compat_missileclip
    compat_shorttex
    compat_floormove
    compat_nopassover
    compat_limitpain
    compat_notossdrops
Fixed check for radius damage and boss flag.
Fixed check for bounce flag and set owner in A_SpawnObject to match dsda.
Added check to early out of z movement for things on ground.
Fixed monster projectile attacks to use the bottom z position instead of center which caused slightly different z velocities.
Added underwater check for boom carry scroll special so that things not on ground can have their velocity modified. Fixed Wormwood EU MAP01.
Interpolate sprite level between floor and ceiling to match boom.
Fixed hud images to be able to pull from any namespace to match doom behavior.
Allow keys to be picked up multiple times.
Fixed boom silent teleport special to use compatibility flag to keep bugged behavior where the thing is set backwards.
Fixed vanilla lift specials to map to PlatDownWaitUpStayLip.
Fixed dehacked issue with decreasing ammo to use Doom's hardcoded amounts if they were not set.
Implemented monsters ignore each other option from dehacked.
Fixed randomized death ticks not being set.

 

[Darkcrafter07]

Your port is an amazing technical achievement, good job! Honestly, it's the only port I could use to play frozen time decently and even prboom had massive problems with it.

[Master O]

Are https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/runtime-desktop-6.0.10-windows-x64-installer?cid=getdotnetcore and https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/runtime-6.0.10-windows-x64-installer the same thing?

 

One installer says it's the Desktop installer and the other one is not.

 

[hobomaster22]

6 hours ago, Darkcrafter07 said:

Your port is an amazing technical achievement, good job! Honestly, it's the only port I could use to play frozen time decently and even prboom had massive problems with it.

Thank you, this means a lot. Funny enough, I finally played Frozen Time from start to finish last month since I could actually get the steady 200FPS with Helion. Had no idea about the whole clock ending sequence which was pretty cool. It also allowed me to slog through SoS MAP32, took quite a bit of time.

[hobomaster22]

28 minutes ago, Master O said:

Are https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/runtime-desktop-6.0.10-windows-x64-installer?cid=getdotnetcore and https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/runtime-6.0.10-windows-x64-installer the same thing?

 

One installer says it's the Desktop installer and the other one is not.

 

They are different, the naming is kind of dumb. The desktop one is basically the runtime for Windows dependencies that we still have hanging around. For the next release we are looking at nuking this entirely since .net7 finally lets us build an entire package without requiring the runtime. This requires removing the final windows dependencies once and for all (which needs to happen anyway).