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! 

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.