renderer: implement mapOverBrightBits in GLSL

[illwieckz]

Implement mapOverBrightBits in GLSL.

This is required for deluxe mapping since we need to do the computation on lights without blended attenuation.

This will also be required when using lightmaps in non-linear colorspace as the computation would have to be done on lights after they are linearized.

[slipher]

Can you say which changes to the GLSL correspond to lightmaps, light grids, and vertex lighting?

[illwieckz]

I think I will postpone that work for after 0.55 is released, with other things like sRGB. Such work may uncover some bugs or require more redesign in other place and may be the entrance of a rabbit hole 😄️.

[illwieckz]

Can you say which changes to the GLSL correspond to lightmaps, light grids, and vertex lighting?

I may have to re-introduce R_ColorShiftLightingBytes for vertex lighting as there is no knowledge in GLSL if the color is a vertex color or something else. This branch was based on old branch I wrote years ago, at a time we did not have vertex lighting yet.

All the code in GLSL in this branch is about both lightmap and gridlight. PR #1032 made possible to write a single mapOverBrightBits function call for non-ambient light in lightMapping GLSL for both light maps and light grid (light maps don't have ambient light).

• renderer: make GLSL code easier to read with computeLight, computeDeluxeLight and computeDynamicLights #1032

[illwieckz]

This implementation has no future.

The design of the optimal code for us is deeply tied to our linear/sRGB implementation, so it will be part of #1034:

• WIP: renderer: implement GLSL sRGB support #1034

[illwieckz]

This was actually repoducing a bug (light being clamped and then wrong)…