SFML community forums

General => Feature requests => Topic started by: l0calh05t on November 26, 2009, 07:37:10 pm

Title: Mouse capture/grab
Post by: l0calh05t on November 26, 2009, 07:37:10 pm
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.
Title: Mouse capture/grab
Post by: panithadrum on November 26, 2009, 07:43:11 pm
Reseting mouse position on MouseMove event doesn't work for this?
Title: Mouse capture/grab
Post by: l0calh05t on November 26, 2009, 07:44:16 pm
Quote from: "panithadrum"
Reseting mouse position on MouseMove event doesn't work for this?


Quote from: "l0calh05t"
Resetting the cursor to the window center is not only a hack, but also fails if the mouse moves too quickly.
Title: Mouse capture/grab
Post by: Laurent on November 26, 2009, 07:48:09 pm
What happens in grab mode when the cursor reaches the border of the window?
Title: Mouse capture/grab
Post by: l0calh05t on November 26, 2009, 08:08:23 pm
In most programs which implement cursor grabbing, the cursor is locked to the client area.
Title: Mouse capture/grab
Post by: Laurent on November 26, 2009, 08:36:28 pm
So how can you continue to move whatever is linked to the mouse, when the cursor is stuck on the border?
Title: Mouse capture/grab
Post by: l0calh05t on November 27, 2009, 08:35:57 am
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)
Title: Mouse capture/grab
Post by: Laurent on November 27, 2009, 08:41:32 am
Quote
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?
Title: Mouse capture/grab
Post by: l0calh05t on November 27, 2009, 08:55:24 am
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.
Title: Mouse capture/grab
Post by: Laurent on November 27, 2009, 09:01:03 am
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.
Title: Mouse capture/grab
Post by: l0calh05t on November 27, 2009, 09:12:39 am
Quote from: "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.


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
Title: Mouse capture/grab
Post by: Laurent on November 27, 2009, 09:18:14 am
I understand. Like I said, I'll see if I can come up with a clean and efficient solution.
Title: Mouse capture/grab
Post by: l0calh05t on July 08, 2010, 12:09:04 am
There is a clean solution on Windows:

http://msdn.microsoft.com/en-us/library/ms648383%28VS.85%29.aspx
Title: Mouse capture/grab
Post by: Krosan on July 08, 2010, 08:20:44 am
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/
Title: Mouse capture/grab
Post by: Tronic on August 13, 2010, 03:04:01 am
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.
Title: Mouse capture/grab
Post by: Tarindel on September 19, 2010, 09:09:00 am
I'd like to see this feature as well.  It'd be useful for writing windowed games where the mouse is used to look around the scene.
Title: Mouse capture/grab
Post by: apoc on October 26, 2010, 08:29:05 pm
So is there really no grab input (like SDL_WM_GrabInput in SDL) for SFML? I'm currently trying to implement mouse look but looks like its impossible in window mode?!

Update!
The mouse look is working now, currently I'm using the workaround described by l0calh05t. But it would be really great if SFML is implementing a cross-platform input grabbing feature like SDL does with SDL_WM_GrabInput (http://sdl.beuc.net/sdl.wiki/SDL_WM_GrabInput). Here is for instance the X11 implementation using XGrabPointer (http://tronche.com/gui/x/xlib/input/XGrabPointer.html): X11_GrabInputNoLock (http://bit.ly/bh1zEy)
Title: Mouse capture/grab
Post by: Crank1d on December 14, 2010, 04:04:24 pm
I was also dissapointed when i found that SFML doesnt support this feature, especially because of OpenGL... (first person camera)
Will this feature be implemented in next SFML version?  :?:
Title: Mouse capture/grab
Post by: Zweistein on January 06, 2011, 03:17:32 am
Another Request from me, pls :)
Title: Mouse capture/grab
Post by: jmp on January 06, 2011, 02:36:44 pm
I would also like to see this feature.  It's pretty much essential for any program that implements mouse look.
Title: Mouse capture/grab
Post by: Zweistein on January 06, 2011, 02:51:34 pm
Can anybody post a workaround until we get it?
Title: Mouse capture/grab
Post by: Walker on January 06, 2011, 03:03:45 pm
Quote from: "Zweistein"
Can anybody post a workaround until we get it?


Code: [Select]

window.SetCursorPosition(halfScreenWidth, halfScreenHeight);
Title: Mouse capture/grab
Post by: jmp on January 06, 2011, 03:27:40 pm
Quote from: "Walker"
window.SetCursorPosition(halfScreenWidth, halfScreenHeight);

Unfortunately that isn't sufficient because the user can still move the mouse outside the window. What's even worse, if the user clicks when the mouse is outside the window, the SFML window loses focus.

Quote from: "Zweistein"
Can anybody post a workaround until we get it?

SFML 2* and Windows only:

Get the HWND of the SFML window with sf::Window::GetSystemHandle (http://www.sfml-dev.org/documentation/2.0/classsf_1_1Window.htm#abb22a285fe50ad45d61cc149240de5d3).
Get the window area coordinates to a RECT with GetClientRect (http://msdn.microsoft.com/en-us/library/ms633503%28v=vs.85%29.aspx).
Translate the window coordinates to screen coordinates with ClientToScreen (http://msdn.microsoft.com/en-us/library/dd183434%28v=vs.85%29.aspx).
Supply those coordinates to ClipCursor (http://msdn.microsoft.com/en-us/library/ms648383%28VS.85%29.aspx). That limits the the mouse movement to the window area.

For sample code (and how to do it on X11 / OSX), you could check how SDL does it (http://hg.libsdl.org/SDL/file/tip/src/video/win32/SDL_win32window.c#l138).

To ungrab mouse, just call ClipCursor(NULL).

*SFML 1.x has no sf::Window::GetSystemHandle, so you would need to get the HWND some other way.
Title: Mouse capture/grab
Post by: Walker on January 06, 2011, 11:21:40 pm
Quote from: "jmp"

Unfortunately that isn't sufficient because the user can still move the mouse outside the window. What's even worse, if the user clicks when the mouse is outside the window, the SFML window loses focus.


Oh I see. I guess at lower framerates this becomes more and more of a problem as well. In my programs (and my hardware) I've never been able to "escape", even with my stupid-fast mouse settings but I see the problem. I will probably try to implement your method now :).

You could always make your game fullscreen :D
Title: Mouse capture/grab
Post by: Zweistein on January 10, 2011, 05:43:03 pm
i am going to wait until its implemented :) As long as its implemented before 20th February :)

lg
Title: Mouse capture/grab
Post by: Wiz on March 13, 2011, 05:17:43 pm
I need this feature for X11, so I tried calling XGrabPointer but my sfml window now receives no more mouse event, whatever I put as owner_events and event_mask.
Does anyone managed to make it work ?
And are there any news on some implementation of this ?
Title: Mouse capture/grab
Post by: cmc5788 on March 29, 2011, 02:09:06 am
EDIT:

So, I solved the problem this post was originally about.

If anyone else is having trouble getting mouse look to work with SFML and OpenGL, I'd be willing to upload my code, which handles restricting the mouse to the window and translating the mouse X and Y velocities into mouse look.  Also it seems to function properly with alt-tab and minimizing, which was hell to figure out.  Just let me know if anyone is interested.
Title: Mouse capture/grab
Post by: Tank on March 29, 2011, 08:30:21 am
Would be nice if you could add that to the wiki.
Title: Mouse capture/grab
Post by: cmc5788 on March 29, 2011, 07:18:12 pm
Quote from: "Tank"
Would be nice if you could add that to the wiki.


I will once I clean it up.  Unfortunately, I had to resort to some Windows-specific functions to make sure that the program played nice with alt-tabbing.

It would really be nice if SFML exposed some of the functionality to check on more nuanced window states.  I discovered that windows has a "minimized but active" state that sends a FocusGained event, but keeps the window minimized.  I had to manually check for that specific window state to make sure that my mouselook code didn't try to hijack the mouse cursor when this happened.

Specifically, I'm referring to this GetWindowPlacement function (http://msdn.microsoft.com/en-us/library/ms633518%28VS.85%29.aspx).  It would be really nice if SFML had a wrapper around this.
Title: Mouse capture/grab
Post by: Tank on March 29, 2011, 08:08:58 pm
Quote
It would be really nice if SFML had a wrapper around this.

+1
Title: Mouse capture/grab
Post by: cmc5788 on March 30, 2011, 08:32:59 pm
One more note on this topic:

Input's GetMouseX() and GetMouseY() functiosn are not accurate/quick enough to support the "snap to center screen every frame" method of mouselook.

I was wonder why my mouselook code was degenerating at lower FPS, and replacing these with Windows-specific code completely fixed the problem.  Not sure why this is, but in case anyone else is having trouble, you should definitely use platform-specific code for something as time-sensitive as getting and setting the mouse cursor location every frame.
Title: Mouse capture/grab
Post by: Tank on March 31, 2011, 01:25:31 am
Well SFML does also use platform-specific code. :) The question is where's the difference? Maybe SFML can be enhanced in this case.
Title: Mouse capture/grab
Post by: cmc5788 on March 31, 2011, 01:30:13 am
Quote from: "Tank"
Well SFML does also use platform-specific code. :) The question is where's the difference? Maybe SFML can be enhanced in this case.


I'm not sure where the difference is, I haven't had a good look at SFML's code.  I can just tell you for sure that there's significant lag in reporting between Input::GetMouseX() and the Windows-specific GetCursorPos (http://msdn.microsoft.com/en-us/library/ms648390%28v=vs.85%29.aspx) (or perhaps the difference is between the cursor-position setting functions).

edit: --------

Having now looked at the SFML code a little bit, I can surmise that the lag has to do with Input::myMouseX and myMouseY only being updated on MouseMove events.  The Windows-specific equivalent immediately queries the mouse state as tracked by the operating system, and is likely independent of the event system.
Title: Mouse capture/grab
Post by: Tank on March 31, 2011, 01:41:26 am
SFML uses its own event queue (sf::Event::MouseMoved), and those events are generated through Windows messages (WM_MOUSEMOVE). This might produce a delay.

A solution would be sf::Input's mouse methods using GetCursorPos() on Windows, instead. This needs modifications in the sf::Window implementations for the various platforms, I guess. Laurent has surely more details on this.
Title: Mouse capture/grab
Post by: cmc5788 on March 31, 2011, 01:43:41 am
Just missed my edit, I reached the same conclusion.  I suppose it would be good if SFML had support for immediate querying via something like

Code: [Select]

POINT cursor_pos;
HWND sys_handle = window.GetSystemHandle();
GetCursorPos(&cursor_pos);
ScreenToClient(sys_handle, &cursor_pos);


which is what I used in my code to fix the delay.

e:  when I get a little farther on my project I'll compile the workarounds I've had to use into a separate feature request thread.
Title: Mouse capture/grab
Post by: Laurent on March 31, 2011, 07:47:56 am
Using OS functions to get the real-time mouse/keyboard state is not a good option. While it should be ok for mouse, for keyboard it doesn't take focus in account (ie. you can read the keyboard state from any window that doesn't have the focus, even hidden/minimized ones) so it may lead to strange behaviours.

But this could also solve problems (key released while out of the window are not notified to sf::Input, for example), so if we can find a satisfying design/implementation for this thing I'm open to discussion :)
Title: Mouse capture/grab
Post by: cmc5788 on March 31, 2011, 09:15:38 am
What's wrong with just implementing it for mouse?  With keyboard response I don't see it being an issue.  Or just keep the current system in-place but also implement an alternative "GetImmediate__" series of functions to clarify the difference.

Just bear in mind that supporting mouse look is fairly important for anything that can be used as an OpenGL context.
Title: Mouse capture/grab
Post by: Laurent on March 31, 2011, 09:28:14 am
Quote
What's wrong with just implementing it for mouse?

Inconsistent design.
And it works only for mouse position, everything else (mouse buttons, keyboard, joysticks, ...) would produce the kind of problems that I described in my previous posts.

Quote
Or just keep the current system in-place but also implement an alternative "GetImmediate__" series of functions to clarify the difference.

There's no point providing two different ways of doing the same thing. If I change this I'd rather end up with only one clean and efficient solution.

Quote
Just bear in mind that supporting mouse look is fairly important for anything that can be used as an OpenGL context.

That's right. I need to think more about this issue; providing mouse grab features would also be a solution.
Title: Mouse capture/grab
Post by: cmc5788 on March 31, 2011, 02:54:40 pm
Quote from: "Laurent"
Quote
What's wrong with just implementing it for mouse?

Inconsistent design.
And it works only for mouse position, everything else (mouse buttons, keyboard, joysticks, ...) would produce the kind of problems that I described in my previous posts.


I understand that the design would be slightly inconsistent, but I think that having an "elegantly designed" function that returns values other than those expected is orders of magnitude worse than having a single function whose design is inconsistent from others of the type for reasons of usability.

Anecdotally, I spent a solid off-day of programming time trying to figure out why my mouse look was degrading precisely because "GetMouseX" sounds as though it should return, with as much precision as possible, the X value of the mouse.  As a client of the library, my application expects the function to work as-advertised, not to be consistent with its own internal state.  One major benefit of separating interface from implementation is that, as a user, I shouldn't CARE about inconsistent implementation so long as results are consistent with expectations.  In that way, I would make the argument that changing it is more elegant design.

As far as I can tell, -only- mouse coordinates would need to be changed in this way since they tend to be used for very time-sensitive tasks, none of the other variables that would produce problems would need to even be touched.

Quote
Quote
Just bear in mind that supporting mouse look is fairly important for anything that can be used as an OpenGL context.

That's right. I need to think more about this issue; providing mouse grab features would also be a solution.


Actually that isn't a solution, that's only part of the solution.  Mouse grab only confines the cursor to the window area; you still need a way of resetting the cursor every-so-often so that it doesn't wind up sticking to the borders.  The most-common way of doing this involves resetting it every frame to the center of the screen.  Mouse grab simply ensures that at low FPS your cursor won't "flicker" off-screen before it's reset.  You still need to ensure that it's reset to center (or some other location sufficiently far from the window borders) so that mouselook works properly.

If you were to provide mouse grab for mouse look support, you would also need to include an an abstracted way of returning an accurate mouse velocity per-frame.  If you can think of a good way to do this without resorting to cursor reset, then you're better than me.  (I also tried "wrapping" the mouse from the right border back around to the left, and top to bottom, etc., but that introduces its own set of problems)

edit:  Sorry for the mild rant, and thank you for your responses ;)
Title: Mouse capture/grab
Post by: Laurent on March 31, 2011, 03:23:52 pm
Quote
I understand that the design would be slightly inconsistent, but I think that having an "elegantly designed" function that returns values other than those expected is orders of magnitude worse than having a single function whose design is inconsistent from others of the type for reasons of usability.

I was not comparing it to the current code. I just said that as a user, seeing an API with two functions that do the same thing is not consistent/elegant/whatever.

So I didn't mean to keep the current function unchanged, but rather than fixing it with something that I don't like, I prefer trying to find a solution which is globally better (even if it means redesigning half of the window module).

I think the first thing to do is to examinate this "lag" problem before throwing away the whole event-based implementation; just to be sure, you know ;)

Would be very cool if you could provide a minimal code that shows the problem (with low FPS simulated) so that I can test it myself and use it as a starting point for improving mouse handling.
Title: Mouse capture/grab
Post by: cmc5788 on March 31, 2011, 03:38:29 pm
Quote from: "Laurent"
Quote
I understand that the design would be slightly inconsistent, but I think that having an "elegantly designed" function that returns values other than those expected is orders of magnitude worse than having a single function whose design is inconsistent from others of the type for reasons of usability.

I was not comparing it to the current code. I just said that as a user, seeing an API with two functions that do the same thing is not consistent/elegant/whatever.

So I didn't mean to keep the current function unchanged, but rather than fixing it with something that I don't like, I prefer trying to find a solution which is globally better (even if it means redesigning half of the window module).

I think the first thing to do is to examinate this "lag" problem before throwing away the whole event-based implementation; just to be sure, you know ;)

Would be very cool if you could provide a minimal code that shows the problem (with low FPS simulated) so that I can test it myself and use it as a starting point for improving mouse handling.


I can do that very easily, I'll just set a #define in my current code to toggle between SFML GetMouseX/Y and the Windows code.  I'll post it soon.
Title: Mouse capture/grab
Post by: Tank on March 31, 2011, 09:23:03 pm
Quote from: "cmc5788"
I can do that very easily, I'll just set a #define in my current code to toggle between SFML GetMouseX/Y and the Windows code

Sorry for being off-topic, but that is just hilarious. :D What it's called, "ENABLE_BUG"? ;)
Title: Mouse capture/grab
Post by: cmc5788 on March 31, 2011, 09:34:25 pm
Quote from: "Tank"
Quote from: "cmc5788"
I can do that very easily, I'll just set a #define in my current code to toggle between SFML GetMouseX/Y and the Windows code

Sorry for being off-topic, but that is just hilarious. :D What it's called, "ENABLE_BUG"? ;)


Now that you mentioned it, I think I -will- call it that.
Title: Mouse capture/grab
Post by: cmc5788 on April 01, 2011, 07:07:47 pm
Well, as embarrassing as this is, it looks like I jumped the gun a bit on blaming SFML.  I rewrote my code in simplified form to submit, and the bug disappeared.  I don't know what was causing it, and I'm not sure if I'll ever find out.

By way of apology, I'll submit a nice tutorial on implementing smoothed mouse look using the weighted mean of velocities to the wiki.

P.S. -- we still want cursor grabbing ;)
Title: Mouse capture/grab
Post by: Laurent on April 01, 2011, 07:32:15 pm
Hehe :)

Quote
By way of apology, I'll submit a nice tutorial on implementing smoothed mouse look using the weighted mean of velocities to the wiki.

That's a very good idea, thanks.
Title: Mouse capture/grab
Post by: kattle87 on April 02, 2011, 01:00:02 pm
What we could do is having the "mouse deltas" as a readly-available feature, giving the user float values calculated by sfml using velocity or position means. This way, one would have not to do anything but calling a function for getting "precise" and not-stuttering movements :P
Title: Mouse capture/grab
Post by: cmc5788 on April 02, 2011, 08:09:30 pm
Quote from: "kattle87"
What we could do is having the "mouse deltas" as a readly-available feature, giving the user float values calculated by sfml using velocity or position means. This way, one would have not to do anything but calling a function for getting "precise" and not-stuttering movements :P


This would simplify things a little bit.  However, for real mouse look you'll still need to reset the cursor every frame to make sure that it doesn't leave the window or get stuck on its edges.  You can't have any deltas if your mouse isn't moving ;)
Title: Mouse capture/grab
Post by: Groogy on May 15, 2011, 05:28:13 pm
Don't mean to resurrect a dead topic but what is the verdict on this? Will you implement some way to get the mouse movement delta instead of getting the position? I know using DirectInput(I know outdated but it works) you get the actual movement of the mouse and not the position of the mouse. So even if the mouse get's stuck on an edge it will still give us the movement of the mouse. I think this is the hardware movement of the actual mouse.

The whole thing with "Moving the mouse back to the center" doesn't work for me as when I do that a new message is sent by windows with the new position and the relative value calculated will be the inverse of what I've just moved. If I don't reset the mouse cursor everything works as intended. Except that the mouse get's stuck on the edge.

NOTE: I've managed to get it to work though in a very awkward way.
Title: Mouse capture/grab
Post by: Wiz on August 02, 2011, 04:19:18 pm
There clearly is a need for real mouse input, with no clamp to borders hack.
DirectInput on Windows would be the perfect solution and on Linux there is evdev. That's what evQuake uses (http://ezquake.sourceforge.net/docs/?vars-input---mouse#in_mouse).
Title: Mouse capture/grab
Post by: Laurent on August 02, 2011, 04:37:51 pm
Yes, raw input looks like an important feature (not only for mouse, for keyboard too).
Title: Re: Mouse capture/grab
Post by: Tuffywub on March 26, 2013, 06:43:38 am
I know this is an old topic, but I was wondering if implementing cursor grabbing was still on the todo list. I love SFML, it's an awesome library, but I think that having a good and easy way of trapping the cursor and getting relative input would be great.
I know you can do it by moving the mouse to the center of the window on move events, and then ignoring events where the mouse is moved to the center. But it would be much nicer if the library had a way of doing that for you with window.relativeCursorMode(true) or something.
Sorry again for reviving an ancient topic, but this is a very important feature, especially for fps/3D games. Thanks.
Title: Re: Mouse capture/grab
Post by: Laurent on March 26, 2013, 07:41:40 am
If it's in the task tracker, then don't worry it will be implemented one day. If it's not, then feel free to add a task containing all the important points that were discussed here.
Title: Re: Mouse capture/grab
Post by: Robert42 on May 21, 2013, 09:14:48 pm
If it's in the task tracker, then don't worry it will be implemented one day. If it's not, then feel free to add a task containing all the important points that were discussed here.

I couldn't find a ticket for mouse capturing/grabbing, so I created one: https://github.com/SFML/SFML/issues/394

Edit: I also created a second ticket for the raw mouse movement: https://github.com/SFML/SFML/issues/395

Edit 2: Closed issue #395 because it was a duplicate to https://github.com/SFML/SFML/issues/304
Title: Re: Mouse capture/grab
Post by: Robert42 on June 04, 2013, 06:51:25 pm
A small update:

MarioLiebisch has created a pull request (https://github.com/SFML/SFML/pull/396) and has implemented the cursor capturing for Windwos and X11.

However, Mac Support still has to be implemented.
Title: Re: Mouse capture/grab
Post by: jeremy on November 20, 2013, 10:51:28 am
I noticed the implementation uses a number of X methods to grab and ungrab the input.

Why doesn't SFML use evdev to capture input to give users more flexibility with this sort of thing? This is how SDL implements it so it can capture the pointer in addition to providing raw mouse input to the developer.
Title: Re: Mouse capture/grab
Post by: Mario on November 24, 2013, 09:11:50 pm
Feel free to rewrite/extend and use the existing code as a base. :) To be honest, my platform dependent knowledge for Unix is almost zero, so I just built on whatever has been there already. Although my patch will need some reworking anyway, considering there have been other patches for this part of the code fixing other things.
Title: Re: Mouse capture/grab
Post by: jeremy on November 28, 2013, 08:59:21 am
Hey Mario,

Thanks a million for the initial patch. I'd really like to get this in.

Basically, I think the initial approach is not a bad one and I think my suggestion is not strictly necessary. I was just considering a possible overhaul of the input system later on to be a bit lower level so the user has more control if desired. Looking into it recently, I think it'd be a significant change so it's worth discussing before any implementation is done.
Title: Re: Mouse capture/grab
Post by: CouteauBleu on January 20, 2018, 05:36:01 pm
It's been a while since this topic has been posted (I think this topic was created prior to the SFML 2 update)... what happened to this feature?

I can't find it in the documentation. Is cursor grabbing no longer maintained?

I can't find window.SetCursorPosition either. EDIT: Nevermind, I think it's in sf::Mouse now.
Title: Re: Mouse capture/grab
Post by: eXpl0it3r on January 20, 2018, 06:45:16 pm
This feature has been implemented.

https://www.sfml-dev.org/documentation/2.4.2/classsf_1_1Window.php#a5b4ef8ede77531e17b7a0287fa6ff9ce
Title: Re: Mouse capture/grab
Post by: CouteauBleu on January 20, 2018, 06:59:53 pm
Oh, I was browsing an outdated documentation. Whoopsie :(

I don't have any excuse, there's even a red "this page refers to an old version of SFML" disclaimer (maybe a little small).

Thanks for the help!
Title: Re: Mouse capture/grab
Post by: eXpl0it3r on January 20, 2018, 09:48:33 pm
No worries, happens sometimes. ;)