There's no vid_refreshrate in QS, it looks like SDL1 didn't support specifying a refresh rate.

SDL2 does support asking for a specific refresh rate, so we could probably add it back in.

I'm not sure what the current behaviour is actually, suppose your desktop resolution is 1920x1080 @ 144Hz, and you launch QS in fullscreen mode at 1920x1080. I'd assume SDL would use the desktop refresh rate and not bother changing it to 60Hz or something.

Maybe you can check that Daz, if there's an info button on your monitor that shows the current refresh rate in the on-screen-display? 

Was that not an original quake physics behaviour? Why cant i easily jump up stairs like in darkplaces or quake 2/3. It would be very helpful as an option at-least. 

Spiney : http://www.amazon.co.uk/gp/product/B00B19T7QC/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1 I am very happy with it!

ericw : The monitor stays in 144hz mode with vsync on/off with host_maxfps 72. There is a very noticeable jump in smoothness when you set host_maxfps to 144 which is why I wanted to ask about this :)

Thanks for the info! 

Quake's physics and QuakeC expect 72 fps as a server, and single player is both client and server.

Jerky lifts, killer elevators, ... 

BUGS
-
There is a lot of lag in big/complex maps
like in scourge of armagon & Airquake

Some textures can be seen through at far distances like in e1m1

Moving models and those with an attached model are very jittery when moving (the tanks in Airquake) 

Can you reproduce with the latest one from http://quakespasm.sf.net/devel ? Try a clear config (delete/move your id1/config.cfg).

Scourge of armagon being laggy suggests software rendering, what are the first 3 lines of output from entering "gl_info" in the console?

Can you post a screenshot of the seethrough textures in e1m1? 

jumping up stairs is a darkplaces change. 

^ and one that doesn't come without its own knockon effects, like increasing the effective jump height to 64 units from 48. 

In light of the map jam 3 theme, I decided to play Zerst�rer using a recent svn version of Quakespasm. I also tried it with the version that you can install from Ubuntu package manager. I downloaded the Zerst�rer package from Quaddicted. (I had to rename the file names to lower case.)

I found out that the cutscenes didn't work quite as intended with either version of QS.

The first cutscene (with the pit trap) had very noticeably jumpy camera movements at some sections. The end cutscene had the camera zoom off to the void before the conclusion and show mostly black.

There is a play-through video on YT for the maps you can watch for comparison (I think it's with Darkplaces), but I think it's quite obvious without them if you get similar results. Please try to replicate, or suggest config settings that might help (if any).

The maps with these two cutscenes are episode 2 and the end map. 

If you are on windows, can you compare against fitzquake-0.85 so that we can understand the source of the issues, fitz or us. 

The ending cutscene is a Fitz problem definitely. 

Isn't that what http://www.quaddicted.com/filebase/zerend_fix.zip is for? 

Afaik reQuiem has some fixes for that builtin and also it smoothes demo gameplay. jdhack was pretty proud of that. 

The camera jerks about when rotating, its a limitation of something in the engine - can't remember what.

Supa solved it in RMQ. 

I thought it had to do with the networking or something? Coarse values in rotations for faster transfers. 

The cutscenes use a bunch of svc_setangle messages which are controlled by setting ent->v.fixangle (sorry, I don't know the QC equivalent to this). It would be possible to lerp between consecutive svc_setangles engine-side, but there are probably edge cases (aren't there always) that need to be worked out.

Summary is that for zer cutscenes it is a combination of coarseness and widely-spaced (via nextthink) messages. 

Sends a byte angle (256 values representing 360 degrees), so using that to continually reposition the angles is going to be jerky.

[And can't be interpolated client-side because the 'resolution' of byte angles leads to inconsistent rouunding.].

Looks like jdhack has the client read it directly from the server-side camera entity in single player. 

We had daisy-changing and interpolation between multiple camera positions at once on all three axis in both rotation and position - it was pretty fucking sweet :D 

In RMQ engine, it looks like you have it reading/writing float with the RMQ protocol.

jdhack has a lot of code detecting the Zerstorer cut-scene.

I'm hoping that code isn't necessary and just doing svc_setangle as either a short (2 bytes) or a float angle would fix this kind of thing.

The choppy angles in the cutscenes in, say, Zerstorer are annoying. 

The texture bug is fixed in the latest version
Also the lag has been reduced but is still noticeable sometimes

A suggestion, allow quakespasm to read from the the game folders, not only the .pak files 

The camera is messed up in the Monster Match mod 

I tested Fitz-0.85 with Wine on Linux. It has the same behaviour, as far as I can tell without a careful side-by-side comparison. The zerend fix pak corrected the end map camera placement.

Rewatching the Youtube clip, I now see it stutters too when the camera is rotating. I think I perceive it as much less annoying because the YT video has a lower resolution and a slower framerate.

Thanks for the responses, everyone! Things work well enough with the patch. It would of course be nice to have non-stuttering rotating cameras in modern Quake source ports, but it's not a feature I really need at the moment.

If I do find unexpected engine differences with a more careful comparison, I'll post about them later. For now, I assume it was resolution, window size and FPS that made the rotational stutter so much more striking in the engine. 

Right now I don't think this is going to fix anything.

The real problem is that you're relying on how often QC updates the angles. If it thinks at 10fps then the angles are only going to update 10 times per second so it's going to be jerky no matter what precision you send the angle as.

The more robust solution seems to be to detect if a Zer cutscene is playing and use the cls.demoplayback angle interpolation code in CL_RelinkEntities.

At least in this case the QC isn't doing a bunch of PF_WriteChar/PF_WriteAngle calls, but that's also something you need to be careful of. 

checking the zer progs, seems like camera updates are 100fps (time + 0.01).
This is just the low res angles for the camera. 

The irony being that the lower the packetrate used, the smoother the interpolation will be, as the network inprecision is hidden behind larger deltas.
with vanilla quake, with no interpolation, you wanted to spam as fast as you can to try to hit every notch to get it as smooth as possible that way. interpolation won't make that any worse, but you'll see it juddering still as the difference between each frame is non-linear due to rounding. shorts will help counter high packet rates.

my general recommendation would be to update angles exactly once per PlayerPostThink. This allows the client to properly detect when there's a camera active by the fact that every single update contains an angle change. The down side is that this requires the update be sent as unreliable packets instead of reliable ones so that they're kept in sync with entity snapshots over the internet where reliables cannot be acked near-instantly.
Anything else will be jerky in some situation. And yes... needs shorts or low snapshot rates.