SFML community forums
General => Feature requests => Topic started by: mateandmetal on April 30, 2012, 12:35:19 am
-
Hi
I would like to propose something. Moving the setKeyRepeatEnabled from sf::Window to sf::Keyboard, and sf::Window::setJoystickThreshold to sf::Joystick.... Since all belongs to the same module (Window), it may not be so difficult.
I´m writing my input manager class, and i need a renderwindow just to set this two options. Does this two functions really need a renderwindow? ???
-
setKeyRepeatEnabled will only impact KeyPressed and KeyReleased events, and it's the same for setJoystickThreshold and JoystickMoved events. So yes, they truly are attributes of the window itself.
If you're creating a window just to call them then you might be doing something really wrong, because they will have effect only on this window.
-
Ah, ok
I´m only using the realtime sf::Keyboard, sf::Mouse and sf::Joystick, so.. I dont need that event functions.
Thanks Laurent
Btw... The mouse wheel.. why can´t be read at realtime using sf::Mouse?
-
Btw... The mouse wheel.. why can´t be read at realtime using sf::Mouse?
because it's not like a joystick, a mouse wheel doesn't have a "middle/neutral/whatever" position. it's button-like.
-
because it's not like a joystick, a mouse wheel doesn't have a "middle/neutral/whatever" position. it's button-like.
Huh? This now doesn't really make sense, does it?
If it's button like why shouldn't it be accessable at realtime? I mean you can check for key strokes and mouse button clicks.
But I don't see how you'd implement a non event process nicely. If you would provide it with sf::Mouse you somehow would need to return a direction vector and the current spinning speed or something like this, otherwise it would be kind of hard to determin the state.
-
The mouse wheel, in all platform-specific implementations, have no state. It only gives you modifications of the state, exactly like when you move mouse in a relative space. Interpretation is always application-dependent.
-
Ok. Thanks!