Helion - C# (0.9.5.0 11/24 - Goodbye BSP tree rendering)

Just now, Master O said:

 

Refer to the original post.

Yes, that's what it says. But are there plans beyond this?

1 hour ago, camper said:

Yes, that's what it says. But are there plans beyond this?

You're gonna have to ask @hobomaster22 himself, since it's his port. You can also private message him and ask as well.

So I managed to spend some time playing around on that tablet with Zorin OS and I noticed that I get the following message in the application logs whenever Helion locks up: 

Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x1e00009

The hex address is not always the same when this shows up, and it seems to be related to loading maps.  Sometimes I can make it into E1M1 with no problems, but then when I complete the map it will instead lock up at the intermission screen when it should be loading E1M2.  One time when I loaded the game up, I used the map command in the console and was able to quickly and successfully load arbitrary maps using this method.

On a side note, you may want to update the op to reflect that Helion is now available for Linux since it still sates that Helion is Windows only.

Good news, this new source port in C#, and the architecture seems excellent to me from what I have seen, there is managed-doom which I had the opportunity to tinker with a little. Looking forward to taking a closer look

EDIT : my bad, I hadn't seen that its first version was from a year ago, definitely, so many things that you don't see if you don't look a little

3 hours ago, camper said:

Is Helion intended only as a port of Doom (and other existing games: heretic, hexen.. etc.) or as a new 2.5D game engine?

Currently it is only a Doom port and has no plans for supporting the others. There is a lot to do, and I personally do not have interest in the other games as I only had Doom itself when I was young. This could change in the future, but for now Helion will be Doom only.

33 minutes ago, TruthInFiction said:

So I managed to spend some time playing around on that tablet with Zorin OS and I noticed that I get the following message in the application logs whenever Helion locks up: 

 

Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x1e00009

 

The hex address is not always the same when this shows up, and it seems to be related to loading maps.  Sometimes I can make it into E1M1 with no problems, but then when I complete the map it will instead lock up at the intermission screen when it should be loading E1M2.  One time when I loaded the game up, I used the map command in the console and was able to quickly and successfully load arbitrary maps using this method.

 

On a side note, you may want to update the op to reflect that Helion is now available for Linux since it still sates that Helion is Windows only.

Thanks for checking into this. I will have to see if anything comes up. The next release for Helion actually has some big changes for map loading so that it can display loading screens. I will try to create a new Linux build tomorrow if you would like to try it. If the problem still persists then I can investigate further.

1 hour ago, hobomaster22 said:

Thanks for checking into this. I will have to see if anything comes up. The next release for Helion actually has some big changes for map loading so that it can display loading screens. I will try to create a new Linux build tomorrow if you would like to try it. If the problem still persists then I can investigate further.

Are we gonna see more speed increases?

8 hours ago, hobomaster22 said:

Currently it is only a Doom port and has no plans for supporting the others. There is a lot to do, and I personally do not have interest in the other games as I only had Doom itself when I was young. This could change in the future, but for now Helion will be Doom only.

Best to focus on Doom for sure as Helion is a new take on a source port to begin with.

I was the same btw never played Heretic or Hexen apart from trying out shareware versions really briefly and they just didn't click.

Think I was mostly into point-and-click adventure games and flight sims around then, until Duke3D happened (and then Quake, Unreal and Half-Life etc) and made shooters my fav genre again.

11 hours ago, hobomaster22 said:

Currently it is only a Doom port and has no plans for supporting the others. There is a lot to do, and I personally do not have interest in the other games as I only had Doom itself when I was young. This could change in the future, but for now Helion will be Doom only.

Thanks for the answer.

18 hours ago, Master O said:

 

Are we gonna see more speed increases?

Sorry, not in the next release. More bug fixes and features :)

21 hours ago, hobomaster22 said:

Thanks for checking into this. I will have to see if anything comes up. The next release for Helion actually has some big changes for map loading so that it can display loading screens. I will try to create a new Linux build tomorrow if you would like to try it. If the problem still persists then I can investigate further.

I'll be willing to give it a try whenever you make it available.

Boy am I glad dotnet is on Linux now. I mean, we did have Mono, but that probably wouldn't have made cross compilation as easy. Only thing it gets in the way of now is using this as a base for a console port. ;p (slaughter maps on wii anyone?)
 

Any chance we could see compatibility with voxel doom or the original smoothdoom? The dsdhacked version of smoothdoom is fantastic but it doesn't have all the configuration options the original does.

I've noticed another oddity.  For whatever reason, Helion seems to double the amount of ammo you get from enemy drops regardless of difficulty level whenever you load a megawad.  It doesn't seem to happen on individual levels, as I tried loading up Romero's E1M4b and E1M8b and this didn't happen for either one individually or when they were loaded together, and also doesn't happen if you don't load any custom maps.  The megawads I tried this with were No End in Sight, Sigil, Breach, Abscission and Return to Hadron.

On 11/19/2023 at 6:46 PM, Jovian D. Ragon said:

Boy am I glad dotnet is on Linux now. I mean, we did have Mono, but that probably wouldn't have made cross compilation as easy. Only thing it gets in the way of now is using this as a base for a console port. ;p (slaughter maps on wii anyone?)
 

Any chance we could see compatibility with voxel doom or the original smoothdoom? The dsdhacked version of smoothdoom is fantastic but it doesn't have all the configuration options the original does.

The original smoothdoom being for GZDoom would require a lot of investment in GZDoom features that we do not have any intention at implementing currently. The focus is on everything through MBF21.

Supporting Voxels is certainly something Helion will do in the future.

13 hours ago, TruthInFiction said:

I've noticed another oddity.  For whatever reason, Helion seems to double the amount of ammo you get from enemy drops regardless of difficulty level whenever you load a megawad.  It doesn't seem to happen on individual levels, as I tried loading up Romero's E1M4b and E1M8b and this didn't happen for either one individually or when they were loaded together, and also doesn't happen if you don't load any custom maps.  The megawads I tried this with were No End in Sight, Sigil, Breach, Abscission and Return to Hadron.

Thanks, I see what the problem is. If a wad has a dehacked patch then Helion overwrites the flags to support dehacked pickups since Doom based them on sprite. This doesn't carry over the dropped flag being set resulting in twice the ammo being picked up. Will be fixed for the next release.

Another weird edge case bug report: Helion appears to handle transfer of secret property wrong (as in different from Doom/Boom). A secret sector can be turned "on" and "off" repeatedly by transfer lines and re-tagged for counting purposes (even in dos doom executable with vanilla transfer properties, and certainly in dos boom exe).

I've recently made a map that relies on this silly behavior and only the "real" secret (in a long voodoo closet to the north of play area) can be tagged in Helion.

1 hour ago, Doomy__Doom said:

Another weird edge case bug report: Helion appears to handle transfer of secret property wrong (as in different from Doom/Boom). A secret sector can be turned "on" and "off" repeatedly by transfer lines and re-tagged for counting purposes (even in dos doom executable with vanilla transfer properties, and certainly in dos boom exe). 

 

I've recently made a map that relies on this silly behavior and only the "real" secret (in a long voodoo closet to the north of play area) can be tagged in Helion. 

Helion doesn't handle it at all. I see why and will have it fixed soon. Thanks for reporting! I also didn't know it worked with secrets so I learned something today :)

Would be nice if GZ could get even close to this performance. As someone running a 360hz monitor, soon to be a 540hz and top end hardware, it would be nice to play my Doom mods with the frames I should be getting with the hardware I have.

Unfortunately all the mods I've been working on and play all rely on GZ/Zscript. 

19 hours ago, Yonko said:

Would be nice if GZ could get even close to this performance. As someone running a 360hz monitor, soon to be a 540hz and top end hardware, it would be nice to play my Doom mods with the frames I should be getting with the hardware I have.

Unfortunately all the mods I've been working on and play all rely on GZ/Zscript. 

Considering the utterly different design methodologies behind Helion versus GZDoom, I'll just make this pretty clear: That will be impossible. It's not like GZDoom is doing things in a dumber way and Helion's renderer is the obvious solution, it's that Helion is doing things in a different way that is basically incompatible with the original renderer.

Helion is an engine that is designed to run Doom games very fast by essentially doing all rendering fundamentally differently, but this absolutely crushes things that rely on that rendering (there's a reason that if you go back in this thread you see people documenting rendering tricks that are/were broken in Helion) until it is dealt with on a case-by-case basis. GZDoom is more of an engine that also just so happens to run Doom in addition to providing capabilities beyond and above it, but is going to still be obedient to the basic rendering concepts behind it, and as a result it should more or less work with most of the ways that mappers used and abused the engine with no extra work needed.

Basically, ultra-fast rendering at the cost of zero compatibility for anything it does not explicitly handle, or considerably more expansion potential at the cost of rendering things the old-fashioned way: Pick one.

30 minutes ago, Dark Pulse said:

Considering the utterly different design methodologies behind Helion versus GZDoom, I'll just make this pretty clear: That will be impossible. It's not like GZDoom is doing things in a dumber way and Helion's renderer is the obvious solution, it's that Helion is doing things in a different way that is basically incompatible with the original renderer.

 

Helion is an engine that is designed to run Doom games very fast by essentially doing all rendering fundamentally differently, but this absolutely crushes things that rely on that rendering (there's a reason that if you go back in this thread you see people documenting rendering tricks that are/were broken in Helion) until it is dealt with on a case-by-case basis. GZDoom is more of an engine that also just so happens to run Doom in addition to providing capabilities beyond and above it, but is going to still be obedient to the basic rendering concepts behind it, and as a result it should more or less work with most of the ways that mappers used and abused the engine with no extra work needed. 

 

Basically, ultra-fast rendering at the cost of zero compatibility for anything it does not explicitly handle, or considerably more expansion potential at the cost of rendering things the old-fashioned way: Pick one. 

The rendering issues are more born of using hardware rendering, not so much that we are using a different rendering methodology. Rendering tricks from Doom's software rendering like self referencing sectors aren't the most trivial things to solve in hardware rendering. The worst offender is how Doom drew sprites on top of everything and didn't clip them. This goes against the most basic truth of hardware rendering Z-Buffer discards. Before GZDoom there was Doom Legacy which also didn't support any of these things at first (maybe not ever). It was common knowledge then that OpenGL ports wouldn't render these tricks. The same was probably true for early versions of GZDoom, but I don't recall exactly. In this period emulating the light banding fade was much more taxing on the GPU tech where as today it's basically free which is why all the OpenGL ports of the time did this bland sector approximation for lighting. GZDoom had to go through a lot of iteration and pain to get where it is today. While it seems silly that Helion did not or does not support all these (yet), we did start Helion from scratch instead of forking off of an existing code base so we didn't get any of these features.

On the flip side GZDoom has nearly two decades of development behind it with an insane feature set. IIRC it was around 2005 that I first started toying with GZDoom. I'm sure there is a lot of code that is dependent on using the BSP and to completely redo the renderer using a completely different methodology would be quite the extreme undertaking, which is probably still an understatement.

1 hour ago, hobomaster22 said:

The rendering issues are more born of using hardware rendering, not so much that we are using a different rendering methodology. Rendering tricks from Doom's software rendering like self referencing sectors aren't the most trivial things to solve in hardware rendering. The worst offender is how Doom drew sprites on top of everything and didn't clip them. This goes against the most basic truth of hardware rendering Z-Buffer discards. Before GZDoom there was Doom Legacy which also didn't support any of these things at first (maybe not ever). It was common knowledge then that OpenGL ports wouldn't render these tricks. The same was probably true for early versions of GZDoom, but I don't recall exactly. In this period emulating the light banding fade was much more taxing on the GPU tech where as today it's basically free which is why all the OpenGL ports of the time did this bland sector approximation for lighting. GZDoom had to go through a lot of iteration and pain to get where it is today. While it seems silly that Helion did not or does not support all these (yet), we did start Helion from scratch instead of forking off of an existing code base so we didn't get any of these features.

On the flip side GZDoom has nearly two decades of development behind it with an insane feature set. IIRC it was around 2005 that I first started toying with GZDoom. I'm sure there is a lot of code that is dependent on using the BSP and to completely redo the renderer using a completely different methodology would be quite the extreme undertaking, which is probably still an understatement.

Hmm, fair enough. I do remember some things being mentioned about how monster closets needed special handling and the like for certain effects, but I'm probably talking about it with incomplete information in some way.

But basically the gist I was trying to get to Yonko is that it's never going to be as simple as "Rip out Helion's renderer and slap it into GZDoom." The latter basically needs to handle a lot more stuff that is currently (and possibly permanently) beyond Helion's scope, and any sort of merging of the two would probably require some very significant modifications to code that might be difficult or even impossible due to fundamental assumptions that might not always be true or whatever.

Helion 0.9.2.4

Helion release ahead of Doom's 30th anniversary. New features include special marking, IWAD selection screen when no iwad is specified, and loading screens.

Will there be palette tonemap? Just curious.

44 minutes ago, Grieferus said:

Will there be palette tonemap? Just curious. 

Yes, Helion will support it eventually.

Good to hear!

2 hours ago, hobomaster22 said:

Helion 0.9.2.4

Helion release ahead of Doom's 30th anniversary. New features include special marking, IWAD selection screen when no iwad is specified, and loading screens.

 

 

Thanks for implementing the IWAD selection menu.  That's greatly appreciated.

It seems i cant rebind mouse wheel down to next weapon. even if the menu says its bound, mouse wheel down always goes to the previous weapon, same with mouse wheel up and next weapon. Also, with fov higher than 100, if you begin to turn when close to a wall, you can see through it, as you can see in the left side on the screen. Also, is there a way to make the automap stats font bigger?

10 hours ago, TheSwordman said:

It seems i cant rebind mouse wheel down to next weapon. even if the menu says its bound, mouse wheel down always goes to the previous weapon, same with mouse wheel up and next weapon. Also, with fov higher than 100, if you begin to turn when close to a wall, you can see through it, as you can see in the left side on the screen. Also, is there a way to make the automap stats font bigger? 

I will take a look today. I have some fixes I want to push out for Eviternity 2, hopefully they are easy I can get these patched.

@hobomaster22, barrels work well now, really good job! The chainsaw deals damage nicely too but it still doesn't pull you to the monsters, instead, some monsters like imps start to get pushed back as soon as you saw them. Seems like it works in the opposite direction?

Helion 0.9.2.5

Patch release to fix issues found in Eviternity 2 and the episode selection missing for Doom 2 when running Sigil 2. Was also able to fix the issue @TheSwordman reported for this one.