unfortunatetly most engines do not allow using independant settings for the min+mag filters.

It's worth noting that this setting is legal in both GL and D3D.

However, GLQuake's gl_texturemode just selects the min and mip filters, then assumes that mag is going to be the same as min.

It's probably worth bouncing around suggestions for how to cleanly handle this without breaking compatibility. Add new filters to the end of the list? Add a separate command to specify mag (and a "revert to default" option)? Accept breaking compatibility and chuck out gl_texturemode, adding new commands for gl_min|mip|magfilter? Some combination of these? Something else? 

However, GLQuake's gl_texturemode just selects the min and mip filters, then assumes that mag is going to be the same as min.

It occurs to me that this may have been a constraint of 3DFX and other contemporary video cards but which is no longer relevant. 

the gl_texturemode list currently has 6 enumerated items, i don't think it breaks compatibility to add more at the end.

I think it merely doubles the length of the list to support mismatch of min and mag filter, which isn't that bad. 

Well I would love to tell you if this worked, but Quakespasm simply refuses to turn it off. Whether it be through the command line, or the autoexec.cfg, Quakespasm decides gl_texture_anisotropy must always stay at 1. 

https://www.opengl.org/registry/specs/EXT/texture_filter_anisotropic.txt

When the texture's value of TEXTURE_MAX_ANISOTROPY_EXT is equal to 1.0, the GL uses an isotropic texture filtering approach as described in this section and Section 3.8.6. However, when the texture's value of TEXTURE_MAX_ANISOTROPY_EXT is greater than 1.0, the GL implementation should use a texture filtering scheme that accounts for a degree of anisotropy up to the smaller of the texture's value of TEXTURE_MAX_ANISOTROPY_EXT or the implementation-defined value of MAX_TEXTURE_MAX_ANISOTROPY_EXT.

A value of 1 is off; unfortunately the stock code contains assumptions that are inconsistent with the spec. 

I tried updating my nvidia driver to 375.70 and I don't see anything wrong (tried all the texture modes, gl_texture_anisotropy 1 and 16.) I am on Win 10 64-bit and a GT 650m, so I imagine it's a case of a different hardware generation behaving differently.

Would you mind uploading a full resolution PNG screenshot? The youtube compression makes it a bit difficult to see. 

https://i.sli.mg/tV6enY.png

I am using an Nvidia GTX 970.
I would hate to think its the cause of the newer hardware generation, but hopefully its not a complicated issue. 

I'm still on 372.54, so I can't say if I'm having the same issues or not. I can say however that the 9XX series of cards are a real pain for compatability compared to older generations... The example that sticks out to me was NFS Shift 2, which would frequently display black frames that made the game basically unplayable.

You could try rolling back and seeing if that helps, unless you desperately need whatever new game support the latest drivers have... 

Even forcing Quakespasm to use no anisotropic filtering through the Nvidia control panel, the issue still persists.

I feel like I really screwed the pooch by updating, but it I haven't in so long and felt it was time to do so. 

Have you tried rolling back the driver update? 

Rolling back the driver to version 364.72, dated march, fixes the issue. 

You could try the second to most recent drivers and see if the issue is there. Basically once you find where the issue first appears, you need to investigate the patch notes and see if any setting had been added or defaults modified from a previous version.

I don't know, that's the best I can think of when tackling from Nvidia's perspective.

I use a 980ti and I believe I have either the latest or second latest driver and do not encounter this issue using the latest non-spiked QS. 

But why does QS have different strafe jump acceleration to darkplaces, and others? 

I'm gonna go out on a limb and suggest that it's darkplaces that has the different-from-quake movement code, and not QS. 

I remember hearing that in vanilla quake, "always run" had different (slower) movement than holding Shift, and that QS changed it so "always run" is the same as holding Shift.

I think this is the patch that changed that (while adding QS's feature that pressing Shift while "Always run" is enabled slows you down to walking speed):
https://sourceforge.net/p/quakespasm/code/797/ 

edit: load the entire Fitz Mark V thread and search in the page for "always run" - Gunter talks about it.

I'm not 100% sure about any of the above, but it sounds plausible after a quick glance at the code. 

That was exactly what I was looking for. I plan to expand my quakespasm-irc port to include speed running features, and "fixing" the strafe jump to the accepted standard (by the speed running community) needs to happen for runs made with the engine to be legitimate. 

Isn't that just console variable manipulation? 

I'm not sure if QS inherited the code from fitzquake. Gunter explains it in post 1149 in that thread.

What I might do is enable caps lock to be used for +speed. That way you don't need to physically hold down the key in order to always run and get the bonus strafe speed. 

Dear Ericw,

... I�m converting myself to pixels (read --> gl_texturemode GL_NEAREST_MIPMAP_LINEAR), but on the other hand, I don�t want to delete my collection of HD textures.

My idea is to put all the HD textures in a HD directory.

With DP is then possible to recall the HD texture when needed with a command like: GAMEDIR HD AD.

has QS a similar command line? command line like "-hd -game ad" does not work, while command line like "-quoth -game 5rivers" does ... why?

Ciao 

The stock Quake engine only supports -hipnotic and -rogue, and these commands have other effects besides just loading a new game dir - they also change the Status Bar layout, for example.

Quoth requires the Hipnotic status bar layout so many engines add -quoth as another option to allow players to more easily specify this. Otherwise players would need to use -hipnotic, thus creating a dependency on the Hipnotic mission pack being installed, and with a side-effect of making it more difficult to split the Quoth content from a mod that uses it.

The big take-home from this is that a game dir that functions in a manner such as Quoth, Hipnotic or Rogue must be explicitly hard-coded in the engine. You cannot specify "-hd" and expect the "hd" game dir to load, because it's not been hard-coded in the engine.

Multiple game dir support - such as "game hd ad" - is trivial to add to the console but slightly more difficult to add to the command-line. 

Otherwise players would need to use -hipnotic, thus creating a dependency on the Hipnotic mission pack being installed, and with a side-effect of making it more difficult to split the Quoth content from a mod that uses it.

You don't need hipnotic to be installed to change the HUD with -hipnotic. You don't even need the directory to exist.

The second point still stands though. 

would it be possible to hard-code "-HD" just for textures?

hard-coded in order to allow command lines like:

-hd (for ID1 and/or generic maps)
-hd -hipnotic
-hd -rougue
-hd -quoth (-game 5rivers)
-hd -game ad

..etc.


..etc 

The (sloppy) DarkPlaces multi-game dir system that has 3 major flaws also depends on the same system that allows DarkPlaces to crash if you have a start.lit file for a different start.bsp

Quakespasm, on the other hand, has the "Quakespasm content protection" system to prevent that.

Implementing a "hires" folder capability as a separate cvar like "cl_replacementfolder" (name?) would be the right way to do it, but might not be trivial to implement due to the above. It would need to be placed at the end of list.

The (sloppy) DarkPlaces way is not the right way.

If it were, a lot of engines would do it that way --- case in point Quakeworld loves replacement textures --- but ezQuake would never do such a thing because the (sloppy) DarkPlaces way breaks the QuakeC precache system and cannot tell replacement content from the original content.

(Also would happen to mess with physics in a FitzQuake engine in some circumstances due to FitzQuake using the model bounding box instead of -16, -16, -16 to 16, 16, 16 ... so your replacement content could actually affect the in-game play in some situations).

The right solution for people like Icaro is a separate cvar for the use of such a folder, and then maybe adjustments as uncommon problems crop up. 

If it were coded as a separate cvar or a command like option like -hd as Icaro suggests, it would be easier to tune and get users to have the right habits.

I've seen notes in Quakespasm Spiked where Spike was at least thinking about the vastly enhanced networking code provide for automatic download for coop (and even the start of commented out prediction code).

Implementing something that separately specified a replacement content folder for the client would be compatible with not breaking such ideas.

(But the DarkPlaces (sloppy) multi-game way would totally break it. ... you would no longer know the user's intent and whether a folder is the game data or if a folder is intended as client-side replacement only.)