New global inputs in SFML 2

[Laurent]

Hi

I've totally broken the sf::Input class. It has disappeared and is replaced with three new static classes: sf::Keyboard, sf::Joystick and sf::Mouse. These are now connected directly to the OS functions, and thus are no longer connected to a particular window.

The consequence is that there's no more bug related to focus, etc.

I've added a few features to joysticks: you can check their connection state, via sf::Joystick::IsConnected or the new JoystickConnected / JoystickDisconnected events.

I've also renamed/reorganized a few things.

I've implemented sf::Window::GetCursorPosition.

Special note on sf::Mouse::GetPosition: to be useful, it doesn't return the position in desktop coordinates, but rather in coordinates relative to the current focus window (the one which has the mouse cursor over it).

The OS X implementation is not done yet, but it will be updated by Hiura as soon as he can.

The C, .Net bindings and the online doc are up-to-date.

Have fun

[keyforge]

Awesome Laurent, thanks! Luckily I only have a few references to the input class. Any chance of getting a Mouse Released event added to the sf::Mouse class?

[OniLinkPlus]

Amazing job Laurent. It feels far more structured than before.

[Nexus]

Just now that I thought my Action system would be finished

The three classes are not directly linked to a window, so I will need to filter the correct events out (since realtime inputs are also able to trigger callbacks). Is there a way to check whether a SFML window is currently focussed? Or do you have another suggestion?

In general, the separation of sf::Input sounds like a good solution, I have to examine it in detail

[Groogy]

When I thought I could start working on GGE because rbSFML was done you come in and ruin everything for me =/

Ah well it's nice with the system and much needed but it means major remake in rbSFML and GGE... maybe shouldn't pick up more projects that depends on SFML2? :wink:

UPDATE: I would like to propose a change... It feels kind of stupid to have to pass the ID of the joystick all the time. Couldn't you wrap this inside an object better?

Code: [Select]

sf::Joystick joystick0( 0 );

[gsaurus]

Those are great news, good work Laurent  

[Laurent]

Any chance of getting a Mouse Released event added to the sf::Mouse class?

Sorry, I don't get what you mean. There is a MouseButtonReleased event, and it has nothing to do with sf::Mouse.

I would like to propose a change... It feels kind of stupid to have to pass the ID of the joystick all the time. Couldn't you wrap this inside an object better?

- it would't be consistent at all with the two other classes
- I don't like the semantics that the class would have

[Nexus]

Can we somehow find out whether a realtime input state belongs to the SFML window (especially for sf::Mouse)? I believe it is sometimes useful to check if the mouse is being clicked inside the window.

sf::Mouse::GetPosition() returns the position in two different coordinate systems, depending on whether the mouse is above a window or not? Isn't that confusing without a further option to check which coordinate system is actually used?

[Laurent]

Can we somehow find out whether a realtime input state belongs to the SFML window (especially for sf::Mouse)? I believe it is sometimes useful to check if the mouse is being clicked inside the window.

No, the purpose of these classes is to get rid of any window/event stuff. It just says what happens on the devices.
But don't forget events...

sf::Mouse::GetPosition() returns the position in two different coordinate systems, depending on whether the mouse is above a window or not?

Indeed.

Isn't that confusing without a further option to check which coordinate system is actually used?

To be honest, I don't know what to do with this function. I tried to make it useful while still being simple. But in fact people should now use Window::GetCursorPosition -- it's just that it's not symmetrical at all with sf::Keyboard, sf::Joystick and sf::Mouse::IsButtonPressed.

[Nexus]

But don't forget events...

That means, to check for mouse buttons currently held down inside a window, I have to implement a bool array for all states and adapt its elements upon each MouseButtonEvent? Basically, the work formerly done by sf::Input must now be handcrafted, is there no simpler way?

Something like sf::Window::IsFocussed() should already be enough, this might be useful in other cases, too. Or I catch the focus events and enable/disable my callbacks accordingly.

To be honest, I don't know what to do with this function. I tried to make it useful while still being simple.

I fear that the current implementation is neither useful nor simple

I don't see how sf::Mouse::GetPosition() can be meaningfully used if the caller doesn't know what coordinates he gets back and has no way to find it out. Maybe an optional bool output parameter could help. But I see that this doesn't solve the actual dilemma... :?

[gsaurus]

Well, there is this:

Code: [Select]

static const Window* GetMouseFocusWindow()
But I think a sf::Window::IsFocussed() would be better even for other situations.

Maybe to avoid confusions there should be something like:

Code: [Select]

static Vector2i GetPosition() // get position in global coordinates
static Vector2i GetPosition(const Window& window) // get position in window coordinates

[Laurent]

That means, to check for mouse buttons currently held down inside a window, I have to implement a bool array for all states and adapt its elements upon each MouseButtonEvent? Basically, the work formerly done by sf::Input must now be handcrafted, is there no simpler way?

"Button currently held down inside a window" is a flawed concept. What if the mouse leaves the window with the button still down? Or if the button is released outside the window? Or if it is pressed outside and moved over the window while still pressed? Do you say "true" or "false" in these situations?
I think people don't need more than two things: the current mouse position, and the pressed/released events. But maybe you have a use case in mind?

Something like sf::Window::IsFocussed() should already be enough, this might be useful in other cases, too. Or I catch the focus events and enable/disable my callbacks accordingly.

Don't forget that there are several definitions of focus (at least two): the keyboard focus and the mouse focus.
There's the Window::GetMouseFocusWindow() functions which is publicly available. I wanted to keep it as hidden/internal as possible, but if you feel like it may help you, you can use it

I don't see how sf::Mouse::GetPosition() can be meaningfully used if the caller doesn't know what coordinates he gets back and has no way to find it out. Maybe an optional bool output parameter could help. But I see that this doesn't solve the actual dilemma...

I think the only alternative is to completely disable this behaviour and make sf::Mouse::GetPosition() always return desktop coordinates.
Any other solution would just add more ugliness to this thing.

[Laurent]

Maybe to avoid confusions there should be something like:

Code: [Select]

static Vector2i GetPosition() // get position in global coordinates
static Vector2i GetPosition(const Window& window) // get position in window coordinates

I don't like having two different functions that do the exact same thing (Mouse::GetPosition(Window) and Window::GetCursorPosition()).
With this function I just wanted to make it simple to get proper mouse coordinates for people that use a single window (99% of use cases), instead of having something nearly useless.

By the way, I copied this behaviour from SDL 1.3... :lol:

[Nexus]

"Button currently held down inside a window" is a flawed concept. What if the mouse leaves the window with the button still down? Or if the button is released outside the window?

I would return true as long as the cursor is in the window and the button is pressed.

I think people don't need more than two things: the current mouse position, and the pressed/released events. But maybe you have a use case in mind?

Consider a shooter: As long as the left mouse button is held down, the player fires. When he clicks somewhere outside the window (for any reason), this shouldn't trigger the weapon. You can't work with events here unless you store bool flags on your own.

I think the only alternative is to completely disable this behaviour and make sf::Mouse::GetPosition() always return desktop coordinates.
Any other solution would just add more ugliness to this thing.

That's what I thought too, but then, people will always use sf::Window::GetCursorPosition() and sf::Mouse::GetPosition() is hardly ever used. And as you stated, it is not optimal with respect to the symmetry, if people still need the window to get the mouse state, but not the keyboard or joystick state.

[gsaurus]

Obviously I was assuming that the Window::GetCursorPosition() was replaced by Mouse::GetPosition(Window).
One looking for mouse coordinates would look first for the Mouse class than for the Window. It's expected that mouse stuff is obtained from the Mouse class.

When he clicks somewhere outside the window (for any reason), this shouldn't trigger the weapon.

Depends, you may want to be friendly and trigger it anyway, maybe the user clicked outside by accident and would loose the game because of that. If you want specific behavior when clicking inside/outside you should handle it yourself.
I think the actual solution for mouse state is the simplest and cleanest, I find it intuitive as well.