Input grabbing expectations?

What are people’s expectations of SDL_SetWindowGrab(), especially as
relates to SDL_SetRelativeMouseMode()?

In SDL 1.2, grabbing the input or going fullscreen and then hiding the
mouse implied SDL_SetRelativeMouseMode(), and that resulted in bugs
and unexpected behavior.

Now that we have SDL_SetRelativeMouseMode(), do people still want to
grab the keyboard and/or constrain the mouse? Do you want separate
functions to control those?

Thanks!–
? ? -Sam Lantinga, Founder and CEO, Galaxy Gameworks

It seems there are three API calls involved here:

SDL_ShowCursor
SDL_SetWindowGrab
SDL_SetRelativeMouseMode

Does SDL_SetRelativeMouseMode imply calling SDL_ShowCursor?
Does SDL_SetRelativeMouseMode imply calling SDL_SetWindowGrab?
On which window?

Unless I’m mistaken, the answers currently are yes, no, irrelevant.

If your question is “should SDL_SetRelativeMouseMode imply calling
SDL_SetWindowGrab?” then my gut reaction is yes, but as I’ve alluded
to, which window gets the grab? It almost seems as if
SDL_SetRelativeMouseMode only makes sense for single window
applications.

Assuming calling SDL_SetRelativeMouseMode does grab the input, should
you then remove SDL_SetWindowGrab? This, I’m not so sure about. In
principle I’d say yeah, why would you want relative mouse without
grabbing?, but there is the debugging case. If you hit a breakpoint
in your debugger while your input is grabbed, things become… awkward.
For this reason in the project I principally use with SDL, we have an
option to disable mouse grabbing. If SDL_SetWindowGrab is removed, I
now have no means of providing this option.

So, If you’re leaving SDL_SetWindowGrab around, I’ve NOW come full
circle and thought maybe having SDL_SetRelativeMouseMode shouldn’t
call SDL_SetWindowGrab. In this way 95% of the time you’re going to be
calling SDL_SetRelativeMouseMode and SDL_SetWindowGrab in the same
place, but you avoid the which-window-gets-grab problem and have the
means to turn off grabbing for the purposes of debugging. Doing it this
way is really a shift of the problem to being a documentation issue;
i.e. always mention SDL_SetWindowGrab in the documentation of
SDL_SetRelativeMouseMode and vice versa.

Apologies for the long email and asking stupid questions or
possibly getting the wrong end of the stick here, but I wanted to
explain my reasoning rather than just stating my preference. It’s
definitely one of those things that is pretty essential to get right
™, or we’re stuck with it for ages ala coupled key/text input in SDL
1.2 :).On Thu, 24 Feb 2011 18:39:14 -0800 Sam wrote:

What are people’s expectations of SDL_SetWindowGrab(), especially as
relates to SDL_SetRelativeMouseMode()?

In SDL 1.2, grabbing the input or going fullscreen and then hiding the
mouse implied SDL_SetRelativeMouseMode(), and that resulted in bugs
and unexpected behavior.

Now that we have SDL_SetRelativeMouseMode(), do people still want to
grab the keyboard and/or constrain the mouse? Do you want separate
functions to control those?

I’ve definitely run into issues where going full screen then hiding
the mouse really messed up expected behavior for a touch-screen driven
application. This actually explains a problem I was having for months
and only solved by creating a transparent cursor.

I’m all for separate functions for increased clarity and bug reduction.

JohnOn Thu, Feb 24, 2011 at 8:39 PM, Sam Lantinga wrote:

What are people’s expectations of SDL_SetWindowGrab(), especially as
relates to SDL_SetRelativeMouseMode()?

In SDL 1.2, grabbing the input or going fullscreen and then hiding the
mouse implied SDL_SetRelativeMouseMode(), and that resulted in bugs
and unexpected behavior.

Now that we have SDL_SetRelativeMouseMode(), do people still want to
grab the keyboard and/or constrain the mouse? ?Do you want separate
functions to control those?

Thanks!

? ? -Sam Lantinga, Founder and CEO, Galaxy Gameworks


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org