What do I do, so the pixels don't dance around on the further away objects, when using texturemode 1 and r_scale 2,3 or 4?

gl_texturemode 1 is the equivalent of GL_NEAREST, which disables mipmapping and which therefore causes the pixel dance. You can't do anything because you asked for mipmapping to be disabled, and you got what you asked for.

You can try setting it to 2 or 3 instead. 

My problem is that mipmapping makes everything washed out. This is probably the obvious reason for usinge MORE pixels instead of less🙃 Duh, then Winquake look might not be my favorite... 

WinQuake used mipmapping too. 

 

Win/Software Quake used mipmaps on world/brush surfaces; it didn't on water or MDLs. Typically Fitz/QS replicates this behaviour.

Mipmapping was specifically coupled to the lighting/surface-cache engine and 4 miplevels were stored for each texture.

There's more discussion of all of this in chapter 68 of Mike Abrash's Graphics Programming Black Book: http://www.jagregory.com/abrash-black-book/#chapter-68-quakes-lighting-model

And software Quake's mipmap code is here: https://github.com/id-Software/Quake/blob/master/WinQuake/r_surf.c 

winquake's mipmapping was based purely upon the distance (and texinfo+screensize+d_mipcap).

on the other hand, opengl decides which mipmap to use based upon the rate of change of the texcoords - or in other words surfaces that slope away from the view are considered more 'distant' and thus get significantly worse mipmaps.

you can work around that with anisotropic filtering, but that requires trilinear filtering in order to be well-defined (some drivers just bug out, some force it, some ignore it).

This is a significant issue in FTE's software-esque rendering, and for now FTE uses only 3 mip levels to avoid the worst of it.
note that the original/sw mipmaps retain their proper palette instead of being a blury mess, but this means that sloped surfaces like the side of health boxes just end up with about 4 random pixels or whatever.
there's a few ways to work around this with recent glsl versions, but I've not tried to so so yet.

tldr:
glquake and winquake have _very_ different mipmapping rules, and glquake just looks blury in about every way possible... 

i prefer GL_NEAREST and gl_texture_anisotropy 8
that way it still looks pixely but less glitter at the distance. 

doh! spike just said that while i was typing :O 

...that in hardware accelerated versions of Quake, mipmap level selection is not normally something that the programmer has control over; this is done by fixed function components in the graphics hardware. 

https://www.youtube.com/watch?v=oQAWZKxKVy0

http://quakeone.com/qrack/dev/config.cfg
http://quakeone.com/qrack/dev/autoexec.cfg 

basically the video shows
game custom
timedemo demo2
host error: progs/player.mdl not found
q{tab}
crash

reload
game custom
exec config.cfg
timedemo demo2
host error: progs/player.mdl not found
game id1
crash 

weird my other machine doesnt do it :/ 

I reproduced the crash here on windows with the 32 bit QS build, so it's indeed just those 2 config files that are doing it. thanks, will investigate. 

...that in hardware accelerated versions of Quake, mipmap level selection is not normally something that the programmer has control over; this is done by fixed function components in the graphics hardware.

Looks like it was first exposed to the programmer with textureLod in GLSL 1.30 / OpenGL 3?

https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/textureLod.xhtml 

You could probably brute-force it on older hardware by storing each miplevel as a separate texture. Performance would be horrible though. 

Supersampling makes unfiltered textures look gorgeous and not flicker at all. Consider adding such an option.

https://imgur.com/a/jumoZ 

Up close or far away?

The thing about far way textures sparking is that it's basic mathematics. You have one pixel on the screen, and when the texture is sampled - either via nearest or linear, doesn't matter which - you're sampling more texels than will fit in that one pixel. Then when the scene shifts a little (like with regular Quake idle movement, or water warping, or whatever) the texels being sampled jump around.

This is basic sampling theory stuff; it shouldn't be necessary to explain it, it's been mathematically proven for donkey's years. 

The supersampling in vkQuake works both up close and far away. The far away flickering was always bothering me and I would begrudgingly turn the texture filtering back on, but with this kind of supersampling you get the best of both worlds, the textures never flicker at the distance, and at the same time don't get blurred up close. Works great even at 4x supersampling with little to no performance hit. Black magic! 

Just to clarify...

Far away flickering is not caused by texture filtering or no texture filtering.

It's caused by not using mipmaps.

You can disable texture filtering and use mipmaps.

gl_texturemode GL_NEAREST_MIPMAP_NEAREST will disable texture filtering but use mipmaps, and will hugely minimize far-away flickering. This is the nearest you'll get to software Quake without custom shaders to more closely replicate it.

gl_texturemode GL_NEAREST_MIPMAP_LINEAR is slightly higher quality. It also disables texture filtering but will interpolate between miplevels, so you don't get jarring transitions between different miplevels as you move about a map.

I'd strongly encourage you to use the built-in modes properly and see if they actually do meet your requirements. It's an unfortunate piece of Quake "lore" over the past 20 years that gl_texturemode GL_NEAREST is the correct "software Quake" mode, and Quake "lore" is full of flat-out wrong bullshit like this. 

I'm sorry that I didn't make this clear, but of course I'm using mipmaps (GL_NEAREST_MIPMAP_LINEAR). Still, it causes quite a bit of aliasing compared to GL_LINEAR_MIPMAP_LINEAR, e.g. when looking at the textures with horizontal lines (like base walls) at an angle and moving back and forth. Supersampling seems to fix this issue. 

You can just enable DSR (nvida) or VSR (AMD) in your video card control panel. 

I'm sorry that I didn't make this clear, but of course I'm using mipmaps...
Ah, OK, my apologies.

I guess this is one of those "different things drive different people nuts" things then. I personally accept a bit of aliasing as part of the tradeoff to achieve the crunchy pixel look, and even expect it as a feature of that look. 

Yeah, I can understand that. WinQuake has tons of aliasing, all over the place, and maybe that's part of its charm, but having crisp sharp unfiltered textures with zero aliasing is also very, very appealing and it's something that couldn't be achieved on the hardware back then, so it feels more like an upgrade than a step back. Just my personal preference, at any rate. 

Is merely a result of using a screen with too low a resolution at too close a viewing distance (dpi vs viewing distance). 

yeah just get a 4k display!