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.) 

fte has a 'gl_load24bit' cvar that can be set to 0 to disable replacement textures.
it has a similar cvar for alternative model extensions to try to load (screw s_light.<mdl|spr>).

this means that mods can provide one set of content for chunk pixel style stuff, and another set for people that weirdly crave shinies and a lack of clear boundaries...
imho, that's much cleaner than lots of different extra directories all over the place.

the easy way to fix the +/-16 issue is to just have setmodel use +/-16 for ANY model with .mdl as an extension. This fixes md3s replacing ammo boxes or whatever other issues that plague DP's replacement models, and also means dedicated servers don't even need to load all of those .mdl files, giving slightly faster map loading in multiplayer. Really its a win/win situation!

regarding downloads, both gamedir switching and downloading paks/pk3s have issues if not handled properly / explicitly. Which files to use/download/cache/reuse/delete is an entire subject in its own right. Avoiding the transmission of personal or copyrighted data makes things fun, and *which* network protocol to use just makes things that much more political.
So yeah, QSS doesn't do downloads, which saves me a massive headache. Besides, download code is annoying to test. 

I have a working solution to this problem in a version of Mark V that will be released in the next 30 minutes.

There is a command called "hdfolder" where you can specify the content replacement directory and change it, it saves to config.

So you can have different sets. A fair number of things that have been proven to be good ideas have gone from Mark V to Quakespasm or Quakespasm to Mark V.

/I'll save explaining to Spike why this is a needed feature or how it avoids every downside of DarkPlaces multi-gamedir for some other time. 

Looks Like One Of My Fans Disappeared In The Final Build
... but only in QS... weird.
Weird. what QS version / OS / 32/64-bit, etc? 

I'm a version behind at 0.92.1
I'm running ubuntu 16.04 64bit 

First of all, thank you for great port!

I'm wondering, is it possible to disable mouse acceleration on Windows 10? It looks like sensitivity in game depends on pointer speed in Windows. 

Try quakespasm-sdl2.exe, it should use raw mouse input on Windows. 

Thank you very much, it indeed helped! 

What's the reason for having two binaries anyway? 

SDL1.2 supports older OSes (back to windows 95? and the mac version, back to 10.4/powerpc), but it's no longer under development.

SDL2 has more features (raw mouse input, borderless fullscreen, better international keyboard support, etc.) but has had more bugs.

At this point I recommend using the SDL2 binary unless you need the old OS support.