Questions about some issues I've encountered

[ByRntStarOEI]

Hello, I have a few questions regarding some minor issues I ran into while running my wad (The Excavation available in wad releases) and I'm guessing it has to do with me potentially doing something wrong. I've uploaded a test wad to help demonstrate some of the problems I ran into. If what I posted below doesnt make any sense, please feel free to ask me to clarify.

 

These first two appear to have something to do with differences between gzdoom and dsdadoom, but I want to make sure.

 

The 1st is related to the 2 doors in the wad. Both doors need the blue key and they both can be opened in gzdoom, however, in dsdadoom only the one on the right can be opened. The left door cannot, which seems to have something to do with the line walking trigger placed in front of it. Is this the intended behavior or a bug? I solved the issue by moving the walk trigger line of course, but I'm just curious what is happening in this situation for future reference.

 

The 2nd is related to sound activation of enemies. In the wad, I have both linedefs of each door and window to block sound. The sergeant should not wake up on the opposite side of the wall in either source port if a gun is fired, but will if you are in the same room. Pressing the computer panel on the far right wall will teleport another sergeant besides the other one asleep and the results from above are the same. Pretty standard stuff. However, if one enters the right door and fires the gun in the room with the first sergeant before pressing the control panel, there are different results between the sourceports when the second is teleported in. In gzdoom, the sergeant stays asleep, while in dsdadoom the sergeant teleports in awake. Once again, is this a potential bug or the intended behavior?

 

 

These next issues appear when running different renderer modes, either software or the advance(opengl) renderer. There may be some slight differences between different source ports, but the results about the same.

 

For the 1st problem is what I'm guessing is texture bleeding into another. Here are some screenshots to explain it better:

 

Spoiler

 

What's actually happening here? This only happened when running the software renderer so I'm guessing it has something to do with limitations? I'm also guessing it has something to do with improper mapping technique? When checked in UDB I can't find anything wrong in the displayed locations. Is there anything I can do to fix this or prevent it from happening?

 

The 2nd is related to the lighting differences between the software renderer and the advance one. The software renderer appears much darker when compare to the advance and is difficult to balance with one appearing to light or to dark depending the changed in light levels. How does one go about balancing these light levels efficiently between different renders? Or is it better to stick with one renderer and recommend the wad be played with the renderer you designed it for?

 

 

That should be it for now. Thanks for your time.

 

 

Oh, and the wad for the test:

 

 

 

 

TESTS.zip

Edited April 13, 2024 by ByRntStarOEI
Grammer, forgot to upload test wad....

[Aurelius]

The doors: what happens is that when trying to press use, Doom stops looking for activatable lines after it finds the closest one to the player. Since there is a walkover line in front of the door action, it won't activate. So for example, your door won't open because the walkover line action is too close to the door line action. Boom and beyond has a flag called PASSTHRU, labeled "Pass use action" in the editor which gets you around this. I'd advice against using it though, for a few reasons, and instead just make sure no line actions are too close to one that requires the player to press use.

 

The not-so-sleepy shotgunner: the classic behavior is that once you shoot in a sector, the sector remains "alerted" until you finish the map, and any enemies finding their way there will immediately be alerted.

 

Texture bleeding: hard to say definitively from the screenshot. Some possible fixes are to

• Press F4 for Map Analysis Mode and see if there's any issues with level geometry.
• Use another nodebuilder (Tools -> Game Configurations -> Nodebuilder). DeepBSP is a good option, for example.
• If that doesn't work, just wiggle some vertices around and see if the issue persists.

 

The narrow and tall rendering artifacts: these are called slime trails. Wiggling vertices around and adjusting geometry can help with this, as might switching the nodebuilder. The more complex your geometry, the more likely is that you'll have slime trails.

 

Lighting: there will always be a noticeable difference in how lighting looks in software rendering of ports like DSDA Doom and Woof! versus GZDoom hardware rendering. There isn't much you can do, besides testing in both ports and seeing how it looks. A good approach is to stick to your intended port and make sure it looks good there. In GZDoom, you can force the sector light mode via MAPINFO using lightmode. This will at least make the look consistent between GZDoom users.

Edited April 11, 2024 by Aurelius

[ByRntStarOEI]

On 4/11/2024 at 7:30 AM, Aurelius said:

The doors: what happens is that when trying to press use, Doom stops looking for activatable lines after it finds the closest one to the player. Since there is a walkover line in front of the door action, it won't activate. So for example, your door won't open because the walkover line action is too close to the door line action. Boom and beyond has a flag called PASSTHRU, labeled "Pass use action" in the editor which gets you around this. I'd advice against using it though, for a few reasons, and instead just make sure no line actions are too close to one that requires the player to press use.

 

The not-so-sleepy shotgunner: the classic behavior is that once you shoot in a sector, the sector remains "alerted" until you finish the map, and any enemies finding their way there will immediately be alerted.

 

Texture bleeding: hard to say definitively from the screenshot. Some possible fixes are to

• Press F4 for Map Analysis Mode and see if there's any issues with level geometry.
• Use another nodebuilder (Tools -> Game Configurations -> Nodebuilder). DeepBSP is a good option, for example.
• If that doesn't work, just wiggle some vertices around and see if the issue persists.

 

The narrow and tall rendering artifacts: these are called slime trails. Wiggling vertices around and adjusting geometry can help with this, as might switching the nodebuilder. The more complex your geometry, the more likely is that you'll have slime trails.

 

Lighting: there will always be a noticeable difference in how lighting looks in software rendering of ports like DSDA Doom and Woof! versus GZDoom hardware rendering. There isn't much you can do, besides testing in both ports and seeing how it looks. A good approach is to stick to your intended port and make sure it looks good there. In GZDoom, you can force the sector light mode via MAPINFO using lightmode. This will at least make the look consistent between GZDoom users.

 

Awesome, thanks! Just like I figured though, most of these have to do with behaviors between sourceports and the way doom original worked. But this is good info that I'll have to keep in mind if I decide to do more mapping in the future. As for the graphical issues, the nodebuilder swap helped with the texture bleeding and some readjusting with the linedefs got rid of most of the slime trails. A couple of them still remain no matter what I try, but I can live with that.

 

Thanks for the tips, I appreciate your help.