boom lighting weirdness

[mouldy]

I've been experimenting with boom lighting specials (213 & 261) and I found that different source ports seem to behave differently when lighting items and monsters, depending on the floor, ceiling or sector brightness.

These are some screenshots of the same test map in different ports. On the left is a dark sector with the floor set to bright. In the middle is a bright sector with ceiling and floor set to dark. On the right is a bright sector with just the ceiling set to dark.

prboom:

In prboom, the ceiling brightness overrides the floor and the sector brightness. Also the sector brightness overrides the floor brightness.

glboom:

In glboom, the floor and ceiling settings are ignored, and the sector brightness defines the lighting of the object.

zdoom:

In zdoom, the floor brightness overrides the sector brightness, and the ceiling setting is ignored. Also the player's hand is effected.

gzdoom/zandronum

This is the same as zdoom except the player's hand is not effected by the boom specials.

So my question is, how come they are all so different and which one is correct?

Here's the test map: http://www.mediafire.com/download/l6jqgi7g55xlxuw/lighting-test.wad

[Da Werecat]

Even Boom and MBF are different in this regard. In MBF transferred ceiling brightness overrides sector brightness, but not for the player's weapon. In Boom in doesn't.

[edit]

Oops.

[Grazza]

Bear in mind that the behaviour in prboom+ and prboom+ should depend on the complevel you are using.

[mouldy]

Grazza said:

Bear in mind that the behaviour in prboom+ and prboom+ should depend on the complevel you are using.

I'm not seeing any difference when I try different boom complevels in either prboom+ or glboom+, unless i'm doing something wrong

[Da Werecat]

The older versions didn't make distinctions between Boom and MBF in regards to brightness transferring. But it was fixed at some point, so at least the latest test verions of PrBoom+ should work differently depending on complevel.

[plums]

Here are my tests. I didn't get the same results as you in PrBoom+, using the 2.5.1.4.test version from June(?).

First is Boom. IMHO this should be the "correct" way of doing it, since this is where the linedef type originated.


MBF [incorrect]


PrBoom+, complevel 9 [correct]


PrBoom+, complevel 11 [intentionally incorrect, since it emulates MBF, except the pistol is still lit]


GLBoom+, complevel 9 [correct?]


GLBoom+, complevel 11 looks the same as complevel 9, which is "correct" but doesn't emulate MBF like it should. (screenshot, not inline so as to fit this in one post.)

GZDoom [incorrect]


ZDoom [incorrect]


Eternity [same as MBF, not sure if there are settings that affect this]


3DGE [correct]


Risen3D [correct]



I'm not sure what kind of conclusions to draw from this, other than "good luck making this look like you want it in all ports." :P

[Da Werecat]

plums said:

[intentionally incorrect, since it emulates MBF, except the pistol is still lit]

Looks like I was wrong about the player's weapon. Should've tested the real deal instead of assuming that PrBoom inherited MBF behavior.

plums said:

I'm not sure what kind of conclusions to draw from this, other than "good luck making this look like you want it in all ports." :P

A common problem with Doom source ports, really. :)

[mouldy]

Thanks plums, I'm still using prboom+ 2.5.1.3 so I guess your more recent test version has 'fixed' this problem. I use inverted commas there, because the way zdoom does it works better for my purposes :)

But yeah, annoying. I can stick with the way zdoom handles it, since more people use that branch of the source port family tree, but then what if they also decide to fix the issue later on...

[kb1]

I don't claim to completely understand it, but Doom lighting is related to Doom texture stretching - the theory being that, the more stretched the texture, the closer the wall, hence the brighter the wall. Or rather, the more shrunk, the further the distance, hence the darker the wall.

It's ugly. This also means that, when you switch resolutions, the light scaling also has to switch, usually by some factor that's not a power of 2. This is problematic, since Doom loves to use fixed-point for everything.

I've said it before: Doom was built empirically. Carmack got one thing working, and then built upon it. That's fine if you plan on always running the same resolution, same maps, etc. But, it's problematic for source port developers, who expect to make what seems to be an easy enhancement, but they quickly find that everything is tied to everything else!

[Da Werecat]

Well, it's not like the difference is in some brightness nuances. The difference is whether the sprites are affected by actions or not.