[Half-Life] Enable pre-release glowing textures

[ExpertPizzaTipper]

In early WON versions of Half-Life, lights having an over-brightening effect applied to them worked correctly, however in the current steam build, the cvar gl_overbright does nothing.

Certain textures have a prefix of ~ in their names to state if they glow or not. This is used in a very large amount of textures in Half-Life, but the feature is only functional in pre-release versions of the game. https://www.valvetime.co.uk/threads/half-lifes-lost-feature-glowing-textures.257841/

Shadows are able to be turned on or off with the cvar r_shadows in WON Half-life, but if you attempt to enable them now in Steam Half-Life, the game will crash.

[kisak-valve]

Hello @ExpertPizzaTipper, in general, multi-issue issue reports are bad for any issue tracker.

The gl_overbright issue is already being tracked at #1891. #451 is a near match for r_shadows, but doesn't mention a crash. Let's use this issue report to focus on the glowing texture pre-release feature because it's the first non-duplicate issue mentioned.

[SamVanheer]

The r_shadows cvar isn't even being registered by the engine in the Steam version so if it is crashing then you're probably doing something funky to get the cvar to register in the first place.

[CS-PRO1]

Although I'd love to see the glowing feature making a return. I don't believe the code for that feature still exist. And bringing it back will be even tougher since this is feature is cut from a very early build (Alpha 0.52) But if it was possible to make a return without breaking anything else. I'm totally in for anything new to improve Goldsrc

[Idiot64]

Although I'd love to see the glowing feature making a return. I don't believe the code for that feature still exist. And bringing it back will be even tougher since this is feature is cut from a very early build (Alpha 0.52) But if it was possible to make a return without breaking anything else. I'm totally in for anything new to improve Goldsrc

no, its still in the old versions of the cd release and you don't know when it was cut, you just know it existed then

[Idiot64]

and software and d3d modes by default

[SamVanheer]

gl_overbright was fixed in the 25th anniversary update so this can probably be closed.

[kisak-valve]

Hello @SamVanheer, gl_overbright was scoped out of this issue report. Is it directly linked to the glowing texture request?

[SamVanheer]

r_shadows was also fixed in the 25th anniversary update. Using the cvar won't crash the game and shadows do show up, though it still has Z-fighting issues like always. That's out of scope for this report though.

I'd say this issue can be closed.

[SamVanheer]

Regarding glowing textures: as far as i know gl_overbright never used the ~ prefix for that. It seems to be a naming convention for textures that had texture lighting configured through light.rad.

If pre-release versions of the game did indeed use it to control overbright then it shouldn't be taken into consideration now because all content made for the released version of the game assumes all lighting is affected by overbright.

I don't see anything that indicates that any release builds relied on that prefix and feedback from the community about textures that should be affected indicates that all textures should be considered. I checked Half-Life: Uplink's engine (the oldest version i have) for any evidence of this and there is none.

A few examples of how using prefixes would break overbright where it should be active:

• map c2a5, the first map in the Surface Tension chapter. The asphalt texture out_pav3 should be affected by overbright which changes the color from blue to bright blue (as if the sun were shining on it, which it is)
• map c0a0, the first map in the Inbound chapter. The vending machine texture generic88a should be affected by overbright to make it appear to be backlit

Changing the behavior to only affect textures whose names start with ~ would break overbright again. Do note that the gl_overbright cvar does not control this behavior; overbright is enabled when shaders are in use using the gl_use_shaders cvar.

The behavior is defined in Half-Life/platform/gl_shaders/fs_world.frag, the fragment shader used to render brush faces. Mods can override this with a custom shader if the current overbright behavior is unwanted by shipping a custom shader in Half-Life/<modname>/gl_shaders/fs_world.frag.

Of course since texture names and/or prefixes aren't passed along to the shader you can't implement this behavior using a custom shader, but you can change the overbright behavior globally for brush faces.

[tschumann]

Oh nice, I didn't realise those shaders were overridable. Is there an easy way to test this like setting everything to black?

On Sat, 29 Jun 2024 at 07:15, Sam Vanheer @.***> wrote:

Regarding glowing textures: as far as i know gl_overbright never used the ~ prefix for that. It seems to be a naming convention for textures that had texture lighting configured through light.rad.

If pre-release versions of the game did indeed use it to control overbright then it shouldn't be taken into consideration now because all content made for the released version of the game assumes all lighting is affected by overbright.

I don't see anything that indicates that any release builds relied on that prefix and feedback from the community about textures that should be affected indicates that all textures should be considered. I checked Half-Life: Uplink's engine (the oldest version i have) for any evidence of this and there is none.

A few examples of how using prefixes would break overbright where it should be active:

• map c2a5, the first map in the Surface Tension chapter. The asphalt texture out_pav3 should be affected by overbright which changes the color from blue to bright blue (as if the sun were shining on it, which it is)
• map c0a0, the first map in the Inbound chapter. The vending machine texture generic88a should be affected by overbright to make it appear to be backlit

Changing the behavior to only affect textures whose names start with ~ would break overbright again. Do note that the gl_overbright cvar does not control this behavior; overbright is enabled when shaders are in use using the gl_use_shaders cvar.

The behavior is defined in Half-Life/platform/gl_shaders/fs_world.frag, the fragment shader used to render brush faces. Mods can override this with a custom shader if the current overbright behavior is unwanted by shipping a custom shader in Half-Life//gl_shaders/fs_world.frag.

Of course since texture names and/or prefixes aren't passed along to the shader you can't implement this behavior using a custom shader, but you can change the overbright behavior globally for brush faces.

— Reply to this email directly, view it on GitHub https://github.com/ValveSoftware/halflife/issues/2955#issuecomment-2197671001, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA34IYSIDJ22GR4NSOVNYNLZJXHAJAVCNFSM6AAAAABJ74YKXSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJXGY3TCMBQGE . You are receiving this because you are subscribed to this thread.Message ID: @.***>