Skip to content
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

Trying to manually control pointerlock #41

Open
jbaicoianu opened this issue Mar 25, 2017 · 2 comments
Open

Trying to manually control pointerlock #41

jbaicoianu opened this issue Mar 25, 2017 · 2 comments

Comments

@jbaicoianu
Copy link

I'm trying to use em-dosbox in a situation where I want to be able to manually enable or disable pointerlock when a system is in use. I'm embedding this into another app which has its own pointerlock handling, so I'd like to only lock to the em-dosbox canvas element when it's been clicked directly, or focused in code.

It seems that as it is now, either em-dosbox or emscripten itself is calling emscripten_request_pointerlock() in response to keydown events, regardless of what I try to do to restrict mouse capture.

Things I've tried so far:

  • ENV['SDL_HINT_EMSCRIPTEN_KEYBOARD_ELEMENT'] = '#canvas';
  • Module.elementPointerLock = true (tried false too, no difference)
  • autolock=false in the [SDL] section of dosbox.conf

I looked into the code to try to trace this, I see two possible places which could be triggering it:

em-dosbox/src/gui/sdlmain.cpp

Lines 1213 to 1225 in 1f46d1d

void GFX_CaptureMouse(void) {
if (use_capture_callback) {
if (sdl.mouse.locked) {
emscripten_exit_pointerlock();
} else {
//This only raises a request. A callback will notify when pointer
// lock starts. The user may need to confirm a browser dialog.
emscripten_request_pointerlock(NULL, true);
}
} else {
doGFX_CaptureMouse();
}
}

which is called from several places, but I wonder if

em-dosbox/src/gui/sdlmain.cpp

Lines 1279 to 1289 in 1f46d1d

EM_BOOL em_pointerlock_callback(int eventType,
const EmscriptenPointerlockChangeEvent *keyEvent,
void *userData) {
if (eventType == EMSCRIPTEN_EVENT_POINTERLOCKCHANGE) {
if ((!keyEvent->isActive && sdl.mouse.locked) ||
(keyEvent->isActive && !sdl.mouse.locked)) {
doGFX_CaptureMouse();
}
}
return false;
}
is causing issues, for example, if I already have the pointer locked when the emscripten module boots, when I exit from my own app's pointerlock, maybe this is triggering?

The other place that looks suspicious is Emscripten's deferred fullscreen/pointerlock requesting code, https://github.com/kripken/emscripten/blob/master/src/library_html5.js#L69-L97 - this queues up any requests to requestPointerLock() which may have happened and forces them to be executed on a qualifying user interaction event. So it's possible some code somewhere is requesting pointerlock and it's not being applied until I start trying to press keys (in this case, WASD to move around my virtual world)

Any hints on how to disable the built-in pointerlock logic and handle it myself?

@dreamlayers
Copy link
Owner

I can't reproduce this. I can click, get pointer lock, break it with the escape key or with setTimeout(function(){ document.exitPointerLock(); }, 3000); and then press keys without re-establishing pointer lock.

After looking at my code I do have some doubts about GFX_CaptureMouse() correctness. It may have some unexpected side effects via SDL calls in doGFX_CaptureMouse() or due to differences between sdl.mouse.locked and the real mouse capture state. Though there's nothing trying to capture the mouse in response to keyboard key events.

I guess what you describe might be happening due to focus changes? I'm just guessing because I can't reproduce this.

@jbaicoianu
Copy link
Author

Hmm. I'll play around with it and see if it's something the loader or something else on my end is doing, I'll set up a simplified test case and let you know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants