I noticed a new bug overnight in my FPS where the mouse movement doesn't track correctly; it is chrome specific and the PointerLock/FPS example is also affected:
https://threejs.org/examples/misc_controls_pointerlock.html
Just move the mouse around quickly for a bit and you'll notice it jumping erratically. If you log the movementX and movementY values, it spuriously throws in movements of 300 to 400 (or -300 to -400 pixels) every once in a while. (Edit: In other words, it appears that the API is adding approximately 360 degrees +/- to fast movement events, but not exactly 360 so it is resulting in large mouse jumps.)
Since this is only an issue in chrome (current version 62.0.3202.94), I'm a bit worried that it might not be an easy fix, but I haven't been able to implement any quick fixes aside from rejecting large numbers, which isn't really ideal.
My game uses the the dev branch of three.js, but the FPS example is obviously run on r88 and the bug still appears.
I don't follow chrome updates very closely, but I did a quick search and I couldn't find any specific update that might have broken their PointerLock API.
I noticed a new bug overnight in my FPS where the mouse movement doesn't track correctly; it is chrome specific and the PointerLock/FPS example is also affected:
https://threejs.org/examples/misc_controls_pointerlock.html
Just move the mouse around quickly for a bit and you'll notice it jumping erratically. If you log the movementX and movementY values, it spuriously throws in movements of 300 to 400 (or -300 to -400 pixels) every once in a while. (Edit: In other words, it appears that the API is adding approximately 360 degrees +/- to fast movement events, but not exactly 360 so it is resulting in large mouse jumps.)
Since this is only an issue in chrome (current version 62.0.3202.94), I'm a bit worried that it might not be an easy fix, but I haven't been able to implement any quick fixes aside from rejecting large numbers, which isn't really ideal.
My game uses the the dev branch of three.js, but the FPS example is obviously run on r88 and the bug still appears.
I don't follow chrome updates very closely, but I did a quick search and I couldn't find any specific update that might have broken their PointerLock API.