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

[nickxcom]

34 minutes ago, hobomaster22 said:

Thanks!

I checked out that map. This happens because the floor lowers below the surrounding floor and it's supposed to flood fill. Helion currently only supports flood filling that exists on map start. Some future work is required to get flood filling to be calculated at runtime.

No worries at all! Purely visual :)

[Madgunner]

I'll give this another spin in a few days. I finally got my other computer up and running, it's got a Quadro P400 card in it, by no means a top of the line card, but hopefully it can get decent fps. On the game I am programming I was receiving 130 fps on the computer with the integrated card in it, and I tested it on this rig and I'm now getting 230 fps (I could potentially get more with some optimization, but I don't feel like torturing myself with Unity's physics anymore at least until I get the alpha out). Definitely a much better fps for sure! Hopefully it'll be the same for Helion.

Edited January 30, 2023 by Madgunner

[Darkcrafter07]

There is a thing I noticed about Helion - the crosshair is a tad bit lower than in the other source ports forcing me to look upper than usual not to hit targets in legs. Could you please lift the crosshair a bit?

[hobomaster22]

7 hours ago, Darkcrafter07 said:

There is a thing I noticed about Helion - the crosshair is a tad bit lower than in the other source ports forcing me to look upper than usual not to hit targets in legs. Could you please lift the crosshair a bit?

I've compared the crosshair to GZDoom and dsda and it looks to be in the exact same position. Are you using the full sized hud or the minimal?

[Darkcrafter07]

1 hour ago, hobomaster22 said:

I've compared the crosshair to GZDoom and dsda and it looks to be in the exact same position. Are you using the full sized hud or the minimal?

Full size (vanilla).

Edited January 31, 2023 by Darkcrafter07

[hobomaster22]

6 minutes ago, Darkcrafter07 said:

Full size (vanilla).

I think what you are seeing is that Helion doesn't support pushing the entire viewport up. The crosshair is pointing at the correct location but the entire view isn't pushed up like it does in vanilla.

[nickxcom]

Came across another visual oddity if you aren't sick of me yet lol. In Jamal Jones, the monster replacements are off. All imps appear to be replaced with the green imp. In the other ports, there is a brown imp with a different sprite and a green imp with different attacks. In Helion, it appears there are all replaced with the green imp, at least visually.

[hobomaster22]

13 hours ago, nickxcom said:

Came across another visual oddity if you aren't sick of me yet lol. In Jamal Jones, the monster replacements are off. All imps appear to be replaced with the green imp. In the other ports, there is a brown imp with a different sprite and a green imp with different attacks. In Helion, it appears there are all replaced with the green imp, at least visually.

Not sick of you. Not yet, anyway. :)

There's two flags from the original game that translate green to different colors. Jamal Jones is using one sprite for both the imps and uses the translation flags to modify the color in game. Helion doesn't support these yet. There's a decent amount of work that needs to be done to be able to handle these translations at runtime.

[nickxcom]

Interesting, thank you!! :) Asked and answered!

[MFG38]

Gave this a brief spin, some assorted thoughts/feedback:

• Ammo clips and weapons dropped by dead zombies seem to give more ammo than they should. Usually, they only give half of the amount that a normal pickup does, not the full amount. Should be corrected.
• It's slightly odd to me that the port doesn't have an in-game option menu of any kind. Not that I'm averse to editing .ini files - I've done that with GZDoom many a time - but providing a way to customize at least some settings in-game would be welcome.
• My volumes seem to reset to the default value (1) every time I launch the port. I don't think I'm doing anything wrong, I set the values to 0.6 and save the .ini and they bump back up to 1 with every launch. Could just be ZDL - it's done that to my GZDoom more than once - but you might want to look into that in case it isn't.

[Maes]

Heh, at a first glance this reminded me of my older project, Mocha Doom -that one was Doom in pure Java. I started it and got it sort or stable about 10 years ago. I don''t have much time for Doom-anything these days, however I'd be curious to glance over Helion's source code -e.g. did you go for a purely managed/OO approach but still close to the original source as I did, or you chose to implement everything from scratch, your own way or -oh, heresy!- just used a wrapper around some C/C++ libdoom.so/dll core? No idea, srsly :-p

 

BTW, this isn't the first port of Doom in C# that I recall, there was one even before I made Mocha Doom -that one was pure C#/.NET, though it was a complete recreation. Too busy even for linking/digging into older posts ATM...

[hobomaster22]

12 hours ago, Maes said:

Heh, at a first glance this reminded me of my older project, Mocha Doom -that one was Doom in pure Java. I started it and got it sort or stable about 10 years ago. I don''t have much time for Doom-anything these days, however I'd be curious to glance over Helion's source code -e.g. did you go for a purely managed/OO approach but still close to the original source as I did, or you chose to implement everything from scratch, your own way or -oh, heresy!- just used a wrapper around some C/C++ libdoom.so/dll core? No idea, srsly :-p

 

BTW, this isn't the first port of Doom in C# that I recall, there was one even before I made Mocha Doom -that one was pure C#/.NET, though it was a complete recreation. Too busy even for linking/digging into older posts ATM...

There is at least one other C# project which I think is more of a direct translation similar to Mocha Doom. Helion is completely from scratch. We obviously referenced the original source and translated some things to get the physics and gameplay to match. Some stuff might be familiar. The action functions (A_Whatever) are mostly the same since they have to match.

I have been extremely busy as well and my time for Doom this week is basically just responding in this post :)

[Darkcrafter07]

15 hours ago, hobomaster22 said:

There is at least one other C# project which I think is more of a direct translation similar to Mocha Doom. Helion is completely from scratch. We obviously referenced the original source and translated some things to get the physics and gameplay to match. Some stuff might be familiar. The action functions (A_Whatever) are mostly the same since they have to match.

I have been extremely busy as well and my time for Doom this week is basically just responding in this post :)

 

It's super impressive that you and your mate went THAT far with it, bravo. It's certainly not exactly 100% doom at this point, but I dont' just hope I know it, with some bit of polishing this is going to reach the apogee of perfectness. Your work is a living proof that it is possible to recreate Doom in other engines and this is the most amazing thing about it.

[invictius]

Which version of gzdoom is this forked off of?  Does it use sse2?

Edited March 31, 2023 by invictius

[Redneckerz]

5 minutes ago, invictius said:

Which version of gzdoom is this forked off of?  Does it use sse2?

It isn't forked off GZDoom. Its built from scratch referencing the original Linux Doom code and the reference implementations of the various standards (DEH, Boom, ZDoom to an extent). It doesn't use the Doom render loop, which is how it avoids the pitfalls commonly associated with any Doom-engine port.

 

TLDR: Helion takes the hard route when it comes to performance. It was already in development for several years before it was unveiled.

[invictius]

1 minute ago, Redneckerz said:

It isn't forked off GZDoom. Its built from scratch referencing the original Linux Doom code and the reference implementations of the various standards (DEH, Boom, ZDoom to an extent). It doesn't use the Doom render loop, which is how it avoids the pitfalls commonly associated with any Doom-engine port.

 

TLDR: Helion takes the hard route when it comes to performance. It was already in development for several years before it was unveiled.

I might try running this on a radeon 2400 (Worst opengl 3.3 gpu that I know of, even worse than gt 210) and a cpu that will barely run 7 (As in, sit idle on the desktop without using a lot of cpu).

[Redneckerz]

1 minute ago, invictius said:

I might try running this on a radeon 2400 (Worst opengl 3.3 gpu that I know of, even worse than gt 210) and a cpu that will barely run 7 (As in, sit idle on the desktop without using a lot of cpu).

I got pretty good performance on a Intel HD 4600. Still a chunk more powerful than a Radeon 2400, but hey. Love to see the results, i do think that at that grade of hardware not even Helion can do an awful lot.

 

I do expect a chunk better than 7 FPS though considering.

[invictius]

52 minutes ago, Redneckerz said:

I got pretty good performance on a Intel HD 4600. Still a chunk more powerful than a Radeon 2400, but hey. Love to see the results, i do think that at that grade of hardware not even Helion can do an awful lot.

 

I do expect a chunk better than 7 FPS though considering.

Can you expect worse performance if you run this on a modern/capable system?  As I was told not to run gzdoom in gles mode on one, for that reason.

[Darkcrafter07]

1 hour ago, invictius said:

I might try running this on a radeon 2400 (Worst opengl 3.3 gpu that I know of, even worse than gt 210) and a cpu that will barely run 7 (As in, sit idle on the desktop without using a lot of cpu).

I gave up on this GPU working in GL3.3 and even installed Win7 back just to install legacy Vista drivers to make it GL2 only because guess what they did when added GL3 support - they removed GL2, so no textures in LZ/GLZdoom in GL2 mode which is magnitudes faster on this card.

Oh, perhaps it's time for new "records". I was able to run Helion via QindieGL that wraps OpenGL to DirectX and in 320x200 it had 35FPS on nuts.wad. It was that "fast" until monsters woke up and it quickly droped down to 7-10FPS maybe because of the CPU (AMD Athlon x64 x2 5000+). Unfortunately I can't run it anymore as it's on GL2 and Win7 now.

PRBoom+ and Crispy Doom are so much faster on such old systems in nuts so this engine is not worth installing on old machines.

Edited March 31, 2023 by Darkcrafter07

[invictius]

30 minutes ago, Darkcrafter07 said:

I gave up on this GPU working in GL3.3 and even installed Win7 back just to install legacy Vista drivers to make it GL2 only because guess what they did when added GL3 support - they removed GL2, so no textures in LZ/GLZdoom in GL2 mode which is magnitudes faster on this card.

Oh, perhaps it's time for new "records". I was able to run Helion via QindieGL that wraps OpenGL to DirectX and in 320x200 it had 35FPS on nuts.wad. It was that "fast" until monsters woke up and it quickly droped down to 7-10FPS maybe because of the CPU (AMD Athlon x64 x2 5000+). Unfortunately I can't run it anymore as it's on GL2 and Win7 now.

PRBoom+ and Crispy Doom are so much faster on such old systems in nuts so this engine is not worth installing on old machines.

How well would QinedieGL run with an igpu such as intel gma 950/3100?  I'm always wanting to run ports like this and gzdoom on laptops with only opengl 1.4.

[Redneckerz]

45 minutes ago, invictius said:

Can you expect worse performance if you run this on a modern/capable system?  As I was told not to run gzdoom in gles mode on one, for that reason.

On the contrary. Performance literally skyrockets to stupid readings. Think 1500+ (!!!) FPS.

 

The comparison with GZ goes bunk in terms of rendering. GZ is fancier, more moddable but restricted to the Doom render loop. Helion is more an interpreter with its own render loop.

[hobomaster22]

1 hour ago, invictius said:

Can you expect worse performance if you run this on a modern/capable system?  As I was told not to run gzdoom in gles mode on one, for that reason. 

The more modern the system the better it will perform. Helion really leverages modern GPUs for performance. Most maps that are slow on other ports because of their complex geometry should run very fast with Helion. My mobile RTX 3070 can render Frozen Time and Planisphere 2 over 1,000 FPS for example.

[Graf Zahl]

12 hours ago, invictius said:

Can you expect worse performance if you run this on a modern/capable system?  As I was told not to run gzdoom in gles mode on one, for that reason.

 

The reason here is something different.

The GLES backend was made for resource constrained systems. As a result some of its properties will cause worse performance on modern hardware. For example, it uses lots of small shaders instead of few bigger ones. On slow hardware the gain in shader performance will easily be more than the cost of switching shaders. On modern hardware this will reverse. Shader performance is so good that the cost of switching shaders will become higher.

Another issue is that the GLES backends puts some constraints on how many dynamic lights you can use.

 

None of these issues apply to Helion.

[invictius]

I've installed both .net packages on windows 7 but still getting "api-ms-win-crt-runtime -l1-1-0.dll is missing".  I'm using windows 7 because the dev is interested in performance on old hardware, and windows 10 wouldn't work that well on it.

 

Installed more prerequisites but now the executable won't start at all.  Also tried on a completely different system with all windows 10 updates:

 

Edited April 2, 2023 by invictius

[Darkcrafter07]

34 minutes ago, invictius said:

I've installed both .net packages on windows 7 but still getting "api-ms-win-crt-runtime -l1-1-0.dll is missing".  I'm using windows 7 because the dev is interested in performance on old hardware, and windows 10 wouldn't work that well on it.

 

I doubt it's made for old hardware, it needs a GPU that was made when OpenGL3 was widespread and even so everything else (made 2008 and newer). I have already demonstated that a 2006 computer with AMD Athlon x2 x64 5000+, ATI Radeon HD2400PRO, 2GB RAM, with a clear installation of a special super fast Win10 build doesn't handle Helion that well and you now want to give it a try on a computer that is far worse than that one, since 

34 minutes ago, invictius said:

windows 10 wouldn't work that well on it.

 

On 4/1/2023 at 1:03 AM, invictius said:

How well would QinedieGL run with an igpu such as intel gma 950/3100?  I'm always wanting to run ports like this and gzdoom on laptops with only opengl 1.4.

I couldn't run GZDoom through QindieGL but you could try it on your own as it exits with an error, it's not hard at all but chances it runs are close to 0. Since 2016 GZDoom renderer needs at least OpenGL2 support because there are new mapping features like portals that require stencil buffers, which are not present in GL1 and even in GL2 dyn lights look crap.

If only somebody would have forked GZDoom and rewrote its renderer entirely to directx 8/9, that would have probably allow modern versions to run on cards with GL1.4 support but how well?

Edited April 2, 2023 by Darkcrafter07

[invictius]

On 4/1/2023 at 9:17 AM, Redneckerz said:

On the contrary. Performance literally skyrockets to stupid readings. Think 1500+ (!!!) FPS.

 

The comparison with GZ goes bunk in terms of rendering. GZ is fancier, more moddable but restricted to the Doom render loop. Helion is more an interpreter with its own render loop.

How do you get 1500+?  With vsync off I'm locked to 240-something.

[invictius]

17 minutes ago, Darkcrafter07 said:

If only somebody would have forked GZDoom and rewrote its renderer entirely to directx 8/9, that would have probably allow modern versions to run on cards with GL1.4 support but how well?

Pretty sure Graf said this would be extremely difficult and not worth it for the few users that would require it.  E.g the reason for dropping xp support.

[invictius]

20 minutes ago, Darkcrafter07 said:

 

I doubt it's made for old hardware, it needs a GPU that was made when OpenGL3 was widespread and even so everything else (made 2008 and newer). I have already demonstated that a 2006 computer with AMD Athlon x2 x64 5000+, ATI Radeon HD2400PRO, 2GB RAM, with a clear installation of a special super fast Win10 build doesn't handle Helion that well and you now want to give it a try on a computer that is far worse than that one

Went back and read your post, thanks.  You've saved me a lot of headaches.

[Graf Zahl]

39 minutes ago, invictius said:

 

57 minutes ago, Darkcrafter07 said:

If only somebody would have forked GZDoom and rewrote its renderer entirely to directx 8/9, that would have probably allow modern versions to run on cards with GL1.4 support but how well? 

 

 

No, it wouldn't. GZDoom requires more modern shader capabilities.

 

There is no hardware in existence that does not support OpenGL 3.3 and has good shader performance.

You need obsolete fixed function functionality here to get decent performance, but GZDoom moved beyond that several years ago. And the last versons that did had a completely separate render path for it.

 

There is really no way to make a renderer that can support both OpenGL 2.x and 3.x at the same time without seriously crippling the feature support for modern hardware. At some point the old, obsolete hardware needs to be left behind. That also applies when using D3D instead of OpenGL because we are speaking about a hardware limitation

 

 

 

Edited April 2, 2023 by Graf Zahl

[Redneckerz]

50 minutes ago, invictius said:

How do you get 1500+?  With vsync off I'm locked to 240-something.

I mean just look at hobo's post stating hitting 1000+ FPS on Planisphere on a RTX 3070.

 

A ludicrous GPU like RTX 4090 may see even 2000 FPS or more.