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

[Edward850]

4 hours ago, Bauul said:

I don't believe any other hardware renderer has managed to implement a proper fix for this

You would be quite mistaken.
https://doomwiki.org/wiki/Strife:_Veteran_Edition (https://doom64ex.wordpress.com/2014/12/24/sprite-clipping-in-strife-veteran-edition-explained/)

https://doomwiki.org/wiki/Doom_64

Edited February 9 by Edward850

[Bauul]

8 hours ago, Edward850 said:

You would be quite mistaken.
https://doomwiki.org/wiki/Strife:_Veteran_Edition (https://doom64ex.wordpress.com/2014/12/24/sprite-clipping-in-strife-veteran-edition-explained/)

https://doomwiki.org/wiki/Doom_64

 

I was aware of Strife: Veteran Edition implemented an approach to sprite overdraw (I myself have shared that blog before) but the method used is described in that very blog as rather inefficient and "This isn’t the BEST way to do it". That's what I meant by a "proper" fix.

 

I wasn't aware of the Doom 64 renderer, but I was more specifically thinking about original engine Doom source ports. And AFAIK none have implemented a fix for this on the hardware renderer (although I welcome being corrected!)

Edited February 10 by Bauul

[hobomaster22]

I think any solution to the sprite clipping is going to come at large cost. With Helion, it's about a 50% loss on Sunder MAP15 for my Mobile RTX 3070 and that is without solving some of the rendering issues. It can be considered an acceptable loss since it still results in over 650FPS which is well over the refresh rates of any monitors people would be using and still order of magnitudes faster than other ports. There is no overdraw, but the flood fill calculations are still more expensive than rendering floors as normal geometry (but significantly cheaper compared to making stencil buffer calls). This is a trade of how much someone wants the feature versus their hardware and the performance they want.

The main problem with this method is that it's a texture so it ends up clipping at sector plane changes as seen here:


But it does emulate this behavior when no clipping:

Edited February 10 by hobomaster22

[Darkcrafter07]

Maybe it's worth trying other methods. From a position of a noncoding guy: isn't it like polygons are clipped because of a zbuffer so that the perfect visibility order gets achieved? If it was to form a zbuffer in such a way:

1) Draw a regular 3D geometry and 3D models (if presented) zbuffer;

2) Draw the polygons that later are going to be textured as sprites as a separate zbuffer;

3) Cull the "sprites zbuffer" with the regular zbuffer;

4) Extend the resulting sprites zbuffer vertically by some pixel algorithm (morphological operations?);
5) Summ up the regular zbuffer and the sprites zbuffer with the latter being placed on top.

A brainfart?

[Turin Turambar]

On 2/9/2024 at 6:14 PM, hobomaster22 said:

Implemented an experimental flood fill all flats option to not clip sprites with the floor/ceiling. Likely to cause rendering artifacts. Expect a 20-50% performance loss.

 

is a toggleable option? Honestly, I never cared for sprites clipping a bit.

[hobomaster22]

41 minutes ago, Turin Turambar said:

 

is a toggleable option? Honestly, I never cared for sprites clipping a bit.

Yeah, it’s the render section. Off by default.

Edited February 10 by hobomaster22

[S3M_XM]

Is it possible to have a plugin to play module tracker files (MOD/S3M/IT/XM) using libmpg123-0.dll as DSDA-Doom and Woof/Nugget Doom(?) does? I'm seeing wads lately that use module tracker lumps in their wads.

And because I was testing if source ports would play module tracker lumps, and I would get an "Unknown/unsupported music format" error message in Helion.

[Edward850]

57 minutes ago, S3M_XM said:

Is it possible to have a plugin to play module tracker files (MOD/S3M/IT/XM) using libmpg123-0.dll as DSDA-Doom and Woof/Nugget Doom(?) does?

I think you're rather confused, libmpg123 is an MPEG audio player (MP2/MP3). Certainly not a module player.

[S3M_XM]

1 hour ago, Edward850 said:

I think you're rather confused, libmpg123 is an MPEG audio player (MP2/MP3). Certainly not a module player.

Oh thanks for the correction, I thought that was the module player.

[Dark Pulse]

Yeah, for a module player that'd be something else entirely.

 

I dunno what (or even if) Helion uses them. I do know the BASS library is free for non-commercial use (which Helion should fall under): https://www.un4seen.com/bass.html

 

Whether or not they want to hook that in or an alternative - or not at all - is obviously their call to make, not mine :P

Edited February 22 by Dark Pulse

[msx2plus]

15 hours ago, Dark Pulse said:

the BASS library

 

i am begging the entire world of doom source ports to use this over libDUMB. libopenmpt is also good.

Edited February 22 by msx2plus

[Dark Pulse]

3 hours ago, msx2plus said:

i am begging the entire world of doom source ports to use this over libDUMB. libopenmpt is also good.

Thing is, that's also not that simple. GZDoom, for example, I think can't use it - even though the engine itself is GPL, commercial games are being made on it, and every commercial game would thus run afoul of BASS' licensing terms (unless someone wants to pony up €9660 to support the four different operating systems GZDoom officially supports - Windows, Mac, Linux, Ubuntu - got the money?), so they basically would have to cut it out of the GPL'd source. Hence, they use foo_DUMB for modules, because none of that legal wrangling can happen. (Other stuff is handled by a combination of OpenAL, an OPL emulator, and an internal Game Music Emu player.)

 

For most Source Ports that just want to play Doom and don't aim to be almost an engine unto themselves, however, it shouldn't be an issue. But that's up to the port authors.

Edited February 22 by Dark Pulse

[dasho]

34 minutes ago, Dark Pulse said:

Thing is, that's also not that simple. GZDoom, for example, I think can't use it - even though the engine itself is GPL, commercial games are being made on it, and every commercial game would thus run afoul of BASS' licensing terms (unless someone wants to pony up €9660 to support the four different operating systems GZDoom officially supports - Windows, Mac, Linux, Ubuntu - got the money?), so they basically would have to cut it out of the GPL'd source. Hence, they use foo_DUMB for modules, because none of that legal wrangling can happen. (Other stuff is handled by a combination of OpenAL, an OPL emulator, and an internal Game Music Emu player.)

 

For most Source Ports that just want to play Doom and don't aim to be almost an engine unto themselves, however, it shouldn't be an issue. But that's up to the port authors.

 

The license is incompatible with a GPL project even if nobody makes a commercial product with the port in question ever, unless they have some exception for external linking.

 

Edited February 22 by dasho

[Dark Pulse]

3 minutes ago, dasho said:

The license is incompatible with a GPL project even if nobody makes a commercial product with the port in question ever, unless they have some exception for external linking.

Yeah, admittedly it doesn't mention that on the page. Presumably that's one of those "If you have that kind of question, get in touch" deals.

 

Point is we're almost certainly not gonna see BASS in GZDoom (or likely most other open-source source ports) anytime soon even as good as it is, so the free competition is just gonna have to slowly make its way up there. :P

[msx2plus]

2 hours ago, Dark Pulse said:

Thing is, that's also not that simple. GZDoom, for example, I think can't use it - even though the engine itself is GPL

 

oh right yeah i totally forgot about that - libopenmpt in that case is still an option and should definitely be considered for its overall compatibility and format support

[deathz0r]

I've done a quick skim through almost all of the TWOGERS maps with Helion and have noticed several issues, some of which appear to be easy fixes while others appear to be more complicated, starting with the common issues I've noticed:

• Monsters with a reaction time of <= 1 never wake up (MAP26, MAP29, MAP36, MAP40, MAP48)
• Monsters don't respect the friendly flag and will attack the player (MAP31, MAP34)
• Dehacked palette translations do not work
• Helion doesn't respect either the COLORMAP lump (any map using FWATER1) or Boom colormap effects through line action 242 (MAP04, MAP16, MAP36)
• Line action 249 (Scroll Tagged Wall w.r.t 1st Side's Sector) does not work (MAP01, MAP17)
• Sound propagation displacement for moving sectors with a joined but distinctally separated sector does not work (MAP04, MAP47)
• Wind effects are either too powerful (MAP14), or do not work (MAP22)
• Speed discrepency with large scrollers that are divisive by 32 (intro of MAP15)
• Picking up a berserk shifts to the item pickup PLAYPAL entries and then to its correct PLAYPAL entry, causing photosensitivity issues with flashing if several are picked up in succession (MAP23)
• No compatibility option for Rev/Manc/Arach projectiles triggering walk-over lines (MAP03)

Other issues which I strongly suspect which are either more complex to handle or outside the scope of Helion:

• The exact position of the player to trigger walk-over linedefs appears to be different than other ports, which can cause unintended effects in tight areas (ie. the MAP04 check for whether to continue the map or exit causes the player to exit early, this may also be related to MAP08 and MAP43 issues)
• Some combination of mapping tricks which causes a ceiling raise to infinitely loop (the start of MAP17)
• Monsters with 1 mass tend to stick to walls rather than bounce off walls (MAP12)
• The vanilla flight technique, (MAP17) while functional has objects that reside within those sectors stick to the ceiling rather than the floor, and player momentum is faster than expected
• Taking lethal damage in a sector with sector effect 11 while being above the floor ends the level, instead of leaving the player at low health (MAP48)
• "mobj swapping" with precisely timed silent teleporter+scroller manipulation does not work for the object being swapped in (MAP36)
• A deliberate setup to break default GZDoom compatibility (MAP36, tag 1) also fails with Helion

 

Edited March 7 by deathz0r

[hobomaster22]

3 hours ago, deathz0r said:

I've done a quick skim through almost all of the TWOGERS maps with Helion and have noticed several issues, some of which appear to be easy fixes while others appear to be more complicated, starting with the common issues I've noticed:

• Monsters with a reaction time of <= 1 never wake up (MAP26, MAP29, MAP36, MAP40, MAP48) 
• Monsters don't respect the friendly flag and will attack the player (MAP31, MAP34) 
• Dehacked palette translations do not work 
• Helion doesn't respect either the COLORMAP lump (any map using FWATER1) or Boom colormap effects through line action 242 (MAP04, MAP17, MAP36) 
• Line action 249 (Scroll Tagged Wall w.r.t 1st Side's Sector) does not work (MAP01, MAP17) 
• Sound propagation displacement with a joined but distinctally separated sector does not work (MAP04, MAP47) 
• Wind effects are either too powerful (MAP14), or do not work (MAP22) 
• Speed discrepency with large scrollers that are divisive by 32 (intro of MAP15) 
• Picking up a berserk shifts to the item pickup PLAYPAL entries and then to its correct PLAYPAL entry, causing photosensitivity issues with flashing if several are picked up in succession (MAP23) 
• No compatibility option for Rev/Manc/Arach projectiles triggering walk-over lines (MAP03) 

Other issues which I strongly suspect which are either more complex to handle or outside the scope of Helion: 

• The exact position of the player to trigger walk-over linedefs appears to be different than other ports, which can cause unintended effects in tight areas (ie. the MAP04 check for whether to continue the map or exit causes the player to exit early, this may also be related to MAP08 and MAP43 issues) 
• Some combination of mapping tricks which causes a ceiling raise to infinitely loop (the start of MAP17)
• Monsters with 1 mass tend to stick to walls rather than bounce off walls (MAP12)
• The vanilla flight technique, (MAP17) while functional has objects that reside within those sectors stick to the ceiling rather than the floor, and player momentum is faster than expected 
• Taking lethal damage in a sector with sector effect 11 while being above the floor ends the level, instead of leaving the player at low health (MAP48) 
• "mobj swapping" with precisely timed silent teleporter+scroller manipulation does not work for the object being swapped in (MAP36)
• A deliberate setup to break default GZDoom compatibility (MAP36, tag 1) also fails with Helion 

 

Thanks for detailing all the issues. As for anything using the colormap/playpal lump, Helion doesn't index light levels using it. Textures are built using the first playpal  and light levels are calculated off it as a base (similar to true color rendering in Odamex). This is probably affecting the Boom colormap effects for transfer heights as well. Currently the best it can do is guess the intention of the overall color being applied and use that in the shader.

I know the friend flag has issues and wanted to start with that, but I didn't see anything in the decohack setting it?

[Doomy__Doom]

1 hour ago, hobomaster22 said:

I know the friend flag has issues and wanted to start with that, but I didn't see anything in the decohack setting it? 

Friend flag can be set from UDB when placing a thing in MBF21 config.

[hobomaster22]

7 minutes ago, Doomy__Doom said:

Friend flag can be set from UDB when placing a thing in MBF21 config. 

That would explain it, had no idea that existed.

[TruthInFiction]

So I just loaded up Helion for the first time in a while, and the new version has fixed the map name issue for Breach and other wads but the issue still persists for No End in Sight.  Does NEIS maybe use a method for renaming maps that isn't supported by Helion? 

[hobomaster22]

13 hours ago, TruthInFiction said:

So I just loaded up Helion for the first time in a while, and the new version has fixed the map name issue for Breach and other wads but the issue still persists for No End in Sight.  Does NEIS maybe use a method for renaming maps that isn't supported by Helion? 

Looks like it's using dehacked to replace the strings and there is no header on it that that is causing Helion problems. I'm working on wrapping up the next release and I have it fixed for 0.9.2.8.

[Maribo]

On 10/7/2023 at 11:10 AM, Maribo said:

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.

Retired my old laptop the other day for a new one with an i9-14900HX + RTX 4070 (Mobile) and decided to do this same simple benchmark (walking outside and looking at the massive sky pentagram, not playing the full map) just for fun. Comparison this time was getting keeled over to around 45-50 FPS on both 1080p and 1440p in DSDA-Doom v0.27.5 OpenGL, while Helion 0.9.2.7 was at 800+ FPS at 1080p and 500+ at 1440p. Wonderful port.

 

Also late, but big thanks again for the viewport fix!

[hobomaster22]

Helion 0.9.2.8
 

Spoiler

Fix for randomized blood states to offset using the hard-coded dooms state when using a dehacked file. This would cause modified blood states to render incorrect sprites.
Fix to not apply weapon offset to it's flash state.
Fix options text header when scrolling in the options menu.
Fix for dehacked frame parsing to support any word inside the parenthesis.
Fix for slide not clearing velocity on blocking line when using vanilla movement physics compat.
Fixed case where flat textures changing from to sky to non-sky would not correctly clear.
Fixed cases where sector movement would miss clearing flood filling.
Fixed get next lowest ceiling for sector movement incorrectly returning the current floor value when none is found.
Fixed friend flag to correctly look for enemies using count kill flag.
Fixed wind/push specials that were incorrectly ignoring when other sector effect flags were set.
Fixed to add max movement check for velocity. This would previously cause the player to move beyond 30 map units per tick on fast scrolling floors.
Added short when hitting a teleport to stop checking crossed special lines to match original doom behavior. Fixes twogers MAP04.
Added compatibility option for Doom 2 projectiles activating certain walk specials.
Fixed hitscan functions using zero damage as a test flag. Fixes twogers RNG generator things firing bullets with zero damage to activate lines.
Fixed mapinfo scroll speed to parse as decimal number.
Update flood filling to no longer ignore in a transfer heights sector.
Fixed small hud fonts to be fixed to the top instead of bottom.
Updated defaultmap from mapinfo to carry over music, titlepatch, partime, and sucktime.
Use Doom's original height for things with the spawn ceiling flag. Matches original behavior for things that are given the spawnceiling flag where their height is only 16.
Fixed stair builder issue with non-contiguous stair sectors and fixed save serialization and loading of active stair builds.
Fixed sector movement interpolation reset not working when a level is flagged to exit.
Fixed boom transfer sky specials rendering the sky backwards.
Fixed dehacked mapping to correctly map BFGEXP to BFGExtra.
Fixed status bar not showing pain face when damage count is exactly one.
No longer gib things that have health to match original Doom behavior.
Updated check for determining a thing's sector to not include zero in dot product checks.
Fixed issue where dehacked files were being skipped when not containing a valid header. Fixes map names for NEIS.
Fixed archvile fire to not be interpolated. Fixes archvile not being visible in certain cases especially when moving towards the archvile.
Added check for closet monsters to use their default movement speed if they failed to move. Fixes cases where they are in tight areas and will not trigger a teleport line.

 

Implemented check for OpenGL 4.4 to force using GL_MAP_PERSISTENT_BIT in glMapBufferRange. NVidia cards would automatically pin the memory. Certain AMD cards (Vega series) would not automatically do this causing FPS drops because of memory synchronization. Will fall back to OpenGL 3.3 if not supported by the GPU.
Optimized sound traversal for noise alert to prevent frame drops when firing.
Implement transfer heights logic for wind/push sectors to match boom behavior.
Implemented friendly flag in map things to be set.
Implemented the fuzz amount to be configurable. The fuzz effect is now uniform across screen resolutions and is projected across all distance from the camera. Previously it would appear more blocky as the camera is further away from the fuzz thing.
Implemented MUSINFO and music changes in maps.

 

[S3M_XM]

Last night, when I was playing on Nugget Doom at the time as I've gotten to MAP23 in Doom 2 in City Only, I had to turn to the lowest resolution setting and I wasn't able to keep it at 144 fps, mainly looking at the direction at the main area.

I've decided to give it a try as a performance test with Helion today and I'm able to keep it at constant 144 fps at 1080 on a Nvidia 3060 Laptop from just looking from the starting point at the main area.

As I agree with Maribo, it's a really wonderful port.

[CacoKnight]

Is there a way to disable the player bobbing (not the weapon)? Also where can I find the full console command list? Did a quick search on the GitHub page. Thank you.

 

edit:

I really like the automap colors, is there a palette I can check to copy it on other ports?

 

edit2:

Been eyeing the port for "a while" now and finally decided to set it all up, I'm really liking it and I added it here (kind of temporary description). Thank you for the effort in creating and optimizing it guys.

Edited April 8 by CacoKnight

[hobomaster22]

18 hours ago, S3M_XM said:

Last night, when I was playing on Nugget Doom at the time as I've gotten to MAP23 in Doom 2 in City Only, I had to turn to the lowest resolution setting and I wasn't able to keep it at 144 fps, mainly looking at the direction at the main area.

I've decided to give it a try as a performance test with Helion today and I'm able to keep it at constant 144 fps at 1080 on a Nvidia 3060 Laptop from just looking from the starting point at the main area.

As I agree with Maribo, it's a really wonderful port.

Thanks! Another thing to keep in mind is if you have a G-Sync (and probably Freesync) capable monitor turning off VSync and capping the framerate to something like 200fps will make it more feel more responsive. I have a G-Sync capable monitor disabling VSync has a noticeable difference for me in the display latency.

[hobomaster22]

2 hours ago, CacoKnight said:

Is there a way to disable the player bobbing (not the weapon)? Also where can I find the full console command list? Did a quick search on the GitHub page. Thank you.

 

edit:

I really like the automap colors, is there a palette I can check to copy it on other ports?

 

edit2:

Been eyeing the port for "a while" now and finally decided to set it all up, I'm really liking it and I added it here (kind of temporary description). Thank you for the effort in creating and optimizing it guys.

There is no separate control for player bobbing vs the weapon. I didn't know of any ports that separate these. What are some ports that currently do this and what do they call the variables? I could add it int he next release. Typing commands in the console will dump all available commands.

The automap colors are defined here. They are defined for OpenGL but multiplying the numbers by 255 would give you the 8-bit RGB values.

[CacoKnight]

12 minutes ago, hobomaster22 said:

There is no separate control for player bobbing vs the weapon. I didn't know of any ports that separate these. What are some ports that currently do this and what do they call the variables?

Tested a little bit more with DSDA, there is bobbing on the player too but it's much less, I was confused when I read this msg because I thought there was actually none for the player on other ports, maybe an option to lower it? Not sure how the other ports do it sorry.

 

Thank you for the rest, awesome!

Edited April 8 by CacoKnight

[Shepardus]

18 minutes ago, hobomaster22 said:

There is no separate control for player bobbing vs the weapon. I didn't know of any ports that separate these. What are some ports that currently do this and what do they call the variables? I could add it int he next release. Typing commands in the console will dump all available commands.

dsda-doom has separate binary toggles for the player and weapon bobbing (dsda_viewbob and dsda_weaponbob), Woof allows adjusting the amount for each in increments of 25% (view_bobbing_pct, weapon_bobbing_pct), and Nugget Doom is the same except it allows any number 0-100 instead of 25% increments.

[mmx]

Would Helion be suited for a TC mod that replaces the weapon sprites with high resolution ones, or even 3D models? What about the enemies?