Brightmaps textures not working right

[Dynamo]

Hello all! I am here to report a bug that has seemingly flown under the radar, hopefully it can get fixed. The bug is related to the BRIGHTMAPS feature. As you all know, the way that one feature works is that a separate, grayscale image is added to the .wad/.pk3, having the same name as an in-game graphic, and that graphic will show up as having higher brightness in some parts depending on how the greyscale image is set up. Personally I think it's an excellent feature as it makes certain maps look much, much more atmospheric. However there appears to be an unintentional limitation regarding texture graphics. Basically the issue is that if I have a texture replacement for an original Doom 2 texture, it will automatically disable the brightmaps. This appears to be akin to using the "iwad" command in the definition as seen here: https://zdoom.org/wiki/GLDEFS#Brightmaps, however it appears to be mistakenly enabled by default. I tried messing with the configurations but did not find any conventional way to get this to work. Here is an example:

http://i.cubeupload.com/KzWkMK.png

As you can see I've replaced the skull lock marker graphics with differently colored variants, however this automatically disables the (otherwise fully working) BRIGHTMAPS. The only way I can get the brightmaps to show up is to either remove the custom graphic completely, or make an edited version of Doom2.wad and remove the original texture completely. If I do the latter thing, it actually works:

http://i.cubeupload.com/G4p42I.png

Now the problem is, this is a bug that seems to be specific only to wall textures, and it seems to have no issues with flat graphics or sprites. Here is an example from Evilution Map24:

http://i.cubeupload.com/hpWvpn.png Again, this is with replaced textures (though they are identical to the originals) and you can see how the lava as well as hellish floor do light up with the brightmaps, yet ROCKRED does not. But, if I go ahead and remove ROCKRED from the IWAD, then it, again, works as it should:

http://i.cubeupload.com/3PLnrc.png

Here are two more extreme examples, from Realm of Chaos map29:

http://i.cubeupload.com/Pka3W7.png With standard Doom2.wad and a graphic replacer

http://i.cubeupload.com/Ur9sqR.png With textureless Doom2.wad and a graphic replacer

So... it is clear there must be some error in the way brightmaps walls, but not other forms, are read by the game. I'd really like to see it fixed as I think brightmaps is a really awesome feature which I hope to make use of more often in the future. Additionally, quite a few mappacks rely on having identical replacmenet textures due to them replacing the original Doom palette (BTSX does this with enemies, for example, even though they look identical), so quite a few mappacks would be affected by this bug.

Thanks, and I hope my explanation was clear enough. Cheers!

[Graf Zahl]

What mod are you using to define the brightmaps?

[Dynamo]

I have been largely using this one:

http://www.moddb.com/games/doom/addons/sbrightmaps

However I tried to edit it with the configurations listed on the zdoom wiki, as well as to import the brightmaps to the main mod I work on, but the results have been the same although, like I said, this problem seems exclusive to walls and does not affects flats or sprites.

Looking at the code, this is a brightmaps definition for a texture:

brightmap texture BSTONE3
{
map "brightmaps/doom/BSTONE3.png"

}

And this is the one for a flat:

brightmap flat FLOOR1_7
{
map "brightmaps/doom/FLAT17.png"

}

They are the same except there's "flat" instead of "texture" in the latter. The latter is what works and the former what does not.

[_mental_]

Fixed in c2b4efb.

[drfrag]

Is the old renderer affected by this? Becouse the patch seems applicable.

[_mental_]

Probably yes but I didn’t check commit history.