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

[sokol_app] Alt-tabbing issues on windows in a FPS game on a multi-monitor setup #1056

Open
jakubtomsu opened this issue May 25, 2024 · 2 comments

Comments

@jakubtomsu
Copy link
Contributor

I'm making a 3d FPS game with sokol_app and sokol_gfx, and I use sapp.lock_mouse(true) and sapp.show_mouse(false) to get the correct hidden FPS cursor behavior. However after alt-tabbing out of the app and focusing back it is broken. The mouse is hidden, but it can exit the clipping rectangle and move to another monitor.

I tried to call lock_mouse and show_mouse both only in init_cb or every frame, both approaches don't work in slightly different ways.

Maybe the issue is with my code, I haven't had time to investigate further. But any help is appreciated :)

floooh added a commit to floooh/doom-sokol that referenced this issue May 25, 2024
@floooh
Copy link
Owner

floooh commented May 25, 2024

Hmm yeah I'm seeing the same thing in the "doom-sokol" example (on Windows, haven't tested other platforms).

One workaround seems to be to disable, and then enable again the mouse lock in the FOCUSED event like this:

https://github.com/floooh/doom-sokol/blob/e87eb25c648f6cc4731fc1a6ba3f72df24abd826/src/doomgeneric_sokol.c#L552-L555

...the explicit disabling is necessary because of this check:

sokol/sokol_app.h

Lines 7096 to 7098 in f30824c

if (lock == _sapp.mouse.locked) {
return;
}

I seem to remember that this was necessary because there's a Windows routine somewhere in there which has something like a reference counter.

Maybe the same is necessary when going from iconified back to restored.

Btw: I'll be travelling from tomorrow until Thursday, I may not respond during that time.

PS: I should really tackle that higher level "sokol_input.h" header which tracks input events, provides a polling API and takes care of little warts like this that are hard to do right down in sokol_app.h with its "stateless" input events.

@jakubtomsu
Copy link
Contributor Author

Thank you, I'll try that out.
The sokol_input header would be cool, especially if there was also support for gamepads (or have a separate sokol_gamepad which I've seen mentioned)

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

No branches or pull requests

2 participants