sv_fps causing jerky movement on stairs or edges

[m4son]

This time I'm gonna show the video :) the yellow text at bottom-left corner shows player updaterate

[Raptor007]

Thanks, the video does help! I think this is what's happening:

To the server, the player entity position is on the ground every frame. When observed at a lower framerate with about 1 update per stair, client-side interpolation will make it will look like a smooth ascent. If there are multiple position updates per stair, the entity remains at the same vertical position for a few frames at a time, making the interpolated motion alternate between horizontal along the stair and more sharply vertical to the next stair.

I don't know if I can fix this. It seems to be a problem inherent in the way Quake2 deals with player positions on stairs that was hidden by the game's original low framerate.

However, it might be possible to do something like I did with the bot aiming, where at 10fps it sends accurate position updates and on other frames interpolates the Z-axis. This would require some trickery where I replace s.origin[2] immediately before network transmission, and restore it to its actual value immediately after. Proper server-side interpolation would also require an additional 1/10th second of lag on Z-axis movement to store the next real Z-value and then move toward it, but I think I can avoid that by storing the phony value each frame and moving proportionally towards the new real value depending on the number of frames remaining until framesync.

https://github.com/Raptor007/aq2-tng/blob/9341a2b1a4905190c4101a750467779545d96b32/source/acesrc/acebot_movement.c#L574-L582

Another possible method would be transmitting the average of the last framediv values of origin[2]. That would put the Z-position a little behind reality, but would more consistently avoid jerky movement in case new stairs are first stepped on during framesync. The more I think about it, the more I'm leaning towards this method.

Either way it should only do this if !(pm_flags & PMF_NO_PREDICTION) and probably (pm_flags & PMF_ON_GROUND) or groundentity == &g_edicts[0] on the current frame and previous.

[Raptor007]

The lasersight should also use this averaged height value.

Actually, the sudden change from crouch/stand is player viewheight, which requires a different trick to smooth.

[Raptor007]

This is almost done, but it's causing a strange issue where 3rd person chase spectate has an orange tint over it, as though the camera were outside the map. This is reproducible on kumanru in the upstairs room with the long boxes.

[Raptor007]

I fixed the orange chasecam tint, but while testing on kumanru I found that bots would sometimes spawn above the map. This is probably caused by restoring a bogus value in FrameStartZ or averaging with bogus values in FrameEndZ.

[Raptor007]

I think I've got it! I'll give it some more testing on my server before I push it up to aq2-tng.

[m4son]

Wow, impressive work. I was testing on your server ( because of the ping ) and I noticed these patches doesn't apply on 3rd person camera, even previous patch for animation ( e.g. spamming jump ), maybe also in-eyes spectating should smooth stair movement or just receive info in 10hz

[Raptor007]

Thanks for letting me know! I disabled smoothing for spectators because it was causing the orange tint on 3rd person chase cam, but I'll see if I can re-enable it and fix that. https://github.com/Raptor007/aq2-tng/commit/ea1c732176cbe70ff04236af465bc37160501974 I don't think there's a way to receive info at 10fps (aside from sv_fps 10).

[Raptor007]

I looked at this code again and all clients run ClientEndServerFrame before any clients run UpdateChaseCam, so the smoothed Z position should be applied to spectating.

Generally 3rd person spectator works fine. The problem with crouch/jump spam is probably caused by the immediate change in viewheight, similar to why the lasersight was reacting to crouch/stand too quickly: https://github.com/Raptor007/aq2-tng/blob/b2314d82fff4ee16fba7084f9e16d6b7cf7c2474/source/g_chase.c#L142

On servers that supports GMF_CLIENTNUM (basically every server) the AQ2 in-eyes spectator is not using the smoothed s.origin but rather seems to use the other player's ps.pmove.origin. I tried to smooth this too and it did work for in-eyes spectators, but it made the actual player's view jiggle vertically when walking up ramps, so I removed it: https://github.com/Raptor007/aq2-tng/blob/3835e46b4016a0e7c582c9bad0e831da1171bf55/source/p_view.c#L1277-L1283

[Raptor007]

I think the most I can add to this now is smooth the application of viewheight to 3rd person spectators, and also use that value for lasersight and flashlight instead of the current hack.

[Raptor007]

Sometimes players walking down slightly sloped ground will jiggle. This is especially harsh to watch when 3rd person spectating them. (I'm not sure if this is related to sv_fps.)

Edit: I have separated this into issue #90, although the chasecam height adjustment for jumping may also benefit from some smoothing with sv_fps similar to viewheight: https://github.com/Raptor007/aq2-tng/blob/3835e46b4016a0e7c582c9bad0e831da1171bf55/source/g_chase.c#L152-L154

[Raptor007]

I did some digging into "jump animation lifts" and found it's from baseq2, which had a fixed over-the-shoulder chase cam. It made sense there because the camera was very close to the player model, and the jump animation raises the model, so it would be hard to see beyond them without lifting.

This doesn't really make sense anymore with AQ2's farther away free-rotate chase cam, and it's the reason the camera was bouncing up and down obnoxiously when players would walk on slopes, so I disabled this. I think it looks better now. If anyone wants this back, let me know and I'll make it a cvar.