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

1 hour ago, Shepardus said:

Another minor issue is that in D5DA3, the episode selection screen displays the first episode twice.

This one appears also in Corruption. Adding "episode = clear" in both wads' umapinfo results in correct one copy of episode 1 in Helion, although per spec "Doom 2 and Chex Quest have no episodes by default" and other UM engines don't require that line in practice.

@hobomaster22, I still notice some things that work not so doomy:

- chainsawing monsters takes longer.

Is it like some functions like damage receiving were not randomized somewhere?

20 hours ago, hobomaster22 said:

It’s in the benchmark spreadsheet here. Still waiting on one PC for the final 0.9.2.0 numbers. 

My results, amd 7600x + nvidia 4080, 4k res = 1730 fps on the starting point of SoS map 32. 2070 on Sunder map 15.

3 hours ago, Darkcrafter07 said:

@hobomaster22, I still notice some things that work not so doomy:

 

- chainsawing monsters takes longer.

 

Is it like some functions like damage receiving were not randomized somewhere?

Good catch, looks the parenthesis for the damage calculation got a typo where it is multiplying to by two early where it should be done last, basically halving it.

4 hours ago, Darkcrafter07 said:

- chainsawing monsters takes longer.

Oh yeah, I noticed that too, but I wasn't too sure if I was just imagining it so I wanted to do some more testing today before reporting it. Glad to see that's already been figured out!

8 hours ago, hobomaster22 said:

Good catch, looks the parenthesis for the damage calculation got a typo where it is multiplying to by two early where it should be done last, basically halving it.

Thank you for paying attention to the forum replies like this to fix it! Bravo!

15 hours ago, Turin Turambar said:

 

My results, amd 7600x + nvidia 4080, 4k res = 1730 fps on the starting point of SoS map 32. 2070 on Sunder map 15. 

When I read this yesterday, I was thinking these results were just OK. Then I read it again today and realized this was at 4k... which completely changes the context. These are crazy numbers.

Related to Sunder MAP15, I am on this tangent of coming up with methods to get Sunder MAP11 and MAP15 playable on the garbage laptop from 2013. Since it can push above 100FPS on MAP11 and above 50FPS on MAP15 it should be possible. I am working on some configurations to make this work. With some minor sacrifices it's possible.

15 minutes ago, hobomaster22 said:

When I read this yesterday, I was thinking these results were just OK. Then I read it again today and realized this was at 4k... which completely changes the context. These are crazy numbers.

Related to Sunder MAP15, I am on this tangent of coming up with methods to get Sunder MAP11 and MAP15 playable on the garbage laptop from 2013. Since it can push above 100FPS on MAP11 and above 50FPS on MAP15 it should be possible. I am working on some configurations to make this work. With some minor sacrifices it's possible.

If and when i get the time, ill post some stats of my HD 4600 PC and GTX 645M laptop.

The finalized benchmarks for 0.9.2.0. Everything got a boost. The stronger the GPU the more the percentages seem to sky rocket. The very limited AMD Radeon HD 8400 only saw a 31% increase for Summer of Slaughter MAP32. I say only because the other GPUs saw more than 200% increases.

In addition to the bug fixes, I have been working on optimizing the routines for monsters and some tools to help slower systems be able to play large slaughter maps. The new functionality is slow ticking more expensive monster routines like A_Chase that are past a configurable distance. Combining this slow ticking option with Helion's existing functionality of monster closet detection and cutting down the rendering distance for dynamic objects/sprites has made sunder MAP15 playable on the Radeon HD 8400 laptop.



In this example the max render distance for dynamic objects/sprites was 2500, and the slow tick distance was 1500. So anything after 1500 (or not visible) will tick more slowly and anything after 2500 will not render. The speeds are increased so they will move at the same rate and missile checks are tweaked so they will fire at roughly the same speed. This means the rest of world functions basically the same (but not exact.) Archviles will still revive enemies at roughly same rate, monsters will shoot at the player from long distances at roughly the same rate and trigger things as they would normally.

41 minutes ago, hobomaster22 said:

The new functionality is slow ticking more expensive monster routines like A_Chase that are past a configurable distance. Combining this slow ticking option with Helion's existing functionality of monster closet detection and cutting down the rendering distance for dynamic objects/sprites has made sunder MAP15 playable on the Radeon HD 8400 laptop.

 

... and the slow tick distance was 1500. So anything after 1500 (or not visible) will tick more slowly and anything after 2500 will not render. The speeds are increased so they will move at the same rate and missile checks are tweaked so they will fire at roughly the same speed. This means the rest of world functions basically the same (but not exact.) Archviles will still revive enemies at roughly same rate, monsters will shoot at the player from long distances at roughly the same rate and trigger things as they would normally.

This is simply incredible. Definitely out of scope for now, C&C Generals had an interesting crowd optimization technique, when you give a huge crowd an order to move, the engine splits that crowd into groups and leads them over the same pathway per group, one after another. Let's say a crowd of monsters coming your way, if it was treated as just a couple or even 1 actor, that could too save you some cycles maybe?

Got a quick bug report of sorts: Vesper uses a lesser known dehacked feature that doesn't look like its supported yet: if both the "misc1" and "misc2" fields on a weapon state are nonzero, they're added to the weapon sprite offsets. Vesper uses this extensively for weapon animations, so they look a bit janky in Helion right now.

Everything else in the mod seems pretty much spot on though (from tbe limited testing ive done so far anyway), so the actual MBF21 features are looking good. :D

[Sorry to interrupt the discussion about perf metric, those Sunder stats are absolutely insane, in the best way. :]

49 minutes ago, Xaser said:

Got a quick bug report of sorts: Vesper uses a lesser known dehacked feature that doesn't look like its supported yet: if both the "misc1" and "misc2" fields on a weapon state are nonzero, they're added to the weapon sprite offsets. Vesper uses this extensively for weapon animations, so they look a bit janky in Helion right now.

 

Everything else in the mod seems pretty much spot on though (from tbe limited testing ive done so far anyway), so the actual MBF21 features are looking good. :D

 

[Sorry to interrupt the discussion about perf metric, those Sunder stats are absolutely insane, in the best way. :]

This is good, thank you. The code exists to set the offsets but it's not being hit so I have to figure out why that is.

18 hours ago, hobomaster22 said:

anything after 2500 will not render.

Just to check, do you mean anything beyond 2500 is simply invisible?  That seems a pretty low number, and could lead to strange issues of not being able to see monsters shooting at you on any remotely large maps.  DSDA-Doom cuts off anything beyond 8192 units and even that was causing issues in a map I've been working on.

Rather than make something invisible, is there a middle ground (or maybe an optional middle ground) that, for example, only displays a single frame (e.g. XXXXA1) rather than the full animation?  Or maybe something that displays sprites cut down to 10% of their resolution?  I'm not sure if either of these are feasible or would even help, but I feel like it's important to still be able to see where an enemy or Thing is even at extreme distances.

5 minutes ago, Bauul said:

 

Just to check, do you mean anything beyond 2500 is simply invisible?  That seems a pretty low number, and could lead to strange issues of not being able to see monsters shooting at you on any remotely large maps.  DSDA-Doom cuts off anything beyond 8192 units and even that was causing issues in a map I've been working on.

 

Rather than make something invisible, is there a middle ground (or maybe an optional middle ground) that, for example, only displays a single frame (e.g. XXXXA1) rather than the full animation?  Or maybe something that displays sprites cut down to 10% of their resolution?  I'm not sure if either of these are feasible or would even help, but I feel like it's important to still be able to see where an enemy or Thing is even at extreme distances.

Yes. To be clear this is a configuration option that exists in Helion right now with the render.maxdistance variable. It's not something that is going to be forced to everyone. The problem with sprites isn't what is being rendered, the actual rendering of a sprite costs practically nothing in OpenGL. The problem is they have to be calculated each game tick which takes a huge chunk out of the CPU and then needs to be uploaded to the GPU making it even more painful. I do have some ideas to mitigate these problems, but it's going to require a rewrite of how sprites are handled.

I do agree it's not preferable to cut down these distances, but it's configurable and a tool to help make maps that would otherwise be unplayable like Sunder MAP11 or MAP15. On this laptop, Sunder MAP11 drops down to 30FPS in the first main area. With these values it can stay above 60FPS and even hit above 80 so I would say it's a sacrifice worth having since 30FPS and below is not even playable.

2500 units is pretty low, in LZDoom sprite distance cull defaulted to 4000.

1 hour ago, drfrag said:

2500 units is pretty low, in LZDoom sprite distance cull defaulted to 4000.

It's not a default. The 2500 is what I set to get the performance I wanted out of Sunder MAP11/MAP15.

On 10/11/2023 at 12:50 PM, hobomaster22 said:

On this laptop, Sunder MAP11 drops down to 30FPS in the first main area. With these values it can stay above 60FPS and even hit above 80 so I would say it's a sacrifice worth having since 30FPS and below is not even playable.

Old Doom veterans: *Wry smile*

I'm going to test this again tomorrow. I borrowed a computer from a friend so I can have a lan party for my game in the coming week, but found out it had an even worse integrated card than the one on my normal computer and it was so bad that I was averaging about 40 fps on my 2d game. I ended up getting a used GTX 730 today from a local store. It's by no means good, but now I'm averaging about 250 fps on my game (Apparently it's a little better than my Quadro P400). I figure while I'm at it another Helion potato test should be interesting.

8 hours ago, Dark Pulse said:

Old Doom veterans: *Wry smile*

Okay took me a little longer than expected but here are the results:

crazy maze 280 fps
planisphere 330 fps
planisphere2 220 fps
sunder map 30 160 fps

This is insanely impressive considering that this computer is over a decade old. For reference it has an Intel i5-2500 quad core and an Nvidia GeForce GT 730 for the graphics card.
 

3 hours ago, Madgunner said:

Okay took me a little longer than expected but here are the results:

crazy maze 280 fps
planisphere 330 fps
planisphere2 220 fps
sunder map 30 160 fps

This is insanely impressive considering that this computer is over a decade old. For reference it has an Intel i5-2500 quad core and an Nvidia GeForce GT 730 for the graphics card.
 

Those are great numbers. Is Sunder map30 a typo? I don't think that map exists? I've never even heard of the GT 730 and had to look it up. It's quite a bit faster than my slowest test GPU, the Radeon HD 8400 which gets about 75 FPS on Planisphere 2.

17 hours ago, hobomaster22 said:

Those are great numbers. Is Sunder map30 a typo? I don't think that map exists? I've never even heard of the GT 730 and had to look it up. It's quite a bit faster than my slowest test GPU, the Radeon HD 8400 which gets about 75 FPS on Planisphere 2.

Yes you're right it was Sunlust map30. Yeah it's a pretty decent card for the price, paid about $10 for it and so far I'm happy. I'm going to go back there soon and see what other graphics cards they have for sale. I have another computer that can use an upgrade 

I ran into some rather interesting anomalies when I loaded up the first level of Back to Saturn X.  Sorry if this was a bit much, but I wanted to showcase a variety of scenarios where it showed up, including a couple of out of bounds perspectives.  The area with the berserk pack is particularly interesting because it wasn't consistently broken and I have no idea what triggered it.  None of these areas have movable walls, floors or ceilings, and you should obviously be able to see under that bridge.  In case you haven't played it, this is a vanilla compatible map set, and I did not have any problems with it in Chocolate Doom or GZDoom under either the software or hardware renderer.  It may be worth noting that I loaded this up on Linux Mint 21.

Helion obviously does not have much handling for vanilla rendering tricks yet. BTSX's first map has quite a few of those so it's no surprise that the map glitches.

2 hours ago, TruthInFiction said:

I ran into some rather interesting anomalies when I loaded up the first level of Back to Saturn X. 

These looks like "invisible holes" - a rendering trick where if you leave the walls of a hole untextured, the floor/ceiling floodfill will cover it up.  The likes of GZDoom had to implement specific coding to render them correctly (AFAIK)

3 hours ago, TruthInFiction said:

I ran into some rather interesting anomalies when I loaded up the first level of Back to Saturn X.  Sorry if this was a bit much, but I wanted to showcase a variety of scenarios where it showed up, including a couple of out of bounds perspectives.  The area with the berserk pack is particularly interesting because it wasn't consistently broken and I have no idea what triggered it.  None of these areas have movable walls, floors or ceilings, and you should obviously be able to see under that bridge.  In case you haven't played it, this is a vanilla compatible map set, and I did not have any problems with it in Chocolate Doom or GZDoom under either the software or hardware renderer.  It may be worth noting that I loaded this up on Linux Mint 21.

Thanks for the report. Helion does support most flood filling cases. Here the map used good old AASHITTY for the textures instead of not setting it. This case should work so I need to investigate why, but I suspect it was an oversight with the texture indexing moving the texture with BTSX's custom textures.

In Doom not setting a texture would set the texture index to zero. They put this texture in that slot since it was never supposed to be rendered. Not setting a texture or using this crap texture ends up being the same internally. This quirk is also what causes the raise by shortest texture bug.

The index for that texture was mistakenly being pushed up so the checks were failing. Fixed for the next release.

Excuse me, 3000 FPS?

Now this is the kinda performance doom should have in 2023!

Im deffinitely giving this a try!

Edit: Tried it, yeap, thats certainly extremely impressive
Now i just wish you had actual options, in-game!

The status bar seems to affect the viewport differently in Helion than it does in other source ports, making playing with the status bar enabled and mouselook disabled (i.e. "classic" style) awkward.

Normally the view gets pushed up when you bring up the status bar (screenshots are from dsda-doom, though this applies to other ports as well):

While in Helion the player weapon sprite moves but nothing else does:

As a result, when playing with no mouselook, having the status bar on gives the feeling that you're always looking upwards, even though you're actually looking straight forward according to the crosshair (but the crosshair isn't centered in the view).

Also, has anyone on Linux (Fedora especially) encountered a problem with the music becoming all garbled (not sure how to describe it, but can provide a video if needed)? It was working fine for me the last time I posted here, but since then something has changed and I'm not sure what. I thought it had to do with a Fluidsynth update that I installed, but I tried downgrading the package and still had the issue. Maybe something to do with PipeWire, but I have no idea where to look for that. The only logs I have from Helion related to Fluidsynth are:

fluidsynth: warning: Requested audio-channels to high. Limiting this setting to audio-groups.
fluidsynth: warning: Failed to set thread to high priority

But I'm not sure if those are new or if it's always been like that.

On 10/17/2023 at 12:06 PM, hobomaster22 said:

Thanks for the report. Helion does support most flood filling cases. Here the map used good old AASHITTY for the textures instead of not setting it.

Oh god... thank you for this because I was trying to merge og Doom textures into a Doom2 pwad with Slade a while back and thought it didn't work, since AASHITTY would display transparent or seriously bug out the rendering.

I had no idea it was such a trick texture to begin with.... lol

(Ofc I might have messed something up otherwise too but this encourages me to retry).

Sorry for off topic but had to mention this!

I am very impressed with Helion as you saw from the Sunder screenies I posted a while back!