rocks ! 

Makes sense since light hitting the surface would be reflected upwards and diffused by the ripples. 

Screenshot plz 

Meh, it's just a bunch of unfinished brushwork and crap placeholder texturing. 

fine. 

fine. 

"I don't know if there is a quake engine that supports it but I would love shadows on water.

This was discussed a while ago and no-one could agree on what these shadows should look like."

Retroquad does support it. Here's a bunch of screenshots:
http://mankrip.tumblr.com/post/120399970810 

I like the look of that ALOT. 

But QS needs that desperately. 

And the software look lends an extra special cachet to any engine. 

It is a software engine. Impressive. 

Quoth supports loading any model for an entity, including .bsps, which is very useful in situations where the lighting doesn't matter (stained glass windows) but stencil alpha with a { texture doesn't work on a bmodel if it's loaded this way, only if it's built in the map itself. :(

Currently if you have an index 255 masked { texture it will only alpha as low as .7 I believe.

I can confirm this too - spiderwebs and the like below .alpha 0.7 just don't draw. 

will try to fix those. Weird that { textures would not work on external .bsp's, but I imagine it is something easy.

I think I know why entity alpha < 0.7 makes the whole fence texture disappear; normally the alpha test value in Fitzquake is left at 0.666, but I think I just need to lower it to (entity alpha * 0.666). 

There's only one alpha value, and you can't use it for both alpha testing/masking(NOT stencils! /me shudders) and alpha blending at the same time... well, you can, but the results are generally wrong.
glsl would allow it by doing any .alpha transparency stuff after the texture-only alpha test.
on the plus side, you might be able to get some funky burn-away effects.
also, its 0.667 and not 0.7. close enough though, but hey, precision!
but yeah... the exact details are very engine-specific, so try not to depend upon stuff too precisely. 

I think the reason the alpha test threshold is 0.666 in glquake is that 0.5 makes the explosion sprite edges look blocky/pixelated even with bilinear filtering (i know this because i tried changing it to 0.5 once), while 0.666 creates a more rounded appearance on the edges. Since that is the most visible sprite in stock quake, i believe they chose that number because they liked the explosion sprite edges to be more rounded. 

In that base map you tested the other day were breakable models(bsp) with {textures on them and they showed up rendered correctly (the unfair breakable grates on the floor).
Dunno if this is on topic, as no alpha is set on those. 

> i believe they chose that number because they liked the explosion sprite edges to be more rounded.

Also because 666 haha. 

I'm having trouble reproducing the { textures not working on external bsp's, they seem to work for me. Mind trying this test case I made? just load fencetest.bsp in Quoth. It loads the fencebmodel.bsp with a mapobject_custom; you should see a box in the room with a metal grill texture.
http://www.quaketastic.com/files/misc/fencetest.zip 

ericw, you aren't wrong, I am.

I always make sure to do my due diligence and create a side-by-side test case before ever involving a programmer, which I did: I had a func_whatever pulling from another bsp and a func_whatever in the map next to each other, with one alphatesting properly and one not. But, I got caught out by the external bsp having a stale texture, with whatever color in the Quake palette that looks exactly like index 255 but isn't. I discovered that error in the wad while tracking down this one, and forgot I had to recompile the external bsp to refresh the textures in it. :( sorry guys. everything actually works fine. (except that 0.7 thing, that's totally a thing still I swear)


Is it specifically because of alpha-tested matte lines in linear texture modes that they picked a color for the transparent index that's so damn similar to a lot of the rest of the palette, and not like hot component pink or something? (Doom used cyan iirc) 

no worries! Yeah, the alpha 0.666 thing is real and I will have a shot at fixing it sometime.

Your theory sounds right.. with stock glquake using linear filtering, you can see the "index 255 beige" fringes on the main menu text. They probably foresaw that and made index 255 a fairly neutral color.

Fitzquake has a cool trick for eliminating those fringes: for any index 255 pixels which have opaque neighbours, it gives them an alpha of 0, but changes the RGB values to an average of the opaque neighbours's colours (iirc). 

hmm, i doubt that they picked the transparent color in the palette based on glquake's bilinear filtering, since the game shipped before glquake was started. (Unless they actually attempted a hardware accelerated version before the original game actually shipped? That would be news to me.) 

^ Yeah, that's what I figured, but my angry head rant was "christ, it's like they picked an alpha color based on the average of all the others or something. ... wait a minute." 

Quake's alpha color is just a random color, and there's a duplicate of it in the default palette (which annoys me, because several custom textures used the index 255 instead of the index of the duplicate, and this gives problems with alphamasked texture support).

There were no 3D hardware accelerators when Quake was released. It was created with only the software renderer in mind, which is why it loses some of its charm when rendered through hardware.
Carmack coded GLQuake in a weekend, and he certainly would've done a lot better if he had the opportunity before.

The first Id Software game made with hardware acceleration in mind is Quake 2. 

I never saw those Retroquad screenshots before. They are amazing. You managed to push that water towards modern standards without losing Quake original charm. Way to go, man. Quake water needed this love. 

Besides those screenshots however I can't seem to find more info about it.