-
-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
requestPointerLock() documentation should note that it must be called from the user's callback #5191
Comments
Hi @jgordon510, thanks for filing this! I hadn't heard this before but it could certainly be true since i think that API is still evolving. However, I tried the example at https://p5js.org/reference/#/p5/requestPointerLock in Chrome (version 90.0.4430.72) and it worked fine. 😕 Does that example work for you in Chrome? (You should see the little sphere mesh rotate around when you move your mouse. Thanks! |
I think you misunderstand what pointerlock does: "You should see the little
sphere mesh rotate around when you move your mouse."
The example is moving because it's panning and tilting the camera by movedX
and movedY respectively. It has nothing to do with the
requestPointerLock().
As the description states: "The function requestPointerLock() locks the
pointer to its current position and makes it invisible." This does not
happen in the example.
Here is that example without the requestPointerLock() that behaves exactly
the same: ***@***.***/p5-template-39
(Here is an example with the requestPointerLock() in the same position as
the example: ***@***.***/p5-template-40 )
Finally, here is an example with the requestPointerLock() working properly
inside of mousePressed(): ***@***.***/p5-template-41
Be sure to click on the canvas itself to activate the pointerLock. You'll
notice that, like the description says, the pointer disappears, and you
must press escape (as your browser will tell you) for the pointer to come
back.
Here's more information on the PointerLock API:
https://developer.mozilla.org/en-US/docs/Web/API/Pointer_Lock_API
"The Pointer Lock API (formerly called Mouse Lock API) provides input
methods based on the movement of the mouse over time (i.e., deltas), not
just the absolute position of the mouse cursor in the viewport. It gives
you access to raw mouse movement, locks the target of mouse events to a
single element, eliminates limits on how far mouse movement can go in a
single direction, and removes the cursor from view. It is ideal for first
person 3D games, for example."
…On Sat, Apr 17, 2021, 7:47 PM evelyn masso ***@***.***> wrote:
Hi @jgordon510 <https://github.com/jgordon510>, thanks for filing this! I
hadn't heard this before but it could certainly be true since i think that
API is still evolving.
However, I tried the example at
https://p5js.org/reference/#/p5/requestPointerLock in Chrome (version
90.0.4430.72) and it worked fine. 😕 Does that example work for you in
Chrome? (You should see the little sphere mesh rotate around when you move
your mouse.
Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5191 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB2DA63TPFOE7JOMIF5DCBDTJJB2NANCNFSM43DMVL5Q>
.
|
I can see this behaviour in Firefox as well. A note about needing user interaction in order to request pointer lock is probably needed in the documentation here and the example be edited to something like. let cam;
function setup() {
createCanvas(100, 100, WEBGL);
cam = createCamera();
}
function draw() {
background(255);
cam.pan(-movedX * 0.001);
cam.tilt(movedY * 0.001);
sphere(25);
}
function mouseClicked(){
requestPointerLock();
} |
Yes, agree. I believe that this requirement wasn't in place when this example was made. |
This reverts commit b8c5da3. reverts commit from another pull request
fixes issue #5191 along with minor grammatical edits
Details about the bug:
The page at https://p5js.org/reference/#/p5/requestPointerLock notes that "not all browsers support this feature." It should also note, however, that the feature requires being called in a user callback (a click or something) in most browsers. Chrome definitely requires it, similar to audiocontext.
The text was updated successfully, but these errors were encountered: