DRD Team

Or so it appears. Running zoon_v3.wad with the latest official build, there are a few stalactite objects in the first room of MAP02 that in some instances appear to be shown as fullbright, as though illuminated by the fullbright floor of the liquid sector below.

The stalactite in question is on the upper-right side of this screenshot. I moved a few steps forward and the object was no longer drawn fullbright.




There is another on the left that seems to stay bright no matter where I position myself. Both stalactites should not be illuminated - in every other port tested: PrBoom+, GLBoom+, Eternity, ZDoom and GZDoom, this was not the case.

This image shows the placement of the thing in the editor. It overlaps the liquid slightly, but for all intents and purposes it's still in the ground sector.


Config file attached, if it helps.

After looking a bit into this, the connection is that once GL nodes are enabled the software renderer behaves like you see in QZDoom. In other words, if you enable textured automap in the menus and restart the map, then you see the same odd behavior in ZDoom and GZDoom's software mode.

So the good news is that it is not a new bug introduced by QZDoom as such, but rather made more apparent by it always using GL nodes. The interesting part is that neither GZDoom's OpenGL or the softpoly renderer displays it fullbright, so I'm not entirely sure yet what triggers it to sometimes think those sprites are fullbright.

This is a known issue with the 'render things outside their own sector' feature. The code too much depends on global variables so I wasn't able to fix it.

How is that feature meant to work? (theoretically, not how it is implemented)

The problem is that the sprite renderer takes the brightness from the current global variable for sector brightness. But for things in other sectors that's obviously not correct. Just par for course for the software renderer.

Apologies for thinking this was strictly a QZDoom issue, I only just now saw it happening in ZDoom. I'm honestly not sure how the issue escaped me even after I tested this wad a whole bunch in ZDoom pretty much to start with.

Perhaps stating the obvious here, but the problem is not prevalent in GZDoom's hardware renderer (it still occurs in the software renderer too) or in PrBoom+, GLBoom+, or Eternity.

I think I'll, um, still move those stalactites in the map though, as it's not too late to do so.

Well it IS a bug that should be fixed. My post was mostly about tracing down the origin of the bug as I've done quite a lot of refactoring of that particular codebase of late.

This one was actually mentioned in the PR by ZZYZX. Like me he found no good way to work around that global variable dependency without breaking other stuff.

Slightly off-topic, but Jimmy didn't you have an account here before?

I did, yeah, but had to reset my password, and didn't get the e-mail to do so until just now. (Speaking of, Jimmy being my name here would be nice. )

I changed it - but just know this is one of those few sites that allows you to change it yourself.