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 @unknown
Secondary code analysis by @unknown (prefer jonathan2520's, though)
Linked issues
is duplicated by 5
Attachments
Comments 43
I can not understand what you mean. I can not reproduce it.
It could be that you are out of attack range.
@unknown: It's still there in the release. I'm not out of attack range. In fact, if you watch the video where I missed a lot at first, you'll see all misses (except possibly one) were at a smaller distance than the eventual hit. The determining factor that made me hit was that I was leading a little with the crosshair. It's odd that the hitbox is effectively offset by about the width of a slime, no?
Maybe it only stands out when you have shooter skills. If you do, it's quite egregious. If you don't, that's why I made these videos to highlight it. You can frame-step through them if needed. You can also categorize your own footage by lead.
I should emphasize that it applies to all 3D aiming and clicking at about the same time; I've misplaced quite a few blocks due to this. This test is merely the least defendable one, chosen so knee-jerk excuses don't make sense.
Man, this is such a pain. I've been playing a little again lately. I just can't help clicking as soon as my crosshair is over the mob/block/chest/whatever I want to hit, meaning I'll often hit the thing my crosshair was over a moment before instead. Why can't such a simple thing work?
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.
[media]
Erik Broes
Ugh. This is getting so annoying. Why do mouse clicks have to register using a mouse position from ages ago? If your mouse control is any good, you'll often move the mouse and then click at the right time in one motion. If you try to do that now, you'll usually hit at a past mouse position.
The one good thing is that the delay roughly counteracts the latency of my system. That means the click will register roughly where the crosshair was physically displayed on the monitor at the time the mouse button was physically clicked. But this property is very rarely helpful when it comes at the huge cost of the loss of coherence. Just don't go there.