Input sampled on wrong side of frame limiter

[ioquake]

Input sampled on wrong side of frame limiter

[youurayy]

Alternate name for this issue: "Halving input latency after 17 years of Quake 3."

[zturtleman]

Fixed in ead5478. Thanks.

[ensiform]

I believe in frame is called in main() after the com frame function so it happens after com frame takes place all together.

[wareya]

Yes, it goes like thus:

while( 1 )
{
    IN_Frame( );
    Com_Frame( );
}

And Com_Frame runs the framelimiter before thinking, which puts things in the wrong order.

[ensiform]

That's really no different from how quake3.exe does it though.

[wareya]

That's right, vanilla quake 3 also has this problem.

[ensiform]

Is there any sort of fixes in cnq3 ?

[wareya]

cnq3 somehow fixes mouse button inputs without fixing mouse movement or keyboard press inputs.

[youurayy]

Blunt test code here: youurayy@6908038

It's just IN_Frame() called again within Com_Frame() right after the limiter code, with a flag added to prevent it from triggering a second vid_restart or possibly a vid_restart in the wrong place. Only tested with bots so far.

Also tested at com_maxfps=1 and the lag is not there anymore, well played sir @wareya, well played.

I'm gaming at 60Hz with GTX 980, and to me the improvement is incredible, there's just no way back. To me, the mouse movement now seems "glued" to the mouse, it's like a different game.

I'm gaming with:

seta com_maxfps "60"
seta r_finish "1"
seta in_mouse "1"
seta cl_mouseAccel "2"
seta sensitivity "1.500000"
seta cl_mouseAccelOffset "5"
seta cl_mouseAccelStyle "1"
seta m_filter "0"
seta r_mode "-1"
seta r_fullscreen "1"
seta r_customwidth "1920"
seta r_customheight "1080"
seta com_hunkMegs "1024"