Open 54ac opened 6 months ago
Ah I thought I was going crazy, yep gl_overbright 1 currently does nothing for me too, but beware, as even with the patched dll, lighting won't be 1:1 match with Software, environments will be, but not entities that will still look better lit in Software, I'm curious if Valve will be interested in fixing that too. I had screenshots at some point to show the subtle differences but I lost them, I'm sorry...
According to the screenshot you posted, the only thing they had fixed is the weird chromatic aberration effect was fixed. It still lacks the bloom from the actual overbright mode through.
In OpenGL, gl_overbright
is no longer used. The new command is gl_use_shaders
(default 1), the overbright fix is implemented on the shader level
In OpenGL,
gl_overbright
is no longer used. The new command isgl_use_shaders
(default 1), the overbright fix is implemented on the shader level
Well, it's not working as intended then, because I compared on and off, and while there is indeed a difference, the overbright hack as well as software mode both have much metter lighting still.
In OpenGL,
gl_overbright
is no longer used. The new command isgl_use_shaders
(default 1), the overbright fix is implemented on the shader level
Disabling gl_use_shaders
seems to making it much brighter.
gl_use_shaders 0
gl_use_shaders 1
gl_use_shaders 0
- Same as gl_overbright 0
gl_use_shaders 1
- Same as gl_overbright 1
, but little bit darker than previous version.
Also with the HLFixes patch:
gl_overbright 1
(gl_use_shaders
now does nothing after patching with HLFixes)
gl_overbright 0
(gl_use_shaders
now does nothing after patching with HLFixes)
In OpenGL,
gl_overbright
is no longer used. The new command isgl_use_shaders
(default 1), the overbright fix is implemented on the shader level
The implementation seems to make the game a lot darker. It also doesn't seem to support multitexturing, at least on that particular wall. See here (gl_use_shaders 0 is brighter):
Looks like the overbright check is still included in the latest hw.dll. Bypassing it enables gl_overbright like in the previous builds, allowing for more comparisons:
gl_use_shaders 0
, gl_overbright 0
:
gl_overbright 1
:
gl_use_shaders 1
:
Will doing the hex edit put you at a risk of getting VAC banned on multiplayer though? Heard that at some point, which is why I kind of prefer waiting for an official fix!
Will doing the hex edit put you at a risk of getting VAC banned on multiplayer though? Heard that at some point, which is why I kind of prefer waiting for an official fix!
I would assume so, just to be safe. But it's useful for comparisons, as seen above.
how do you hex edit the new dll though? the sector isn't the same, and the hex string is different too!
how do you hex edit the new dll though? the sector isn't the same, and the hex string is different too!
It's the same thing still, but at a different location:
The jump instruction is now at offset 2378047 in hw.dll. I think the latest release of HLFixes linked above supports the latest build and enables gl_overbright without the need for manual hex editing, though in a different way, by forcing gl_texsort.
The new update doesn't appear to actually add overbrightness, but merely restores the original look of gl_overbright 0. This is still a step in the right direction, as many lights are no longer clipped at the expense of the artist's intention. One consequence is that modern map compilers expect this quirky behavior and try to compensate for it, so now they will look wrong. Preferably, actual overbrightness would be a thing, for it has rather large aesthetic benefits.
One consequence is that modern map compilers expect this quirky behavior and try to compensate for it, so now they will look wrong.
They'll look different, but not incorrect. When displayed with proper overbrightness, they'll just be slightly brighter, but not by much. The clamping only occurred above a certain brightness threshold (about 160, I think? the lightmaps are 24-bit); anything darker than that was basically the same.
To any map makers reading: add the -limiter 255
argument to your HLRAD compilation step to remove the compensation done by VHLT.
gl_use_shaders 0 vs gl_use_shaders 1
IMHO, gl_use_shaders 1 looks pretty good.
Odd. I took this screenshot yesterday, and it definitely doesn't seem as bright.
Booting it up now, though, it does actually look brighter. Did they hotfix it, or was my config screwed?
Seems like it got hotfixed today.
Looks fine now:
The wall texture still changes for some reason, but the effect has indeed been fixed.
Replying to https://github.com/ValveSoftware/halflife/issues/3424#issuecomment-1817682182
And this is with gl_use_shaders "1"? The gl_overbright command is still defunct?
And this is with gl_use_shaders "1"? The gl_overbright command is still defunct?
Yes, this is gl_use_shaders
0 and 1 from the latest untouched build, so without the overbright patch. It seems that an update was pushed earlier today which modified hw.dll among other files, so it checks out.
They'll look different, but not incorrect.
In comparison to stock maps, that is. They looked "fine" before since the clamping level was consistent across all maps, but now you won't ever get full brightness until you shine a flashlight onto something. I'll definitely be noticing sand textures out in the sun somehow not blooming out when they should.
gl_use_shaders
breaks underwater fog:gl_use_shaders
set to 0
: gl_use_shaders
set to 1
: Better comparison after November 19 patch:
NOTE: everything below looks almost vanilla or vanilla with HLFixes, just with the PS2 rock textures and that was it, but the result should be the same.
gl_use_shaders 0
with latest update, vanilla:Fog is bright, which makes the black metal gate more visible.
gl_use_shaders 1
with latest update, vanilla:Broken fog, obviously.
gl_use_shaders 1
and gl_overbright 0
with latest update, HLFixes 1.20 Beta 1:NOTE: HLFixes 1.20 Beta 1 is only compatible with older Nov 17 version, but it works fine with the Nov 19 patch. Fogs looks extremely dark, and the brightness was reduced. But this makes the black metal gate less visible as its should be.
gl_use_shaders 0
and gl_overbright 0
with latest update, HLFixes 1.20 Beta 1:Only brightness differences.
gl_use_shaders 0/1
and gl_overbright 1
with latest update, HLFixes 1.20 Beta 1:If gl_overbright 1 is enabled (with HLFixes patch), gl_use_shaders does nothing. Underwater fog is slightly brighter, but not as bright as software mode or with gl_use_shaders 0 on vanilla.
Another comparison with disposal
map, its best to use something like this image comparison slider tool to comparing these screenshots.
gl_use_shaders 0
with latest update, vanilla:gl_use_shaders 1
with latest update, vanilla:gl_use_shaders 1
and gl_overbright 0
with latest update, HLFixes 1.20 Beta 1:Differences: Appears to be darker than vanilla.
gl_use_shaders 0
and gl_overbright 0
with latest update, HLFixes 1.20 Beta 1:Looks the same as having it off on vanilla, same brightness.
gl_use_shaders 0/1
and gl_overbright 1
with latest update, HLFixes 1.20 Beta 1:If gl_overbright 1 is enabled (with HLFixes patch), gl_use_shaders does nothing. Differences: Waste looks much brighter with gl_use_shaders 1 on vanilla than gl_overbright 1 with HLFixes patch.
Conclusion: gl_use_shaders 1 has broken underwater fog, but brighter toxic waste, while gl_overbright 1 did not have any issues whatsoever. For the lamp textures, both seems to look the same.
Underwater rendered with OpenGL looks buggy, look at semitransparent wall on the screenshots, it's not covered with fog. If only they could do the same look as SW renderer does
Decided to testing it again with c2a4e.bsp
(Questionable Ethics), with HLFixes (latest one, 1.2.0 beta 2, which just come out recently) and vanilla. HLFixes now disable gl_overbright
if gl_use_shaders
is used instead.
This time I have to make sure the gl_overbright
and gl_use_shaders
are loading properly by reloading the map to get the actual result, and it's seems to look identical.
gl_use_shaders 1
gl_overbright 1
Underwater bug is still present.
gl_overbright 1
- Underwater (HLFixes 1.2.0 B2)gl_use_shaders 1
- Underwater (HLFixes 1.2.0 B2)gl_use_shaders 1
- Underwater (Vanilla)brightness 1
gamma 2.2
Protocol version 48
Exe version 1.1.2.2 (valve)
Exe build: 23:48:06 Nov 20 2023 (9888)
November 22, 2023 Update
Fixed underwater fog rendering in OpenGL.
Not bad, I wonder if the tranparent textures can be included in the fog pass.
well, this most recent update seemed to have fixed the water-fog with overbright enabled, but it broke being able to enable Detailed Textures with overbright.
Detailed Textures and Overbright combined wasn't possible until the Anniversary update, but now it isn't working.
If it's possible try to get all 3 working Overbright/DT/FOG simultaneously and it will be the best it has ever been.
Also, I think depending on the game, if Shaders are enabled by default now, it's going to break DT with no ingame option to disable the overbright/shader. DOD/CSZ both can use DT among with mods.
Detailed Textures and Overbright combined wasn't possible until the Anniversary update, but now it isn't working.
Are you sure detail textures worked together with shaders before? I was under the impression it was one or the other, like overbright pre-Anniversary, but I haven't tested this out much. There is an unused detail textures entry in the new video options menu, hopefully we won't have to deal with a limitation from decades ago for much longer.
November 22, 2023 Update
Fixed underwater fog rendering in OpenGL.
Definitely better than before, although HLFixes is still viable since it preserves the correct appearance of that black gate (and presumably similar geometry/textures). It would be nice if they could tweak the effect further.
Detailed Textures and Overbright combined wasn't possible until the Anniversary update, but now it isn't working.
Are you sure detail textures worked together with shaders before? I was under the impression it was one or the other, like overbright pre-Anniversary, but I haven't tested this out much. There is an unused detail textures entry in the new video options menu, hopefully we won't have to deal with a limitation from decades ago for much longer.
(The bottom picture is before the update with both Overbright and Detailed Texture enabled. Now if you enable the shader, it forces the DT off.)
Yeah, it works.
I was actually in the middle of creating some new subtle Detailed Textures too haha. Just because I was happy I could combined which wasn't possible before.
Also, a lot of upcoming mods use a lot of DT now, even if subtle, which all looks even better combined with Overbright.
In OpenGL,
gl_overbright
is no longer used. The new command isgl_use_shaders
(default 1), the overbright fix is implemented on the shader level
They should remove the cvar then.
In OpenGL,
gl_overbright
is no longer used. The new command isgl_use_shaders
(default 1), the overbright fix is implemented on the shader levelThey should remove the cvar then.
It probably still does something if you rely on the old method (for whatever reason). Either way, they should rather make it actually do something by default.
Looks like there is a different issue. While the world is now affected by overbright, models are still clamped at 100% in OpenGL. In software rendering, models are properly overbrigtened as well.
Same thing. In this new update HLFixes (both 1.2.0 Beta 1 and 2) stops working aswell (as gl_overbright
does nothing now even it was patched using HLFixes), so had to using the pre-25th with HLFixes patch to compare the changes with older fix.
The older gl_overbright 1 method from pre-25 also have the issue aswell.
gl_use_shaders 1
gl_overbright 1
(older pre-25th anniversary with HLFixes 1.1.0)gl_use_shaders 0
Protocol version 48
Exe version 1.1.2.2/Stdio (valve)
Exe build: 12:56:39 Nov 22 2023 (9890)
Currently it seems Detailed Textures, Underwater Fog, and Overbright are all working in tandem now.
The fact that there was always an inconsistency between models and the world just reinforces the need for it to be optional, for I would rather have a cohesive look than the occasional eye candy.
Really though, it should be an easy fix. There is a fragment shader in the files that controls this behavior using predefined math. All it would take was a variable inserted into the shader code based on the state of gl_overbright. I'm not certain if this is VAC safe, though. A similar fragment shader for models would also work out well. Here is Xash3D with unified overbrightness using just fixed function OpenGL 1.3. Nothing sticks out and creates the infamous cartoon object effect. https://tvtropes.org/pmwiki/pmwiki.php/Main/ConspicuouslyLightPatch
Currently it seems Detailed Textures, Underwater Fog, and Overbright are all working in tandem now.
edit
At least with Half-Life only.
@SirYodaJedi should be able to verify detailed textures working again in both CZero and DoD per today's update - they had a separate issue for it that they marked as "completed" this morning.
How do one get DT with Half Life? Through a mod?
gl_use_shaders seems broken in DoD. CZero won't even launch (Assertion failed!
).
How do one get DT with Half Life? Through a mod?
It's a feature of GoldSrc added in Condition Zero, but it can retroactively be added with mods. https://gamebanana.com/mods/6737
@SirYodaJedi should be able to verify detailed textures working again in both CZero and DoD per today's update - they had a separate issue for it that they marked as "completed" this morning.
gl_use_shaders seems broken in DoD. CZero won't even launch (Assertion failed!).
I only tested in DoD, yes; haven't bothered testing CZero because I've heard it doesn't load (which is a separate issue altogether). You might be right about gl_use_shaders being broken in DoD; it didn't make any visible difference when toggled. I closed #3555 nonetheless because the detail textures themselves weren't broken, which was what the issue was for.
i hope they manage to fix this issue with the renderer gl_use_shaders
Looks like there is a different issue. While the world is now affected by overbright, models are still clamped at 100% in OpenGL. In software rendering, models are properly overbrigtened as well.
Overbright on models (aka: Overbrightbits) I don't think was ever supported in Half-life with 3D acceleration. So that would be a new feature.
Looks like there is a different issue. While the world is now affected by overbright, models are still clamped at 100% in OpenGL. In software rendering, models are properly overbrigtened as well.
Overbright on models (aka: Overbrightbits) I don't think was ever supported in Half-life with 3D acceleration. So that would be a new feature.
It indeed wasn't, which is one of the reason I always preferred Software rendering over OpenGL, with some legacy effects like more accurate colors with tranparency and the sweet looking water ripple effect. (as well as better handling of decals too) And I'm all in for new features :) Basically Software is the ground truth, and I want OpenGL to be like Software, but in 32 bit color and arbitrary resolutions.
The lack of 24-bpp is the only reason I stay away from software rendering. Unreal managed to do it in its software renderer.
After today's hotfix, it doesn't seem that sv_allow_shaders
is enabled by default on every application. (Like, Team Fortress Classic) Which makes the new shader option in the menu not function.
After today's hotfix, it doesn't seem that
sv_allow_shaders
is enabled by default on every application. (Like, Team Fortress Classic) Which makes the new shader option in the menu not function.
Yeah It seems like sv_allow_shaders
is defaulted to off in the engine and flipped on specifically in Half-Life 1 meaning that currently the "Use shaders" option under video settings is effectively non-functional by default for any GoldSrc game that isn't Half-Life 1.
This affects and is not limited to the below:
If possible please make it so sv_allow_shaders
is defaulted to 1
engine side or maybe find a way to hardcode the new overbright shader and have sv_allow_shaders
just affect loading of custom non-default shaders.
This was probably a deliberate action to discourage any potential foul play in Counter-Strike through shader modification that VAC (probably) won't restrict.
The Anniversary Update website states:
However, toggling gl_overbright does not seem to make any difference, as can be seen in the following screenshots of the first lamp on the left on t0a0:
Compare this to the previous build with hw.dll patched to allow for overbright support: