Any reason why one would want a light level above 255?

In the Doom engine, one can set a sectors light level to values above 255.

Now this doesn't affect the sector light level, but I was wondering if there are any rendering hacks people have discovered with 255+ light levels?

I have seen a couple of maps over the years with sector light levels of 256 for instance; are these to achieve rendering hacks, or simply the result of mappers mistakenly thinking 256 is the 'max'?

Share this post


Link to post

if you set sectors to light values above 255 and then have them glow (sector action 8? iirc) they'll stay fullbright longer the higher the value is. This can be used to create cool lighting effects.

Share this post


Link to post

I suppose you could rewrite the engine/PLAYPAL to allow for "overbright" sectors, similar to the effect you get in Quake when a light source is really close to a wall.

Actually, you could probably do that without engine rewrites by shifting "full bright" down to 224 or 192 or so in PLAYPAL, although I can't imagine it'd look very good. Either way, it'd be totally unsupported in OpenGL...

Honestly, this is the first I'm hearing about light going over 255 at all; I thought that was a hard limit. Apparently not.

Share this post


Link to post

I've made that mistake a couple times only because Doombuilder 2, unless entered manually, lets you pick light levels in intervals of 16, so if I look at a whole room and it looks a little dark, (aside from a few ceiling lights that may be lit at 240) I may select all the sectors in the room and change the light level to "++16" which bumps it up one light level higher, naturally making the ceiling light sectors 256 instead of 255, and I just neglect to fix it as it's not a bug that can really be observed in gameplay.

Never heard about that glowing light thing Ribbiks said though. I wonder if it has a similar effect on effect 17, "light flickers"

Share this post


Link to post

Uhh, actually 256 is brighter than 255 I think. All brightness values get rounded down to the closest 16*x. So just like 193=192, 255=240, while 256 is brighter.

edit: yep, there is definitely a difference - http://i.imgur.com/wLPs0gh.png (left - 255, right - 256, wad link)

Share this post


Link to post
Memfis said:

Uhh, actually 256 is brighter than 255 I think. All brightness values get rounded down to the closest 16*x. So just like 193=192, 255=240, while 256 is brighter.


This is actually an artifact of the COLORMAP system, and can be changed to obtain coarser or finer light/distance mapping gradients. Of course, with standard 256-color rendering, the maximum number of transitions you can obtain is just 32, since there are 32 colormaps (even though the source code only defines 16 light levels...).

With source ports having true color 24-bit rendering (15-bit HiColor is not enough, as you only get 32 distinct colormaps, tops), you can have 256 truly distinct light levels.

And yeah, I know of a certain banned DW member that has -among others- an obsessios with "superbright" lighting. It's possible to create colormaps with increasingly saturated/bleached color, until they are practically all-white and indistinguishable, and you can in theory have at least as many "overbright" colormaps as there are "underbright" ones.

Share this post


Link to post

Light levels greater than 255 appearing brighter only applies to horizontal walls (East - West on automap).
This is because the reduction in brightness that is normally applied to them (by fake contrast) is being removed.

Share this post


Link to post

It does have an effect on sector specials that fade light levels up or down. It has to actually "get through" the "overbrightness" before you will start to see the lighting effect. esselfortium says he has used this in maps to achieve different lighting effects than what are available given the stock sector effects and the "normal" range of light level values.

Share this post


Link to post
Memfis said:

All brightness values get rounded down to the closest 16*x.


I use one unit light differences to keep middle textures from bleeding through the floor, are we sure there is not the slightest difference, even if it's extremely difficult to detect? I've noticed 240 and 255 are indistinguishable in DB2's visual mode though.

Share this post


Link to post
40oz said:

I use one unit light differences to keep middle textures from bleeding through the floor, are we sure there is not the slightest difference, even if it's extremely difficult to detect? I've noticed 240 and 255 are indistinguishable in DB2's visual mode though.

Vanilla's lightlevel quantization does not apply there.

Share this post


Link to post
40oz said:

I use one unit light differences to keep middle textures from bleeding through the floor, are we sure there is not the slightest difference, even if it's extremely difficult to detect? I've noticed 240 and 255 are indistinguishable in DB2's visual mode though.

It depends on the source port you're using. In vanilla, though, anything from 128 through 143 will be drawn identically to 128, with no increase in brightness until it hits 144. So a 1 unit addition from 128 will be identical to it, but a 1 unit subtraction from 128 will be treated the same as 112.

Share this post


Link to post
Ribbiks said:

if you set sectors to light values above 255 and then have them glow (sector action 8? iirc) they'll stay fullbright longer the higher the value is. This can be used to create cool lighting effects.


You can also have negative light values so that rooms stay dark longer.

Share this post


Link to post
plums said:

You can also have negative light values so that rooms stay dark longer.



oooh, this I did not know. I must play with this :D

Share this post


Link to post

I always thought that if you gave a sector a light value of over 255 it would cause some weird "negative" light effect. I thought this because of how 255 is the maximum speed when the player is Turbo, but exceeding this would cause them to walk backwards etc.

And at light level 255, no gradual darkness is made (this can be observed using the Line Horizon effect).

Share this post


Link to post
plums said:

You can also have negative light values so that rooms stay dark longer.


What if you had a sector with a light value of +255 with action 8 (Light glows 1+ sec.) next to a sector with a light value of -0? It would stay light for a while, then fade smoothly into darkness, and back again. It would make those computer wall mazes more interesting...

Edit: You could even create a lightning effect with it! If your "dark" sector had a light level of -0 but your "bright" sector DIDN'T have a light level of +255.

Share this post


Link to post
Joe667 said:

I always thought that if you gave a sector a light value of over 255 it would cause some weird "negative" light effect. I thought this because of how 255 is the maximum speed when the player is Turbo, but exceeding this would cause them to walk backwards etc.


In that case speed is stored as an unsigned byte, which has a range of 0-255.

Doom's lighting could be stored in one byte, but for some reason it's a signed short integer (two bytes) instead, meaning a range of -32768 to 32767. The only typically useful values are 0-255 though.

Share this post


Link to post

Yeah... I'm trying to follow, but the most technical terms I've ever heard are in GameMaker 7/8's 3D engine... X)

Share this post


Link to post

Haha, sorry. OK.

Basically the container for speed values is small, 0-255. If you go over the limit of what it can hold, you wrap back around to small numbers.

Doom uses the same numbers for light as it does for speed, 0-255. But the container for light is larger than it needs to be, so it can hold larger or smaller numbers without wrapping around.

Share this post


Link to post
plums said:

...The container for light is larger than it needs to be, so it can hold larger or smaller numbers without wrapping around.


And what is its maximum value?

Share this post


Link to post

Light can go from -32768 to 32767.

One byte = 8 bits = 2^8 different values = 256 values. Generally this is either 0-255 (unsigned, i.e. no +/- sign) or -128 to 127 (signed).

Two bytes = 16 bits = 2^16 values = 65536. Unsigned this is 0-65535, signed is -32768 to 32767.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now