@metslime. No doubt that work and I likely devised something like it.

I think the situation that was aggravating is the possibility of the regular texture and the glow texture replacement not being the same size and factoring in possible rescaling in the (rare) absence of power of 2 textures.

With normal _glow textures, this isn't a factor since there isn't a dependent relationship between the regular texture and the _glow one. 

baker: good point about the different resolutions. While it's still solvable, it's clearly more work to correctly sample one texture and lookup the correct alpha value for the other one. 

fullbrights have the same issues that lightmaps have in a single-tmu environment.
you need to use glDepthFunc(GL_EQUAL) for both your lightmap and your fullbrights, which prevents either additional pass from breaking anything.

with multitexture you just have to ensure your fullbrights don't harm the fragment alpha, so that your alphatest can still discard the fragment correctly.

if you're doing glsl-less bumpmapping and need to use the fragment alpha for some dotproduct values, you can just use glColorMask and specify the masked depth as an initial pass. this of course means that the fence and diffusemap don't have to have any correlation to each other whatsoever, if you're doing weird effects or whatever.

alpha-test has a specfic cut-off point somewhere between 1 and 0. this means that even internal fullbrights can bleed if you don't handle them properly (half-life didn't do fullbrights at all).

if it was blended then you'd have a point, along with other quirks.
there are still problems with coplanar surfaces, of course, but there's nothing you can really do about those. 

GL_EQUAL sounds like a good solution for multipass rendering.

And alpha shouldn't be an issue with fullbrights as fitzquake uses additive blending starting in 0.85. 

Just to keep track, I posted my test with October 2014 build at Quakeone. No fullbrights showing. Here is the test:

https://drive.google.com/open?id=0B3Ww0W8WFfq7SDdxMmxweVotRUU&authuser=0 

@adib

Assume the problem is solved for the moment.

I have been procrastinating on polishing up the Mark V beta mostly because there are 4 or 5 tedious issues that are unrewarding to work through.

But I think I've waiting long enough.

Within a week, there will be a polished Mark V non-beta I will ensure this inconsistency is gone. 

I'm of the opinion that the equivalent of glBlendEquation (GL_MAX) and glBlendFunc (GL_ONE, GL_ONE) is the most appropriate way of handling fullbrights.

The reason why is that there are areas in maps where (diffuse * light * 2) is actually brighter than the fullbright on it's own. This shouldn't be too hard to conceptualize; it's going to happen if the light is brighter than 0.5 (or 128 on a 0 to 255 scale).

The result is that you get a weird transition between normally lit texels and fullbright texels (and the brighter the light the weirder the transition).

This is easily visible on e.g the right-hand lit arrow leading into the e1 entrance in the Start map, and while using a GL_MAX blend doesn't replicate software Quake with precise fidelity, it is much more visually pleasing. (Other examples of the same concept include some lights in Quake which saturate even with 2x overbrighting, particularly if you add dynamics (although some even rarer areas don't even need that); not such a big problem for FQ as it doesn't create coloured dynamics, but very observable if you add them to it).

As a bonus you don't have to remove the fullbright texels from the source image using this method.

Unfortunately neither GL_COMBINE modes nor D3D SetTextureStageState support a maximum blend, so the only ways to do it are to multipass it or do it in a shader. 

I asked you so many questions and forgot to thank you for this awesome work. Hope I could help someway.

Here is another one: does Mark V load external sky textures? There is a sky_mb1.pcx (already tried TGA and PNG as well) in my textures folder, but the engine goes on loading the internal BSP texture. How can I make it load the external one? 

Just skybox support.

None of the FitzQuake/Quakespasm family of engines loads actual replacements for the 256x128 scrolling sky textures. DarkPlaces is the only engine I know offering the ability to replace the scrolling sky with a hi-res version.

[FitzQuake/Quakespasm don't + won't support PNG, just like Q3 doesn't support PNG.] 

Extra info: PNG serves no purpose for replacement textures because when the set is compressed into a .zip file, it gets compressed. The only thing PNG does is require the engine to increase map load times by decompressing the textures every single time. 

TGA already have alpha channel, so screw PNG :)
Your skybox works neat, just tested it. So, screw iD's moving PCX. 

I checked the vs2008 build in the 20141010 package again and noticed that liquids look fine again on my nvidia card if you use r_oldwater "1".

Dunno if that helps with solving the problem - still waiting and hoping for a fixed release. 

Interesting, thanks for info. Could be involved in this somehow. 

Anyone with sky issue (NVidia only) will still have sky issue. Still working on that as I do not have a Nvidia card available. And does not yet have the DX improvements.

http://quakeone.com/proquake/interims/mark_v_20150410.zip

This is a much nicer release than the previous one, but more to go.

The WinQuake version should work and these are proper builds. The glow textures should work.

New feature: Select text using SHIFT in the console and copy, cut and paste with CTRL+X, CTRL+V, CTRL+C, SHIFT+INS, SHIFT+DEL

More versions will follow as I eliminate the known issues. Next one might not be until Monday or Tuesday. 

How does the sky look with r_oldwater 0 and r_oldwater 1?

Does the sky look correct with r_oldwater 1?
Does the sky look wrong with r_oldwater 0? 

also do you get any issues with "r_oldwater 0" with Fiitzquake 0.85 or Quakespasm? 

@ericw -- any oldwater problems in Mark V wouldn't be inherited from Fitz, but something I introduced.

r_oldwater 0 as you no doubt know requires a bit of hand-holding (in the code) because it is ingenious evil render-to-texture trick. Likely, video mode change isn't updating it or I'm clearing (or not clearing) a buffer at the wrong time or not updating the texture at the right time.

Probably a simple oversight on my part.

Source for Beta 2 which is easy to build (compiles out of the box with a key press) for Visual Studio 2008 or CodeBlocks (or Visual Studio 6 with service packs). The WinQuake build does use assembly language for speed and the project files compile those easy.

(The structure of the source is a bit more complex than I prefer, partially due to Nehahra support and Direct3D support.) 

@ericw -- any oldwater problems in Mark V wouldn't be inherited from Fitz, but something I introduced.

r_oldwater 0 as you no doubt know requires a bit of hand-holding (in the code) because it is ingenious evil render-to-texture trick. Likely, video mode change isn't updating it or I'm clearing (or not clearing) a buffer at the wrong time or not updating the texture at the right time.

Probably a simple oversight on my part.

Source for Beta 2 which is easy to build (compiles out of the box with a key press) for Visual Studio 2008 or CodeBlocks (or Visual Studio 6 with service packs). The WinQuake build does use assembly language for speed and the project files compile those easy.

(The structure of the source is a bit more complex than I prefer, partially due to Nehahra support and Direct3D support.) 

With the new build (using mark_v.exe), behavior is exactly the same as with the previous version.

Using r_oldwater "1" only fixes liquids and teleporters, but NOT skies. Setting the variable to 0 breaks liquids, too (white surfaces).

Nothing has changed about my hardware setup since post #514, just using newer nvidia driver (v347.52). I have another system with an older nvidia card running on Windows 7 x64 (4GB RAM) which doesn't have show any issues at all, btw. 

If it helps, here is my current config.cfg. Maybe there is another variable in it which I might try changing.

Config.cfg (3KB) 

I'd bet the farm on this being the graphics driver.

And since you provided the version #, maybe I have a shot in addressing it.

(I've seen DarkPlaces users mention certain driver #s being bad several times. I didn't expect this kind of thing to enter my world of "classic Quake appearance engines" but if this driver # can cause the problem, maybe I can target it. Nvidia used to have the reputation of providing stability and ATI was the shoddy/incompatible vendor. I don't claim to know much about graphics card drivers but things I have read makes it sound like they traded places.) 

In the gl version, type gl_clear 1

Does this fix the sky issue?

[The r_oldwater 0 issue is separate deal, I have plan to fix.] 

Setting this through console unfortunately doesn't have any visible effect, sky on start map still looks like in post #533.

My driver settings in nvidia control panel:

Anisotropic Filtering: Application-controlled
Antialiasing - FXAA: Off
Antialiasing - Setting: Application-controlled
Antialiasiang - Gamma correction: On
Antialiasing Mode: Application-controlled
Antialiasing Transparency: Off
Refresh Rate: Application-controlled
CUDA-GPUs: All
DSR Factors: Off
DSR Smoothing: Off
Triple Buffering: Off
Energy Saving Mode: Adaptive
Max amount of prerendered frames: Use settings of 3D application
Shader cache: On
Texture Filtering: Anisotropic Pattern Optimization: Off
Texture Filtering - Negative LOD Bias: Allow
Texture Filtering Quality: High Quality
Texture Filtering - Trilinear Optimization: On
Threaded Optimization: Auto
SSAO: Off
Vertical Sync: Use settings of 3D application
Prerendered VR frames: 1

My monitor refresh rate is at 120 Hz, if that matters at all. 

Mark V Beta 3

r_oldwater 0 issue gone. Was trying to resize warp image buffer before valid screen width/height determined. 

Fix confirmed, works. ^^ Now all that's left to do is looking up to the sky!

Btw, before you release the final version, is there any chance to add a menu toggle between gl_nearest_mipmap_linear ("classic") and gl_linear_mipmap_linear ("smooth") texture filtering? Currently, you still need to put this into autoexec.cfg if you prefer the "pixel look".