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

[Shepardus]

36 minutes ago, TheSwordman said:

Eviternity map30 doesn play any music. Console says "Unable to play music, cannot convert from mus to midi"

Eviternity MAP30 uses OGG music, which Helion doesn't support.

[hobomaster22]

30 minutes ago, TheSwordman said:

Eviternity map30 doesn play any music. Console says "Unable to play music, cannot convert from mus to midi"

It's an ogg file. Helion currently only supports mid/mus formats.

[Grieferus]

13 minutes ago, hobomaster22 said:

It's out of scope. Helion depends on hardware rendering. Software rendering requires the BSP.

Thank you for clearing things up.

[camper]

18 hours ago, hobomaster22 said:

You should use DECOHack so you can write decorate like code that will be translated into dehacked.

Thanks for the link

I looked at assets\actors\doom\weapons , there is Skulltag/Zandronum compatibility actor Grenade. But the functions A_FireGrenade or A_FireSTGrenade. Are they not available yet?

[hobomaster22]

3 hours ago, camper said:

Thanks for the link

I looked at assets\actors\doom\weapons , there is Skulltag/Zandronum compatibility actor Grenade. But the functions A_FireGrenade or A_FireSTGrenade. Are they not available yet?

They are not. The base decorate is just a dump of base ZDoom functionality. Helion only supports the functions underneath that are required to support vanilla and boom features. 

[PhoenixBlade]

Gave this a shot and am liking what it does. Having an Ironwail-equivalent for Doom, while ensuring a clean and readable codebase, is very admirable. Far more preferable to the travesty that GZDoom has become. Never let yourself go full Bloat, remember that.

 

On the Linux side, the binary works well with the ZDL launcher, but in the future I hope to see an Appimage executable as well. That is my favourite format just for how easy it is to use and transfer around with little-to-no headaches. I also hope to see more accessibility options, like controlling the view bob, flashing lights, and even blood color settings like Doom Retro has, and a built-in mod launcher akin to Ironwail. On a slightly more unrelated note, I was also wondering if you've given any thought to the SDL platform?. It's an open standard and used for a lot of cross-platform game development, including Windows, Mac and Linux. I can't help but notice a lot of Windows DLLs and I feel that it may hurt the long-term portability factor of this project. Will Windows still be around 20+ years from now?, it's doubtful. DOS certainly wasn't in the 20+ years after Doom's original release.

Edited December 25, 2023 by PhoenixBlade

[camper]

14 hours ago, hobomaster22 said:

They are not. The base decorate is just a dump of base ZDoom functionality. Helion only supports the functions underneath that are required to support vanilla and boom features. 

My knowledge of DEH was difficult. But it's so simple that people don't write it in help pages. But I should have guessed. I experimented with some mods and found that the grenade launcher below link works well in Helion.

 

Spoiler

 

 

[hobomaster22]

3 hours ago, PhoenixBlade said:

Gave this a shot and am liking what it does. Having an Ironwail-equivalent for Doom, while ensuring a clean and readable codebase, is very admirable. Far more preferable to the travesty that GZDoom has become. Never let yourself go full Bloat, remember that.

 

On the Linux side, the binary works well with the ZDL launcher, but in the future I hope to see an Appimage executable as well. That is my favourite format just for how easy it is to use and transfer around with little-to-no headaches. I also hope to see more accessibility options, like controlling the view bob, flashing lights, and even blood color settings like Doom Retro has, and a built-in mod launcher akin to Ironwail. On a slightly more unrelated note, I was also wondering if you've given any thought to the SDL platform?. It's an open standard and used for a lot of cross-platform game development, including Windows, Mac and Linux. I can't help but notice a lot of Windows DLLs and I feel that it may hurt the long-term portability factor of this project. Will Windows still be around 20+ years from now?, it's doubtful. DOS certainly wasn't in the 20+ years after Doom's original release.

 

You can already control the viewbob (Options -> HUD -> movebob), not sure what flashing lights would be.

As for the DLLs, switching to SDL wouldn't solve any of that. Helion uses .NET and what you are seeing is the DLLs for .NET. They are not traditional Windows DLLs but .NET DLLs that contain the platform independent IL code.

[Master O]

9 hours ago, PhoenixBlade said:

Gave this a shot and am liking what it does. Having an Ironwail-equivalent for Doom, while ensuring a clean and readable codebase, is very admirable. Far more preferable to the travesty that GZDoom has become. Never let yourself go full Bloat, remember that.

 

On the Linux side, the binary works well with the ZDL launcher, but in the future I hope to see an Appimage executable as well. That is my favourite format just for how easy it is to use and transfer around with little-to-no headaches. I also hope to see more accessibility options, like controlling the view bob, flashing lights, and even blood color settings like Doom Retro has, and a built-in mod launcher akin to Ironwail. On a slightly more unrelated note, I was also wondering if you've given any thought to the SDL platform?. It's an open standard and used for a lot of cross-platform game development, including Windows, Mac and Linux. I can't help but notice a lot of Windows DLLs and I feel that it may hurt the long-term portability factor of this project. Will Windows still be around 20+ years from now?, it's doubtful. DOS certainly wasn't in the 20+ years after Doom's original release.

 

Well technically, there's https://www.freedos.org/ and for games, https://dosbox-staging.github.io/releases/release-notes/0.81.0-rc/....

Edited December 25, 2023 by Master O

[PhoenixBlade]

5 hours ago, hobomaster22 said:

 

You can already control the viewbob (Options -> HUD -> movebob), not sure what flashing lights would be.

As for the DLLs, switching to SDL wouldn't solve any of that. Helion uses .NET and what you are seeing is the DLLs for .NET. They are not traditional Windows DLLs but .NET DLLs that contain the platform independent IL code.

Ah I didn't see that viewbob option, thank you for specifying where it was. I really can't play with the stock settings as it causes me motion sickness, 0.60 is where it's at!. What I mean by flashing lights though is the effect that happens when you pick up an item, or when the radiation suit is expiring. That effect. It's not a health concern for me, I don't suffer from epilepsy, but it may get a little much after a while and that's why I recommend including it in a future update. Some just hate flashing lights of any kind.

 

As for the DLLs, while it's fine that the engine uses the .NET framework, that is a proprietary standard that's owned by Microsoft. They have full legal control over it, and it's largely a Windows thing. SDL is a free, open standard that will stand the test of time far better. Microsoft could decide to phase out their .NET stuff at any time, and any devs who use it will be forced to "upgrade" to whatever standard MS provides themselves. 

[hobomaster22]

27 minutes ago, PhoenixBlade said:

Ah I didn't see that viewbob option, thank you for specifying where it was. I really can't play with the stock settings as it causes me motion sickness, 0.60 is where it's at!. What I mean by flashing lights though is the effect that happens when you pick up an item, or when the radiation suit is expiring. That effect. It's not a health concern for me, I don't suffer from epilepsy, but it may get a little much after a while and that's why I recommend including it in a future update. Some just hate flashing lights of any kind.

 

As for the DLLs, while it's fine that the engine uses the .NET framework, that is a proprietary standard that's owned by Microsoft. They have full legal control over it, and it's largely a Windows thing. SDL is a free, open standard that will stand the test of time far better. Microsoft could decide to phase out their .NET stuff at any time, and any devs who use it will be forced to "upgrade" to whatever standard MS provides themselves. 

I think you are confusing two different things. We are using C# and the rendering library we are using is OpenTK which is a wrapper for GLFW. Changing the rendering library to SDL wouldn't change the fact that we are using .NET, so you would still see all those spooky DLLs. We are also not using .NET Framework, which is the old Windows specific framework, but what is just called .NET now. Since 2016 .NET has been cross platform and completely open source.

Edited December 25, 2023 by hobomaster22

[PhoenixBlade]

37 minutes ago, hobomaster22 said:

I think you are confusing two different things. We are using C# and the rendering library we are using is OpenTK which is a wrapper for GLFW. Changing the rendering library to SDL wouldn't change the fact that we are using .NET, so you would still see all those spooky DLLs. We are also not using .NET Framework, which is the old Windows specific framework, but what is just called .NET now. Since 2016 .NET has been cross platform and completely open source.

I see. Thank you for clarifying.

[hobomaster22]

4 minutes ago, PhoenixBlade said:

I see. Thank you for clarifying.

No problem. I hope it didn’t come across as harsh or negative. Reading again I think it may have but that wasn’t my intention.

[PhoenixBlade]

1 hour ago, hobomaster22 said:

No problem. I hope it didn’t come across as harsh or negative. Reading again I think it may have but that wasn’t my intention.

No worries!.

[TruthInFiction]

I finally got around to trying out Helion's newest release and I've got to say the key binding functionality has been improved a lot, although I think some of the terminology in there could use a bit of work.  Instead of automap "increase" and "decrease" I think you would be better off with automap "zoom in" and "zoom out" for clarity purposes.  I'm not really sure what to think of "hud increase" and "hud decrease", because while I can see that those are the intended functions of the keys, they can be confusing when compared to how other ports handle it.  GZDoom for instance labels them as "decrease screen size" and "increase screen size" respectively.  Maybe this is just something users need to get used to when playing with Helion as opposed to another port, but going from a port that says "decrease screen size" to another that says "increase hud" for changing the status bar size in the same direction can definitely throw people off.

 

One thing that has been bugging me for a while, and that I'm surprised nobody else has brought up is how Helion handles skyboxes.  I wasn't sure of this at first but having loaded up the same map in GZDoom and Helion there is a clear difference.  Here is what Helion looks like:

 

 

 

 

Now here is GZDoom:

 

 

Now here is GZDoom with software rendering and skyboxes set to stretched:

 

 

You don't need to load custom maps for this, as you can see the difference just by loading up vanilla Doom maps in Helion and GZDoom.  It doesn't look exactly the same as GZDoom's stretched skies so maybe that isn't what's happening, but that's not really my wheel house XD.

[hobomaster22]

13 hours ago, TruthInFiction said:

I finally got around to trying out Helion's newest release and I've got to say the key binding functionality has been improved a lot, although I think some of the terminology in there could use a bit of work.  Instead of automap "increase" and "decrease" I think you would be better off with automap "zoom in" and "zoom out" for clarity purposes.  I'm not really sure what to think of "hud increase" and "hud decrease", because while I can see that those are the intended functions of the keys, they can be confusing when compared to how other ports handle it.  GZDoom for instance labels them as "decrease screen size" and "increase screen size" respectively.  Maybe this is just something users need to get used to when playing with Helion as opposed to another port, but going from a port that says "decrease screen size" to another that says "increase hud" for changing the status bar size in the same direction can definitely throw people off. 

I can rename the automap to zoom in/out. The screen size one is interesting since it's kind of a legacy feature from Doom where it's main was to change the screen size. Continuing to press minus would make the view smaller and draw that marble texture with a tiny view. Largely pointless today, especially with only hardware rendering. ZDoom just piled the minimal HUD onto this naming. I just named it what I thought makes more sense, the intention nowadays is to change the HUD display and not really the screen size.

As for the skies it looks like I did make an issue for it and we haven't got around to fixing it.

[TruthInFiction]

12 hours ago, hobomaster22 said:

I can rename the automap to zoom in/out. The screen size one is interesting since it's kind of a legacy feature from Doom where it's main was to change the screen size. Continuing to press minus would make the view smaller and draw that marble texture with a tiny view. Largely pointless today, especially with only hardware rendering. ZDoom just piled the minimal HUD onto this naming. I just named it what I thought makes more sense, the intention nowadays is to change the HUD display and not really the screen size.

 

Fair enough.  Just because it has always been named one way doesn't mean it needs to stay that way forever.  I do hope that if and when newer modernized ports come out they begin adopting the same naming convention because that will go a long way with helping people get used to it, and it probably is better that way since the main purpose of that functionality has changed.

 

12 hours ago, hobomaster22 said:

As for the skies it looks like I did make an issue for it and we haven't got around to fixing it. 

 

Ah, that's good to hear.  I'll look forward to seeing that get rolled out, then.

[camper]

Regarding the question about skyboxes, will there be support for cubic skyboxes (like in Quake 2)?

[hobomaster22]

On 12/29/2023 at 7:48 PM, TruthInFiction said:

 

Fair enough.  Just because it has always been named one way doesn't mean it needs to stay that way forever.  I do hope that if and when newer modernized ports come out they begin adopting the same naming convention because that will go a long way with helping people get used to it, and it probably is better that way since the main purpose of that functionality has changed.

 

 

Ah, that's good to hear.  I'll look forward to seeing that get rolled out, then.

I have a way that should function well for varying sky sizes.

 

On 12/31/2023 at 8:35 AM, camper said:

Regarding the question about skyboxes, will there be support for cubic skyboxes (like in Quake 2)?

Skyboxes are not a priority, but something that will likely be added down the line. Would be nice for things like Eviternity 2 that provide higher resolution skies for GZDoom.

[hobomaster22]

Helion 0.9.2.6
 

Spoiler

Implemented fade effect for loading screen.
Implemented scaling for skies.
Added option to render status bar without background and face graphic.
Added ogg/mp3 support (Currently Windows only). Cleaned up music creation warnings and errors.
Updated minimal hud to use Doom sprite scaling and fixed alignment for health/armor.
Updated weapon drawing to support interpolation on the viewport dimensions instead of being stuck to 320x200.
Added invert mouse Y option.
Performance improvements for map loading times. Includes reusing the previous BSP tree and sky textures.
Added option to disable caching all sprites. Sprite caching prevents stuttering when encountering unseen sprite rotations. This caused issues with Eviternity 2 on 4GB systems because of the very large and numerous sprite rotations for the final boss consuming all the systems memory even if the map is not loaded.
Areamap/map cheats from player are applied to chasecam.
Fixed uninitialized shader value for flood filling that would cause flood filling to render black. Caused when firing gun or manually setting extralight.
Fixed NoGravity to not apply friction to objects.
Added check for weapon sound to use hard coded vanilla saw index if dehacked is being used. Fixes Eviternity 2 Perforator playing saw sound.
Added check to match boom functionality that continually checks to change weapons in G_BuildTickCmd. Fixes Eviterinity 2 Perforator not changing when out of ammo.
Do not parse GameInfo weapon slots if parsing dehacked. Fixes Eviternity 2 Perforator weapon selection.
Steam paths fixed for Linux and includes other shared Linux paths. PR: #554
Fixed options menu resetting position when scrolling keyboard up/down.
Fixed visual scrolling to apply for floor/ceiling when there is more than one special.
Fixed crash that is caused when an object is disposed through modified dehacked frames. Fixes Eviternity 2 MAP36 shattering glass.
Fixed A_LineEffect where the first called line special would be called for every subsequent call. Fixes Eviternity 2 MAP30.
Allow monsters to fall off ledges from scrolling and push specials. Fixes Eviterny 2 MAP32.
Fixed MBF21 kill effects to be transferred with trigger specials. Fixes Eviternity 2 MAP32.
Match magnitude calculation from boom for push specials.
Force decimal parsing to use period for separator and replace commas with period to conform configurations to en-US format.
Fixed broken commands being shown in options menu.
Options menu will show custom user commands and fixed some missing built in commands not showing.
Fixed menu shortcuts eating key presses when using keybinding menu.
Cleaned up automap key binding names in options menu.
Fixed dangling references causes memory not to be freed when loading new maps.

Happy new year! There was a lot more in this release than I would have guessed until I started going through the commits since the last release. For the ogg/mp3 support I didn't realize it wouldn't function on Linux until my final testing today. It was unfortunately not obvious. NAudio existed before Microsoft transitioned to .NET means NAudio has a lot of reliance on WinMM for more sophisticated audio playback. I was excited about this feature but unfortunately I can't have it for both operating systems right now.

[TruthInFiction]

Looking great!  Just an FYI, screenshots are listed in the keybinding menu twice, once with the print screen button and again with f12.

[hobomaster22]

24 minutes ago, TruthInFiction said:

Looking great!  Just an FYI, screenshots are listed in the keybinding menu twice, once with the print screen button and again with f12. 

Thanks for letting me know. It looks like it copied my config on the publish for the win-x64 and it shouldn't be there. I have f12 in my custom config for when I use my laptop keyboard that doesn't have the print screen button. I removed the config from the release on GitHub.

[TruthInFiction]

Are there methods of pushing custom map names to the automap that Helion doesn't support?  I've noticed that it works for some maps but not others.  Examples where it doesn't work would be No End in Sight, Breach (by Viggles) and Don't Turn Your Back on the City.

[hobomaster22]

22 hours ago, TruthInFiction said:

Are there methods of pushing custom map names to the automap that Helion doesn't support?  I've noticed that it works for some maps but not others.  Examples where it doesn't work would be No End in Sight, Breach (by Viggles) and Don't Turn Your Back on the City. 

Don't Turn Your Back on the City is odd. It's using Eternity's EMAPINFO that Helion doesn't support. Apparently GZDoom will parse it.

I can see Breach shows MAP01: breach and No End in Sight is showing the custom map names as well, for example E1M1: Slime Trails so maybe I am missing something here.

[TruthInFiction]

2 hours ago, hobomaster22 said:

Don't Turn Your Back on the City is odd. It's using Eternity's EMAPINFO that Helion doesn't support. Apparently GZDoom will parse it.

I can see Breach shows MAP01: breach and No End in Sight is showing the custom map names as well, for example E1M1: Slime Trails so maybe I am missing something here.

 

Here's what I'm seeing in Breach:

 

 

And here's No End in Sight:

 

 

The loading screen is also showing the default map names as opposed to the custom names, although I'm having a hard time getting a screenshot of that.  I find it odd because for instance Valiant and Abscission both work fine.

Edited January 15 by TruthInFiction

[hobomaster22]

51 minutes ago, TruthInFiction said:

The loading screen is also showing the default map names as opposed to the custom names, although I'm having a hard time getting a screenshot of that.  I find it odd because for instance Valiant and Abscission both work fine.

Hmm this is strange. Both of those wads work for me and I tested with 0.9.2.5 and 0.9.2.6. Are you running on Linux? It shouldn't make a difference but if that's the case I may need to test that build specifically.

[TruthInFiction]

Yes, I'm running Linux Mint 21.

[hobomaster22]

Helion 0.9.2.7
 

Spoiler

Implemented fixed point underflow emulation in physics to support mikoportals and KDiKDiZD.
Implemented compatibility for mid texture hacks that will automatically be applied to emulate the transparent floor/ceiling effects in KDiKDiZD.
Implemented detection for vanilla self-referencing sector hacks.
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.
Support Boom colormaps for transfer heights.
Implemented Boom door light tag.
Implemented fuzz effect on player weapon sprite.
Implemented compatibility flag for vanilla movement physics. Emulates preserving momentum when running into other things.
Automatically apply compatibility flags from complvl lump.
Viewport is correctly pushed up with full screen HUD.
HUD now draws independently from virtual dimensions. The world will be draw at the virtual resolution and the HUD will be drawn at the window resolution.
Sector movement sounds are no longer played from self-referencing sources.

Fixes for intermission drawing offsets.
Fixed large HUD number rendering to be fixed width to match original position rendering.
Fixed crash that can be caused by single line comment characters inside quoted strings.
Fixed cluster text to be split by newlines in legacy mapinfo.
Fixed floor/ceiling movement specials when there is no adjacent sector to use default min/max values. Fixes Congestion 1024 MAP02 exit door.
Fixed fake contrast not being applied on the shader.
Fixed save game issue where on ground was not being serialized.
Fixed map info map names being overwritten.
Fixed randomize not being set if missile and a dehacked patch is applied.
Added skullfly velocity check in movement code to stop skullfly. Fixes KDiKDiZD bruiser fire.
Fixed A_SkullAttack to correctly add 8 to the start height and set velocity to the center of the target from it's bottom to match the original functionality.
Fixed A_PainShootSkull to properly ignore parent collision when dehacked has changed solid flags.
Added check for warptrans. Fixes KDiKDiZD episode start map.
Updated slide movement code to not include 0 and 1 hit times to match Doom's original side behavior. Fixes KDiKDiZD voodoo closets.
Fixed line id assignment for islands/monster closet detection.
Fixed monster closet assignment for loading saves/same map.
Fixed transfer heights rendering issue with transparent lines that were getting stuck in the cache that could cause them not to render.
Fixed idbehold strength.
Updated episode selection menu to support larger number of episodes.
Updated options screen title to use font instead of M_OPTIONS graphic as some custom wads clear the graphic.
Fixed UMAPINFO parsing to handle new episodes that do not exist in the IWAD.
Fixed dehacked lookups for BSPI_RUNx.
Fixed A_NoBlocking action being called on Command Keen death frame when it shouldn't.
Fixed UMAPINFO parsing to optionally read episode key.
Fixed UMAPINFO so that maps that do not exist in the IWAD are correctly added.
Fixed fast speed for demon and correctly apply fast speed to projectiles for Nightmare difficulty.
Fixed incorrect total time being written to levelstat.
Fixed shader issue that prevented compilation on Intel cards.
Fixed sky rendering to take configurable FOV into account.
Fixed gun sprite to correctly use transfer heights sector for light level.
Fixed shoot traversal to only check shootable.
Allow missiles to collide with things that only have the shootable flag.

Fixed issue in zdbsp where the splitter was creating vertices outside of the blockmap bounds causing an overflow crash.
Fixed zdbsp to correctly rebuild reject when removing unused sectors and use the new reject lump in Helion.

A lot of new features. Most notably is the work I have done to support KDiKDiZD. The mikoportal voodoo closets are functional as well as the self-referencing 3D bridge tricks, which will work across all maps like Hell Revealed 2. Also specific for KDiKDiZD, is emulation for the mid texture tricks to make floors look like they are transparent. The complvl lump is read and will automatically apply all the compat options that make sense for Helion. This includes a new flag for vanilla movement physics that preserves velocity when hitting other things that is required for KDiKDiZD to function.

Here is a video demonstrating KDiKDiZD functioning with the new rendering effects.
 

This release also includes a very experimental flood fill all flats option. This is using the same method to emulate the mid texture features built for KDiKDiZD. It needs a a lot more work but is a very promising start to solving one of the biggest annoyances plaguing hardware rendering ports, sprite clipping.
 

 

[Bauul]

35 minutes ago, hobomaster22 said:

a very promising start to solving one of the biggest annoyances plaguing hardware rendering ports, sprite clipping.

 

This is pretty huge!  I don't believe any other hardware renderer has managed to implement a proper fix for this, so this would be an amazing feather in Helion's cap if you can get it fully implemented.

[Darkcrafter07]

Holy fucking shit, that flood fill in a hardware renderer? Everyone look and repeat after Helion hehe.