Introduce fast mouse polling for lower lag interpolation

[mikeday0]

This is my humble attempt to port to Crispy the fine work that @ceski-1 did for Woof. It's not ready yet but I thought it might be prudent to go ahead and get it out there for early review and testing.

EDIT: Calling this one complete. We are still missing vertical mouse and gamepad, but those can come later. The vertical mouse implementation in particular needs some careful study and refactoring across the four games.

This is not as sophisticated as the current implementation in Woof! but I think it stands on its own as a solid improvement to mousefeel for typical KB + M players.

[ceski-1]

Nice starting point, I tested it briefly. Some issues I noticed:

• Mouselook and mousevert feel off (compare capped and uncapped).
• Combining keyboard turning and mouse turning at the same time has visual glitches (occasional "pops").
• The "mouse threshold" concept in Chocolate/Crispy/Woof assumes each update is a tic in duration (1/35th of a second). So it doesn't work correctly with fast polling and the mouse will feel "slow" at higher fps. I sidestep the issue in Woof by ignoring threshold under certain conditions.
• If you follow the mouse input calculations from start to finish, you'll notice that Crispy has rounding error in several stages. First there's AccelerateMouse() in I_ReadMouse(), then there's *(mouseSensitivity+5)/10 in G_Responder() or G_FastResponder(). By the time the error accumulator runs ("carrying" the error), it's too late and ineffective. I prevent this in Woof by doing the calculations as a single step and using doubles as working variables (see CalcMouseAngle() for example). The rounding only occurs once, in the carry function.

I'll try to give more feedback later, I know it's WIP right now.

[mikeday0]

• Combining keyboard turning and mouse turning at the same time has visual glitches (occasional "pops").

I can repeat this. It appears to be fixed on my end by moving the fractionaltic update back to the end of I_FinishUpdate().

Diff

diff --git a/src/i_video.c b/src/i_video.c
index ab3c7bc9..b5f9f6f1 100644
--- a/src/i_video.c
+++ b/src/i_video.c
@@ -544,9 +544,6 @@ void I_StartDisplay(void) // [crispy]
 {
     SDL_PumpEvents();
 
-    // [AM] Figure out how far into the current tic we're in as a fixed_t.
-    fractionaltic = I_GetFracRealTime();
-
     if (usemouse && !nomouse && window_focused)
     {
         I_ReadMouseUncapped();
@@ -941,6 +938,9 @@ void I_FinishUpdate (void)
                 }
             }
         }
+        // [AM] Figure out how far into the current tic we're in as a fixed_t.
+        fractionaltic = I_GetFracRealTime();
+
     }
 
     // Restore background and undo the disk indicator, if it was drawn.

Does this fix the "pops" for you?

[ceski-1]

Does this fix the "pops" for you?

That seems to work fine, or like Woof:

Diff (Alt)

diff --git a/src/i_video.c b/src/i_video.c
index ab3c7bc9..328e6b1e 100644
--- a/src/i_video.c
+++ b/src/i_video.c
@@ -542,11 +542,11 @@ void I_StartTic (void)
 
 void I_StartDisplay(void) // [crispy]
 {
-    SDL_PumpEvents();
-
     // [AM] Figure out how far into the current tic we're in as a fixed_t.
     fractionaltic = I_GetFracRealTime();
 
+    SDL_PumpEvents();
+
     if (usemouse && !nomouse && window_focused)
     {
         I_ReadMouseUncapped();

[JNechaevsky]

Finally, tried it out on both 60 and 120 Hz monitors. It's a God's job. The difference is notable even on 120 Hz!

[JNechaevsky]

Small thought: probably worth to check for !demorecording here as well. At the moment, while demo recording there is a small notable jiterring between frames while camera rotation, most likely brought by "short tics".

[mikeday0]

Thanks for the review Julia. I noticed this issue too. I have a fix for the jittering on my local pc that I will clean up and push when I return home this weekend.

[mikeday0]

@fabiangreffrath Kindly requesting a review of this PR for inclusion in the next release. Thanks!

[fabiangreffrath]

Wow, this change is massive! I must have somehow missed that it was ready for review, sorry. Looks good to me, thank you. I cannot review every single line change, but I trust you enough to judge the change set just from the looks of it. 😉

[mikeday0]

Just noticed this was a non-squashed merge. Should I revert and re-merge with squash?

[fabiangreffrath]

Just noticed this was a non-squashed merge. Should I revert and re-merge with squash?

Na, it's okay. Thanks!