Helion - C# (0.9.2.8 4/24 - Goodbye BSP tree rendering)

[hobomaster22]

Hello everyone,

 

Helion is a new port developed in C# using .NET Core by WChrisK and myself. The main objectives of Helion are to have readable code along with good performance. Usually these are counter-intuitive but we put a good amount of effort to hit these goals. It's my hope that those interested in the source find it easy to understand and can learn how games like Doom work. Helion is different from most ports in that started entirely from scratch and isn't based off any existing code base. Some very specific code sections were basically translated line by line such as enemy action functions to match the original game. The base of Helion uses ZDoom specifications like decorate, mapinfo, gameinfo, and ZDoom action specials etc. We weren't looking to re-invent the wheel with new formats.

 

Helion supports decorate/ZDoom specials. However, it is partial and implemented up to a point to support Vanilla, Boom, and MBF21. If a wad includes both dehacked and decorate, the dehacked will be used by default as it's currently more stable.

Screenshots:

Spoiler

Note: hud.showfps and hud.showstats set to 1

 

Doom 2 MAP01:

 

 

Doom E1M1:

 

Eviternity MAP29:

 

Fractured Worlds MAP05:

 

Rendering Options:

Spoiler

render.staticmode - Enabled by default. Only uploads map geometry to the GPU when changed.
render.blockmap - Enabled by default. Uses the blockmap for rendering sprites and dynamic sectors. When disabled it will use the BSP tree.
render.maxdistance - 6000 by default. Stops rendering sprites and dynamic sectors past this distance. Tweak this value to gain more performance or render sprites in the distance to your liking.
render.floodfill - Enabled by default. Emulates vanilla flood filling with missing upper and lower textures.

Testing Tech:

Spoiler

Helion has full testing capabilities where every vanilla action special is tested for expected behavior. This was accomplished by creating a world simulation without rendering and manually ticking the simulation and asserting expected values (like sector height values etc). Code for these tests can be seen here:
https://github.com/Helion-Engine/Helion/blob/master/Tests/Unit/GameAction/Vanilla/VanillaActions.cs
Examples for Vanilla boss behavior tests. This tests behavior where sectors tagged 666 lower when barons die, or the level exits when the cyberdemon dies in E2M8.
https://github.com/Helion-Engine/Helion/blob/master/Tests/Unit/GameAction/Boss.cs

 

Brain dump of more technical features:

Spoiler

Brain dump of more technical features:
Console with searching and auto-complete features.
    Page Up/Page Down to scroll.
    'Commands' to view all commands.
    'Search [text]' to view all commands containing the search text.
    Press tab once will display all matching commands.
    Press tab on a completed command will display the documentation for the command.
    Double pressing tab will auto-complete.
OpenGL 3.3:
    Vsync support.
    Decoupled rendering with interpolation.
    Alpha/transparency support.
    Examples of rendering console commands: (render.vsync, render.maxfps).
HUD support:
    Minimal hud.
    Crosshair that changes red when targeting.
    Full hud background can be changed with hud.backgroundtexture console command. Can be any texture/flat/patch/image.
    Hud scaling using hud.scale console command.
Mouse look support.
    mouse.look 0 in console to disable.
    game.autoaim 0 to disable autoaim.
Automap:
    Zoom in and out with +/- keys.
    Look around with arrow keys.
    mark.add console command to add a flashing map marker.
    Lines requiring keys are colore matched.
    Teleport lines are colored green.
Screenshots with print screen key.
Midi/mus playback using Fluidsynth.
    Default sound font can be changed in the SoundFonts folder.
Supports 3D physics with 3D bridge things and things walking on other things.
    Can be disabled with console command compatibility.infinitelytallthings.
Vanilla light dropoff emulation.
Uses the vanilla random table.
Widescreen asset support.
Uses ZDoom as a base. Currently only supports enough ZDoom features for Vanilla/Boom functions.
Supports wad, pk3, zip, and direct folders.
Supports nearly all Boom features.
    Wads such as Eviternity and Fractured Worlds are fully functional.
    Does not support light level changes as door opens/closes.
    Does not support bumping off walls when sliding on ice floors.
    Does not support colored sectors.
    Does not support all intricies of friendly monsters from MBF.
Supports MBF21.
Dehacked, BEX, and DEH extra.
Decorate (not fully functional).
Statistics.
    Show statistics on hud with hud.showstats
    Output after level completion with -levelstat (same output format as Boom).
Save/Load menu.
    Automatically writes level with name.
    Only shows results for the current wad(s).
Demos.
    Uses -record/-play parameters like original.
Uses zdbsp (painfully) translated into C#.
   https://github.com/nstlaurent/zdbspSharp

 

tldr
Supports Doom shareware, the Ultimate Doom, Doom II, TNT, Plutonia, and Chex Quest IWADS (IWAD can be dropped in main folder, but there is no selection UI)
Supports usual parameters such as -iwad, -file, -skill, -warp, +map
Supports Vanilla, Boom*, MBF21. dehacked, bex, dehextra
Windows - Windows 7 minimum
.NET 7 runtime. Should prompt if not already installed. (Note: not required if using 'with runtime' packages)
https://dotnet.microsoft.com/en-us/download/dotnet/7.0
OpenGL 3.3 required
Config.ini / console for configuration
mouse.look 0 and game.autoaim 1 for classic configuration

hud.showstats 1 for hud stats

 

For error: Unable to load DLL 'glfw' or one of it's dependencies:
https://aka.ms/vs/17/release/vc_redist.x64.exe

 

*Download here:
https://github.com/Helion-Engine/Helion/releases/latest

 

*Source:
https://github.com/Helion-Engine/Helion

Benchmarks

 

Credits:
We tried to credit specific ports and people/teams as much as possible in code.

Obviously id software, as we referenced the original source.
Randi Heit and the ZDoom team for zdbsp and the ZDoom format specifications.
Lee Killough and the Boom team. MBF was referenced for constants and functionality to match Boom special functionality.

@Redneckerzand @Doomkid for play testing.

Edited March 31 by hobomaster22

[Redneckerz]

Some additional notes from an occassional playtester:

 

This is some serious stuff. As much as us Doomers like to play with various source ports - They all have to rely on the Doom rendering loop. Especially in the case of GZDoom, you are going to hit limits simply because Doom's renderer isn't built to play completely nice with modern architecture.

 

Helion seeks to change this. But it does so with a custom renderer. This represents other challenges:

• Doom behavior needs to be perfect. This community harvests enough know how to instantly point out the flaws with this approach, so Doom behavior needs to be absolute.
  • This goes especially for Vanilla behavior, which is where all things start. I have supplied several examples of Vanilla pushing mapsets in order to ensure that Helion can meet these edge cases: If it can run an edge case, it can run everything that doesn't hit those limits. The same goes for ZDoom and Boom wads.
• One of Helion's goals is to remove the overhead extreme WADS now impose on ports (like Planisphere 2, Frozen Time, etc). Although most users can get good performance on these WAD's, this is purely through brute forcing and not so much because the renderer itself. Helion wants an optimized experience on these WADS.
• Helion is a project long in the making. This isn't a ''I have an idea, how should i implement it'' but rather ''We have a certain goal in mind and we are going to meet it.'' Whilst my role was small (I just relayed advice and links and some occasional testing), the folks behind this (Hobo and Water) have proven that they could meet the standards they have set for themselves. Planisphere 2 is now 60 FPS on low end hardware, removing the brute forcing cap.
• Helion isn't, atleast in my eyes, a GZDoom competitor. Whilst Helion is obviously inspired by it, it is rather a supplemental product for high performance Dooming. A close competitor would be Ironwail, the Quake Engine port whose renderer was rewriten for performance.

I like Helion because, like @kgsws Ace Engine, it approaches a Doom port (Technically it isn't one) differently. A huge amount of effort went into this implementing Vanilla, Boom, MBF21, DEHEXTRA and ZDoom behaviors.

 

Its the kind of thing where source port authors would say: ''It can be done, but nobody is actually mad enough to do it, because it requires such an amount of work to get it right.''

 

I believe Hobo and Water have done just that. Doing it the hard way to challenge one of the things that makes Doom, well, Doom.

 

Helion isn't a perfect program, but i do believe it can withstand some beating. If just for the curiosity, try it out. Slap some Doom-renderer abusing WADS against it, and see how it fares.

[fabian]

This has probably the most passive aggressive license I have ever seen. Is it even allowed to clone the repository? 

[Doomy__Doom]

16 minutes ago, fabian said:

This has probably the most passive aggressive license I have ever seen. Is it even allowed to clone the repository? 

https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository

Github states that if a repo is public, according to its TOS people are allowed to view and clone, although they are discussing a "no license = all right reserved" scenario there. Not a lawyer(tm).

[hobomaster22]

38 minutes ago, fabian said:

This has probably the most passive aggressive license I have ever seen. Is it even allowed to clone the repository? 

It’s obsolete. I should have checked. When I am back at my computer I will update it. Should just be gpl3.

[hobomaster22]

A lot have work has been going into Helion for rendering. One thing we have always wanted to do is handle static rendering. Traversing the BSP tree is painfully slow on complicated maps. The way Doom works makes this pretty hard to unwind, but work is being done here. Helion can currently cache static geometry and use the BSP tree for rendering sprites and dynamic data. This means we can set distance cut offs for BSP traversal and still render *something*. So now trash PCs can reasonably render something like Planisphere 2... because why not.  Texture animations are handled. Skies are not rendering with this feature... yet.

 

Cheap Amazon special micro pc from 2019
Windows 10
Intel Celeron
Intel HD 500
4GB RAM

This PC is painful. It's slow just using the desktop. Hard drive access seems to be a huge bottleneck even though it has an SSD. Let's see what it can do anyway.

Rendering at 1920x1080

Planisphere 2 (2048 cutoff): 60 FPS
Planisphere 2 (4096 cutoff) 39 FPS
Sunlust MAP28 (2048 cutoff): 55 FPS
Dance on the Water MAP04 (2048 cutoff): 52 FPS
Eviternity MAP26 (2048 cutoff): 45 FPS

 

Spoiler

 

 

Budget laptop from 2014
Windows 8.1
AMD A6-5200
AMD Radeon HD  8400
4GB RAM

Compared to the previous pc this laptop is useable. Hard drive access isn't painful like the cheap Amazon micro pc.

 

Rendering at 1024x768
Planisphere 2 (2048 cutoff): 75 FPS
Planisphere 2 (4096 cutoff) 55 FPS
Sunlust MAP28 (2048 cutoff): 97 FPS
Dance on the Water MAP04 (2048 cutoff): 84 FPS
Eviternity MAP26 (2048 cutoff): 86 FPS

 

Spoiler

 

 

 

 

 

 

And now for something more modern (but still a laptop because why not. Even if it is a beast of a laptop.)

Windows 10
Ryzen 5900HS
RTX 3070
16 GB RAM

 

Here the numbers can get pretty absurd. Especially if a lot of the map is static.

Render at 1920x1080
Planisphere 2 (8192 cutoff): 671 FPS
Dance on the Water MAP04 (4096 cutoff): 1800 FPS
Sunlust MAP28 (4096 cutoff): 250 FPS
Eviternity MAP26 (4096 cutoff): 368 FPS

 

Spoiler

 

 

 

 

 

 

[PKr]

This is so cool!

 

Since we have already talked about mouse interpolation briefly in another topic, I have to point out that... It doesn't work properly in Helion (stutters while strafing and moving camera around). 😄 That said it's not needed at all, as mouse inputs translate 1:1 to what you can see on the screen. Perfection. And input lag wise seems like it even beats GZDoom.

 

One question though. Have you tested it on variable refresh rate monitors?

Edited November 12, 2022 by PKr

[hobomaster22]

33 minutes ago, PKr said:

This is so cool!

 

Since we have already talked about mouse interpolation briefly in another topic, I have to point out that... It doesn't work properly in Helion (stutters while strafing and moving camera around). 😄 That said it's not needed at all, as mouse inputs translate 1:1 to what you can see on the screen. Perfection. And input lag wise seems like it even beats GZDoom.

 

One question though. Have you tested it on variable refresh rate monitors?

I appreciate the comment :). I did put a lot of effort to pull the raw mouse input from Windows as OpenTK unfortunately doesn't support it. As for mouse interpolation, there is an option for it (mouse.interpolate 1) which should make it feel more prboom/dsda-doom.
 

As for variable refresh rate, I haven't really played with it. I have a display that supports G-SYNC but admittedly I don't have a lot of knowledge about it. Helion supports adaptive v-sync as well. I think it was packaged with it vsync on, but not set to adaptive. I'm thinking adaptive should probably be the default (render.vsync 2).

[PKr]

19 minutes ago, hobomaster22 said:

As for variable refresh rate, I haven't really played with it. I have a display that supports G-SYNC but admittedly I don't have a lot of knowledge about it. Helion supports adaptive v-sync as well. I think it was packaged with it vsync on, but not set to adaptive. I'm thinking adaptive should probably be the default (render.vsync 2).

Oh I see. Well I asked because if you haven't tested it a lot, then in case if somebody will complain about the game stuttering in g-sync mode in the future suggest them to set render.forcepipelineflush to True and under no circumstances to use custom frame rate limits (either the Helion's in-game framerate limiter or driver one/etc) while low latency mode is set to on or ultra... For some reason it causes insane frametime spikes.

 

Both low latency mode and in-game framerate limiter seem to be working perfectly fine separately though - so it's ok to use either option.

 

P.S. In fact, no, after a little bit more testing it seems like low latency mode set to on provides better (perfect) results while in g-sync mode. Using custom framerate limits still can cause some frametime spikes (not as extreme as fps cap + low latency though).

Edited November 12, 2022 by PKr

[hobomaster22]

Here is a video demonstrating what we are working on. This is very new and I am just scratching the surface with this one.

What this does is stops traversing the BSP at the configured distance. Dynamic sections (changing lights, sector movement, and scrolling textures) will not be rendered. However, static geometry will still be rendered even past the cut off.

Focus on the large scrolling mountain, torches, any flashing lights and watch them phase in and out as they come into distance.

 

[hobomaster22]

Planisphere 2 more than playable.
 

 

[DrR0Ck]

Is it possible to invert the mouse Y axis?  Did some googling and checked the ini file but nothing leaped out at me.

 

Thanks!

[hobomaster22]

8 minutes ago, DrR0Ck said:

Is it possible to invert the mouse Y axis?  Did some googling and checked the ini file but did not have any luck. 

 

Thanks! 

Hi! You can set the yaw and pitch values to a negative number. Setting mouse.pitch to -1 should invert the Y.

[JustAthel]

I am assuming just based off what I'm reading and seeing here you're aiming for vanilla compatibility? If that's the case, I can run this through some WADs that I know push the scopes of vanilla boundaries and report back what I experience. This is some pretty excellent stuff on display here!

[hobomaster22]

1 hour ago, Athel said:

I am assuming just based off what I'm reading and seeing here you're aiming for vanilla compatibility? If that's the case, I can run this through some WADs that I know push the scopes of vanilla boundaries and report back what I experience. This is some pretty excellent stuff on display here!

I would like to support as much as reasonably possible, which is kind of hard to define. I thought I understood Doom really well until I developed this. It was quite a humbling experience, especially when I got to dehacked. I would definitely like to know what works and what doesn't for sure.

[JustAthel]

Alright, give me a few days and I think I'll be able to come up with something usable for you!

[jeremieh]

This is one of the coolest things I’ve seen in a while.  you are an absolute wizard!

[Master O]

On 10/30/2022 at 6:32 AM, hobomaster22 said:

Hello everyone,

 

Helion is a new port developed in C# using .NET Core by WChrisK and myself. The main objectives of Helion are to have readable code along with good performance. Usually these are counter-intuitive but we put a good amount of effort to hit these goals. It's my hope that those interested in the source find it easy to understand and can learn how games like Doom work. Helion is different from most ports in that started entirely from scratch and isn't based off any existing code base. Some very specific code sections were basically translated line by line such as enemy action functions to match the original game. The base of Helion uses ZDoom specifications like decorate, mapinfo, gameinfo, and ZDoom action specials etc. We weren't looking to re-invent the wheel with new formats.

 

Helion supports decorate/ZDoom specials. However, it is partial and implemented up to a point to support Vanilla, Boom, and MBF21. If a wad includes both dehacked and decorate, the dehacked will be used by default as it's currently more stable. Does not support different viewport sizes in fullscreen. Only supports fullscreen at the native resolution. This means the full sized hud is not technically correct as it does not change the viewport size.

Screenshots:

  Hide contents

Note: hud.showfps and hud.showstats set to 1

 

Doom 2 MAP01:

 

 

Doom E1M1:

 

Eviternity MAP29:

 

Fractured Worlds MAP05:

 

Testing Tech:

  Hide contents

Helion has full testing capabilities where every vanilla action special is tested for expected behavior. This was accomplished by creating a world simulation without rendering and manually ticking the simulation and asserting expected values (like sector height values etc). Code for these tests can be seen here:
https://github.com/Helion-Engine/Helion/blob/master/Tests/Unit/GameAction/Vanilla/VanillaActions.cs
Examples for Vanilla boss behavior tests. This tests behavior where sectors tagged 666 lower when barons die, or the level exits when the cyberdemon dies in E2M8.
https://github.com/Helion-Engine/Helion/blob/master/Tests/Unit/GameAction/Boss.cs

 

Brain dump of more technical features:

  Hide contents

Brain dump of more technical features:
Console with searching and auto-complete features.
    Page Up/Page Down to scroll.
    'Commands' to view all commands.
    'Search [text]' to view all commands containing the search text.
    Press tab once will display all matching commands.
    Press tab on a completed command will display the documentation for the command.
    Double pressing tab will auto-complete.
OpenGL 3.3:
    Vsync support.
    Decoupled rendering with interpolation.
    Alpha/transparency support.
    Examples of rendering console commands: (render.vsync, render.maxfps).
HUD support:
    Minimal hud.
    Crosshair that changes red when targeting.
    Full hud background can be changed with hud.backgroundtexture console command. Can be any texture/flat/patch/image.
    Hud scaling using hud.scale console command.
Mouse look support.
    mouse.look 0 in console to disable.
    game.autoaim 0 to disable autoaim.
Automap:
    Zoom in and out with +/- keys.
    Look around with arrow keys.
    mark.add console command to add a flashing map marker.
    Lines requiring keys are colore matched.
    Teleport lines are colored green.
Screenshots with print screen key.
Midi/mus playback using Fluidsynth.
    Default sound font can be changed in the SoundFonts folder.
Supports 3D physics with 3D bridge things and things walking on other things.
    Can be disabled with console command compatibility.infinitelytallthings.
Vanilla light dropoff emulation.
Uses the vanilla random table.
Widescreen asset support.
Uses ZDoom as a base. Currently only supports enough ZDoom features for Vanilla/Boom functions.
Supports wad, pk3, zip, and direct folders.
Supports nearly all Boom features.
    Wads such as Eviternity and Fractured Worlds are fully functional.
    Does not support light level changes as door opens/closes.
    Does not support bumping off walls when sliding on ice floors.
    Does not support colored sectors.
    Does not support all intricies of friendly monsters from MBF.
Supports MBF21.
Dehacked, BEX, and DEH extra.
Decorate (not fully functional).
Statistics.
    Show statistics on hud with hud.showstats
    Output after level completion with -levelstat (same output format as Boom).
Save/Load menu.
    Automatically writes level with name.
    Only shows results for the current wad(s).
Demos.
    Uses -record/-play parameters like original.
Uses zdbsp (painfully) translated into C#.
   https://github.com/nstlaurent/zdbspSharp

 

The future

  Hide contents

Work on Helion has slowed down a lot. Helion was originally started in 2019 and things in our lives have changed a lot over the years, ultimately shifting our priorities. Helion had a lot of feature goals that we wanted that became unrealistic as our available free time dwindled. We decided three years later it needs to be released. While Helion isn't exactly what we originally set out for, it is a fully functional game.

 

tldr
Supports Doom shareware, the Ultimate Doom, Doom II, TNT, Plutonia, and Chex Quest IWADS (IWAD can be dropped in main folder, but there is no selection UI)
Supports usual parameters such as -iwad, -file, -skill, -wap, +map
Supports Vanilla, Boom*, MBF21. dehacked, bex, dehextra
Currently Windows only - Windows 7 minimum
.NET 6 runtime. Should prompt if not already installed. Direct links just in case:

https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/runtime-desktop-6.0.10-windows-x64-installer?cid=getdotnetcore
https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/runtime-6.0.10-windows-x64-installer
OpenGL 3.3 required
Config.ini / console for configuration
mouse.look 0 and game.autoaim 1 for classic configuration

hud.showstats 1 for hud stats

 

*Download here:
https://github.com/Helion-Engine/Helion/releases/latest

 

*Source:
https://github.com/Helion-Engine/Helion

 

Credits:
We tried to credit specific ports and people/teams as much as possible in code.

Obviously id software, as we referenced the original source.
Randi Heit and the ZDoom team for zdbsp and the ZDoom format specifications.
Lee Killough and the Boom team. MBF was referenced for constants and functionality to match Boom special functionality.

@Redneckerzand @Doomkid for play testing.

 

How well does it work with nuts.wad?  :D

[hobomaster22]

40 minutes ago, Master O said:

 

How well does it work with nuts.wad?  :D

 Depends on your CPU, you would have to give a try. On the original nuts.wad I can currently stay around 60fps when the initial onslaught begins.

[Doomkid]

This port feels so good, man. Just tried the build from ~3 weeks ago (finally) and am really loving the feel. I know this is a random detail to latch onto and it's acknowledged in the OP, but I'm eager for viewport size to be more adjustable than it is currently, but I think you explained to me on Discord a while back that it would be a bit painful.

 

Keep it up man, more people need to try this thing out! This is kinda an empty post but damn, I just had to give some more acknowledgement.

[hobomaster22]

16 minutes ago, Doomkid said:

This port feels so good, man. Just tried the build from ~3 weeks ago (finally) and am really loving the feel. I know this is a random detail to latch onto and it's acknowledged in the OP, but I'm eager for viewport size to be more adjustable than it is currently, but I think you explained to me on Discord a while back that it would be a bit painful.

 

Keep it up man, more people need to try this thing out! This is kinda an empty post but damn, I just had to give some more acknowledgement.

It's definitely on the list. We just got really excited about the new rendering developments, which is where our focus is now. Even some of those most garbage integrated integrated Intel graphics cards can render Planisphere at a somewhat playable FPS. So maps that normally crush existing ports will run on most people's machines in excess of 100fps now, if not over 1k fps... And on this topic, I would like to know what Vanilla/Boom maps that people love to play but run slow on their current machines so we have more to test against with our big rendering upgrade.

[Redneckerz]

59 minutes ago, hobomaster22 said:

It's definitely on the list. We just got really excited about the new rendering developments, which is where our focus is now. Even some of those most garbage integrated integrated Intel graphics cards can render Planisphere at a somewhat playable FPS. So maps that normally crush existing ports will run on most people's machines in excess of 100fps now, if not over 1k fps... And on this topic, I would like to know what Vanilla/Boom maps that people love to play but run slow on their current machines so we have more to test against with our big rendering upgrade.

Knee Deep in KDIZD ofcourse.

[Bauul]

I tried this the other day on Sunder Map15 as a bit of a stress test, and was slightly surprised to see it ran significantly worse than GZDoom 4.9.0 - 45fps for Helion versus 115fps for GZDoom.

 

The impression I got from the OP was that Helion should be quicker than GZDoom, so I'm trying to understand what might be causing the slow-down.  One thought I had - is Helion a software rendering engine?  It could be the GPU is doing the heavy lifting for GZDoom.

[hobomaster22]

6 minutes ago, Bauul said:

I tried this the other day on Sunder Map15 as a bit of a stress test, and was slightly surprised to see it ran significantly worse than GZDoom 4.9.0 - 45fps for Helion versus 115fps for GZDoom.

 

The impression I got from the OP was that Helion should be quicker than GZDoom, so I'm trying to understand what might be causing the slow-down.  One thought I had - is Helion a software rendering engine?  It could be the GPU is doing the heavy lifting for GZDoom.

We are not using software rendering. 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. It's hard to develop something from scratch in a managed language and compare yourself to ports that have had decades of performance tuning written in C/C++. This initial release is using BSP traversal like everyone else, and we aren't using frustum occlusion either which is probably the biggest performance gap on a gigantic map like that. We didn't originally intend on having our initial release using BSP traversal, but life gets in the way and it's stable. I have found some more time and working hard to try to get this new version out for people to test. With this rendering upgrade, at least on my machine with a mobile RTX 3070 Sunder Map15 gets above 700fps. The videos I posted above demonstrate some of the things we are working on, and it has become a lot faster from even that.

[jeremieh]

On 11/17/2022 at 12:38 PM, Master O said:

 

How well does it work with nuts.wad?  :D

tested it myself with nuts3- port still chugs but still produces enough frames to be playable on a 6 core

[hobomaster22]

7 hours ago, jeremieh said:

tested it myself with nuts3- port still chugs but still produces enough frames to be playable on a 6 core 

This is mostly going to be determined by single core performance. Nuts3 is an absolutely brutal performance test. Rendering large thing/monster counts is a huge bottleneck right now. It's impressive your CPU was fast enough to be playable. I'm hoping to get this next release out by next week that will increase rendering performance dramatically.

[Turin Turambar]

Quote

 

Planisphere 2 (8192 cutoff): 671 FPS
Dance on the Water MAP04 (4096 cutoff): 1800 FPS
Sunlust MAP28 (4096 cutoff): 250 FPS
Eviternity MAP26 (4096 cutoff): 368 FPS
 

 

 

How do you change the cutoff? I searched commands, but I couldn't find anything with a similar name.

 

edit: actually the first map I tested was Sunder map 15 and like others before, I had a similar performance to GZDoom... but I see your reply above. Good luck!

[hobomaster22]

19 minutes ago, Turin Turambar said:

 

How do you change the cutoff? I searched commands, but I couldn't find anything with a similar name.

 

edit: actually the first map I tested was Sunder map 15 and like others before, I had a similar performance to GZDoom... but I see your reply above. Good luck!

These posts are what we are working on for the next release. For most machines this next release will make the current version look like a joke in terms of performance. We are just doing final testing and cleanup and it should be available in the next few days. 

[hobomaster22]

Looks like I will be releasing this sooner than expected. Here is Sunder MAP15. The funny thing is recording with OBS studio actually drops the frame rate about 200FPS, but the frame rate is so absurdly high it doesn't matter. Wrapping up some final testing and it should be available to test today.

 

 

[hobomaster22]

Goodbye BSP tree rendering. This release has what we always wanted. Static mode is enabled by default, and here are the options to play with:
render.staticmode - Enabled by default. Only uploads map geometry to the GPU when changed.
render.blockmap - Enabled by default. Uses the blockmap for rendering sprites and dynamic sectors. When disabled it will use the BSP tree.
render.maxdistance - 6000 by default. Stops rendering sprites and dynamic sectors past this distance. Tweak this value to gain more performance or render sprites in the distance to your liking.
render.staticlights - Enabled by default. This uploads light changes on the fly to the GPU. Some old integrated cards might hate this for maps that abuse light changes (*cough* Dance on the Water MAP01)

 

So, what is the catch with static rendering? For one, the automap currently can't work the same way. Because Doom marked the lines you saw by using the BSP traversal in the redering, this won't work without BSP tree traversal. For now with static mode you get the entire map in the automap view. Second, anything that changes how a sky would render isn't handled. These cases are kind of rare and it's not a trivial thing to solve right now, but it's on the list. There are also likely to be a few rendering glitches either way. Trying to render Doom maps riddled with software abuse hacks in a hardware world is complicated.

 

For the majority of PCs this rendering change multiplies the rendering performance significantly. A budget laptop from 2014 running an AMD Radeon HD 8400 can play a map like Eviternity MAP26 and stay above 100fps almost the entire time. I actually forgot I was playing a piece of garbage laptop with Windows 8.1 (gross). Potato PCs can are able play Planisphere 2 even with the render.maxdistance value defaulted to 6000.

 

Download here:
https://github.com/Helion-Engine/Helion/releases/tag/0.9.1.0

 

Sprite rendering and world simulation with tons of monsters is still a bottleneck. So extreme maps like nuts and nuts3 depending on your CPU could be an issue.

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