You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most operating systems enable a feature known as mouse acceleration, which ramps up the speed of your cursor the faster you move your mouse. This basically means your cursor will be less sensitive to slower mouse movements and more sensitive to faster mouse movements. This is fine for most tasks that use a mouse cursor but is not the best fit for controlling 3D cameras (e.g., in first-person games). For gaming, non-accelerated input is generally preferred because then the camera moves exactly as your mouse does.
Chrome supports PointerLockOptions.unadjustedMovement to ignore mouse acceleration.
This could easily be integrated into the Pointer Lock extension. Obviously, this could be controlled by the project creator using a block. Here's a wording I came up with to make it as intuitive as possible for anyone who has never heard of this terminology before:
"Exact movement" means raw input is obtained directly from the mouse, bypassing modifiers from sensitivity and mouse acceleration settings.
This works best for 3D camera rotation and is the default option.
"Cursor (absolute)" obtains mouse input from the OS, which may be adjusted by sensitivity and mouse acceleration settings.
This works best for most computation tasks.
"Cursor (scaled)" obtains mouse input from the OS and then multiplies it by the project player's pixel density (measuring as if you were moving your cursor across the entire stage).
This works best for moving objects on a canvas or workspace, since the amount of movement will be based on the size of the player screen.
This might be overthinking it and making it even more complex for some people, though; just a block to enable or disable raw input would be fine.
Chrome supports PointerLockOptions.unadjustedMovement to ignore mouse acceleration.
Not everywhere. I have developed a dislike for unadjustedMovement: true, because of how often it's implemented incorrectly. It's not supported for me and makes requestPointerLock throw an exception. I've come across plenty of websites that do not handle it correctly, and as such become unusable, unless I manually modify them. Websites that handle it correctly first try with it, and then if that fails - without it.
That's not the same thing at all? The issue is about getting unaccelerated movement values from the browser. Not about processing those values in various different ways.
Activity
Brackets-Coder commentedon May 30, 2025
might be helpful
Xeltalliv commentedon Jun 4, 2025
Not everywhere. I have developed a dislike for
unadjustedMovement: true, because of how often it's implemented incorrectly. It's not supported for me and makesrequestPointerLockthrow an exception. I've come across plenty of websites that do not handle it correctly, and as such become unusable, unless I manually modify them. Websites that handle it correctly first try with it, and then if that fails - without it.DNin01 commentedon Jun 4, 2025
MDN Web Docs says it's not supported on Linux, but that might not be the only issue.
Good to know that a fallback may be necessary.
SharkPool-SP commentedon Jul 21, 2026
Technically hyper sense V2 can do this when merged?:
SharkPool-SP commentedon Jul 21, 2026
Just as a thought for later. No need for that chrome-only api
GarboMuffin commentedon Jul 25, 2026
That's not the same thing at all? The issue is about getting unaccelerated movement values from the browser. Not about processing those values in various different ways.
SharkPool-SP commentedon Jul 25, 2026
I'm a bit confused then on what the values should be
GarboMuffin commentedon Jul 25, 2026
I think the original issue description is very detailed