Half-Life overbright compatibility

[PhilsComputerLab]

And two more...

[swaaye]

What version is that?

[PhilsComputerLab]

So here are some screenshots with 1.1.1.0 patch.

Also, can someone please tell me what level or area the first photos in this thread are from?

[ZanQuance]

Is it a level or a test map? I don't recognize it.

[PhilsComputerLab]

Not sure. I did send a pm, hopefully I get a reply.

[Firtasik]

Xash3D FWGS 0.19 has been released.

"Two overbright modes are implemented. Toggle with gl_overbright <0/1/2> cvar."

[swaaye]

That looks really interesting. I'm going to try that on Android and Windows...

[leileilol]

xash sucks though. suspicious origins of allegedly "written from scratch" code resembling actual valve (and id) code, and sdk-license violatiions make xash too legally toxic

Messing with HL myself i've only noticed overbrights only seem to be working for Voodoo Graphics. Voodoo2 and later breaks it, likely not implemented for multitextured paths

EDIT: This seems to be the case. Copying 3dfxgl.dll, hexing SGIS_ to ASSS_ in its multitexture extension string (so half-life can't detect it) brings overbrights to Voodoo2, at a performance cost

Hexing hw.dll would be more ideal, but that's more encrypted/compressed in later patches (anti-cheat reasons) so you'll have to copy your ICDs over and hex em instead.

Don't forget to hex the ARB_Multitexture stuff too.

(this may also trip VAC in Steam half-life so don't do it there)

[tgod]

Messing with HL myself i've only noticed overbrights only seem to be working for Voodoo Graphics. Voodoo2 and later breaks it, likely not implemented for multitextured paths

Isn't "gl_texsort 1" suppose to be enough to disable multitexturing for overbrights to work on those cards?
http://www.play-half-life.de/H-L_2.html#txsrt

[swaaye]

Maybe XASH3D is questionable but you do get overbrights even on Android devices. I got Half Life, Blueshift, Gunman Chronicles, They Hunger and Darkstar running on my tablet and the touch controls work great. Taking screenshots on it it tricky though.

The two center touch buttons are two I made to take screenshots and open the console. It's tricky to take screenshots on a tablet....

gl_overbright 2


1


0



0


1


2

[Firtasik]

Sunny day in Black Mesa:

[j^aws]

Regarding multi-texturing on Voodoos breaking the overbrighting effect, has anyone tried it on a Banshee? I played Half-Life on one at launch, and seem to recall an excessive glowing affect around vending machines...

[leileilol]

A Banshee doesn't have multi-texturing and likely would have working overbright.


I have an AGP Banshee....somewhere.

Isn't "gl_texsort 1" suppose to be enough to disable multitexturing for overbrights to work on those cards?

gl_texsort isn't on all versions.

[silikone]

Late reply to a PM, that map is just something quick I made to test the lighting. Perhaps I should create a map dedicated to the testing of all kinds of conditions with lighting and textures.

From what I gathered, with overbrightness, textures seem to reach original brightness when exposed to around 75% lightmap intensity levels. I'm sure there's some simple math that describes this process, but it's probably complicated by the way gamma is handled in Half-Life.
There are all sorts of possible combinations with the 'gamma', 'brightness', and 'lightgamma' variables. Half-Life defaults to 2.5 gamma, but the engine appears to natively work with a level of 2.0. I have experimented with these, but how they work exactly is still a mystery to me.

On a side note, Half-Life also seems to support two types of dynamic lights. The first one blends in with the ambient lighting in a pseudo-directional manner. The second one only lights up models, but it is properly directional and locally present. Only up to three of these are active simultaneously

[leileilol]

What can also help in determining the lightness is loading a Half-Life map in one of those Quake source ports that support HL BSPs (i.e. Darkplaces, Engoo, etc). Quake's overbrights are usually one half of a lightmap's brightness and get clamped to half in GLQuake normally. Quake2's overbrights are only calculated for the software renderer's lightmap build code and are shifted down in GL on that (looking rather dark)

[silikone]

http://puu.sh/vY6tk/74878fe1ac.zip

Here's a small test map. There is a room that has a wall of squares, which are various combinations of light levels and pigments. The light scale doesn't follow a consistent curve, so for reference, 50% (128/255) is on the bottom left.

Sunny day in Black Mesa:

Speaking of the sun, using the default gamma correction in the editor, assuming the light is supposed to be physically accurate, the ratio between the the brightest white and the darkest non-black is about 1:65536 (2^16), as opposed to 1:255 as seen in Quake 2. Still lower than the real ratio of one to one million between moonlight and sunlight, but close nonetheless. This doesn't really matter much in terms of how bright the levels are and can be, but it does mean that making the levels look good in the latter game relies on good artistry rather than knowledge of physics.

[auron]

And two more...

what renderer did you use for these screenshots? D3D gives me severe Z-fighting issues on a V5 5500, last official drivers and fully patched game. i also got missing decals but could fix them with gl_polyoffset -0.01. thinking of swapping to a TNT2 for this game as the readme mentions D3D as unsupported for 3dfx.

[auron]

had no luck with the tnt2, and a kyro ii also gave me z-fighting, but it turns out overbright works when using opengl on the kyro. finally correct graphics! there's only one level of overbright available with the newest patch, but still pretty good

on a side note, the kyro's filtering can look somewhat like n64 in spots

[silikone]

Using a tool to enable OpenGL extension limiting on the NVIDIA drivers results in a functional gl_overbright in Half-Life Steam on a modern PC. Unfortunately, without multitexture support, detail textures are also disabled.
Wouldn't it be insanely easy to have both by using GL_RGB_SCALE? As a bonus, there would be no banding caused by a two pass blend.