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

[Master O]

2 minutes ago, hobomaster22 said:

They are different, the naming is kind of dumb. The desktop one is basically the runtime for Windows dependencies that we still have hanging around. For the next release we are looking at nuking this entirely since .net7 finally lets us build an entire package without requiring the runtime. This requires removing the final windows dependencies once and for all (which needs to happen anyway).

 

Also, thank you and everyone else working on Helion. This is excellent work being done.  Doom definitely needs a source port that better utilizes modern hardware.

[camper]

How would multiplayer work on the Helion engine if there was one? What improvements would there be in gameplay?

[hobomaster22]

2 hours ago, camper said:

How would multiplayer work on the Helion engine if there was one? What improvements would there be in gameplay?

We would likely implement the lock step multiplayer that most ports have first. The improvement would really be the rendering improvements that Helion has. Coop would be playable on large maps with relatively slow hardware, whatever junk laptops you have lying around would likely be fine.

 

We have been looking into what the bottlenecks slow GPUs have like the Radeon HD 8400 in our benchmarks. Without spoiling too much, in our testing we have increased the performance another 30-70% depending on the map thanks to two optimizations in our rendering techniques. Sunlust MAP28 and Frozen Time were already playable above 60fps on junk hardware anyway. But we really wanted to push Summer of Slaughter MAP32 into more playable territory on trash hardware. Most of Sunder is playable. Something exciting about pushing the limits this hard.

[Darkcrafter07]

4 hours ago, hobomaster22 said:

We would likely implement the lock step multiplayer that most ports have first. The improvement would really be the rendering improvements that Helion has. Coop would be playable on large maps with relatively slow hardware, whatever junk laptops you have lying around would likely be fine.

 

We have been looking into what the bottlenecks slow GPUs have like the Radeon HD 8400 in our benchmarks. Without spoiling too much, in our testing we have increased the performance another 30-70% depending on the map thanks to two optimizations in our rendering techniques. Sunlust MAP28 and Frozen Time were already playable above 60fps on junk hardware anyway. But we really wanted to push Summer of Slaughter MAP32 into more playable territory on trash hardware. Most of Sunder is playable. Something exciting about pushing the limits this hard.

I'm really curious why GZDoom and PRboom plus still have that BSP, it's good when you need to limit max polygons on the screen to 30-60, maybe some more but as soon as geometry complexity goes higher it becomes a really heavy burden that is the same as if a small tunnel was build on the way to the big army.

 

It's bad even for software rendering for the same reasons, I think something like occluders would have made the matters insanely faster on today hardware.

Is this really hard to get that part away?

[hobomaster22]

34 minutes ago, Darkcrafter07 said:

I'm really curious why GZDoom and PRboom plus still have that BSP, it's good when you need to limit max polygons on the screen to 30-60, maybe some more but as soon as geometry complexity goes higher it becomes a really heavy burden that is the same as if a small tunnel was build on the way to the big army.

 

It's bad even for software rendering for the same reasons, I think something like occluders would have made the matters insanely faster on today hardware.

Is this really hard to get that part away?

I think for one it's because it was the way it has always been done. Every other source port was based off another at some point, and it's already there. It's difficult to take the existing code base and completely gut the fundamental rendering method. This was one of the main reasons we started from scratch. We didn't want to be burdened with a code base that was intertwined with the BSP for rendering. Starting from scratch is a massive undertaking in itself even if you use the BSP tree like we did from the start.

Second, people didn't seem to think ditching the BSP could be done. I known I've seen posts saying it's not feasible in the past. It has been pretty difficult, given Doom's nature of everything is dynamic and you can't safely assume something will be static. Add this with it's rendering quirks and bugs that map makers rely on as features and trying to adopt a more modern approach to rendering starts to crumble. Sprite rendering is expensive, flood filling is expensive, and Boom's 242 transfer heights special is an absolute nightmare.

While this method is the optimal route, it's really hard to get right. It's a lot easier to wipe the slate clean, traverse the BSP, and dump the data out. Any changes that may have happened since the last render will be reflected. For example light changes with this method are free. You just read whatever the light level happens to be. For Helion we have to do something with our state to deal with these changes. And up until the last release this was incredibly expensive to deal with. This is one of the main reasons React was created for web development. Manipulating the DOM in javascript made UI state management difficult and more problematic the more things were modified.

Edited September 25, 2023 by hobomaster22

[Master O]

@hobomaster22, is Helion gonna support UDMF at all?

[hobomaster22]

3 hours ago, Master O said:

@hobomaster22, is Helion gonna support UDMF at all?

Yes it's definitely on the list. We will likely be looking at it after this next release is completed.

[Madgunner]

On 9/25/2023 at 11:11 AM, hobomaster22 said:

We would likely implement the lock step multiplayer that most ports have first. The improvement would really be the rendering improvements that Helion has. Coop would be playable on large maps with relatively slow hardware, whatever junk laptops you have lying around would likely be fine.

I gotta admit I'm actually surprised that p2p would work for Helion. Admittedly it works decent in vanilla doom assuming you're using a lan and the map isn't too intensive, but on more advanced ports such as zdoom/gzdoom its definitely another story and performs rather poorly to the point where its near unplayable even over lan. I would have thought that having a large monster count on some of the resource intensive maps would cripple a p2p solution. Would there be a reason why it would be preferable to c/s for netcode? I actually have seen some people in Unity who use p2p for multiplayer, however I'm not sure how well it works since I ended up going with regular c/s using the Mirror library since Unity's netcode is next to non-existent.

 

Edit: NVM I'm wrong on this. I did a little reading before bedtime and apparently p2p actually uses less bandwidth than c/s. I naively assumed it uses more since all connections communicate with each other. 

Edited September 27, 2023 by Madgunner

[hobomaster22]

17 hours ago, Madgunner said:

I gotta admit I'm actually surprised that p2p would work for Helion. Admittedly it works decent in vanilla doom assuming you're using a lan and the map isn't too intensive, but on more advanced ports such as zdoom/gzdoom its definitely another story and performs rather poorly to the point where its near unplayable even over lan. I would have thought that having a large monster count on some of the resource intensive maps would cripple a p2p solution. Would there be a reason why it would be preferable to c/s for netcode? I actually have seen some people in Unity who use p2p for multiplayer, however I'm not sure how well it works since I ended up going with regular c/s using the Mirror library since Unity's netcode is next to non-existent.

 

Edit: NVM I'm wrong on this. I did a little reading before bedtime and apparently p2p actually uses less bandwidth than c/s. I naively assumed it uses more since all connections communicate with each other. 

No problem! It is less bandwidth and from an implementation standpoint much simpler. I didn't mean to say p2p was better than having a client/server solution like Odamez/Zan/ZDaemon, but significantly simpler to implement so we should support it. It has it's own set of issues and limitations but a full client/server solution would become an entire project in itself.

[Madgunner]

Well I was hoping to test Helion with my GTX 570 HD, but unfortunately, it looks like my card is bad and I was unable to test with it since the screen resolution was locked at 800x600 and the graphics driver didn't work. I'm going to try installing this card in another computer to see if it by some minuscule chance it happens to be something else that's causing the issue, but the fact that this computer runs perfectly with a different card and that the graphics are garbled, makes me strongly suspect that the card is the issue. It's too bad it would have likely gotten some really good fps with Helion.

[Blzut3]

On 9/26/2023 at 5:32 PM, Madgunner said:

but on more advanced ports such as zdoom/gzdoom its definitely another story and performs rather poorly to the point where its near unplayable even over lan.

GZDoom should definitely be fine on a LAN (have used it quite a bit), but if you have wireless clients it does seem to struggle with the shared medium.

[Professor Hastig]

On 9/25/2023 at 9:55 PM, Darkcrafter07 said:

I'm really curious why GZDoom and PRboom plus still have that BSP, it's good when you need to limit max polygons on the screen to 30-60, maybe some more but as soon as geometry complexity goes higher it becomes a really heavy burden that is the same as if a small tunnel was build on the way to the big army.

 

You are missing something important here:

 

The BSP not only gives you a limited set of geometry to render but also visibility information to help out which parts of a map to process.

Take dynamic lights as an example. If you do not know which parts of the map are visible you also do not know which lights are needed, so you'd have to process them all, which may turn out more costly than traversing the BSP. Rendering the plain level in one go without effects only requires some scheme to keep the data on the GPU updated, but your mileage with this may vary once you have to consider other things that are costly to process.

 

 

On 9/25/2023 at 9:55 PM, Darkcrafter07 said:

It's bad even for software rendering for the same reasons, I think something like occluders would have made the matters insanely faster on today hardware.

 

That may well be, but you have to contend with map data that has no such information readily available, it just uses one-sided walls as occluders and calculates occlusion on the fly for two-sided ones - as you may guess the latter is the problem here, because due to the dynamic nature of the level format these can change at random and may be hard to guess for cases when a wall closes later on during gameplay.

As it stands, the BSP is very fast because it only looks at every relevant map object only once, there is just one exception to it: Large open areas with lots of connected sectors. In this case it has to calculate occlusion of each of the lines - and fail every time, of course. I'd guess that any Doom port programmers would jump for joy if someone could solve this conundrum.

To handle those reliably with visibility clipping you really need more info than is there. If you knew, for example, that if sector A is visible, sectors B-F are also always visible, you could just remove all lines between these sectors from the BSP and get an instant speed-up. The problem is, you do not know and are limited to heuristics, and if these fail you may get visual corruption or unexpected slowdowns with some things that need proper visibility checks.

 

 

[hobomaster22]

4 hours ago, Professor Hastig said:

 

You are missing something important here:

 

The BSP not only gives you a limited set of geometry to render but also visibility information to help out which parts of a map to process.

Take dynamic lights as an example. If you do not know which parts of the map are visible you also do not know which lights are needed, so you'd have to process them all, which may turn out more costly than traversing the BSP. Rendering the plain level in one go without effects only requires some scheme to keep the data on the GPU updated, but your mileage with this may vary once you have to consider other things that are costly to process.

 

There are ways to handle things outside of the BSP tree. Yes, Doom has some really unique problems that are Doom and hard to solve because modern video games don't have Doom's quirks. On the plus side, maps that are considered stressful and complex really aren't hard for GPUs of the last 10 years to process. So we also have this on our side. We have been working hard to solve these problems the best we can while keeping the game 'Doom'. The last release solved the issue of sector light updates, and we have just solved the issue of flood filling for the next. Even in our benchmarks that saw very high numbers, we were surprised to find out how much flood filling in the last release was a massive bottleneck. Quite a few of the benchmark maps were seeing 30%-50% FPS drops from flood filling. The method we have for the next release will increase Summer of Slaughter MAP32 about 200% on modern cards, and gives us the capability to update them at runtime which we didn't have before. There are ways to do these things, it just requires thinking outside the box.

[Graf Zahl]

On 9/25/2023 at 9:55 PM, Darkcrafter07 said:

I'm really curious why GZDoom and PRboom plus still have that BSP, it's good when you need to limit max polygons on the screen to 30-60, maybe some more but as soon as geometry complexity goes higher it becomes a really heavy burden that is the same as if a small tunnel was build on the way to the big army.

 

It's bad even for software rendering for the same reasons, I think something like occluders would have made the matters insanely faster on today hardware.

Is this really hard to get that part away?

 

Have you ever tested other occlusion algorithms? Most are effectively quite a bit slower than BSP traversal. If you ran any of those on a highly detailed Doom map, they'd crash and burn because they still have to cope with the same problem the BSP traverser is facing, i.e. it cannot take visibility state for granted and has to dynamically re-check it.

 

If you need efficient visibility culling the map needs to provided the needed info. In modern games this is easy because you got a static mesh that never changes, so all you need to consider are objects like doors which are not normally part of the map geometry but separate entities. This will allow to do this stuff far more efficiently. In absence of that there really is nothing faster than using a BSP. I've toyed around with other engines, e.g. Build for Raze, and their algorithms are far less performant and would show signs of stress at considerably less detailed maps.

 

[hobomaster22]

13 minutes ago, Graf Zahl said:

If you need efficient visibility culling the map needs to provided the needed info. In modern games this is easy because you got a static mesh that never changes, so all you need to consider are objects like doors which are not normally part of the map geometry but separate entities. This will allow to do this stuff far more efficiently. In absence of that there really is nothing faster than using a BSP. I've toyed around with other engines, e.g. Build for Raze, and their algorithms are far less performant and would show signs of stress at considerably less detailed maps.

Seems to me like this is missing the point. Doom really doesn't need visibility culling to the extent the BSP provides as Helion has shown.

[Graf Zahl]

That entirely depends on what you need it for. If it is to exclude things like portals or save on expensive calculations like collecting active dynamic lights for a specific surface is very much needed. If you just want to render the plain level as-is, modern graphics hardware surely is fast enough. I've seen dynamic lights bring down FPS on vanilla maps even on good hardware when used poorly, so rendering these in sectors you can't see is something you need to avoid. There's surely room for optimization in that area, but the whole notion was about BSP presumably being a slow occlusion culling algorithm which is simply not correct.

[Darkcrafter07]

58 minutes ago, Graf Zahl said:

 

Have you ever tested other occlusion algorithms? Most are effectively quite a bit slower than BSP traversal. If you ran any of those on a highly detailed Doom map, they'd crash and burn because they still have to cope with the same problem the BSP traverser is facing, i.e. it cannot take visibility state for granted and has to dynamically re-check it.

Maybe they indeed are slower but what if there was no task to occlude polygons and objects with a higher accuracy rather leaving some tolerance, let's say, one big occluder for area #1, anoter for area #2?

As a side question here, can it be like if BSP traversal results were used more than just for 1 frame, like if the whole operation was performed less often and there were, let's say, 10 more "safe" sectors added into the frustrum?

 

What about handling huge scenes like mine (Map15 HellRen) if virtually the frustrum would have been expanded to 360 degrees to BSP traverse the whole scene from all the sides just once, upon the game starting process and then used for that map at all times until it ends?

[Graf Zahl]

40 minutes ago, Darkcrafter07 said:

Maybe they indeed are slower but what if there was no task to occlude polygons and objects with a higher accuracy rather leaving some tolerance, let's say, one big occluder for area #1, anoter for area #2?

 

That would indeed be faster, the problem is that Doom maps lack the needed information. You can guess, but if you guess wrong you get a hell of a render glitch or weird performance drops.

 

42 minutes ago, Darkcrafter07 said:

As a side question here, can it be like if BSP traversal results were used more than just for 1 frame, like if the whole operation was performed less often and there were, let's say, 10 more "safe" sectors added into the frustrum?

 

 

The moment you move the result will be invalidated, so you'd optimize the one case that doesn't matter

[Darkcrafter07]

6 minutes ago, Graf Zahl said:

 

That would indeed be faster, the problem is that Doom maps lack the needed information. You can guess, but if you guess wrong you get a hell of a render glitch or weird performance drops.

That's why mappers should place occluders manually and test it thoroughly.

 

7 minutes ago, Graf Zahl said:

The moment you move the result will be invalidated, so you'd optimize the one case that doesn't matter

Indeed but could it help if multiple (surrounding) cases were also took into account and traversed in series or in parallel?

 

I got another question sir, the maps in doom have a blockmap grid. Perhaps if each of them stored solved traversal results that could help to accelerate it somehow. As if camera occured in a blockmap A it would address to that solution and compare it's position in the blockmap accordingly to the solved "points".

 

Let's say each blockmap has 9 solved points, a camera is between them and it projects that frustrum. Only those solved branches that appear on the frustrum make it to the render. Then the frustrum widens and makes it to the next blockmap and the process gets repeated. What's about this?

 

 

 

[Graf Zahl]

30 minutes ago, Darkcrafter07 said:

That's why mappers should place occluders manually and test it thoroughly.

 

If Doom worked like that it'd all be easier, but it'd also make mapping a lot harder. You win some, you lose some. I think the only viable solution that's doable is to change sector movement rules to only allow it for sectors that are specifically unlocked to be freely movable. Then you could easily group everything that's known to be static, create a single mesh from it and render it in one go. Of course even then you need to be careful with dynamic lights, if such a section becomes too large you may lose again in the end.

 

 

30 minutes ago, Darkcrafter07 said:

Indeed but could it help if multiple (surrounding) cases were also took into account and traversed in series or in parallel?

 

I got another question sir, the maps in doom have a blockmap grid. Perhaps if each of them stored solved traversal results that could help to accelerate it somehow. As if camera occured in a blockmap A it would address to that solution and compare it's position in the blockmap accordingly to the solved "points".

 

Let's say each blockmap has 9 solved points, a camera is between them and it projects that frustrum. Only those solved branches that appear on the frustrum make it to the render. Then the frustrum widens and makes it to the next blockmap and the process gets repeated. What's about this?

 

 

 

I'm sorry to break the news to you, but this does not work. Any block is 128x128 map units, that's 128 x 128 x 65536 x 65536 distinct positions, and depending on what you look at, even small variations affect the visible set.

[Darkcrafter07]

38 minutes ago, Graf Zahl said:

 

If Doom worked like that it'd all be easier, but it'd also make mapping a lot harder. You win some, you lose some. I think the only viable solution that's doable is to change sector movement rules to only allow it for sectors that are specifically unlocked to be freely movable. Then you could easily group everything that's known to be static, create a single mesh from it and render it in one go. Of course even then you need to be careful with dynamic lights, if such a section becomes too large you may lose again in the end.

That would be cool to try out.

 

39 minutes ago, Graf Zahl said:

I'm sorry to break the news to you, but this does not work. Any block is 128x128 map units, that's 128 x 128 x 65536 x 65536 distinct positions, and depending on what you look at, even small variations affect the visible set.

 

A precision needed to put 9 solved positions per block map is 64 units, so each map units in that formula can be divided by 64.

 

2 * 2 * 1024 * 1024 = 4 194 304 solved positions per map? I really don't think a precision of this kind would give you glitches. Why not just traverse BSP for each of them with an extremely wide FOV, and choose only those solved branches that intersect with player camera's frustrum?

[hobomaster22]

11 hours ago, Darkcrafter07 said:

That's why mappers should place occluders manually and test it thoroughly.

 

Indeed but could it help if multiple (surrounding) cases were also took into account and traversed in series or in parallel?

 

I got another question sir, the maps in doom have a blockmap grid. Perhaps if each of them stored solved traversal results that could help to accelerate it somehow. As if camera occured in a blockmap A it would address to that solution and compare it's position in the blockmap accordingly to the solved "points".

 

Let's say each blockmap has 9 solved points, a camera is between them and it projects that frustrum. Only those solved branches that appear on the frustrum make it to the render. Then the frustrum widens and makes it to the next blockmap and the process gets repeated. What's about this?

Unfortunately, you can't traverse once per block. There are too many positions. If the player is at a certain coordinate a one-sided line or a two-sided line with the ceiling <= floor can block rendering, but may not block rendering just a single map unit away. This doesn't even work in the most simple case of only doing BSP traversal once per tick and using that to interpolate the frames.

 

13 hours ago, Graf Zahl said:

That entirely depends on what you need it for. If it is to exclude things like portals or save on expensive calculations like collecting active dynamic lights for a specific surface is very much needed. If you just want to render the plain level as-is, modern graphics hardware surely is fast enough. I've seen dynamic lights bring down FPS on vanilla maps even on good hardware when used poorly, so rendering these in sectors you can't see is something you need to avoid. There's surely room for optimization in that area, but the whole notion was about BSP presumably being a slow occlusion culling algorithm which is simply not correct. 

You weren't talking about dynamic lights or portals. Neither of which Helion cares about (or most ports for that matter), so I'm not sure why it's being brought up. The vast majority of Doom maps do not have either of these features anyway. So even if the BSP was required for these two features, it's like throwing the baby out with the bathwater to take the gigantic performance penalty of rendering with the BSP when it's not required for most maps.

[Darkcrafter07]

1 hour ago, hobomaster22 said:

Unfortunately, you can't traverse once per block. There are too many positions. If the player is at a certain coordinate a one-sided line or a two-sided line with the ceiling <= floor can block rendering, but may not block rendering just a single map unit away. This doesn't even work in the most simple case of only doing BSP traversal once per tick and using that to interpolate the frames.

My bad, I didn't know that floors and ceiling may block as well as single sided linedefs?

[Graf Zahl]

1 hour ago, hobomaster22 said:

You weren't talking about dynamic lights or portals. Neither of which Helion cares about (or most ports for that matter), so I'm not sure why it's being brought up. The vast majority of Doom maps do not have either of these features anyway. So even if the BSP was required for these two features, it's like throwing the baby out with the bathwater to take the gigantic performance penalty of rendering with the BSP when it's not required for most maps.

 

Different engines have different goals. If you want lights or portals you have to sacrifice some performance. If I said to people that "oh, I removed dynamic light support so that you can run these huge-ass maps faster" my customers would justifiably be pissed. I can run Frozen Time (view from the bridge) at 30fps on my work machine with an Intel HD4600 at full HD with lights on with the GLES backend, and for me this is enough for such old and declining hardware. I wouldn't want to sacrifice the stuff people are using GZDoom for to make it faster.

 

[hobomaster22]

8 minutes ago, Graf Zahl said:

 

Different engines have different goals. If you want lights or portals you have to sacrifice some performance. If I said to people that "oh, I removed dynamic light support so that you can run these huge-ass maps faster" my customers would justifiably be pissed. I can run Frozen Time (view from the bridge) at 30fps on my work machine with an Intel HD4600 at full HD with lights on with the GLES backend, and for me this is enough for such old and declining hardware. I wouldn't want to sacrifice the stuff people are using GZDoom for to make it faster. 

 

Yes, they have different goals. But this is the Helion thread after all. I didn't say GZDoom had to remove dynamic lights, you could use a different rendering method if the maps have none of these features. I'm not saying it's easy or even something you should do, but it's possible.

[hobomaster22]

40 minutes ago, Darkcrafter07 said:

My bad, I didn't know that floors and ceiling may block as well as single sided linedefs?

They do, but it still breaks with one-sided lines.


The colored blocks are the subsectors, the black block is a square of one-sided lines. With my crappy paint job, the green box is the first position, red is second. Lines show view angle. If you take the first position (green) the green subsector would not be traversed. Move just a bit over (red) in the same 128x128 block and now the green subsector is in view. In more realistic scenarios these cases drop entire node branches and would result in a lot of missed rendering.

Edited October 3, 2023 by hobomaster22

[ChopBlock223]

17 hours ago, Graf Zahl said:

 

Have you ever tested other occlusion algorithms? Most are effectively quite a bit slower than BSP traversal. If you ran any of those on a highly detailed Doom map, they'd crash and burn because they still have to cope with the same problem the BSP traverser is facing, i.e. it cannot take visibility state for granted and has to dynamically re-check it.

 

If you need efficient visibility culling the map needs to provided the needed info. In modern games this is easy because you got a static mesh that never changes, so all you need to consider are objects like doors which are not normally part of the map geometry but separate entities. This will allow to do this stuff far more efficiently. In absence of that there really is nothing faster than using a BSP. I've toyed around with other engines, e.g. Build for Raze, and their algorithms are far less performant and would show signs of stress at considerably less detailed maps.

 

Say, "non-solid" barriers cannot occlude, even when the height inside the sector is 0, because a sector can at any moment's notice be a lift or otherwise made to change heights.

 

But would it in any way be possible to somehow have occlusion for things like these (like two-piece walls and columns), IF  the premise is that the sector in question has zero height, no tags, no sector effect, and there's no linedef action tied to it somehow?

 

I'm not sure it would be of any tangible benefit or easy to implement (maybe with ZScript?) and I'm likely missing some detail. I can also picture some gameplay mods breaking things like these, but that's gameplay mods to you.

[Master O]

On 10/2/2023 at 7:00 AM, hobomaster22 said:

There are ways to handle things outside of the BSP tree. Yes, Doom has some really unique problems that are Doom and hard to solve because modern video games don't have Doom's quirks. On the plus side, maps that are considered stressful and complex really aren't hard for GPUs of the last 10 years to process. So we also have this on our side. We have been working hard to solve these problems the best we can while keeping the game 'Doom'. The last release solved the issue of sector light updates, and we have just solved the issue of flood filling for the next. Even in our benchmarks that saw very high numbers, we were surprised to find out how much flood filling in the last release was a massive bottleneck. Quite a few of the benchmark maps were seeing 30%-50% FPS drops from flood filling. The method we have for the next release will increase Summer of Slaughter MAP32 about 200% on modern cards, and gives us the capability to update them at runtime which we didn't have before. There are ways to do these things, it just requires thinking outside the box.

 

Will that method also help with Nuts 3?

[Graf Zahl]

2 hours ago, ChopBlock223 said:

Say, "non-solid" barriers cannot occlude, even when the height inside the sector is 0, because a sector can at any moment's notice be a lift or otherwise made to change heights.

 

Such a sector will occlude if it is closed. That's one of the most important aspects of the BSP clipping algorithm because it allows the software renderer to process the scene without any overdraw aside from mid textures and sprites.

 

 

3 minutes ago, Master O said:

 

Will that method also help with Nuts 3?

 

Nuts 3 isn't limited by geometry rendering but by the processsing of the sheer amount of monsters and projectiles. In this case the level mesh is the least of your problems. Having thousands of moving sprites both constantly do movement checks and having them rendered one by one is what costs time here

[hobomaster22]

52 minutes ago, Master O said:

 

Will that method also help with Nuts 3?

Like Graf said it is mostly the monster movement and partially sprite rendering. You can tweak the rendering distance in Helion to see how much it affects the FPS by setting render.maxdistance to 2000 or 1000. Setting it to 1 would effectively disable sprite rendering all together.

Edited October 3, 2023 by hobomaster22