Implement r_teleporterFlash cvar

[drjaska]

In Quake 3 Arena when the player goes in a teleporter entrance but has yet to arrive at the exit (probably due to the server and client architecture and ping) the renderer registers this as being in hyperspace and the screen is covered with a pure white shader. Having there brief pure white flashbangs is obviously bad for the more photosensitive players.

r_teleporerFlash is a new cvar which allows more photosensitive users to opt out of seeing a white flash every time they are in hyperspace between a teleporter entrance and its exit. For now there is only a fade to black option implemented alongside the fade to white original and default option.

The new feature is opt-in and preserves the original pure white teleporter flash as the default. Though I would be happy to change the cvar default to 0 to not flashbang users who explicitly do not wish for them.

Earlier this year CPMA developers committed this to cnq3 which allows players to draw pure black screens instead of white when in hyperspace.

Quake 3 DeFRaG has for a long time allowed for a shader which addresses the issue like this:

teleportEffect
{
    cull none
    {
        map gfx/colors/black.jpg
        blendFunc GL_zero GL_ONE
    }
}

Both of these will work in DeFRaG via quake3e or oDFe in the future (though when I attempted to test that shader with quake3e even before my changes I don't see it affecting the hyperspace visual but I guess it works for others) I have not looked at other engines or mods for what they are doing. I chose the same cvar name as cnq3 for cross-engine config compatibility and user intuitivity as I do not see a reason to change it.

This cvar is future-proof and extendable as more styles are easy to add with the cvar value being 2 or above. 0 for black, 1 for white, 2 and above for new funky variants.

These changes implement the cvar in renderer, renderer2 and renderervk. (renderer2 and renderervk are untested but should work with the same copypaste changes AFAIK. Just running make did not build them and I did not look into how to build them.)

[ensiform]

Doesn't renderervk have a blackshader that's optimized for uploading pure black image data to the gpu rather than using the white shader colored 0,0,0,1 ?

[drjaska]

Doesn't renderervk have a blackshader that's optimized for uploading pure black image data to the gpu rather than using the white shader colored 0,0,0,1 ?

I did manage to find image_t *blackImage in rendervk but images were not used for the hyperspace visual. For shaders which were used I can't find a shader_t *blackShader or similar myself.

I personally would value more having more identical codebases between the render backends by having more shared or duplicate code but I'm not a maintainer here. If you feel like there should be a micro-optimisation (the hyperspace visual is rendered as a view blocker when nothing meaningful can be shown instead of it) done here at the potential cost of readability and maintainability then you can open another pull request and the maintainers can decide on merging it. I'm not a graphics programmer but I don't think that in the context where that visual is shown that it is awful to keep branching code as minimal as possible and to just show a white shader with 0,0,0,1 RGBA.