Helion - C# (0.9.4.0 8/24 - Goodbye BSP tree rendering)

[Theespressoman]

decided to try this port out after haring about it, looks like a really cool project.

 

few things to note
-works on linux with proton (feels weird to need to use it, but if all else fails or this port is a dead-end, it won't be too hard to try out)
-feels great already, other than a weird and minor jitter when you look all the way up and turn, its nothing but smooth, better feeling than ports like eternity IMO.
-options are a bit bare-bones, no fov options feel so strange (ive become spoiled by GZ and prboom) , but needing the console is fine for me, id recommend focusing more on the options themselves than the UI for now.

 

seems like it has some huge potential (none of the first impression issues are too major, even linux support is probably not too far with .net core and not a deal-breaker. which is great for such an early project), if you get the time to really put the work in, this could be a new staple for doom fans, nothing but positive thoughts.

[Turin Turambar]

Jesus this is fast. Literally two magnitudes faster than before. Now this is Cacoward worthy.

 

[hobomaster22]

21 hours ago, esspressoman said:

decided to try this port out after haring about it, looks like a really cool project.

 

few things to note
-works on linux with proton (feels weird to need to use it, but if all else fails or this port is a dead-end, it won't be too hard to try out)
-feels great already, other than a weird and minor jitter when you look all the way up and turn, its nothing but smooth, better feeling than ports like eternity IMO.
-options are a bit bare-bones, no fov options feel so strange (ive become spoiled by GZ and prboom) , but needing the console is fine for me, id recommend focusing more on the options themselves than the UI for now.

 

seems like it has some huge potential (none of the first impression issues are too major, even linux support is probably not too far with .net core and not a deal-breaker. which is great for such an early project), if you get the time to really put the work in, this could be a new staple for doom fans, nothing but positive thoughts.

Thanks for taking the time to respond. That is cool that you got it working on Linux. One problem was using System.Drawing for image processing and Visual Studio didn't warn us that it's Windows only like it does now. I wanted to remove this dependency but the third party .NET core image processing libraries aren't as nice to use. But it will happen eventually. I can add the field of view option quite easily for the next release. I was honestly unaware that ports even let you change this, so I learned something new.

[hobomaster22]

12 hours ago, Turin Turambar said:

Jesus this is fast. Literally two magnitudes faster than before. Now this is Cacoward worthy.

 

Wow, those are some absurd numbers! I think the most I saw on Sunder MAP15 was 1.2k with my Mobile RTX 3070. I have to ask what you are running that is capable of pushing that many frames!

[Martin Howe]

Looking good; when it can be built natively on Linux I'll give it a go (I realise that's not a priority right now). I had no idea that System.Drawing was Windows only, though; it's been a long time since I coded in .NET.

[Madgunner]

OH man I am soooo happy to see that this is still around, I had feared the worst over the past year. Looking great, I'll have to test it out again sometime soon. Don't sleep on this port, folks! Definitely going to check out the source code too!

Edited November 23, 2022 by Madgunner

[Turin Turambar]

On 11/21/2022 at 11:59 PM, hobomaster22 said:

Wow, those are some absurd numbers! I think the most I saw on Sunder MAP15 was 1.2k with my Mobile RTX 3070. I have to ask what you are running that is capable of pushing that many frames!

 

amd 3700x, 16 gb ram, rtx 3070, win11

[Madgunner]

Took a cursory glance at the source code and I gotta say I am completely amazed at how clean the code is in comparison to pretty much any other doom port out there especially those in the ZDoom family. I mean this is some insanely clean code, it's hard to believe it's even doom. I had a quick question though, I didn't really immerse myself too much in the code since I'm really busy coding a video game right now, but I noticed a Circle2d class, and I was wondering if you guys are implementing support for circular objects in doom or if thats for something else. That would be really cool since afaik no other port current supports objects that are anything other than AABB's.

[hobomaster22]

9 hours ago, Madgunner said:

Took a cursory glance at the source code and I gotta say I am completely amazed at how clean the code is in comparison to pretty much any other doom port out there especially those in the ZDoom family. I mean this is some insanely clean code, it's hard to believe it's even doom. I had a quick question though, I didn't really immerse myself too much in the code since I'm really busy coding a video game right now, but I noticed a Circle2d class, and I was wondering if you guys are implementing support for circular objects in doom or if thats for something else. That would be really cool since afaik no other port current supports objects that are anything other than AABB's.

Thanks for the feedback, I really appreciate it! I think Microsoft gets a lot of crap (some very deserved) but .NET is absolutely amazing. Being able to create something like this in a managed language with great performance speaks volumes to .NET. and it certainly helped to create cleaner code. Since I switched jobs about a year ago I don't even code in C/C++ anymore professionally. I think if I tried this from scratch in C++ I would have gave up because there are so many pitfalls and ways to shoot yourself in the foot. Part of me misses the language (apparently a masochistic part), but I don't miss that feeling of always having a shotgun pointed at my foot with a trigger that goes off for like... no reason. No more debugging dumps from access violations.

We do not have any plans for circular objects. All the math classes were generated for anything we might need when development started. Quite a few of them are probably not used.

[RastaManGames]

This is small test that I've made on the wave of hype about that big & dense "CrazyMaze.WAD".
In "GZDoom" 4.9.0 I had only ~5 FPS and not sure how many I had on "Helion C# 0.9.1.0" ('cause just writing vid_fps 1 does nothing here & am not sure if I can attach "ReShade" to it at all), but entire feeling of framerate was very smooth & comfortable!

Only sad thing that entire auto-map is revealed at the start, but it can be fixed soon!

 

[hobomaster22]

8 minutes ago, RastaManGames said:

This is small test that I've made on the wave of hype about that big & dense "CrazyMaze.WAD".
In "GZDoom" 4.9.0 I had only ~5 FPS and not sure how many I had on "Helion C# 0.9.1.0" ('cause just writing vid_fps 1 does nothing here & am not sure if I can attach "ReShade" to it at all), but entire feeling of framerate was very smooth & comfortable!

Only sad thing that entire auto-map is revealed at the start, but it can be fixed soon!

In Helion the console command is hud.showfps 1 :)

There is hud.showstats to see live map statistics.

[Bauul]

On 11/17/2022 at 11:44 AM, hobomaster22 said:

I can be more clear with the OP but we did put a lot of effort in getting good performance, but I didn't say it would beat any port, or compare it to any.

 

Ah, my apologies, I think I was conflating your OP with the first reply from Redneckers, which does focus primarily on the performance benefits of the port.

 

On 11/20/2022 at 1:04 PM, hobomaster22 said:

PS @Bauul this is probably what you are looking for :)

 

I tried out the new build, and performance is indeed much quicker! It seems to perform about 50%-75% quicker than GZDoom in a couple of test maps (Sunder Map15 and The Given).

 

Although I could never get FPS higher than 60, even with vsync disabled through the console. Is there something else I need to do to unlock the framerate?

 

I also tried it with two proper UDMF performance challenges (the type GZDoom more commonly struggles with), Lullaby and Bastion of Chaos. Lullaby loaded, but showed Entryway instead of the map. Bastion of Chaos crashed on startup.

 

Should I presume this is only compatible with essentially Boom maps at present?

[hobomaster22]

22 minutes ago, Bauul said:

 

Ah, my apologies, I think I was conflating your OP with the first reply from Redneckers, which does focus primarily on the performance benefits of the port.

No problem. Red is specifically running an integrated Intel card that GZDoom seems to especially hate. With these very limited integrated cards even the previous version of Helion fares significantly better. I have one old laptop that can't even move out of the single digits in GZDoom with E1M1 where Helion can push it into a playable range near 60.

 

25 minutes ago, Bauul said:

I tried out the new build, and performance is indeed much quicker! It seems to perform about 50%-75% quicker than GZDoom in a couple of test maps (Sunder Map15 and The Given).

 

Although I could never get FPS higher than 60, even with vsync disabled through the console. Is there something else I need to do to unlock the framerate? 

Hmm, it should be much faster given the frame numbers you were giving before. I went from about 30 FPS to 700 FPS on average for Sunder MAP15, with sections like the start area pushing 1.4k.

The only things that should need to be set to unlock the framerate is:
render.vsync 0
render.maxfps 0

 

35 minutes ago, Bauul said:

I also tried it with two proper UDMF performance challenges (the type GZDoom more commonly struggles with), Lullaby and Bastion of Chaos. Lullaby loaded, but showed Entryway instead of the map. Bastion of Chaos crashed on startup. 

 

Should I presume this is only compatible with essentially Boom maps at present?

It would be fair to consider us a Boom port. I have only implemented ZDoom specials to support Vanilla/Boom/MBF21 at this point.

[Bauul]

7 minutes ago, hobomaster22 said:

Hmm, it should be much faster given the frame numbers you were giving before. I went from about 30 FPS to 700 FPS on average for Sunder MAP15, with sections like the start area pushing 1.4k.

The only things that should need to be set to unlock the framerate is:
render.vsync 0
render.maxfps 0

 

Did a re-test on the very opening shot of Sunder Map15, deleting Helion's config.ini first to ensure true defaults.  GZDoom (before the enemies wake up) averages 78-79fps, dropping to 49-50fps once after shooting the pistol to wake everything up.

 

By comparison, Helion (which deleting the config seems to have solved the vsync issue) averages 78-79 for "fps", 95 for "max fps" and 45 for "min fps" (not sure exactly what those are measuring). The bigger difference is on waking the monsters up, Helion averages around 60-65fps.

 

I also restested The Given's opening shot.  GZDoom averages around 26fps while Helion settles to 41fps.  So Helion is definitely better, but it's not orders of magnitude better.

 

For reference my specs are:

 

Intel Core i5-7300HQ CPU @ 2.50GHz 

16.0 GB RAM

GTX 1060 Max-Q 6Gb VRAM

[hobomaster22]

8 minutes ago, Bauul said:

 

Did a re-test on the very opening shot of Sunder Map15, deleting Helion's config.ini first to ensure true defaults.  GZDoom (before the enemies wake up) averages 78-79fps, dropping to 49-50fps once after shooting the pistol to wake everything up.

 

By comparison, Helion (which deleting the config seems to have solved the vsync issue) averages 78-79 for "fps", 95 for "max fps" and 45 for "min fps" (not sure exactly what those are measuring). The bigger difference is on waking the monsters up, Helion averages around 60-65fps.

 

I also restested The Given's opening shot.  GZDoom averages around 26fps while Helion settles to 41fps.  So Helion is definitely better, but it's not orders of magnitude better.

 

For reference my specs are:

 

Intel Core i5-7300HQ CPU @ 2.50GHz 

16.0 GB RAM

GTX 1060 Max-Q 6Gb VRAM

Min fps is the minimum seen over a certain duration. It’s a good indicator of how much world simulation is sucking off the CPU causing framerate drops.
 

A 1060 Max-Q should get much higher framerates. I think I know what the problem is. This is a laptop correct? I can pretty much guarantee Helion is using the integrated card and not the GTX 1060. Windows has made this annoying to deal with. I don’t even think the NVIDIA control works for overriding it anymore. I fight this all the time on my laptop because I use it for development. 

[Bauul]

15 minutes ago, hobomaster22 said:

Min fps is the minimum seen over a certain duration. It’s a good indicator of how much world simulation is sucking off the CPU causing framerate drops.
 

A 1060 Max-Q should get much higher framerates. I think I know what the problem is. This is a laptop correct? I can pretty much guarantee Helion is using the integrated card and not the GTX 1060. Windows has made this annoying to deal with. I don’t even think the NVIDIA control works for overriding it anymore. I fight this all the time on my laptop because I use it for development. 

 

Yep it's a laptop!  Funnily enough I had the same thought just after I posted, and you are absolutely right, it was using the integrated GPU.  I forced it to use the 1060 through Windows, and FPS on the opening shot of The Given has increased to about 52 fps.

 

It's odd, according to the Task Manager it is using the GTX 1060, but maximum load was about 7%. CPU max load was about 40%.  Something seems to be bottlenecking performance, but I'm not sure what.  I checked the power saving settings (which can be notorious on laptops) and there's nothing going on there, so I'm a bit stumped.

 

Edit: Also discovered a lighting bug.  If you look straight upwards, you can see that everything behind the player isn't having any lighting applied to it.

 

[hobomaster22]

2 minutes ago, Bauul said:

 

Yep it's a laptop!  Funnily enough I had the same thought just after I posted, and you are absolutely right, it was using the integrated GPU.  I forced it to use the 1060 through Windows, and FPS on the opening shot of The Given has increased to about 52 fps.

 

It's odd, according to the Task Manager it is using the GTX 1060, but maximum load was about 7%. CPU max load was about 40%.  Something seems to be bottlenecking performance, but I'm not sure what.  I checked the power saving settings (which can be notorious on laptops) and there's nothing going on there, so I'm a bit stumped.

I really hate how windows handles this. With how common laptops with two GPUs are now one would think they would handle it better. I have not found a good way to force it. For me the only way Windows will ever fully use my RTX 3070 is if I'm plugged into my external gaming monitor. If not it always puts it on my integrated Radeon GPU...

You can try this but I have never had any luck with it (I think it requires a restart to take effect... if it feels like it)

[hobomaster22]

1 hour ago, Bauul said:

 

Edit: Also discovered a lighting bug.  If you look straight upwards, you can see that everything behind the player isn't having any lighting applied to it.

 

I will have to fix that in the shader. Never thought to test what is behind the player, thanks for posting.

This map is an interesting test case. All the scrolling texture sections is hurting the framerate quite a bit. Maybe I can come up with something clever to handle this.

[Arsinikk]

So I was really excited to try this port to see how well it would run WADs. However it seems that in the Dehacked, there's still quite a few things that need to be fixed. I used (or tried to use) my recent megawad 200 Line Massacre as a DehackEd playtest.

 

Here are some of the things I ran into:
- Helion seems to inconstantly throw a "failed to load assets.pk3" error

- DehackEd fast weapon switching straight up doesn't work in the latest build. Basically you can't fire, swap weapons, and when you pick up weapons nothing happens.

- flat bleeds do not seem to bleed when they should (quite important for Vanilla WADs). See 200lnm MAP25 outside beginning for example.

- Would be nice for flat and texture animations to be synced like ZDoom ports. I've worked with multiple ports recently to sync wall and flat animations together like ZDoom (Woof and Doom Retro have made this fix. DSDA Doom fix is in the queue.)

 

My other question is to ask if there's any plans in the future to support ZDoom compatibility options. It's very important for WAD makers like me that rely on Vanilla tricks and gimmicks. Since it didn't seem like there was any complevel support.

Edited November 26, 2022 by Arsinikk : Added link to actual flat/wall sync fix

[hobomaster22]

8 minutes ago, Arsinikk said:

So I was really excited to try this port to see how well it would run WADs. However it seems that in the Dehacked, there's still quite a few things that need to be fixed. I used (or tried to use) my recent megawad 200 Line Massacre as a DehackEd playtest.

 

Here are some of the things I ran into:
- Helion seems to inconstantly throw a "failed to load assets.pk3" error

- DehackEd fast weapon switching straight up doesn't work in the latest build. Basically you can't fire, swap weapons, and when you pick up weapons nothing happens. 

- flat bleeds do not seem to bleed when they should (quite important for Vanilla WADs). See 200lnm MAP25 outside beginning for example.

- Would be nice for flat and texture animations to be synced like ZDoom ports. I've worked with multiple ports recently to sync wall and flat animations together like ZDoom (Woof and Doom Retro have made the fix. DSDA Doom fix is in the queue.) 

 

My other question is to ask if there's any plans in the future to support ZDoom compatibility options. It's very important for WAD makers like me that rely on Vanilla tricks and gimmicks. Since it didn't seem like there was any complevel support. 

The only way I can think of that Helion would fail to load the assets.pk3 is because the file is use, for example if Helion hasn't completely closed yet. It's a limitation of the built in .NET zip reading library where it won't share access. This isn't a problem wad files.

 

I will have to debug the dehacked for 200 Line Massacre. Because we are using decorate everything has to be translated. One single frame mess up unfortunately breaks the entire thing, which is likely the case here.

Flat bleeding is not implemented, yet. Not a simple thing to emulate in hardware unfortunately.

Not really familiar with the flat and texture animation syncing. Is there an example map that shows what it should look like?

We do have compatibility options, like compatibility.vanillasectorphysics, and allowitemdropoff. If more are needed we will add them as they come up.

 

[Arsinikk]

18 minutes ago, hobomaster22 said:

The only way I can think of that Helion would fail to load the assets.pk3 is because the file is use, for example if Helion hasn't completely closed yet. It's a limitation of the built in .NET zip reading library where it won't share access. This isn't a problem wad files.

This is correct, probably a result of me trying to run it without the .NET libraries and having to download them or something. Or perhaps it's a result of me trying to drag-and-drop the WAD files, which doesn't seem to work quite yet. This is a beta after all.

 

18 minutes ago, hobomaster22 said:

Flat bleeding is not implemented, yet. Not a simple thing to emulate in hardware unfortunately.

Fair enough. GZDoom has found a way to get around, so I'm sure at some point you'll find a solution.

 

18 minutes ago, hobomaster22 said:

Not really familiar with the flat and texture animation syncing. Is there an example map that shows what it should look like?

An easy test is to look at 200 Line Massacre MAP25. Traditionally most source ports have had completely different timing from Vanilla and even other source ports, resulting in mappers not being to do cool synced animation tricks like this. It's currently my mission to remedy this oversight in source ports. Here's a gif showing what the effect I did in the WAD is:

Spoiler

 

The actual fix that used for Woof, Doom Retro and at some point DSDA Doom is this: https://github.com/jeffdoggett/Doom/commit/e2e0e69d367f748b235fa3c4b81e5fb4b042ce52

 

18 minutes ago, hobomaster22 said:

We do have compatibility options, like compatibility.vanillasectorphysics, and allowitemdropoff. If more are needed we will add them as they come up.

I'm not exactly sure how these are implemented. As a map maker, it'd be a lot more work to have to implement a brand new list of compatibility options. I'd honestly suggest using the ZDoom compatibility names so that map makers don't have to implement specific compat options just for Helion. This is what ports like Doom Retro do.

Edited November 26, 2022 by Arsinikk

[hobomaster22]

48 minutes ago, Arsinikk said:

An easy test is to look at 200 Line Massacre MAP25. Traditionally most source ports have had completely different timing from Vanilla and even other source ports, resulting in mappers not being to do cool synced animation tricks like this. It's currently my mission to remedy this oversight in source ports. Here's a gif showing what the effect I did in the WAD is: 

 

The problem isn't that the timing is wrong. It apparently has to do with texture indexing, at least for Helion. It's dependent on the texture index range and it's not getting rearranged when 200lm.wad is loaded causing only GTSFONT1, 2, and 3 to be in the animation range only. It will get fixed anyway.

[GooberMan]

20 hours ago, hobomaster22 said:

I really hate how windows handles this. With how common laptops with two GPUs are now one would think they would handle it better. I have not found a good way to force it.

I had to deal with this recently myself. If the drivers can resolve some exported integers from your program, then they'll always choose the discrete GPU over the integrated one.

This is C/C++ code, I can half imagine how ugly it'll be to get it working in C#.

#if defined( __cplusplus )
extern "C"
{
#endif
	// https://docs.nvidia.com/gameworks/content/technologies/desktop/optimus.htm
	_declspec(dllexport) DWORD NvOptimusEnablement = 1;

	// https://gpuopen.com/learn/amdpowerxpressrequesthighperformance/
	_declspec(dllexport) int AmdPowerXpressRequestHighPerformance = 1;
#if defined( __cplusplus )
}
#endif

 

[hobomaster22]

32 minutes ago, GooberMan said:

I had to deal with this recently myself. If the drivers can resolve some exported integers from your program, then they'll always choose the discrete GPU over the integrated one.

This is C/C++ code, I can half imagine how ugly it'll be to get it working in C#. 

#if defined( __cplusplus )
extern "C"
{
#endif
	// https://docs.nvidia.com/gameworks/content/technologies/desktop/optimus.htm
	_declspec(dllexport) DWORD NvOptimusEnablement = 1;

	// https://gpuopen.com/learn/amdpowerxpressrequesthighperformance/
	_declspec(dllexport) int AmdPowerXpressRequestHighPerformance = 1;
#if defined( __cplusplus )
}
#endif

 

Thanks! It's probably going to look horrible in C#, if it's even possible. I could do through a .NET C++ dll using the CLI but that approach sucks too. I guess I will have to pick whichever one sucks less :)

[tengv]

When I try using this sourceport with mouselook off, the player view always skews off-center at map start. Is there a command to re-center the view?

Also, given that this port relies heavily on console commands, is there an exhaustive list of cvars that can be used with Helion?

[Graf Zahl]

On 11/26/2022 at 2:32 PM, hobomaster22 said:

Flat bleeding is not implemented, yet. Not a simple thing to emulate in hardware unfortunately.

 

 

It's not really that hard. What you need is a stencil buffer to mask out the part you want to draw in and then render the part of the sector plane into it. After that clear the stencil again.

[hobomaster22]

1 hour ago, tengv said:

When I try using this sourceport with mouselook off, the player view always skews off-center at map start. Is there a command to re-center the view?

Also, given that this port relies heavily on console commands, is there an exhaustive list of cvars that can be used with Helion?

Centerview command should center it. You can view all commands by typing commands in the console and using page up/page down to scroll.

[Gregor]

I can't load any pwads. i tried running it from the command line with a random pwad and all i get is "failed to load assets.pk3". I downloaded the .net libraries it prompted me to download and it does run Doom 2 just fine (and extremely fast, mind you). But what now?

[hobomaster22]

2 minutes ago, Gregor said:

I can't load any pwads. i tried running it from the command line with a random pwad and all i get is "failed to load assets.pk3". I downloaded the .net libraries it prompted me to download and it does run Doom 2 just fine (and extremely fast, mind you). But what now?

 

Is the command prompt in the Helion directory? If it changes the directory then Helion will fail to find the assets.pk3 file. I just put in a fix for this now since I realized we don't support dragging and dropping files, and Helion needs to set the current directory to it's executing directory. I've become accustomed to using Doom Launcher I forgot dragging and dropping was a thing.

[Gregor]

i changed the directory on the command line to helion's dir. but it now it complains that can't load the iwad even though it is right there in its root directory.