Jump to content

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


Recommended Posts

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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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?

Share this post


Link to post
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. 

Share this post


Link to post

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 by PhoenixBlade

Share this post


Link to post
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

 

 

Share this post


Link to post
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.

Share this post


Link to post
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 by Master O

Share this post


Link to post
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. 

Share this post


Link to post
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 by hobomaster22

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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!.

Share this post


Link to post

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:

 

 

 

helion_20231228_01_59_07_1001.png.d4efa74868fb79dcf7c68172c6123817.png

 

Now here is GZDoom:

 

Screenshot_Doom_20231228_135653.png.74329ba660b79ac1d9a8290254a0c664.png

 

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

 

Screenshot_Doom_20231228_145817.png.f2ac9295724cd9cd70f140a7887a6413.png

 

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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

1872579426_screenshot_HelionDebug_neis.png.770d187b08614ea9ae983b8df4dcbd4c.png

 

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.

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post
  • 2 weeks later...

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.

Share this post


Link to post
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.

Share this post


Link to post
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:

 

helion_20240115_06_39_49_4908.png.086885ec361091235121e250a00a8a21.png

 

And here's No End in Sight:

 

helion_20240115_06_46_49_7826.png.3bcd023e8788c2871970d8af0887daa4.png

 

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 by TruthInFiction

Share this post


Link to post
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.

Share this post


Link to post
  • 4 weeks later...
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.

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