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! 

thanks! GL_NEAREST_MIPMAP_LINEAR is the perfect balance i was looking for. Too long i was using gl_linear_mipmap_linear and the scene on large maps just looked blurry far away, (thought might feel like GTA-V), lol

small maps like the dm maps it looks perfect like standard true grit Quake :) 

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

On the map E1M3(The Necropolis) at the end right before the fight for the exit gate, the lift has a bug. About half way up the lift I get hurt for no apparent reason(HP going from 100 to 45) and the lift goes back down.

I am running Windows XP x86, Intel E6550, 2GB RAM, Geforce GTX 550 Ti 

host_maxfps is probably set above 72 - setting it back to 72 should fix the physics glitch. 

Feature list sounds great, congrats!

Find ;-) WinQuake gun pos ;-) Alpha .mdl texture masking, not that anyone will ever use it because about no one is capable of making models these days but should someone arise, it is available which is nice. PNG shots ;-) Having actually Quake-correct always run ;-)

1. gethostbyname -- has no purpose in the engine at all.

2. Steal r_viewmodel_fov -- sheesh! It's been nearly 6 years Mark V has had that barely 8 lines of code feature -- maybe be slightly more complex in QS, but seriously. No excuses. It's rather unacceptable Quakespasm does not have that feature, in all seriousness.

3. Maybe make a Con_Print when someone changes maxfps away from 72 do a message "This may cause physics glitches, missed triggers and killer elevators". Because clearly people post the same damn thing 80 times per year.

Anyway, I quite like the change list! 

What r view model fov does 

if (sv.active) Cvar_SetValue ("host_maxfps", 72);

Obviously it would be nice to fully decouple the timers, then work over the client code and fix up all the FPS-dependent stuff properly, but in the absence of that surely we're past the point where the disadvantages far outweigh the advantages? 

Decoupling these things is a huge task if I recall which is why no one has done it yet 

recent release attempted this IIRC

Could you tweak the physics (or damage) code to behave better at those higher rates? 

Could you tweak the physics (or damage) code to behave better at those higher rates?

This isn't something that's a simple tweak otherwise it would have been done long ago, everybody would be using it now, and we wouldn't be having this conversation.

This is something that we've all been aware of for almost 20 years - at least ever since the Quake source release and early attempts at implementing maxfps. But yet people still continue to report it as though it were a new bug several times per year. 

But yet people still continue to report it as though it were a new bug several times per year.

Well that's because we're not omniscient. 

Hello. There is any plans to do the same port for Quake 2? I'd like to play it very much, cuz there is no such a port for Quake 2 like QuakeSpasm. There is only unofficial patch, but it's not enough - the mouse input is very shitty, no support for all keybuttons in controls options etc. I hope you will do it, as I know, the Q1 and Q2 engines are very similar. 

Here you have similar project for Quake2: https://www.yamagi.org/quake2/ 

Can you make QS default to gl_flashblend 0? Unless you already have... 

Yes, it's been the default for several versions (iirc since 2014-ish) 

This may have already been discussed to death, but I'm just returning from not having played Quake in a few months and saw QS got to 0.93.0. How similar is this release to QSS? I've been using QSS or the AD version for pretty much everything since Sepulcher came out. Can 0.93.0 do pretty much everything QSS does? Which should I use for normal play? 

I'm running latest SVN code on Linux. I notice that when several enemies teleport in, only one teleport effect is displayed, while the other enemies just pop in. Is this normal? 

QSS is a separate fork/experimental build and QS 0.93 doesn't include any of its features. Perhaps for the best.