The former use DX8, the latter uses DX9 which adds to my confusion... 

Could produce faster engines than those initial ones in 2009. Which have performance issues for reasons that have been solved since then (flashes using video hardware gamma instead of just drawing an alpha-blended poly).

Case in point, the Direct3D8.1 wrapper version of ProQuake gets 80% of the performance of GL ProQuake (equivalent of stock GLQuake rendering).

And GL ProQuake gets 600 frames per second on some CPU + video card combinations *and* ProQuake's render is NOT as fast as FitzQuake's entirely rewritten renderer.

The DirectQ engine ... MH's main project ... can get 5000 FPS (no kidding) on id1 maps.

I do understand that people who are not active follower's of MH's work don't know how incredibly powerful his DX9 rendering engine is.

But ...

1. FitzQuake modification and experimentation is a bit fragmented right now. You've got a lot of different FitzQuake forks that "matter" including the RMQ Engine/Quakespasm and some things that FitzQuake could do natively in Windows like some of my experiments and mods. This is all good ... several independent laboratories sorting out the "good stuff". Maybe at some future point metlslime will decide on the features for FitzQuake 0.90 or even FitzQuake 1.0 ;)

2. No one is being stopped from single player goodness right now. Even though there may not be a single option, there are plenty of options that are quite similar to each other. So no urgency. 

both directfq and directq run slowly. since it's clearly not a programming problem, the problem lies with directx or hardware. but since i have no problems with normal opengl fq (or qs in this case), i don't want to invest time into finding out what's up.

i find proquake is a terrible engine. mainly because when it crashes, it screws up the gamma settings in windows and i have to run through colour calibration to get gamma back to normal. it also has that old really annoying bug that glquake has where each time you run it, it moves all the windows down and to the right so that eventually after a few starts, all your windows are cowering in the corner.
also, it doesn't have extra edicts (or i couldn't figure out how to get it working) so it doesn't load any of the maps i make. 

since you guys seem to know all the 'big names' these days, you should post up a list of them somewhere. finding custom engines (and trying to test them, never knowing if they are abandoned or not) is really hard for me. you engine guys need to work on market penetration! :P 

...but DirectQ currently gets maybe 2000 downloads per month. I reckon it's got market penetration. ;) 

ok then. 

I maintain ProQuake but wouldn't recommend it for single player over FitzQuake any day of the week.

Anyway, yes we are in a time of a bit of engine flux due to a great many authentic baseline improvements being littered all over the place.

But as long as someone is able to play single player releases with some preferred and quality engine, there is no emergency ... and in time all this will sort itself out.

I myself would prefer to live in a world with a lot of general interest experimentation that "matters" going on. And regardless of preference or not, it is, in fact, exactly what is happening ;) 

did you guys really implement fog interpolation? or was that always there and i never knew?

cause it's pretty fucking cool. and also annoying because only a few weeks ago i wrote qc to handle fog interpolation with a complicated system to get ftos to output more than 1 decimal. :P 

it was always there :) 

queue "fuuuuuuu" on my part. :D 

Fog interpolation? I thought fog just kind of sat there statically. What is this fog interpolation? 

I believe it's that if fog changes colour it blends smoothly between the before and after colours over a period of time. 

Its only really decent when you control what the player is seeing and how they're moving. For example, sticking them inside a lift and blending it from a lot to none. 

little while ago, gb made a speed map and i mentioned being unable to load it in rmqengine. ("The application was unable to start correctly (0xc000007b). Click ok to close the application")
turns out, the SDL.dll included with 64bit quakespasm is what causes the error.

unfortunately, 64bit quakespasm can't run with the (i'm assuming?) 32bit SDL.dll that rmqengine uses.

just fyi, i guess. 

you can't mix a 32 bit app with a 64 bit library or vice versa 

sure, i mean, i guess that makes sense. the problem is there's no way to know since the file is named the same thing. 

try the InspectExe tool (http://www.silurian.com/inspect/index.htm) 

My sound is lagging hard in the new build,I was just wondering if anyone else is having an issue? 

After having gotten sick of some of the issues I had with Darkplaces (stuff not spawning properly, doors not working, items floating in mid air), I made the switch to Quakespasm and have been pretty happy.
Still having some issues, not sure whether it's due to my n00biness as someone that doesn't really understand Quake tech that well, or the engine itself.
Recently tried to play the map pack, Digs01 again, which worked fine on Darkplaces.
Water and teleporter graphics wont show up at all.
I know you can get around that problem in Travail with +r_oldwater 0 +r_waterquality 32, but I have no idea if there's any command line that will fix the issue I'm having with Digs01.
I fear this may effect some other map packs too, but I haven't tried much others yet.

Also, the NightJourney map pack (http://www.quaddicted.com/reviews/nightjourney_v2.html), just wont work once you try to start a new game. Minus some errors with stuff. Says something about missing Lava/md2 model (I think that's what it said, I ended up deleting Nightjourney in frustration because it wouldn't work anymore lol), which is odd because I never encountered that issue with Darkplaces 

hate to ask a question like this, but is r_wateralpha set to 0? that'd make it not show up. 

I just tried using +r_wateralpha 1 and it works fine, so indeed just n00biness on my part.
Odd that +r_oldwater and +r_wateralpha are the same thing, damn quake and interchangeable command lines :P
The +r_oldwater command line was the suggestion made on the Travail site which makes the alphas work properly. Why that is, I don't know, but it works for Travail.
Just calling it +r_wateralpha would have made more sense.

Anyway, thanks for the help, Necros (although the help was in a rather roundabout way lol) 

r_oldwater has nothing at all to do with alpha.
r_oldwater 1 uses the original method of making the water texture warp. turning the option off uses a more expensive, but much nicer looking warping effect.
r_waterquality controls how good the warp looks, when using r_oldwater 0. 

r_oldwater 0 fixes up bad texture alignment for liquid brush seams. And too much water alpha may make a teleporter disappear. 

The problem is that sine waves don't linearly interpolate. r_oldwater 0 doesn't actually fix it correctly: what it does do is reduce the problem to an extent that it's not really as noticeable, but the tradeoff is that it imposes limits on the maximum size you can use for external textures. Doing the warp per-pixel in a shader is the only real way to definitively fix it in the general case. 

I guess there might be a situation that r_oldwater 0 makes it not as noticeable, but I've seen only perfect results so far. No complaints.