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
Virtual mouse module currently uses clientX and clientY from the patched event. When pointer lock is on, those values stick to what they were when pointer lock was enabled, and instead movementX and movementY values are provided. (which are deltas and not absolutely values - combined with your "starting x/y" you can construct absolute values)
You can test this by setting it up so that pointer lock is turned on with a click on canvas. If you click to enable pointer lock while over a component who is emitting click events, that component will be clicked, then you can move your mouse around and click again, and the component will be clicked again.
It is possible to have your mouseX and mouseY go to any size the user desires. But if we by default just limit it to screen size, then can just generate our own mouseX and mouseY based on mouseX/Y += movementX/Y and have it so that it does not increment/decrement if on edge of screen. Then pointer lock'ed mouse's x/y values will behave same as clientX/Y and it should work with existing virtual mouse code. But maybe locking to screen size will not work with FPS controls which use pointer lock. Can do some interesting things, like wrap mouse around as in the mozilla example, or "extend beyond the page width/height" - in which case how could raycaster continue to work?
Will also need to include pointer lock browser prefixes.
Version:
v2.x.x
v1.x.x
Issue type:
Bug
Proposal/Enhancement
Question
Tested on:
Desktop
Chrome
Chrome Canary
Chrome dev-channel
Firefox
Opera
Microsoft IE
Microsoft Edge
Android
Chrome
Firefox
Opera
IOS
Chrome
Firefox
Opera
The text was updated successfully, but these errors were encountered:
Oh, we will also need to draw a pointer in place, since pointer lock hides it. could be a quad with a texture that doesn't use modelView matrix and just set gl_Position between 0-1. Or maybe sprite
Pointer lock hides your cursor, and makes it so you can move your mouse "infinitely"
see https://developer.mozilla.org/en-US/docs/Web/API/Pointer_Lock_API
Virtual mouse module currently uses
clientX
andclientY
from the patched event. When pointer lock is on, those values stick to what they were when pointer lock was enabled, and insteadmovementX
andmovementY
values are provided. (which are deltas and not absolutely values - combined with your "starting x/y" you can construct absolute values)https://github.com/WhitestormJS/whitestorm.js/blob/beta/src/modules/app/VirtualMouseModule.js#L24-L34
You can test this by setting it up so that pointer lock is turned on with a click on canvas. If you click to enable pointer lock while over a component who is emitting click events, that component will be clicked, then you can move your mouse around and click again, and the component will be clicked again.
It is possible to have your
mouseX
andmouseY
go to any size the user desires. But if we by default just limit it to screen size, then can just generate our ownmouseX
andmouseY
based onmouseX/Y += movementX/Y
and have it so that it does not increment/decrement if on edge of screen. Then pointer lock'ed mouse'sx/y
values will behave same asclientX/Y
and it should work with existing virtual mouse code. But maybe locking to screen size will not work with FPS controls which use pointer lock. Can do some interesting things, like wrap mouse around as in the mozilla example, or "extend beyond the page width/height" - in which case how could raycaster continue to work?Will also need to include pointer lock browser prefixes.
Version:
Issue type:
Tested on:
Desktop
Android
IOS
The text was updated successfully, but these errors were encountered: