Mouse capture/grab

[l0calh05t]

I thought this would have been discussed before, but didn't find anything. A proper mouse capture/input grab mode would be very helpful. Resetting the cursor to the window center is not only a hack, but also fails if the mouse moves too quickly.

[panithadrum]

Reseting mouse position on MouseMove event doesn't work for this?

[l0calh05t]

Reseting mouse position on MouseMove event doesn't work for this?

Resetting the cursor to the window center is not only a hack, but also fails if the mouse moves too quickly.

[Laurent]

What happens in grab mode when the cursor reaches the border of the window?

[l0calh05t]

In most programs which implement cursor grabbing, the cursor is locked to the client area.

[Laurent]

So how can you continue to move whatever is linked to the mouse, when the cursor is stuck on the border?

[l0calh05t]

ah, sorry I think there is a small misunderstanding here, input capture in win32 means catching all input, even that for other windows, in that case the mouse would just continue and we would get mouse messages with values outside the client area (therefore with x/y negative or or large position values). this can be useful for things like drag&drop etc. useful but not what i meant ;-)

i'm rather thinking about the behavior in many games where you cannot move the mouse outside the window, for example in an fps. or whenever else we don't use the mouse to point at anything. (vm's often do this as well)

[Laurent]

i'm rather thinking about the behavior in many games where you cannot move the mouse outside the window, for example in an fps. or whenever else we don't use the mouse to point at anything. (vm's often do this as well)

My question still applies: what happens when the mouse reaches the border of the window? In a FPS you would be stuck rotating the player, isn't it?

[l0calh05t]

Ah, no, the way I meant it (and GLFW does it when the mouse is hidden/locked) the actual hardware cursor does not move at all so we are basically working on mouse position deltas.

As far as I can tell from a cursory glance at the GLFW sources, it also only resets the cursor to the window center, but it does it internally and apparently that is enough to stop the cursor from leaving the window.

EDIT: But locking the cursor to the client area would also work for me, in that case we can just do the reset to center ourselves, which would merely result in a clamping of the rotation speed in the fps example.

[Laurent]

So we're back to the good old "hack", finally.

I'll take a look at GLFW and see how they manage to keep the cursor inside the window. Maybe they use mouse capture (like in Win32) so that the mouse move events are still received if the cursors leaves the window due to a quick move.

[l0calh05t]

So we're back to the good old "hack", finally.

I'll take a look at GLFW and see how they manage to keep the cursor inside the window. Maybe they use mouse capture (like in Win32) so that the mouse move events are still received if the cursors leaves the window due to a quick move.

It's a hack if we (as a user) do it externally, because this is not fast enough and doesn't work.

I also added this

Code: [Select]

case sf::Event::MouseLeft:
if(cursorLocked)
window->SetCursorPosition(window->GetWidth()/2,window->GetHeight()/2);
break;

to my code, but the mouse cursor is still visible outside the window for a moment, but at least it isn't lost

[Laurent]

I understand. Like I said, I'll see if I can come up with a clean and efficient solution.

[l0calh05t]

There is a clean solution on Windows:

http://msdn.microsoft.com/en-us/library/ms648383%28VS.85%29.aspx

[Krosan]

The input system OIS is able do do that on windows and linux, maybe you can get there informations

here the sourceforge:
http://sourceforge.net/projects/wgois/

[Tronic]

It would be optimal if raw mouse movements could be read, avoiding the concept of screen pixels, desktop acceleration/speed adjustment and other cruft entirely, but unfortunately I don't think this is very practical on Windows nor Linux. On Linux you could read the input event device directly, but that requires root access

Even so, it would be very good if SFML offered an API for this kind of mouse control and then internally implemented the best known solution for each platform. The current way of application programmers having to hack something together is the worst solution.

In such an API, the user wants to know how much the mouse has moved since the last read, without having to wonder about window center coordinates or other such things. This should also always hide the cursor.