Doom: brightmap improvements

[SoDOOManiac]

I have a couple of suggestions regarding one particular texture brightmap and an IMO desirable special case when the brightmaps shouldn't be applied to textures on particular lines even when Apply brightmaps to parameter is Walls or Both.

1. The COMPTALL texture has a monitor with green text/image that IMO deserves a brightmap.
   BTW, for some reason I cannot find this texture in Doom(2).wad files

2. In BOOMER.WAD I found a very cool mapping trick that signals interactivity of the linedef:
   there is a little, only 3 units tall sector window in the wall, that sector has special blinking light, and the linedef seen through the window is textured with the red part of SW1STON2.

I recorded a video showing that, alas, the blinking button glows constantly when brightmaps for walls are enabled.
https://youtu.be/RWvDFWMXaas

My suggestion to handle such buttons is:
even when crispy->brightmaps & BRIGHTMAPS_TEXTURES is non-zero,
don't apply brightmaps to sidedef that faces a sector which is
2.1) 8 units tall or less (should suffice for buttons) and
2.2) has lighting-related special (special is 1, 2, 3, 4, 8, 12, 13 or 17).

[fabiangreffrath]

I like the ideas, both of them.

1. The COMPTALL texture has a monitor with green text/image that IMO deserves a brightmap.

I'm pretty sure that @JNechaevsky has once assigned a brightmap to this, but I may be mistaken.

2.1) 8 units tall or less (should suffice for buttons) and
2.2) has lighting-related special (special is 1, 2, 3, 4, 8, 12, 13 or 17).

This is probably not as easy to implement as it sounds. 🤔

Which map and part of boomer.wad is this?

[fabiangreffrath]

That's somehow working:

diff --git a/src/doom/p_lights.c b/src/doom/p_lights.c
index 96ddacc8..a40053b9 100644
--- a/src/doom/p_lights.c
+++ b/src/doom/p_lights.c
@@ -30,6 +30,8 @@
 #include "r_state.h"
 #include "a11y.h" // [crispy] A11Y
 
+#include "r_bmaps.h"
+
 //
 // FIRELIGHT FLICKER
 //
@@ -80,6 +82,11 @@ void P_SpawnFireFlicker (sector_t*	sector)
     flick->maxlight = sector->lightlevel;
     flick->minlight = P_FindMinSurroundingLight(sector,sector->lightlevel)+16;
     flick->count = 4;
+
+    if (sector->ceilingheight - sector->floorheight <= (8 << FRACBITS))
+    {
+        sector->brightmap = R_BrightmapForFlatNum(-1);
+    }
 }
 
 
@@ -141,6 +148,11 @@ void P_SpawnLightFlash (sector_t*	sector)
     flash->maxtime = 64;
     flash->mintime = 7;
     flash->count = (P_Random()&flash->maxtime)+1;
+
+    if (sector->ceilingheight - sector->floorheight <= (8 << FRACBITS))
+    {
+        sector->brightmap = R_BrightmapForFlatNum(-1);
+    }
 }
 
 
@@ -210,6 +222,11 @@ P_SpawnStrobeFlash
 	flash->count = (P_Random()&7)+1;
     else
 	flash->count = 1;
+
+    if (sector->ceilingheight - sector->floorheight <= (8 << FRACBITS))
+    {
+        sector->brightmap = R_BrightmapForFlatNum(-1);
+    }
 }
 
 
@@ -365,5 +382,10 @@ void P_SpawnGlowingLight(sector_t*	sector)
     g->direction = -1;
 
     sector->special = 0;
+
+    if (sector->ceilingheight - sector->floorheight <= (8 << FRACBITS))
+    {
+        sector->brightmap = R_BrightmapForFlatNum(-1);
+    }
 }
 
diff --git a/src/doom/r_defs.h b/src/doom/r_defs.h
index 3be22180..3d57bbec 100644
--- a/src/doom/r_defs.h
+++ b/src/doom/r_defs.h
@@ -165,6 +165,8 @@ typedef	struct
 
     // [crispy] A11Y light level used for rendering
     short	rlightlevel;
+
+    const byte *brightmap;
 } sector_t;
 
 
diff --git a/src/doom/r_segs.c b/src/doom/r_segs.c
index f215f951..d1d2a799 100644
--- a/src/doom/r_segs.c
+++ b/src/doom/r_segs.c
@@ -264,7 +264,7 @@ R_RenderMaskedSegRange
 		    index = MAXLIGHTSCALE-1;
 
 		// [crispy] brightmaps for mid-textures
-		dc_brightmap = texturebrightmap[texnum];
+		dc_brightmap = frontsector->brightmap ? frontsector->brightmap : texturebrightmap[texnum];
 		dc_colormap[0] = walllights[index];
 		dc_colormap[1] = (crispy->brightmaps & BRIGHTMAPS_TEXTURES) ? colormaps : dc_colormap[0];
 	    }
@@ -411,7 +411,7 @@ void R_RenderSegLoop (void)
 	    dc_texturemid = rw_midtexturemid;
 	    dc_source = R_GetColumn(midtexture,texturecolumn);
 	    dc_texheight = textureheight[midtexture]>>FRACBITS; // [crispy] Tutti-Frutti fix
-	    dc_brightmap = texturebrightmap[midtexture];
+	    dc_brightmap = frontsector->brightmap ? frontsector->brightmap : texturebrightmap[midtexture];
 	    colfunc ();
 	    ceilingclip[rw_x] = viewheight;
 	    floorclip[rw_x] = -1;
@@ -435,7 +435,7 @@ void R_RenderSegLoop (void)
 		    dc_texturemid = rw_toptexturemid;
 		    dc_source = R_GetColumn(toptexture,texturecolumn);
 		    dc_texheight = textureheight[toptexture]>>FRACBITS; // [crispy] Tutti-Frutti fix
-		    dc_brightmap = texturebrightmap[toptexture];
+		    dc_brightmap = frontsector->brightmap ? frontsector->brightmap : texturebrightmap[toptexture];
 		    colfunc ();
 		    ceilingclip[rw_x] = mid;
 		}
@@ -467,7 +467,7 @@ void R_RenderSegLoop (void)
 		    dc_source = R_GetColumn(bottomtexture,
 					    texturecolumn);
 		    dc_texheight = textureheight[bottomtexture]>>FRACBITS; // [crispy] Tutti-Frutti fix
-		    dc_brightmap = texturebrightmap[bottomtexture];
+		    dc_brightmap = frontsector->brightmap ? frontsector->brightmap : texturebrightmap[bottomtexture];
 		    colfunc ();
 		    floorclip[rw_x] = mid;
 		}

[JNechaevsky]

I'm pretty sure that @JNechaevsky has once assigned a brightmap to this, but I may be mistaken.

Over the years I've tried repeatedly to make a brightmap for this texture. It is impossible because the colors are repeated in many areas.... For example, even if you try to highlight the green colors as carefully as possible, they will still be very common on the metal parts:

If you capture less green colors, then the text on the monitor will stop highlighting, which is not logical at all.

Here, unfortunately, only the PNG-brightmaps implementation will help.

[SoDOOManiac]

@JNechaevsky, thank you for all the research on this texture 's brightmap! In fact I am fine with the brightmap you posted here, assuming there are green LEDs on the PCB.

this texture

I couldn't find the answer anywhere why COMPTALL isn't present in doom.wad or doom2.wad either.
Does the executable compose this texture out of other COMP* parts?

[JNechaevsky]

I couldn't find the answer anywhere why COMPTALL isn't present in doom.wad or doom2.wad either.

COMPTALL It appears on...

Doom.wad:

• E1M1: 6 times
• E1M2: 90 times
• E1M3: 31 times
• E1M4: 31 times
• E1M5: 20 times
• E1M6: 66 times
• E1M7: 82 times
• E2M2: 18 times
• E2M4: 11 times
• E2M5: 1 times
• E2M6: 4 times
• E2M7: 22 times
• E3M3: 3 times

Doom2.wad:

• MAP02: 3 times
• MAP08: 7 times
• MAP09: 4 times
• MAP10: 1 times

And of course it's heavily composited (it is not crucial for brightmap, because it is applied to the whole texture, not to its patches.) :

Details

[SoDOOManiac]

And of course it's heavily composited (it is not crucial for brightmap, because it is applied to the whole texture, not to its patches.)

Now I see that my SLADE just doesn't have the needed window open.

I'm fine with the brightmap making all the green parts of this texture bright, for circuit boards let's imagine the green pixels are LEDs.

@fabiangreffrath, @JNechaevsky , what do you think?

[fabiangreffrath]

@fabiangreffrath, @JNechaevsky , what do you think?

Nope. I don't think we win anything if we turn the entire texture into a greenish glowing mishmash.

Also, I am not convinced of the patch I posted earlier. At first, it appears like a generic solution, but in reality it is very much tailored to this one specific situation in this one specific map. And it takes sectors into the solution which were formerly completely kept out of the equation.

[JNechaevsky]

I agree, it's a mishmash indeed, matters no if just a few, rational or whole amount of pixels are brightmapped.
Iconic huge secret from E1M2:

Details

See? It's always just wrong. If only there could be a tiny chance to properly apply even a few colors to this texture, then such brightmaps will be already available in all friendly ports with PLAYPAL-based brightmaps. But it's technically impossible.