if you know how to roll back a Windows 10 update, please let me know :P

I decided to open an issue on the TB2 github, but I'm doing it as a feature request for making an engine launch part of the compilation process options as I get the feeling that running it as a "tool" is not ever going to be properly supported. 

Necros' compiling GUI requires no clicks.

Leave GUI running in BG
Save map.
Alt+Tab to GUI
Ctrl+C to compile.

https://imgur.com/YgIacZt

If you dive in, it's quite powerful:

https://shoresofnis.wordpress.com/utilities/ne_q1spcompilinggui/ 

Do r_scale 4, then gl_texturemode 6. Enjoy your bleeding eyes!

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? 

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.