Doom Sector Light levels

[hawkwind]

Could someone please point me in the right direction in the doom source code as to the sector light levels.

It seems that there is some disagreement as to whether the highest light level is 255 or 256.

Both DeepSea and Eureka show the highest as 255. This makes sense to me as 0 to 255 is 256 light levels.

Ultimate DoomBuilder shows the highest as 256. Which is  ( more ) correct ?

[Raleigh]

For me 255, in edmap for example at ligh sector says (0-255) and same in Wadauthor, DB2... and more editors.

On UDB i don't know why put 256 as highest.

[Gez]

Technically a sector's lightlevel variable is held by a short, so the maximum value would be 32767.

 

Even worse, lighting thinkers use an int to store current light level, so the maximum value becomes over two billions.

 

However, this all gets squashed to the COLORMAP's 32 light levels by these constants:

#define LIGHTLEVELS	        16
#define LIGHTSEGSHIFT	         4

#define MAXLIGHTSCALE		48
#define LIGHTSCALESHIFT		12
#define MAXLIGHTZ	       128
#define LIGHTZSHIFT		20

extern lighttable_t*	scalelight[LIGHTLEVELS][MAXLIGHTSCALE];
extern lighttable_t*	scalelightfixed[MAXLIGHTSCALE];
extern lighttable_t*	zlight[LIGHTLEVELS][MAXLIGHTZ];

extern int		extralight;
extern lighttable_t*	fixedcolormap;


// Number of diminishing brightness levels.
// There a 0-31, i.e. 32 LUT in the COLORMAP lump.
#define NUMCOLORMAPS		32

Then we have code like this for walls:

    lightnum = (frontsector->lightlevel >> LIGHTSEGSHIFT)+extralight;

    if (curline->v1->y == curline->v2->y)
	lightnum--;
    else if (curline->v1->x == curline->v2->x)
	lightnum++;

    if (lightnum < 0)		
	walllights = scalelight[0];
    else if (lightnum >= LIGHTLEVELS)
	walllights = scalelight[LIGHTLEVELS-1];
    else
	walllights = scalelight[lightnum];

(note fake contrast in the middle, with the lightnum-- or ++) and similar for flats:

	light = (pl->lightlevel >> LIGHTSEGSHIFT)+extralight;

	if (light >= LIGHTLEVELS)
	    light = LIGHTLEVELS-1;

	if (light < 0)
	    light = 0;

	planezlight = zlight[light];

So in either case, we get a light index between 0 and 15. And we get from the lightlevel to the light index by a right-shift with LIGHTSEGSHIFT, which has a value of 4. For those who don't know computer maths, right-shifting is division by a power of 2 (and left-shifting is multiplication by a power of 2), so right-shifting by 4 means dividing by 2 to the power of 4; in other words: dividing by 16. (Also, extralight is a value that can be 0, 1 or 2 and that is set by the viewpoint player's gunfire. Yes, the whole "might makes light" scene from the Doom Comic is absolutely canon to the game mechanics.)

 

Since the maximum value we can get after dividing by 16 is 15, the maximum effective value is therefore 15×16=240. Now to be honest with fake contrast we can get walls that have an arbitrary reduction of light index by 1, so 16×16=256 is the way to get them to keep a maximum light index after fake contrast.

 

Finally, there are some specials that will turn light on or off. Interestingly, the "off" light level is 35 (light index 2) and the "on" light level is 255 (light index 15).

[hawkwind]

I have been in consultation with biwa, who works on Ultimate Doom Builder, and they use 256 to allow a doom quirk in which a horizontal one sided line ( maybe two sided as well ? ) assigned to a sector with 256 light level will render brighter than a line alongside it which is assigned to a sector with a light level of 255. He sent me a test wad to show me this and it is confirmed, at least with doom2.exe and choco doom. What other doom mysteries await ...

Attached is a modified version of the wad biwa sent me.

255-256.zip

[Gez]

30 minutes ago, hawkwind said:

I have been in consultation with biwa, who works on Ultimate Doom Builder, and they use 256 to allow a doom quirk in which a horizontal one sided line ( maybe two sided as well ? ) assigned to a sector with 256 light level will render brighter than a line alongside it which is assigned to a sector with a light level of 255. He sent me a test wad to show me this and it is confirmed, at least with doom2.exe and choco doom. What other doom mysteries await ...

Well...

 

9 hours ago, Gez said:

Since the maximum value we can get after dividing by 16 is 15, the maximum effective value is therefore 15×16=240. Now to be honest with fake contrast we can get walls that have an arbitrary reduction of light index by 1, so 16×16=256 is the way to get them to keep a maximum light index after fake contrast.

255>>4=15, -1 for fake contrast = 14.

256>>4=16, -1 for fake contrast = 15.

 

 

 

I'll also mention here that it's pretty trivial to get Doom to make full use of its 32 colormaps instead of only using 16 of them. Change LIGHTLEVELS to 32 instead of 16, LIGHTSEGSHIFT to 3 instead of 4, and perhaps tweak R_InitLightTables() though at a glance it does not seem like it actually needs any change. This gives a light index change every 8 light level values instead of every 16.

[hawkwind]

2 hours ago, Gez said:

 a light index change every 8 light level values instead of every 16.

 

Correct me if I'm wrong, but does not Boom and above already do that ?

[Nevander]

To be honest, I've never understood the 256 thing. I've just always used 255 for the max of anything like this. Same goes for RGB colors.

[Edward850]

4 hours ago, hawkwind said:

 

Correct me if I'm wrong, but does not Boom and above already do that ?

Not Boom, no. It is present in Boom based ports like prboom+, but not Boom itself. (It might be in MBF, I wonder?)

1 hour ago, Nevander said:

To be honest, I've never understood the 256 thing.

It's quite straight forward really, Gez's post explains it solidly (remember, indexes in computers are 0 based as they represent an ordinal):

Quote

 

255>>4=15, -1 for fake contrast = 14.

256>>4=16, -1 for fake contrast = 15.

 

 

[boris]

9 hours ago, Gez said:

I'll also mention here that it's pretty trivial to get Doom to make full use of its 32 colormaps instead of only using 16 of them. Change LIGHTLEVELS to 32 instead of 16, LIGHTSEGSHIFT to 3 instead of 4, and perhaps tweak R_InitLightTables() though at a glance it does not seem like it actually needs any change. This gives a light index change every 8 light level values instead of every 16.

 

When I explained it to hawkwind yesterday I had a look at the Unofficial Doom Specs. In section 4-9 it actually says that there are 32 brightness levels, not only 16. I didn't really dive deep into the source, can anyone explain why there are colormaps for brightness when apparently only 16 are used? Does it just use every other one or something like that?

[Gez]

28 minutes ago, boris said:

Does it just use every other one or something like that?

I decided to test it, and apparently not!

 

Tweaked COLORMAP:

Every even row has been given a striking blue tint, while the odd rows are still in their original color.

 

In-game result:

A mix of blue and normal. (And yes I haven't updated Choco in forever, I know.)

 

Edit: I think light diminishing is the reason why all rows of the colormaps are used, though. If you disable it and test that edited COLORMAP lump, it might give you a fully-normal view without blue bands.

[esselfortium]

In vanilla, the entire 240-255 range is equivalent to 240, in the same way that anything between 128 and 143 is drawn as 128, etc. Fullbright being considered 255 instead of 256 is just a mistake that was carried over from the iwad maps into nearly every map editor ever made.

[Kappes Buur]

4 hours ago, esselfortium said:

Fullbright being considered 255 instead of 256 is just a mistake that was carried over from the iwad maps into nearly every map editor ever made.

 

In Doombuilder2 that is true. The highest value is 255.

In the iterations thereafter (GZDB, GZDBBF, UDB) that is 256.

[hawkwind]

5 hours ago, esselfortium said:

In vanilla, anything between 128 and 143 is drawn as 128, etc.

So does that mean that a sector brightness level of 0 to 15, renders a a brightness of 0 ? All interesting stuff ...

 

Edited November 16, 2020 by hawkwind

[Kappes Buur]

6 hours ago, hawkwind said:

So does that mean that a sector brightness level of 0 to 15, renders a a brightness of 0 ? All interesting stuff ...

 

Pretty much.

For example, a range from 72 to 115, with 115 barely visible in a map

 

 

or 120 to 163

 

 

in increments of 1.

 

Notice the dramatic light level change at the low end.

 

 

But it is easy enough for you to test yourself.

 

Edited November 16, 2020 by Kappes Buur

[retro65]

Welp, time to mod my Eureka further...

(I already corrected the vertical limits from

-32767 <= h <= 32767

to

-32768 <= h <= 32767

). Maybe I gotta PR or something, but idk the devs seem busy

[plums]

On 11/14/2020 at 9:28 AM, Gez said:

Technically a sector's lightlevel variable is held by a short, so the maximum value would be 32767.

Using values < 0 or > 255 can occasionally be useful for creating lighting effects with some sector light types.

 

On 11/15/2020 at 5:01 AM, Gez said:

Edit: I think light diminishing is the reason why all rows of the colormaps are used, though. If you disable it and test that edited COLORMAP lump, it might give you a fully-normal view without blue bands.

This is definitely the reason. The banding looks really severe with only 16 light levels. You can test this by editing the source, or just fake it by duplicating every other row of the COLORMAP.