You can see things up close in the dark

[esselfortium]

Here is the discussion the last time this came up, mixed in with discussion of COLORMAPS: http://forum.zdoom.org/viewtopic.php?f= ... 0&start=10
What I wrote then still stands: It's not a simple one-line fix, and since the conditions where it's most noticeable are limited, it doesn't seem worth the effort.

Also, might I also mention that in standard Doom, floors and ceilings are allowed to get much brighter as they get closer to you than are walls? You can't really see in it Doom, since you can't pan the view up or down. It might be possible to construct a 0-brightness map in Heretic and Hexen and see it there, though I haven't tried. This is a consequence of Doom precalculating 16 tables for lighting (hence the reason it has only 16 real light levels) but accessing them differently for walls vs floors.

Which also raises the question: Is the clamp on maximum brightness of walls in Doom a conscious design decision, or was it simply a consequence of their lookup tables? Was it even considered in any way at all? What ZDoom does is basically identical to Doom but without the lookup tables.

Speaking of clamps on brightness, randy, is there any chance of ZDoom adding back support for light levels outside the 0-255 range? In vanilla and most other ports, you can use a light level like, say, 5000, combined with the Light Glow sector special, to cause the sector to remain fullbright for several seconds before it begins visibly fading back down. In ZDoom, it immediately fades back down as soon as it reaches fullbright (as though it were somehow internally clamping light levels to a 0-255 range when loading the map), so the timing control is lost.

[NeuralStunner]

In vanilla and most other ports, you can use a light level like, say, 5000

Holy cow, I thought that was an 8-bit value in vanilla map format.

[randi]

You can do that? I turned it into a byte because I trusted the unofficial editing docs that said it only used values 0-255 without actually confirming the reality of that claim. Oops.

[esselfortium]

Yeah, I believe it goes from -32768 to 32767.

[Graf Zahl]

I turned it into a byte...

I have to say that this kind of 'efficiency' has been the cause of far too many problems already. All variables should be ints if you ask me.

[Edward-san]

Even better int32_t ?

/me hides

[randi]

All variables should be ints if you ask me.

Hey, back when this project started, conserving memory still meant something.

[Blue Shadow]

I see the thread's been given a "Fixed" tag, does that mean it now behaves just like vanilla?

[Graf Zahl]

No, for that the number of light levels had to be reduced. But it handles the 'too bright' case explicitly now.

[Graf Zahl]

Even better int32_t ?

/me hides

That'd be an SDWORD in ZDoom terms. And if you ask me, yes, these variable type names do bother me and I'd happily replace them with their C99 equivalents if this was my project alone.

[NeuralStunner]

No, for that the number of light levels had to be reduced.

Optionally I hope.

[Graf Zahl]

The number of light levels was not reduced. Just the 'too bright' case was explicitly handled.

[NeuralStunner]

The number of light levels was not reduced. Just the 'too bright' case was explicitly handled.

Ah, okay.