Minecraft
  1. Minecraft
  2. MC-67665

Mouse click position always lags a few frames behind the crosshair

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Resolution: Fixed
    • Affects Version/s: Minecraft 14w33c, Minecraft 14w34b, Minecraft 1.8-pre1, Minecraft 1.8-pre3, Minecraft 1.8, Minecraft 1.8.1-pre2, Minecraft 1.8.1-pre3, Minecraft 1.8.1-pre4, Minecraft 1.8.1-pre5, Minecraft 1.8.1, Minecraft 1.8.2-pre1, Minecraft 1.8.2-pre4, Minecraft 1.8.7, Minecraft 1.8.8, Minecraft 15w39b, Minecraft 1.9, Minecraft 1.9.4, Minecraft 1.10, Minecraft 1.10.2, Minecraft 16w39b, Minecraft 16w39c, Minecraft 16w40a, Minecraft 16w41a, Minecraft 16w42a, Minecraft 16w43a, Minecraft 16w44a, Minecraft 1.11 Pre-Release 1, Minecraft 1.11
    • Security Level: Minecraft - Public (Viewable by everyone)
    • Labels:
      None
    • Environment:

      Mac OS X 10.9.4
      Java 8u11

    • Confirmation Status:
      Confirmed

      Description

      Lately I've been noticing some odd mouse lag, where the game registers clicks where the crosshair was aimed a few frames ago. You can actually see the selection box lagging behind the crosshair by a few frames (this lag was introduced between 14w21b and 14w25b). I believe the responsiveness of the crosshair itself hasn't changed.

      It's hard to account for all the different factors leading to an experience of a certain type of lag, so I devised a simple test: circle around mobs and try to hit them. If you keep the crosshair continuously centered and the game is consistent, this should always hit. In ≥14w25b you can do this for a while to no avail; you need to lead by a few frames to hit reliably. ≤14w21b is much better, perhaps off by one frame.

      To reproduce most effectively, circle around tiny slimes at full speed creative flight and try to hit them. This is to reduce the temporal size of the target, making timing issues more apparent. The problem seems to be limited to mouse movements, which circling takes care of.

      My videos were recorded at 60 fps in 14w33c. The fps limit was set to 120 fps. My machine actually hits 120 fps under these circumstances.


      See:
      Code analysis by jonathan2520
      Secondary code analysis by caucow (prefer jonathan2520's, though)

      1. Bildschirmaufnahme (11).mp4
        1.31 MB
        [Helper] Fabian Röling
      2. Direct hit is not a hit 720p.mov
        8.81 MB
        jonathan2520
      3. Pitch good yaw bad.mov
        6.59 MB
        kellen
      4. Pitch good yaw bad.mov
        6.59 MB
        jonathan2520
      5. Way off is a hit 720p.mov
        2.12 MB
        jonathan2520
      1. 2016-10-21_23.50.05.png
        287 kB
      2. 2016-10-29_02.24.37.png
        109 kB
      3. 2016-11-09_13.45.03.png
        98 kB

        Issue Links

          Activity

          Hide
          jonathan2520 added a comment - - edited

          1.11-pre1 (and now the release) is mostly correct! I'm still marking it because disabled interpolation from a previous purported fix is still there. The thing where the selection box tends to lead you when you sprint. In MCP parlance, renderWorld needs getMouseOver(partialTicks), not getMouseOver(1.0F). As I mentioned before, interpolation conveniently doesn't do anything for angles updated by setAngles, so once you're using those it doesn't incur any mouse look delay.

          Show
          jonathan2520 added a comment - - edited 1.11-pre1 (and now the release) is mostly correct! I'm still marking it because disabled interpolation from a previous purported fix is still there. The thing where the selection box tends to lead you when you sprint. In MCP parlance, renderWorld needs getMouseOver(partialTicks), not getMouseOver(1.0F). As I mentioned before, interpolation conveniently doesn't do anything for angles updated by setAngles, so once you're using those it doesn't incur any mouse look delay.
          Hide
          Alexey Shlyonskikh added a comment -

          What's wrong? I think it's fixed now.

          Show
          Alexey Shlyonskikh added a comment - What's wrong? I think it's fixed now.
          Hide
          [Mojang] Grum (Erik Broes) added a comment -

          Let this be fixed please ;D

          Hard to verify it IS fixed, looks better but meh

          Show
          [Mojang] Grum (Erik Broes) added a comment - Let this be fixed please ;D Hard to verify it IS fixed, looks better but meh
          Hide
          [Helper] Pokechu22 added a comment -

          Can confirm that this seems to be fixed from my testing with a 10x slowdown factor.

          Show
          [Helper] Pokechu22 added a comment - Can confirm that this seems to be fixed from my testing with a 10x slowdown factor.
          Hide
          jonathan2520 added a comment -

          I agree it's fixed in 16w50a. Well, as good as it was before 1.8 when problems weren't so blatant. My remarks about further improvements still stand. But let's call it fixed for now. Thanks for sticking with it, Grum!

          Show
          jonathan2520 added a comment - I agree it's fixed in 16w50a. Well, as good as it was before 1.8 when problems weren't so blatant. My remarks about further improvements still stand. But let's call it fixed for now. Thanks for sticking with it, Grum!

            People

            • Assignee:
              [Mojang] Grum (Erik Broes)
              Reporter:
              jonathan2520
            • Votes:
              18 Vote for this issue
              Watchers:
              16 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                CHK: