I have a similar 4:3 situation on an old laptop. Set vid_nativeaspect 1.333 in the console. By default super8 will guess aspect based on the highest available resolution.

Rolling with 8-bit purism theme, the only legitimate framerate comparison is with Quakeforge and GLSL simulated 8-bit. How's that compare on same machine? 

Biggest boost to framerate would be fog 0 in console. But it will never reach Quakespasm fps. (Well, maybe on fast CPU with lousy GPU.) Among all bigmap-capable engines QS is the fastest I've seen.

I usually set cl_maxfps to 24. In SW mode it doesn't feel as choppy as one might think. Hardcore is 12 or maybe 10. Might have been thrilled to get 12 fps in '96. 

I don't know if it's the same issue, but just realized my fov compensation is slightly off-center. The effect is that the view and the vwep are not rotating on the same axis. Fixable. 

Yah, what you said sounds like the culprit. Here is the porblem as I see it:

Look left: http://i.imgur.com/U4aX3sR.png

Look right: http://i.imgur.com/CnvoYH4.png 

>> Pentium 3 laptop?

No, but I often use 640x480 to improve performance, because it's the smallest resolution available to me.

Thanks, "vid_nativeaspect 1.333" helped, although 2D is still distorted. That was my main gripe, really, because unfiltered artwork looks very ugly when stretched by the wrong amount.

>> The effect is that the view and the vwep are not rotating on the same axis.

TBH, it's the case even with the vanilla engine, although it's not nearly as noticeable. 

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.