[CS 1.6] [Feature Request] cl_flashlights

[Maxi605]

A client-side command to allow the player to see/not see flashlights from other players, this request is because there's players who play the game that don't have a good PC (This is still a thing, i know, but as it's a game that doesn't require a lot of resources, some of the popularity is because of it)

I mainly ask for this for CS 1.6, i don't know if all the HL games uses flashlights, but if could be useful for other games, cool.

[RauliTop]

Also, a server cvar to allow or not the flashlights.

It will be useful too

[SamVanheer]

Also, a server cvsr to allow or not the flashlights.

It will be useful too

The mp_flashlight cvar already does that.

[RauliTop]

Also, a server cvsr to allow or not the flashlights. It will be useful too

The mp_flashlight cvar already does that.

True, I was thinking in another thing.

Probably a cvar to avoid spamming flashlights. One use per X seconds or simply add a delay without a cvar when flashlight is used multiple times by the same player

[SamVanheer]

The problem with the flashlight is it moves around all the time, so it interacts poorly with the dynamic lighting system.

Every frame the engine marks every surface that is touched by a dynamic light: https://github.com/id-Software/Quake/blob/bf4ac424ce754894ac8f1dae6a3981954bc9852d/WinQuake/gl_rlight.c#L184-L192

And then it applies the light: https://github.com/id-Software/Quake/blob/bf4ac424ce754894ac8f1dae6a3981954bc9852d/WinQuake/gl_rsurf.c#L85-L86

The problem is that GoldSource's code for R_MarkLights is a little different:

if ( surf->dlightframe != r_dlightframecount )
      surf->dlightframe = r_dlightframecount;
    surf->dlightbits |= bit;

Quake resets the bits, GoldSource just adds them and resets them elsewhere:

R_BuildLightMap

psurf->dlightbits &= r_dlightactive;

I'm assuming this change was done for a reason, but reverting it might fix it.

r_dlightactive is a mask of all currently active lights, updated once per frame after decaying lights. All lights that have died (die time <= current time) or that have decayed to 0 radius are considered to be inactive.

As a result, as long as the flashlight dynamic light remains active the engine thinks that all surfaces that have at some point been in range of the flashlight are still in range, resulting in an increasing number of surfaces whose lightmaps are being recalculated and reuploaded.

A player could turn on their flashlight and shine it on all surfaces to increase the bandwidth usage for dynamic lighting. Fortunately flashlights are rendered at player origins for all players other than the local host, but it's still somewhat exploitable.

This is in addition to the performance issues caused by dynamic lighting in general, which is caused by the system re-uploading lightmap data that has been changed by dynamic lights. Modern cards expect you to perform those calculations on the GPU using shaders.

A proper fix would require the distance check to be performed during lightmap calculation, before anything has been modified so the surface can be excluded from dlights that are no longer in range.

An even better solution would require the use of a shader to perform these calculations in the GPU, eliminating both the bandwidth usage for dynamic lights and allowing the dlight code to leverage the GPU's processing power. Unfortunately shaders are not an option without a complete renderer rewrite.

[i486]

A client-side command to disable flashlight will certainly reduce amount of swearing by players with low spec PC on public servers. Very good request! I hope it's doable.

[RauliTop]

@mikela-valve maybe you should take a look here for future release

[metita]

This should be a high-tier priority request, some servers relies on night vision/flashlight to make gameplay more realist.

[kolcsarlevi]

but the fps drop remains for he grenades dynamic lightning, so removing the flashlight is not the best solution. removing the dynamic lightning (allowing r_dynamic 0) or fixing is the way to go.

[Maxi605]

but the fps drop remains for he grenades dynamic lightning, so removing the flashlight is not the best solution. removing the dynamic lightning (allowing r_dynamic 0) or fixing is the way to go.

This issue is to add a option to give the player an option to see/not see others flashlights, not remove them entirely

[kolcsarlevi]

but the fps drop remains for he grenades dynamic lightning, so removing the flashlight is not the best solution. removing the dynamic lightning (allowing r_dynamic 0) or fixing is the way to go.

This issue is to add a option to give the player an option to see/not see others flashlights, not remove them entirely

yes, I know that your thread is about removing the flashlight with a command but the real problem is in the opengl dynamic lightning rendering: " The GoldSrc engine was written long before modern graphics programming techniques such as vertex buffer objects were around. The OpenGL in GoldSrc (and all other OpenGL games of the time) were executing OpenGL instructions in immediate mode, meaning that everything to be drawn on screen must be sent to the GPU and redrawn every frame -- the GPU forgets everything when it comes to rendering the next frame. AMD (and ATI) GPU's have bad performance issues with immediate mode OpenGL, whereas nVidia GPU's handle this much quicker.

You can experience the same issue in Minecraft (before 1.8), as that was entirely using immediate mode OpenGL too. I have exactly the same issue with my AMD R9 280X, where as my (years older) nVidia GTX 560Ti handled Sven Co-op and Minecraft much faster. I did ask AMD about this but they blamed the games (GoldSrc and Minecraft), due to them not making the best use of a modern OpenGL API. I guess nVidia were just nicer when it came to retaining strong compatibility with older software."

[SamVanheer]

We've known why it happens for years, the problem is changing it to retained mode (shaders, GPU buffers and so on) represents significant changes in graphics code and system requirements, and the potential to introduce new bugs, such as mods that use immediate mode OpenGL in their own code no longer functioning.

The cost of making those changes is pretty big so it would have to be handled in a way that still allows the older immediate mode version to be used, which means at the very least separating out the graphics code into interfaces that multiple backends can implement.

That's a lot of work, the potential to break all sorts of stuff is pretty high (e.g. renaming engine libraries due to backends being implemented in separate dlls can break AMXMod code that relies on hooking into specific memory locations) and there is likely custom content and even official content that is relying on some glitch or undefined behavior in OpenGL APIs to work. Replicating that exactly is difficult.

And lastly, it's costly to make (in terms of money) which is why open sourcing the engine and letting the community develop it as a standalone version is the best solution.

As far as GPU-specific compatibility goes different drivers have different degrees of support. One implementation could support it at the hardware level, others may use software emulation (much slower). Immediate mode is very old, does not scale well and relies on frame-by-frame input from main memory so dropping support could allow for better optimizations for retained mode.

[kolcsarlevi]

Nice explanation, so the real solution for the gamers is to get a GPU vendor who handle better the immediate OpenGL instructions. And that's Nvidia basically.

[SamVanheer]

Pretty much. That's the only realistic solution for the time being.