Helion - C# (0.9.2.6 1/1/23 - Goodbye BSP tree rendering)

2 hours ago, Bauul said:

 

Just FYI there are GZDoom mappers, even with access to Thing_Spawn (or the other ACS equivalents), that prefer to use classic monster closets for a couple of reasons:

 

1) The monster count number is accurate upon loading the level (with summoning monsters it increases over time)

2) The flow of teleporting monsters into a level is more organic rather than all spawning it at once, as the natural movement AI introduces some variation

 

Thinking out loud here, what might be more useful is a "Monster Closet" sector flag, that simplifies the monster AI when a monster is inside it.  You could do a something like have the flag trigger a simplified version of A_Chase that skips the melee check and the missile check (because monsters will necessarily do neither in a monster closet), the active sound function, even the LOS check.  All a monster needs to do is wake up and the raw basics of moving around.  Then when they teleport in, the flag is no longer present so the monster reverts to the full-fat AI.

As most things in software development, both things can be fixed with enough programming (taking in account he is doing a new port, and one that seems to try to not limit itself a lot by previous sourceports). It's a question of course , if the effort is worth the net result. It should be possible to modify the stat logic to take in account all the possible enemies including the ones still not really existing in the map but depending on special lines, and you can introduce parameters on that new logic that allows for variations, inject random delays and random order, etc.

53 minutes ago, Turin Turambar said:

 

As most things in software development, both things can be fixed with enough programming (taking in account he is doing a new port, and one that seems to try to not limit itself a lot by previous sourceports). It's a question of course , if the effort is worth the net result. It should be possible to modify the stat logic to take in account all the possible enemies including the ones still not really existing in the map but depending on special lines, and you can introduce parameters on that new logic that allows for variations, inject random delays and random order, etc. 

I think our first step is to optimize what we have first, since it certainly could be optimized further. From testing the monster movement has better performance than GZDoom but still much slower compared PrBoom+/DSDA. We are doing full 3D checks and do support some crazy stuff dealing stacked things, physics with pushing them up and down etc (that will probably never happen). Event with this I'm sure we have room to improve these routines when we can really start digging into them.

What we are working on is flood filling since we have a way to do it that won't kill performance. Of course like everything in Doom there is a bunch of edge cases and it currently doesn't play nice with our sky rendering, so there is quite a bit of work to do. But the simple case is working anyway. I forgot how trippy this effect is.

3 hours ago, hobomaster22 said:

This is an interesting idea, there could definitely be ways to help that I will have to think about. The unfortunately thing is that the biggest time suck for A_Chase is purely the monster movement. I ran a few of the large monster count maps including Sunder MAP15 against the Visual Studio profiler and it all comes down to monster movement. It wastes the most time checking blocks against other things/lines. It compounds from here because they are boxed in so the first direction might fail, and then the next... etc. Then when it determines a successful move the next biggest time suck is actually linking it to the sectors in the blockmap (which is a line blockmap traversal) and then BSP subsector link. I believe LOS checks only accounted for 2% or less of the total CPU time, while blocking and linking was about 15% total. You can also take this with a grain of salt because this is Helion, these numbers could be very different for other ports.

Interesting insight, thank you!  The slow-down caused by the monsters waking up in latter Sunder maps is pretty infamous, it's a good stress-test for any port.  However it's achieved, it definitely feels a monster in a closet could perform as required by the mapper with a simpler movement routine, although how far you could pare it down before it starts behaving tangibly differently to the full movement AI I'm not sure.  

The other thought I had was the number of times a monster calls A_Chase - even the humble imp calls it nearly 12 times a second while moving.  If you automatically doubled a monsters speed and but also doubled the frame duration of its See state while it was in a monster closet, in theory it would have similar movement but would call A_Chase half as often.  No idea if it would work in practice, but there feels like enough levers to pull that it could be worth experimenting with.

13 hours ago, Bauul said:

 

Interesting insight, thank you!  The slow-down caused by the monsters waking up in latter Sunder maps is pretty infamous, it's a good stress-test for any port.  However it's achieved, it definitely feels a monster in a closet could perform as required by the mapper with a simpler movement routine, although how far you could pare it down before it starts behaving tangibly differently to the full movement AI I'm not sure.  

 

The other thought I had was the number of times a monster calls A_Chase - even the humble imp calls it nearly 12 times a second while moving.  If you automatically doubled a monsters speed and but also doubled the frame duration of its See state while it was in a monster closet, in theory it would have similar movement but would call A_Chase half as often.  No idea if it would work in practice, but there feels like enough levers to pull that it could be worth experimenting with. 

Sounds like you are on to something. The routines can be pared down if they are past a certain distance from the player as well. The player would likely never be able to know or see it anyway, so why waste so much time on it. Having a cut off distance for this might automatically handle the monster closet issue without needing any map flags. I could probably mock something up pretty quickly.

Flood fill sectors are looking very good now. And holy crap is Summer of Slaughter MAP32 recommended by @Blip is really cool. This map absolutely destroys other ports. I couldn't get a single port to stay above 30fps in this outside area... and my laptop is no slouch with a Ryzen 5900HS and an RTX 3070. This map also has a lot of flood filling going on dropping a decent chunk of performance with Helion (119 unique flood planes to be exact). Still, I was able to squeeze out 650FPS looking at the entire map with the latest development build:

16 hours ago, Bauul said:

The other thought I had was the number of times a monster calls A_Chase - even the humble imp calls it nearly 12 times a second while moving.  If you automatically doubled a monsters speed and but also doubled the frame duration of its See state while it was in a monster closet, in theory it would have similar movement but would call A_Chase half as often.  No idea if it would work in practice, but there feels like enough levers to pull that it could be worth experimenting with.

If you double a monsters speed, but also double its frame duration, while its movement may look similar, it will end up trying to take steps twice as long, which could potentially result in it getting stuck depending on how tight of a place it is in.

Here's a test map where Dehacked has been used to make the Hell knight move in this way: monster_speed_test.zip

(Compare it to the Baron which has the same movement and speed as what a hell knight would normally have.)

Calling A_Chase fewer times also has an effect on when monsters can change targets, since the switching threshold is reduced each time A_Chase is called.

10 minutes ago, boris said:

Calling A_Chase fewer times also has an effect on when monsters can change targets, since the switching threshold is reduced each time A_Chase is called.

True, although aside from a co-op session where players are dying frequently, I can't imagine that monsters in a monster closet would have much chance to change target.

Some shower thoughts about the rush hour.

Assuming a) we worry mostly about massive slaughter teleporter closets, b) demo compat is not in the picture, c) we can clearly define said monster closets:

• Does a closet-dweller really need to recheck a bunch of directions upon failure to move every time? If that's a major hog, how about limiting to one check and then next time try a different direction?
• Maybe an increased-delay-on-repeat approach could reduce the volume - if a movement fails (or idk succeeds "badly" - after checking > x directions), next check would occur later.
• Could introducing a delayed wake-up to artificially spread the initial roar(tm) strain be a thing? At least from "normal" play perspective, the value of having all tucked away monsters actively doing move checks on the very same frame when you're barely anywhere near gameplay is ???
• Negative/sanity thought - some slaughter setups could be affected if simplified routine ends up having a significant effect on spawn speed.

As to the problem of defining closets - I feel like it's a job for a (new?) lump really. Distilling down to what is required to know, it would be a) that sector index where the monster spawns is a closet, so the thing can be flagged for/assigned/whatever a PrimitiveChase routine during map load and b) a list of line specials that lead the monster into the wild - aka the teleport types - so that upon the successful spechit we know to "undo" the primitive routine association, as the monster enters play.

The teleport types are a fairly limited list and I guess there's little value in having a highly specific association per closet - I don't see how it would matter that it's possible for a monster to undo dumbAI via type 97 when respective monster closet is running on 126.

That leaves us with the list of sectors, for which selecting all your closets and running a simple UDB script can do just fine.

/// <reference path="../../udbscript.d.ts" />

`#version 4`;

`#name Selected sector index list`;
`#description Selected sector index list`;

let sectors = UDB.Map.getSelectedSectors();

if(sectors.length == 0)
    UDB.die()
	
let output = ''
sectors.forEach(s => { output += s.index + ','})
UDB.showMessage(output.slice(0, -1))

There are plenty of closet designs out there and I feel like it's not that hard to provide static data on mapping side in a port/map format-agnostic way compared to producing robust heruistics for "what is a closet". Plus there'd be flexibility - if a mapper really wants a certain closet to just function normally for some reason - that's possible to force. Of course, the usefulness hinges on actually having a stripped down chase routine in the first place.

9 minutes ago, Doomy__Doom said:

Does a closet-dweller really need to recheck a bunch of directions upon failure to move every time? If that's a major hog, how about limiting to one check and then next time try a different direction? 

Maybe an increased-delay-on-repeat approach could reduce the volume - if a movement fails (or idk succeeds "badly" - after checking > x directions), next check would occur later. 

Could introducing a delayed wake-up to artificially spread the initial roar(tm) strain be a thing? At least from "normal" play perspective, the value of having all tucked away monsters actively doing move checks on the very same frame when you're barely anywhere near gameplay is ??? 

Negative/sanity thought - some slaughter setups could be affected if simplified routine ends up having a significant effect on spawn speed.

We could short out of checking multiple directions, checking multiple directions just to bounce around in a sector is largely pointless. If a sector is marked as a monster closet we could find the closest teleport line and only allow the monster move in that direction. If the monster fails to move towards the teleport line then it just stops.

We could also just skip playing the see sound entirely since it's pretty pointless. The only enemies you might hear anyway are the ones flagged not to have attenuation.

If I were implementing this now, I would likely mark the sector with a closet flag. Anything in that sector would run the simple routine since they would be linked to that sector. Once a monster teleports they are linked to the teleport destination which would would not have this flag, so the monster would no longer run the simple movement routine. I'm going to call it A_ClosetChase for now.

A_ClosetChase would remove all these checks:
Potentially looking for a new target. The closest teleport line is it's sole purpose in life.
Melee range check.
LOS with missile range check.

Playing active sounds.

And the big one, setting a new chase direction it fails to move.

At this point we would just have to determine an acceptable movement speed and how many ticks to call it. The cool thing is doesn't need to reflect it's real movement speed, since we are just trying to flush it out of the closet. The movement time could potentially be as infrequent as every second, but probably something more like 16 ticks. Then I would likely want to stagger these with randomization so that they don't all try to move on the same exact tick.

Hmm. I am not sure if in understand the direction of this monster-closet .. brainstorming.

To me it seems like you are proposing new feature that would only work in this port, which would make it incompatible with anything else.

But why so complicated?

Try this one: closet.zip

It works in vanilla and you can clearly detect which monsters are "disabled".

Until you activate this closet you can simply check:

if(mo->ceilingz - mo->floorz < mo->height)
  // skip a_chase stuff

You can even detect this at map loading and mark those monsters for simpler AI, then cancel this mark after first teleportation.

But of course this won't address existing maps.

On a separate note, I had a hunch about another potential good stress-test for the port: MSCP Map 02, notable for the extreme number of Light Glow sectors.

And indeed it looks like this is a challenge for the port: on my laptop which now gets ~250fps on Sunder Map15 with the latest build, MSCP Map02 is bouncing along at ~50-60 average FPS, with a low of 35.  For reference, I get basically the same FPS on GZDoom, and a little lower on DSDA.

39 minutes ago, Bauul said:

On a separate note, I had a hunch about another potential good stress-test for the port: MSCP Map 02, notable for the extreme number of Light Glow sectors.

 

And indeed it looks like this is a challenge for the port: on my laptop which now gets ~250fps on Sunder Map15 with the latest build, MSCP Map02 is bouncing along at ~50-60 average FPS, with a low of 35.  For reference, I get basically the same FPS on GZDoom, and a little lower on DSDA.

Oh, that's a cool effect. Both scrolling and light changes have massive efficiency upgrades for the next release. I'm getting about 80FPS on my RTX 3070 on that map for 0.9.1 But for the development build I am currently getting:
140 FPS - Integrated Radeon
1,300 FPS - Mobile RTX 3070

Just a slight boost ;)

We are just working out the kinks and bugs from these upgrades now. A lot of code to test!

Just wanted to mention, that if you're looking for a map to push your engine, I suggest using my map Hellcinerator. It was a map that was made to push the limits of the Boom Engine (with some MBF21 DehackEd). It includes 600+ voodoo dolls with some actions that have 100 voodoo dolls moving at once, and while it's not the prettiest map out there, it pushes the mechanics of the Boom engine to it's limits. (At the moment, the map currently breaks immediately in Odamex).

I just wanted to mention that I tried testing the map in Helion and the first switch softlocks in this port for some reason. When I IDCLIPed, further in the map, most of the stuff seemed to work, although I used alot of flat bleed and fake floors that Helion seems to not know how to render. The sky transfer seems to not work correctly as well.

There's a certain part of the map which has around 100 ceiling sectors raise up at once, and it hard crashed Helion (not surprising - see errorlog.zip). I wanted to test this because GZDoom's Hardware renderer super lags when trying to render this part of the map. Software renderer runs smoothly however. You can see a demonstration of the demanding section here:

Just another small question: are there any plans to support custom invulnerability overlays / custom colourmaps. here's an example of a custom colourmap section in that map:

4 hours ago, Arsinikk said:

Just wanted to mention, that if you're looking for a map to push your engine, I suggest using my map Hellcinerator. It was a map that was made to push the limits of the Boom Engine (with some MBF21 DehackEd). It includes 600+ voodoo dolls with some actions that have 100 voodoo dolls moving at once, and while it's not the prettiest map out there, it pushes the mechanics of the Boom engine to it's limits. (At the moment, the map currently breaks immediately in Odamex).

 

I just wanted to mention that I tried testing the map in Helion and the first switch softlocks in this port for some reason. When I IDCLIPed, further in the map, most of the stuff seemed to work, although I used alot of flat bleed and fake floors that Helion seems to not know how to render. The sky transfer seems to not work correctly as well. 

 

There's a certain part of the map which has around 100 ceiling sectors raise up at once, and it hard crashed Helion (not surprising - see errorlog.zip). I wanted to test this because GZDoom's Hardware renderer super lags when trying to render this part of the map. Software renderer runs smoothly however. You can see a demonstration of the demanding section here:

 

Just another small question: are there any plans to support custom invulnerability overlays / custom colourmaps. here's an example of a custom colourmap section in that map:

 

It's beautiful in it's own way ;)

Like I mentioned before the current release doesn't support flood fill rendering. It's a feature we are working on now. Thanks for posting the error, I can see the problem area in the code dealing with sector changes so we can have that fixed for the next release.

Colormaps would be a very far in the future feature most likely.

13 hours ago, kgsws said:

Hmm. I am not sure if in understand the direction of this monster-closet .. brainstorming.

To me it seems like you are proposing new feature that would only work in this port, which would make it incompatible with anything else.

But why so complicated?

 

Try this one: closet.zip

It works in vanilla and you can clearly detect which monsters are "disabled".

Until you activate this closet you can simply check:

if(mo->ceilingz - mo->floorz < mo->height)
  // skip a_chase stuff

You can even detect this at map loading and mark those monsters for simpler AI, then cancel this mark after first teleportation.

 

But of course this won't address existing maps.

It's just a way to flag something as a closet for optimization. If a port doesn't support it then the optimization simply doesn't exist and the map would work normally anyway. Part of my motivation behind this is to be able to help existing maps. We could create an algorithm that detects the monster closets are completely boxed off. Everything in this game is still very brute force. Map designers want to make large complex maps that stress out Doom's ancient rendering tech, and large monster counts that add even more stress. There isn't much in the way of tools to help map designers make them more playable, so I'm enjoying the discussion and the ideas.

On 12/3/2022 at 2:03 PM, hobomaster22 said:

And holy crap is Summer of Slaughter MAP32 recommended by @Blip is really cool. This map absolutely destroys other ports. I couldn't get a single port to stay above 30fps in this outside area

i7-6700HQ 2.6GHz software rendering at 1920x900. No Boom functionality in Rum and Raisin yet, so unplayable. Throwing some Ryzen cores at it should bring that render time down from my ageing machine.

Ran it on my profiling build to get an idea of where the time is actually going, and yeah good ol' fashioned setup/clipping stuff. Which I have solid plans to tackle, so expect better performance in R&R in the future on this scene. Won't be a concern with a hardware renderer, basic Z clipping will handle everything that these software routines do.



I should also say, this port is basically doing what I was going to do with Calamity. So it pleases me to see it doing as well as I expected. There have been better ways to render Doom scenes for a very long time, and no one should be discouraged from going down those paths to see what shakes out. There's some reference maps in that thread I linked in fact that will help with flat rendering issues.

9 hours ago, GooberMan said:

I should also say, this port is basically doing what I was going to do with Calamity. So it pleases me to see it doing as well as I expected. There have been better ways to render Doom scenes for a very long time, and no one should be discouraged from going down those paths to see what shakes out. There's some reference maps in that thread I linked in fact that will help with flat rendering issues.

Thanks, that is interesting. It's impressive how much performance you have been able to squeeze out of software rendering. I do enjoy those UI windows very much.
 

I think Doom has been stuck with the BSP tree for many reasons. The first being that that's just how it was done. It works and most of us understand it, but it's only really required for software rendering. The second issue is that Doom is incredibly dynamic, and anything can change at any time for any reason. The third, is that doing anything in this game is full of edge cases and gotchas because of the software rendering. Add in the fact that mappers use these quirks to build effects in their maps and you end up with a serious mess of undefined edge cases. It has been a massive undertaking to deal with all this.

Like you have shown traversing the BSP tree to render segs and dealing with line clipping sucks. And is required to happen sequentially for the the line clipping to occlude nodes. Even worse it's breaking up the map into these very tiny precise slices that really doesn't matter with hardware rendering. Then you are constantly uploading data to the GPU (a lot of which doesn't really change) dragging performance down further.

Modern GPUs have become truly absurd parallel processing capabilities. An RTX 3070 can have more than 4,000 cores, and the newest RTX 4080 pushing nearly 10,000. Even cheap junk integrated cards now will have over 100 cores to process with, so taking the entire level and letting the GPU figure it out is pretty much always going to be faster. Modern games essentially do this. They will do frustum culling and some possible occlusion queries on expensive stuff to reduce draw calls, but they are not running algorithms on the CPU to occlude every single piece of geometry possible. Map designers are also increasingly wanting to make more open and nice looking maps with complex geometry where not much is being occluded anyway.

Helion deals with dynamic data in this fashion:
The entire map is statically generated and uploaded to the GPU.
If sector lighting changes, it modifies that buffer and uploads it to the GPU.
If a sector starts moving then it's vertex data is collapsed from the static buffer and uploaded, then sector is linked to the blockmap. This is just to handle interpolation, and gets rendered in brute force way.

When a sector stops moving it updates the buffer with it's new data.
Rendering iterates the blockmap with a max distance in front of the player, which takes care of active moving sectors, scrolling sides, and sprites.

And even with the FPS numbers we have been able to generate, there is actually a ton of room to improve.
 

Slightly different to the approach I was going to take.

There's a bit of a misconception about Doom, in that there's not enough static data to create static buffers and just roll with it. But the reality is that there's exactly four dynamic elements of a Doom world:

• Floor height
• Ceiling height
• Light level
• Scrolling textures

The last two are exclusively visual effects and have no relevance to anything but the end user; the first two are both a visual effect and required for culling objects.

The approach I was going to take was to bake that static mesh, but never update subregions. I was going to use constant buffers for each sector (and for scrollers) and only update those four values listed. Less to go up to the GPU that way. Then reconstruct what is required on the GPU from those constant buffers. Honestly, Doom's rendering is so simple that you're probably wasting wavefronts. There's likely a ton of processing power to spare in each wavefront, but I won't know exactly what the cost differential is until I try each method and see what the results are.

It's funny though, since that could sound like the opposite approach I take to bring Rum and Raisin's times down further. Sprite clipping is a nightmare, and there's going to be more efficient ways to do it. But a large chunk of time you see in my screenshot is the renderer preparing walls. Setting up the values for the column renderer to just go for it. This can all be computed at map load time. Adding a scroll offset and projecting the required UVs for the renderer is the smallest cost, there's milliseconds in that screenshot that can be saved just from checking flags if it's upper/lower pegged etc and adjusting offsets according. On the other hand, it's virtually equivalent to setting up those static buffers with constant buffers used to update select values.

Updated to 0.9.1.1

https://github.com/Helion-Engine/Helion/releases/tag/0.9.1.1

A lot of stuff in this one.

Reported by @Athel

Fixed attack sound for melee state.
Fixed sprite clipping issue. (Afrit from Emblem)

Reported by @Arsinikk

Added dehacked misc1 for modifying weapon offsets. Fixes fast switching in 200 line massacre. @Arsinikk
Fixed displacement scrolling special.

Added FOV (field of view) option (render.fieldofview). @esspressoman

Implemented drag and drop file on the exe.
Significant efficiency upgrades for wall scrolling and light changes.
Fixes for transfer floor light sector light changes.
Fixes for dynamic sector changes.
Sector movement that changes sky rendering.
Flood filling for missing upper and lower textures. Flood filling is currently an alpha feature. Can become very expensive on maps with a lot of missing uppers and lowers. Toggled via render.floodfill.
Fixed texture serialization to use name to prevent texture management changes from breaking older saves.
More efficient voodoo doll and inventory handling. Fixes performance issue in wads where voodoo dolls continually attempt to pickup items when the player's inventory is full.

Some examples of maps that were inefficient with before and after FPS:
Ryzen 5900HS
Mobile RTX 3070
1920x1080

Micro-Slaughter Community Project MAP02: @Bauul
180 FPS -> 1,300FPS

The Given:
150 FPS -> 1,800FPS

Saturnine Chapel:
35FPS -> 600FPS

So far I think the most stressful map in terms of map geometry is SOS_Boom.wad MAP32. I can't find a port where it's reasonably playable. Even with a low-end power saving GPU this map is perfectly playable above 100FPS.
Helion with flood fill enabled:
Mobile RTX 3070: 650FPS
Mobile AMD Radeon: 145FPS

Drag and drop is a godsend and seeing the perf boosts is too. Now lets get some more low-end performance metrics in with this new release.

Tagging @Athel @Arsinikk and @Bauul for the updates above. Apparently I am dumb and messed up the tags.

Oooh, dope stuff, I'll give things another run through when I get the chance. Kind of swamped with finals ATM, but thanks for letting me know!

This whole thread brings back some fond memories.

I remember when @taufan99 wanted to try my CatacombGL source port on his laptop with Intel 945GM integrated graphics. At first it didn't even startup. But after some fixes and tweaking he got it running at 200 FPS.

It's true that we often don't realize how much processing power hides inside old or budget graphics hardware, and I love it when source port devs harness that power to achieve a seemingly "impossible" performance in games.

I'm truly impressed that you managed to do this in a game like Doom, which is far more complex than Catacomb Abyss.

Keep up the good work!

Wow this is some absolutely insane specs in the new version. I'm completely floored that you guys are able to achieve such high FPS using C#. I'll definitely give this a try in a couple of days after I finish up some coding. It'll be interesting to see what I can get on my potato of a computer.

20 hours ago, Madgunner said:

Wow this is some absolutely insane specs in the new version. I'm completely floored that you guys are able to achieve such high FPS using C#. I'll definitely give this a try in a couple of days after I finish up some coding. It'll be interesting to see what I can get on my potato of a computer.

Definitely interested to hear how it goes and what your graphics card is. Below is a list of the benchmark wads I have been using. Some of them for various purposes. Some have high monster counts, tressful geometry, high amounts of light changes and scrolling textures, or some combination. Some maps likes DOTW MAP01, Saturnine Chapel, MSCP MAP02, have so many light / scroll changes pummel the graphics card with so many uploaded changes that an old and slow card will be decimated. But maps like Frozen Time and Planisphere should be perfectly playable on a potato computer.

Hello again, I have returned with a couple more trivial things to report on, based off the most recent version of Helion. This report is going to be slightly more detailed to make it easier for both of us!

Starting off, I have taken notice of the new changes such as the sprite clipping being fixed--now, I can hit the afrits in Emblem exactly where they are! +1 on that! However, it would appear A_KeenDie is still a broken codepointer. As demonstrated in the screenshot below, even though one afrit still remains, the door on the far end has opened.
 

I have went back into base Doom 2 just to check, and it DOES indeed work as intended on map32. I'm assuming you hardcoded it so that it would only work as intended on that map slot, however, be wary that other mods such as Plutonia 2 also use KeenDie outside of the map slot to access a secret. I'd imagine this breaking progression on maps that solely rely on having all enemy types calling A_KeenDie being dead first before proceeding.

Another issue I noticed is that Helion doesn't seem to respect DeHacked color transitions. I'm not sure if this is something you've removed due to not having multiplayer, however keep in mind there are other mods that also utilize this feature (I know fraggle's DEH9000 uses it for the torches for optimization, for example). Pictured below is an example from my WIP mod Artifice. The left demon should be red and the other should be grey, however here they both show up in untranslated green.

And lastly, I decided to stay true to my word and give Batman Doom a try, seeing how much stuff is stretched to make it work, and... wow, there's quite a few things stopping me from properly playing this mod on Helion.

One of the first thing I noticed was the spamming of "Invalid doom sound" during the train part of the first level, as depicted here. Chocolate Doom doesn't seem to complain about any missing sounds, so I'm not sure if this is a Helion thing or just vanilla promptly ignoring the sound. It also seems to trigger when in the menu, so I'm not too sure what's going on here.

In addition, there's also a pretty bad lockup in this same segment. You're supposed to collect a blue key which comes from a downed enemy/guard(?), and whilst the key DOES spawn in as it should and it even acknowledges the pickup IS a key (signaled by the text "You picked up a blue key!"), it... gives me the shotgun replacement instead? And it doesn't actually give me a key?

There are also color translation issues prevalent in this mod, but I was unable to capture those in action. I could still do other tests on some more technical mods, but I thought I'd report what I've found so far. I'm sure there's other tricky things that are done behind the hood, but I have to find a good wad that really stretched vanilla to its limits. I will keep snooping around other WADs I have on hand and get back to you on what I find. If there's any questions on this report, do let me know!

1 hour ago, Athel said:

Hello again, I have returned with a couple more trivial things to report on, based off the most recent version of Helion. This report is going to be slightly more detailed to make it easier for both of us!

Starting off, I have taken notice of the new changes such as the sprite clipping being fixed--now, I can hit the afrits in Emblem exactly where they are! +1 on that! However, it would appear A_KeenDie is still a broken codepointer. As demonstrated in the screenshot below, even though one afrit still remains, the door on the far end has opened.
 

I have went back into base Doom 2 just to check, and it DOES indeed work as intended on map32. I'm assuming you hardcoded it so that it would only work as intended on that map slot, however, be wary that other mods such as Plutonia 2 also use KeenDie outside of the map slot to access a secret. I'd imagine this breaking progression on maps that solely rely on having all enemy types calling A_KeenDie being dead first before proceeding. 

 

Another issue I noticed is that Helion doesn't seem to respect DeHacked color transitions. I'm not sure if this is something you've removed due to not having multiplayer, however keep in mind there are other mods that also utilize this feature (I know fraggle's DEH9000 uses it for the torches for optimization, for example). Pictured below is an example from my WIP mod Artifice. The left demon should be red and the other should be grey, however here they both show up in untranslated green.

 

And lastly, I decided to stay true to my word and give Batman Doom a try, seeing how much stuff is stretched to make it work, and... wow, there's quite a few things stopping me from properly playing this mod on Helion.

 

One of the first thing I noticed was the spamming of "Invalid doom sound" during the train part of the first level, as depicted here. Chocolate Doom doesn't seem to complain about any missing sounds, so I'm not sure if this is a Helion thing or just vanilla promptly ignoring the sound. It also seems to trigger when in the menu, so I'm not too sure what's going on here.

 

In addition, there's also a pretty bad lockup in this same segment. You're supposed to collect a blue key which comes from a downed enemy/guard(?), and whilst the key DOES spawn in as it should and it even acknowledges the pickup IS a key (signaled by the text "You picked up a blue key!"), it... gives me the shotgun replacement instead? And it doesn't actually give me a key?



 

There are also color translation issues prevalent in this mod, but I was unable to capture those in action. I could still do other tests on some more technical mods, but I thought I'd report what I've found so far. I'm sure there's other tricky things that are done behind the hood, but I have to find a good wad that really stretched vanilla to its limits. I will keep snooping around other WADs I have on hand and get back to you on what I find. If there's any questions on this report, do let me know! 

 

 

Thanks for going through these! I took a look at all of these, and most are easily fixed for the next release.

With A_KeenDie I misinterpreted the original code and thought it only counted the keen object, when it actually counts whatever thing was passed in.

This Batman Doom case is funny. I forget exactly why it works, but a shotgun is dropped. Something do with how vanilla actually tied pickups to the sprite if I recall. This broke because of the inventory refactor I did to fix conveyor voodoo spamming. It doesn't pass the dehacked lookup through to item pickup.

The sound thing will be fixed. Batman Doom has some garbage sound files which I guess were designed to prevent from playing, but they are invalid causing an error to log so it looks like I have to turn off the error logging.

The color translation flags are something we have to implement. It's going to take some thought, but I probably have to scan the frames and check for the translation flag and make new textures with the colormap translation.

Solid stuff!! If anything I can also try a couple of other dehacked things to get the more technical side of things scoped out--I think its time maybe we give the greatest vanilla mod of all time (/j) a try...

Also, if your renderer can pick up on sprites themselves, you could maybe pass a check of sorts for the bits that Dehacked uses to recolor, then do some render changes to that object before its rendered to the screen?

8 hours ago, Athel said:

Solid stuff!! If anything I can also try a couple of other dehacked things to get the more technical side of things scoped out--I think its time maybe we give the greatest vanilla mod of all time (/j) a try...

Also, if your renderer can pick up on sprites themselves, you could maybe pass a check of sorts for the bits that Dehacked uses to recolor, then do some render changes to that object before its rendered to the screen?

That mod is a true treasure. It was actually helpful in finding that it modifies the sprite names for the keys which breaks the lookup for pickups in this case. So it was useful in weeding out this issue.

There are things we can do. Software rendering looks up each pixel from the colormap when rendering and change the lookup to generate different colors from the same 'image' on the fly. Helion generates textures at start up using the colormap to work with OpenGL so this is why the translations don't work.

On 12/14/2022 at 8:25 PM, hobomaster22 said:

Definitely interested to hear how it goes and what your graphics card is. Below is a list of the benchmark wads I have been using. Some of them for various purposes. Some have high monster counts, tressful geometry, high amounts of light changes and scrolling textures, or some combination. Some maps likes DOTW MAP01, Saturnine Chapel, MSCP MAP02, have so many light / scroll changes pummel the graphics card with so many uploaded changes that an old and slow card will be decimated. But maps like Frozen Time and Planisphere should be perfectly playable on a potato computer.

  Reveal hidden contents

 

Sorry for the delay, I've been busy coding. I've kind of realized that I'm bad at estimating how long it takes for me to code stuff, heh. Anyways I will run the test tomorrow and let you know what fps I get. The graphics I have on this machine is an Intel HD Graphics 4600.