Cheers Baker. :) 

is it possible to have the environment map over a standard texture though?

I agree, but I didn't want to introduce a hack into this. I'm not sure what a good mapping use of sphere maps are (except making metals look nice). That being said, you could use FitzQuake protocol 666 to place an alpha brush in front of another brush and use the environmental map texture on the alpha brush.

-sndspeed 44100 doesn't enable 44khz sound?

That isn't actually a FitzQuake 0.85 feature. 

Sorry, I've been using QS for so long now, I totally forgot about that. 

I've always liked the original Quake sounds as-is and one of the first times I gave a serious look at using DarkPlaces my first question was "The sounds in DarkPlaces are very 'crisp'" and I was told about the -sndspeed parameter which I set to 11025.

Maybe I'm in the minority.

I added -sndspeed command line param. 

With the sources at 11k and with the way Quake "upsamples" them by default, all it's really doing is pitch-shifting. The crispness may be there, but the bottom-end welly is all gone. 

don't really care about that myself. i've never noticed anything bad with the way it's done in quakespasm. that said, for whatever reason, the 11khz sounds seem uglier in DP for some reason.
Also, with my habit of using so many ambient sounds and random crap, i really can't do without 44khz. 

Is it implementation-time vs. level-of-interest prohibitive to add GLSL support for the sake of restoring software Quake's original per-pixel waterwarp on liquid surfaces and on the screen while underwater? If not it seems like a clear visual win over relying on subdivision and ST distortion, and I'm surprised we haven't seen it in more engines by now (MHQuake comes to mind).

GLSL isn't exactly new, and vertex based warp still exists as an elegant fallback. 

doing waterwarp on the surface with GLSL is fairly doable (though it is something I have never done.) It's probably cheap enough on any shader-capable card.

Doing the fullscreen warp when underwater involves touching a bit more of the renderer because you have to render the scene to a texture, then copy that texture to the screen using a warping shader. In terms of hardware requirements, I think anything that can run doom3 can handle it, but this is, again, based on zero personal experience. 

It's very cheap on any shader-capable card. The per-pixel sin is slightly expensive (although the shader compiler will typically optimize it to a single sincos instead of two sins) but that balances against a lower vertex submission cost due to no subdivision (and not to mention the ability to keep everything in a static VBO if you want to go that far).

Doing shader-based versions of both water and sky means that every single surf can go into a single static VBO, in fact, as no per-vertex data needs to be updated on the CPU at all (you'd use a cubemap for skyboxes in this setup - Doom 3 has some code for converting Q1/Q2 skybox layouts to alignments suitable for cubemaps and I've independently written the same conversion myself a few years ago so I'm reasonably certain that it can't be rocket science). Get some draw call batching in and you're suddenly running up to 5 times or more as fast in big, heavy scenes. That does require a higher GL_VERSION than Fitz aims for, as well as some massive surgery to the current codebase. Probably not reasonable to expect in any kind of short/medium timeframe, if ever.

The fullscreen warp has some complexities in how you handle the edges. You can use GL_CLAMP_TO_EDGE but it won't handle the bottom edge which juts against the sbar. There are solutions (I used a "control texture" that fades off the warp effect at the edges, another option is to just destroy and recreate the texture at the appropriate size if it needs to change, which generally doesn't happen at any performance-critical time).

Generally glCopyTexSubImage is going to be slower than using an FBO for this because it needs to shift more data around. Overall you can expect to lose maybe one third of your performance owing to increased fillrate even in the best case.

Another way to do it that doesn't need shaders (and will even work on GL1.1 hardware) is to use a grid of quads (much the same as what Fitz does for r_oldwater 0). That can give acceptable enough quality.

The third way is just to rotate the projection matrix a little based on time, which gives a reasonable enough effect at no performance cost. It's like Fitz's current stretch'n'squeeze effect but with some rotation added in too. You need to extract your frustum from the combined MVP rather than calculating it separately if you do this though. Easy enough (and a little more robust than calculating it separate).

Despite all this seeming complexity and multiple options it's probably cleaner and easier to integrate with any engine as it doesn't need to touch any code outside of it's own subsystem. So - detect if we're underwater (via r_viewleaf->contents) at the start of the scene, and either (a) just set a flag and/or (b) switch the render target. At the end of the scene, either capture the scene to a texture or put the old render target back, then draw using the appropriate method depending on what hardware capabilities are available.

For an engine like Fitz I'd recommend asm shaders rather than full GLSL. The main reason for that is that they're available on a much wider range of hardware, so they seem more in keeping with the Fitz philosophy. 

good news!
thanks, Baker. 

Would it be possible to do alpha animated textures?

Something like this:
{+fire1
{+fire2
{+fire3 

I'll let Baker answer on his own behalf; this opnion is mine and mine alone.

Yes, it should be possible with the necessary code changes. However, by this point in time you're stacking up multiple "first character" hacks (alpha animated water with alternate anims anyone?) and things will begin to look a little delicate.

So some form of alternate system would be needed. Since Q3A shaders are out there, since we have a GPL working reference implementation (the Q3A engine), and since they don't require any format changes (just add a .shader file for anything you want different behaviour for), that would be my own preference. 

It might already be possible to do them:

Set r_texprefix_fence "+alpha" and load your level.

It should process all the textures that begin "+alpha" and likewise set a flag to mark that surface for alpha mask rendering.

I hadn't expected someone to want to use alpha textures like that, but I bet it works.

(Note: fullbright pixels in alpha textures are supported (except color 255 of course). Replacement textures replacing an alpha texture that has an alpha mask are also supported.) 

Baker this makes fitzquake look more like darkplaces, joequake, qrack e.t.c?

record demo is awesome... 

 

If by chance you are looking for something like JoeQuake, you might try Engine X. Engine X supports FitzQuake 666 protocol and looks like JoeQuake with the kind of very recent engine features one would expect (video mode change, etc). 

Obrigado Baker

I will see it ASAP!

thanks 

Thanks for the reply!

Also, regarding the alpha textures, I think there is a bug with the way they are rendered, or it may be intended. The transparency textures bleed through the floor and you can see the void of the map.

Here is a picture showing what I mean:
http://imgur.com/ZFOz1

Even if I paint the bottom of the glass brush with a solid texture, it still shows the void through the floor. 

Turn your alpha brushes into an entity like illusionary, door, func wall etc. Use a really good q3 fence texture, enable texture scroll and be amazed. 

Yup.

Because of the way QBSP seals the world and chops off outside faces, putting this texture type on a brush that's not part of an entity will produce this result. It's expected behaviour and a result of normal QBSP operation, not really an engine bug (there's actually nothing that the engine can do to work around it as the data required isn't even there in the BSP to begin with). 

See above. I almost decided to enable alpha textures only for entities (func_wall, etc.).

But an experienced mapper knows all the rules and how the tools work and allowing it for the world is no different than, for instance, using the skip-remove tool.

Alpha textures should generally be limited to entities (func_wall, platforms, doors, etc). 

I have been testing my map with the mark V engine and for some reason all my models (map objects, items, weapons and monsters) randomly go black and monsters do it while patrolling.

I have checked the area the monsters patrol and my weapon does not go black. It is not a subtle change either, they are normal (full bright) one minute and then solid black the next.

Is there a special reason for this? (I know this is a counter productive thing to say but it does not happen in Fitz85) Is there a command line parameter I need to stop this? 

do they stay black with r_fullbright 1?

If yes, may be a texture problem.... if no, may be a lighting problem. (not a problem with your level, i mean a problem with the engine) 

I loaded the map, typed in r_fullbright 1 and I could see everything, no blackness. It looks like r_fullbright removes the light map from everything. It is very strange the blackness on certain objects, I thought it was specific locations where I have spawned stuff but it happens to wandering monsters.

I checked the original Q1 maps (played episode 1) and could not see any problems. I am using the latest compiler tools, hitting a couple of max limits but the engine still copes with it. 

It could be because I made the light check test against world submodels (plats, lifts).

I have a new revision to this with new features essentially done. I'll put a cvar in disable shadows/lighting from world submodels to see if that is the origin of the issue.

I also changed the lighting depth check (because MH did) from 8192(Fitz 0.85) to 2048 (original Quake) because MH had a comment about performance (8192 is a long, long distance).

The new version should be be available in 6-7 hours.