Input latency revisited

[aufau]

This is how original, multiplayer client input latencies worked:

IN_Frame |--- sleep ---| CL_SendCmd | CL_SetCGameTime |--- SCR_UpdateScreen ---| IN_Frame …

Where:

• IN_Frame – Collect user input since previous IN_Frame
• sleep – Framerate limiter
• CL_SendCmd – Generate and send user command with current cl.servertime and user input
• CL_SetCGameTime – Update cl.servertime to approximate time on a server at this moment
• SCR_UpdateScreen – Update local game state based on cl.servertime and render the frame

Only sleep and SCR_UpdateScreen can take substantial amount of time. Their respective times may vary, but we know that any period of time containing BOTH is constant for our purposes (assuming perfect fps conditions).

Positives/Negatives:

• [+] Delay between a moment when mouse input is collected (IN_Frame) and when it's printed on the screen (end of SCR_UpdateScreen) is constant. From now on I'll be calling it input-screen delay

• [-] Unnecessary additional input-server delay in sleep phase (between IN_Frame and CL_SendCmd)

JK2MV/OpenJK patch: Improve input responsiveness by moving sampling to other side of framerate limiter.

IN_Frame | CL_SendCmd | CL_SetCGameTime |--- SCR_UpdateScreen ---|--- sleep ---| IN_Frame …

• [+] Minimal input-screen delay
• [+] Minimal input-server delay

• [-] Input-screen delay can vary depending on rendered scene complexity, hardware speed, load and clock rates even if fps is stable

My proposition:

IN_Frame | CL_SendCmd | CL_SetCGameTime |--- sleep ---|--- SCR_UpdateScreen ---| IN_Frame …

• [+] Minimal input-server delay
• [+] Constant (one frame, worst-case scenario for OpenJK version) input-screen delay

• [-] ?

Note:

• Generated user commands have servertime one frame behind for no good reason. Afaik this doesn't affect anything as both server and cgame use servertime deltas rather than absolute values for their calculations. Also it's consistent with original code.

What do you think? Did I miss something? Do you agree than minimizing variance is more important?

[aufau]

Few more things to take into consideration:

1. Sleep time calculations – It's really not great and doesn't take into account that CPU core may be taxed by other tasks. This is why some quake engines come up with com_affinity cvar I think. It tries to keep average framerate close to 1000 / com_maxfps, but time periods between the ends of consecutive |--- sleep ---| elements can be very uneven. On the other hand, many game physics calculations are very sensitive to such variations (eg jump height, third person camera).

2. Physics calculations (cgvm's DRAW_ACTIVE_FRAME) are linked with rendering in SCR_Update. This isn't a necessity and they can be unlinked if such logic doesn't match our latency goals.

3. The fact that generated command has serverTime one frame behind cl.serverTime may actually be a behaviour expected by mods, ie serverside "unlagged" lag compensation technique. In basejk command serverTime is used by server-side Game physics, cl.serverTime is used by CGame entity interpolation.

4. Sleep time calculations are completely broken when running builtin server with sv_fps different than com_maxfps which is a long standing issue with q3 engine (causes a lot of lags and warping on local server).