Thanks for the pics. Bob settings move the model but scr_ofsx, y, and z move player POV. Hadn't thought about that before.

aspect: It might be possible to affect 2D graphics by the override as well. Will look into it. 

Does snd_speed "11025" work? I set this in my config but the sound still seems all crisp and squeaky, like it's stuck at a higher value...? 

Anybody here using QF on Windows 7?

I was giving it a try, and I can't get it to go fullscreen. Console just says "vid_updatefullscreen: error setting fullscreen".

Googling just turns up a lot of "yep that's a problem" sorts of pages, either about QF specifically or about SDL on Windows, so I thought I'd ask here if it is a known QF issue that has a fix/workaround.

Perhaps related: the framerate tanks if I leave QF in windowed mode but increase it to some usable resolution (like 1280x720) using command-line args. 

I tried QuakeForge - can't get it to do anything beyond a 320x200 window.

Buggered about for a few minutes with configs, command line bollox etc, then gave up. 

Sound initialization occurs very early in Winquake. It's in the video code prior to video initialization. According to code comments, this is so that a pop-up error message could be displayed if the audio card is already in use by another program.

In next build this will be a command-line setting:
-sndspeed

Really the only the way to get to it without possibly breaking compatibility. Because that is the case, will leave the original 11025 as default. 

can set -width 800 -height 600 (for example) in cammand line to get a bigger window. Still won't be fullscreen, and the FPS is very low for me. 

is so damn buggy. I went through a two day period of absolutely loving that engine, then realised it was buggy and (then) abandoned. 

Did you report them? Bug finding needs active users. 

runs at a really low frame-rate for me. lasted about 5 minutes with it then deleted it. 

Yeah, if it can't even get fullscreen stuff right, I'm not surprised that the rest of it is jangly as all trousers too... 

There are different renderers available, try

+set vid_render (gl|gles|sw|sw32)

No idea if the windows binary has them built in or something.

http://forums.inside3d.com/viewtopic.php?f=1&t=5118 has some more tips. 

(The accidentally-anon QF post above was me, BTW.)

This command line works for me: +set vid_render sw +set vid_width 1920 +set vid_height 1080 +set vid_fullscreen 1 +set con_width 640 +set con_height 360

Both sw and sw32 work for vid_render. Not sure what the difference is? Output pixel bit depth?

The gl renderer is painfully slow, and glsl causes an error dialog that says "Couldn't load critical OpenGL function glActiveTexture" (same thing that sock reported in that thread). 

fteqw has r_softwarebanding now, I never knew the software stuff was responsible for the proper brownness. It looks so much nicer, especially the bricks.

http://www.quaketastic.com/files/screen_shots/fte-20150208220201-0.png

http://www.quaketastic.com/files/screen_shots/fte-20150208220215-0.png 

Those are the colours I remember in my Quake. 

is it possible glquake/fitzquake/etc. are missing a gamma correction step somewhere? The second shot "pops" more, I'm not sure it's just the banding doing it 

those are both from FTE

i think what you're noticing is the first shot has blurry floors and ceilings from the trilinear filtering (plus the lack of anisotropic.) Second shot appears to use GL_NEAREST filtering. 

You need to compare thoses images on a fairly bright monitor to really appreciate the difference, and when you do it's crystal clear that the colours are totally different, especially in the shadows, because the first image is just combining the textures with the lightmap using multiply or whatever, whilst the second image is using quake's colormap shenanigans. You can see it especially in the wood texture, which darkens to a rich, almost purpley shade in the software version. The colours have a lot more life in them, because the colormap bojangles shades and highlights the textures in a way that changes the hue in subtle ways, and your usual Fitz-esque lighting doesn't. 

Hmm, here is fitz085 vs winquake at 1024x768, gamma 1 on both, and gl_overbrights is turned on in fitz:
http://i.imgur.com/16ekm0r.png
http://i.imgur.com/FDd880C.png

The difference I'm looking at is the metal around the Q vs the A. In the winquake shot it's brighter around the A than the Q, in fitz they're about the same. I guess it's probably just an artifact of the lightmap * texture being snapped to a fixed set of values in WQ, but i was wondering if there was some gamma curve in the colormap table that WQ uses. 

You should be thankful that the colormap in Quake is not nearly as crude and abysmal as the one in Doom. 

There's no special magic in the colormap.

It's just a 2D table which takes a palette index and a lighting intensity and returns another palette index as the lookup result.

Because Quake is an 8-bit renderer the returned palette index isn't a straightforward multiplication but instead a nearest colour match (I assume; I haven't done any deep analysis of this beyond a rough comparison with what the result would be if it had been a multiplication, and determined that they match well enough).

So sometimes what would be a brown, or a green, if it had been a multiplication comes out as a yellow or an orange instead and hence software Quake can seem to display a greater variety of colour; but you shouldn't fool yourself into thinking that it's anything other than a flawed approximation that looks good by accident rather than by design.

This same applies to mipmap level reduction. In GLQuake it's a straightforward average of 4 texels to produce the reduced texel, but that can give results that aren't in the Quake palette, and so it's not possible in software Quake. Again, I assume that ID did nothing more than nearest-colour-match this to the Quake palette, and again that means that you can get results that were never in the top-level image, which again can give the illusion of more detail, or more colours.

A GL-based engine should gamma-correct it's mipmap reduction, but most don't. At the most basic level this means square each texel, then do the average, then take the square root of the result. That can give a huge improvement in the look of GLQuake right off the bat and without anything fancy needed. 

Most rows of the quake palette tend to gain saturation as they darken. It's an aesthetic choice (a very painterly one) that causes shadows to richen a little bit as the indexes are stepped down by shadows.

Very carefully tuned colored lighting could achieve a similar effect ... 

Software Quake lighting doesn't step down the palette indexes though. It's perfectly possible for a column in the colormap to jump from, say, palette index 89 to 21 as part of a single step in the lighting ramp.

For a real-world example, if we look at column 128 of the colormap, as the lighting darkens we step from palette index 254 to 15 to 14 to 161 to 128; at one point it goes from 4 to 36 to 3 over the space of 3 consecutive steps.

Now, obviously there's nothing in the Quake palette between indexes 4 and 3, so that 36 must have come from taking what it would have been and performing some colour matching to select a palette index to use.

So it's a good deal weirder than just a simple stepping-down of palette indexes. 

I can reproduce the same "painterly" effect in Photoshop in about 10 seconds by overlaying a banal black gradient over the Quake colors, and then quantizing the result into the Quake palette. 

for reference, here is the colormap converted to a PNG:
http://i.imgur.com/BGldFo6.png
(I used lordhavoc's lmp2pcx tool to convert to tga, then gimp to convert that to a png, but had to hardcode the width/height into lmp2pcx because the colormap doesn't have the lmp header) 

The thing is, whether the effect is painterly, or aesthetic, or deliberate, or some, all or none of the above, is totally irrelevant because it's not what software Quake uses for lighting.