Welcome to the ZDoom Forums!

I need a little help. I'm trying to make a chunk of map that uses 3D floors for floating platforms, and also has adjustable brightness (commanded via ACS script). However, I'm finding myself unable to control the brightness of actors that are above the platforms. I can change the brightness of the sector below the platform, as well as brightness of the platform itself. The actors atop the platform remain unchanged. Most puzzling to me is that this only happens with the GL renderer. I don't experience any problems in software mode.

Anyone know of something I might've forgotten to do?

Ed the Bat wrote:Most puzzling to me is that this only happens with the GL renderer. I don't experience any problems in software mode.

That's probably a bug, then.

Any guesses as to which renderer is behaving as intended? I'd like to hope it's software, since that's the effect I wanted, but as far as I've seen, when the renderers disagree on matters of 3D floors, GL is usually the one considered correct.

Went ahead and trimmed things down to make a demonstration of the issue. As the brightness changes, the actors that are atop the 3D floors will only change their brightness in software mode, but not in GL.

I remember I had this problem and someone told me to play with the floor flags. I don't recall if that's what fixed it but its worth a try, even though something working differently in renderers sounds like a bigger issue and quite possibly a bug.

Hi,

I know you said ACS, but wondering if it is 100%:
A script only method?
Or editing only method? ~ and using nothing but line type/control/target/sector based lighting?
Or both and using ACS for lighting and or editing Sector lighting?

This all might help shed some light on things.

Thanks

I already posted it, so you're more than welcome to look at it for yourself.

Ah okay, I see what you're saying and yeah that may be a bug, as it should change the thing/item lighting while in sector area.
A work around may however be in map editing only and then just use a script to change the lighting pointing to sector # until a fix comes along.
That is, if it's indeed a bug instead of something I may be over looking too?

Here is a small demo I made for Doom Legacy some years ago having to do with 3dfloors, its soul purpose was to quickly test all the 3dfloor type #'s in one run.
It later ended up on the legacy wiki as a demo. It works pretty well in Gzdoom and may be of some help here as well.
http://www.legacywiki.net/downloads/legacy_3ddemo.zip

Good luck!

Mr.Rocket wrote:A work around may however be in map editing only and then just use a script to change the lighting pointing to sector # until a fix comes along.

I'm not sure I understand what this means, but if it can fix my problem, then I'd like to know.

I can't really say because on my current computer I can't install DoomBuilder so I have no means to look at UDMF maps.
If you could make the same demonstration WAD as a Hexen format map with less sprites (only one per lighting zone) I might have a better chance telling you what's wrong.

Presto! The link in my earlier post has been updated; the map is now in Hexen format, with only one actor in each sector.

There's definitely something not right with the GL renderer. I wonder if some insufficiently reviewed code submission broke some stuff. I had problems with those before.
I'll have to fire up the debugger to see what's happening. More info later.

Ugh...

Found the problem. It actually *does* use proper light levels. It just didn't clamp them to byte values when reading from the 3D floor light lists. And you used a light value of 256 which got truncated to - 0!

Should I have used a different value? And does this mean the software renderer is wrong when it behaves the way I expected?

Also, as a quick side note, I was curious and ran this test map in Zandronum, for the sake of using an older version of the GL renderer, and everything lit up like in software.

No, it was clearly a bug in the GL rendering code. Some time ago the internal size of the light variable was extended from 8 to 16 bits and lots of places in the GL code needed to be adjusted because it uses a byte to store it and treats 255 as 1.0. This was just overlooked in this particular spot but now it's fixed.