Fitzquake supports glow textures, so i would assume it also works in Mark V, but maybe there's something that changed. 

Here is a hideous screenshot demonstrating _glow textures against a test folder:

http://quakeone.com/proquake/media/sfloor4_2_glow.png

It uses the following 2 textures that happen to be .pcx format

http://quakeone.com/proquake/media/sfloor4_2.pcx

http://quakeone.com/proquake/media/sfloor4_2_glow.pcx 

Alpha translucency is not a texture feature in any Quake engine except DarkPlaces because it is a recipe for cheating (FTE ... ezQuake ... any NQ engine etc do not support them.). Somewhere earlier in this thread there is a discussion involving Spike, Sock and myself and others on that topic.

In fact, if you having trouble with textures I would recommend removing the alpha channels.

I think the alpha channels are ignored in FitzQuake (not a common topic, so from memory I can't recall.)

If you want things like glass in a map, you have to set the entity alpha of the brush (for instance alpha 0.5.

Both Mark V and Quakespasm support alpha masked (a pure mask like a fence where each pixel is either fully transparent or fully opaque -- there is no translucency) and the texture in the map must begin with a { and Quake color #255 is the mask color.) 

The current Mark V beta, unlike Quakespasm, only supports alpha masked { fence-like textures on entities. Quakespasm supports them on the world model, but this shows void (areas outside the map) but Rubicon Rumble needed that because of a visibility issue that has since been resolved (i.e. masked textures really should not be on anything except entities). 

Looks like we're double-posting here and at QuakeOne. My bad :( Hope it's all useful.

Anyway, I just downloaded the two textures you posted to ID1/textures folder. Here is another hideous screenshot for you:
http://i3.photobucket.com/albums/y80/amurad/Games/scrn_zps1e3wcnqi.jpg

It's your texture pointer showing Mark V is loading sfloor4_2.pcx, but not sfloor4_2_glow.pcx.

Are you sure we're running the same version? Mine is 05:49:41 Jul 13 2014 

And here is the fence-like alpha blended working like a charm (on the background, sfloor4_2 fullbright not working):

http://i3.photobucket.com/albums/y80/amurad/Games/scrn2_zps9l2ffkid.jpg 

The screenshot above is a world brush, not an entity. So your engine alpha blends world geometry as well.

It's showing void where the brush touches the floor, wich makes perfect sense: the world brush subdivided the floor and the surface it hides was removed by the bsp compiler. Thing is, you can see thru this world brush, so you can see the hole the removed surface left.

I just tied the brush to a func_wall entity and recompiled the map. No void showing anymore. I'm gonna use it! 

I'm using the October 10 beta build which is known to have issues with drawing the sky on Nvidia cards due to a stencil operation and may have a couple of other things like that (which is why it was marked as a beta). The download is buried in the thread.

Words: It is unfortunate that work alpha gets used for everything but I do want to point out that no blending is occurring for "fence textures". Blending means it is combining 2 colors, fence textures are an alpha mask and isn't blending. 

sorry if I've it's been mentioned and I haven't noticed - is there any support (or planned support ;) )for Alpha masks on external textures?

Thanks for all your work on this so far, it's awesome. 

I don't remember if there is external texture support for the masked textures.

I would guess "no", but I can't remember because normally this is something I would do.

I think a roadblock was external textures for masked textures and the possibility of the masked texture having a fullbright component.

That is a complicated scenario to draw for external textures because fullbright is an additive blend but should only affect the masked area.

Which is quite a headache to devise the drawing for when almost no one even uses external textures, let alone masked textures. 

for alpha masked fence textures and fullbrights, you could process it at load time:

for the main texture, keep track of which pixels are < 0.666 alpha. On the glow map, set those pixels to pure black. This way the glowmap won't be visible on any screen pixels where the main texture is masked out.

I'm not sure if this will still cause tiny bleed overs where the glow slightly overhangs the hard edge of the mask, but it could be tweaked, maybe by raising the alpha threshold or something.

But at least this doesn't affect render code at all. 

In that screenshot I posted above, that transparent wall with yellow balls is a brush with an external TGA type 2 with an alpha channel, where white makes a pixel visible and anything else makes it invisible. So I would say yes, Mark V seem to support external alpha masked textures.

Tried the three EXE of the October beta. The WinQuake version wouldn't show external stuff anyway. The other two don't even have the r_texprefix_fence cvar :o

Please Baker, don't rip the transparency off the engine, I need it! Didn't follow the discussion, but a security solution can't be to cripple the engine. 

r_texprefix_fence cvar is gone because since Quakespasm adopted fence textures ported from Mark V with exclusively the prefix "{", it is no longer an option to pick a prefix. This is consistent with Half-Life and The Remake Quake engine and FTEQW. [Yeah, the WinQuake build doesn't seem to work]. 

@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.