Helion - C# (0.9.2.6 1/1/23 - Goodbye BSP tree rendering)

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.

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.

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.

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?

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. 

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.

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.

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.

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/....

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. 

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.

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.

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.

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!.

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.

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.

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.

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

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.

Helion 0.9.2.6
 

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.

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

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.

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.

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.

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.

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.

Yes, I'm running Linux Mint 21.