Oh, and one more thing. In vanilla GLQuake the gib skins in Shrak are completely white, while they show up just fine in WinQuake (and supposedly DOS Quake as well). It's definitely some old GLQuake quirk. 

I was the one that at added the blue checkerboard feature. I didn't realize at the time how many mods relied on the behavior of vanilla quake to show skin 0 when the mod asks for an invalid skin. So I now agree, the engine should replicate vanilla quake's permissive behavior and maybe just put up a non-spamy console warning when the bad skin is first set. 

Glad that I could help. Here's a couple more oddities that I've come across:

- r_wateralpha < 1 results in various see through glitches on non water VISed maps, like e.g. qte1m2 in Travail. Other engines seem to ignore r_wateralpha if the current map is not water VISed, I'd prefer such behavior.

- Console font sometimes has a thin underline/overline with some characters, no matter what value scr_conscale is set to.

- Water textures are not mipmapped and thus look pixelated at distance. 

•Missing skin: console warning and checkered texture
•Missing sound: console warning
•Missing model: CRASH to desktop! You lose.

Couldn't this also just be a console warning and remove the entity? 

well... we could play a checkerboard sound for missing sounds. Like a horn honking or something. 

play the Wilhelm scream 

 

Har har 

Is there a console command in QuakeSpasm similar to sv_gameplayfix_nogravityonground in Darkplaces? I'm experiencing something called the sliding effect on my setup; it's basically when the player slides forward a small distance before coming to a full stop. AFAIK it is how the Quake engine behaves on modern hardware so the issue persists with all ports faithful to vanilla Quake (FitzQuake, QS etc). My workaround is setting sv_stopspeed to 200 (def 100) but I wonder if that has any effect on player movement (jumping etc). Is there a workaround? Could it be input-related? 

Isn't that just normal Quake physics momentum at work? Not sure I understand what you're describing. 

Not really because it looks like I'm walking on ice or some other low-friction surface rather than the ground. Moreover it reduces the precision of player control when navigating ledges, lifts etc. I don't see this when watching other people's demo runs. 

That is a normal effect in FPSes. Stopping dead from a full out run is jarring and odd. Sv_stopspeed woukd be your best option for this. Try like 1000. This may affect, however, some wind tunnels by preventing them throwing you as far once you touch the ground, but this might be ok. 

Yes sv_stopspeed is the workaround I'm using. It's not perfect but it gets me there. I tested a value of 9999 to see its effect exaggerated and oddly enough it results in almost 0 forward movement. Similar to setting sv_friction to a high number, except that here it's deceleration and shouldn't affect speed or acceleration, if I have my physics right. 

The physics in NetQuake and Quakeworld clients is different.

Quakespasm, Fitzquake, Mark V are considered NetQuake. Darkplaces, FTE and others are based on QW. I find QW clients very "swimmy" almost like what are describing. But not so with Quakespasm.

I'm wondering what version of QS are you using (SDL or SDL2) OR if perhaps a setting from another source port has carried over to your current config?

From the readme:

Quakespasm utilizes either the SDL or SDL2 frameworks, so choose
which one works best for you. SDL is probably less buggy, but SDL2
has nicer features and smoother mouse input - though no CD support.

I honestly don't know which one I am using because I switch between source ports quite often. 

I don't know what's going on to be honest..

AFAIK it is how the Quake engine behaves on modern hardware so the issue persists with all ports faithful to vanilla Quake (FitzQuake, QS etc).

The only thing I have heard of that is similar to this is the "multicore timing bug" that affected some Quake clients on Windows (including Fitzquake 0.85 I think?) that had to do with a specific timer API. AFAIK it never affected Quakespasm.

I'd suggest trying MarkV for comparison. 

I'm using SDL2. But I've had this for years and also on a previous system so it makes sense that it's just Quake physics as Johnny Law and Qmaster eluded to.

Also sv_gameplayfix_nogravityonground in Darkplaces seems unrelated to the issue, so that's that. 

The "lastweapon" command in DirectQ is really nice for quick grenades. Wish it could be added to Quakespasm. It's the same thing as in Half-Life, you can switch between any two weapons with one button. 

Looks like it's not a bug or even QuakeSpasm-related, but rather a "feature" of the Quake engine. I'll deal with it. 

Just out of curiosity - are you running with maxfps > 72? Lots of physics problems manifest in this case, and setting it back to 72 is often the quickest and easiest fix. 

No, host_maxfps is unchanged at 72. I also have vsync enabled which caps my framerate at 60. 

Try disabling vsync. I get input lag with it too, and I think the implementation might be buggy 

Disabling vsync didn't solve the stopdrift and I saw some image tearing with the video card getting ahead of the monitor. My solution is increasing sv_stopspeed to 300 (def=100). Looks like there's no adverse effect on player movement up to a setting of ~500. Thanks lads, appreciate the help. 

The hidden closet with the Shambler at the start of id1/e4m7 is visible through the sky brush.

https://i.imgur.com/ssW4CLT.jpg

Doesn't happen in Mark V, DarkPlaces or DirectQ. Does happen in vkQuake, which is a Quakespasm fork. 

On further inspection, this seems to be caused by my wrapper (QeffectsGL) trying to do a "ZTrickFix", works fine if I set ZTrickFix to 0. However, the bug does occur in vkQuake regardless. So, maybe still worth looking into. 

Ah - that's good. I checked and can't reproduce on QS 0.93.0-RC1. Can reproduce on vkQuake, though. Maybe file a bug at: https://github.com/Novum/vkQuake/issues