Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: [Solved] Mouse input is slower than other types of movement  (Read 1202 times)

0 Members and 1 Guest are viewing this topic.


  • Newbie
  • *
  • Posts: 3
    • View Profile
[Solved] Mouse input is slower than other types of movement
« on: August 30, 2013, 04:21:57 am »

I'm trying to implement mouse movement into my game, but the problem I've been running into is that mouse movement is much slower than movement with other input methods (keyboard and joystick). What I'm doing is checking to see if the mouse moved from the center of the window and then moving the sprite and re-positioning the mouse in the center of the window. I have added the relevant code below.

Thanks for your time and any help you provide in advance! Please let me know if you would like more information.

const sf::Vector2i WINDOW_CENTER(window.getSize().x / 2, window.getSize().y / 2);
sf::Mouse::setPosition(WINDOW_CENTER, window);

if (the joystick moved left || the left key was pressed ||
    sf::Mouse::getPosition(window).x < WINDOW_CENTER.x)
    sf::Mouse::setPosition(WINDOW_CENTER, window);
if (the joystick moved right || the right key was pressed ||
    sf::Mouse::getPosition(window).x > WINDOW_CENTER.x)
    sf::Mouse::setPosition(WINDOW_CENTER, window);

I'm using SFML 2.1 with Visual Studio 2012.
« Last Edit: September 04, 2013, 03:41:46 am by andrasveto »


  • Hero Member
  • *****
  • Posts: 1241
    • View Profile
    • Email
Re: Mouse input is slower than other types of movement
« Reply #1 on: August 30, 2013, 04:33:22 am »
I'm not sure that's a good way to implement mouse movement because there's no real way to "hold" the mouse to the left, whereas you can easily hold down the left key or hold a joystick to the left.

Try not resetting the mouse position and instead simply let it be "held" to the left or right of center and see if you like that behavior better.

If you don't like that, consider using the mouse moved events instead of real time input.

If neither of those help, we'll probably need more complete code (ie, something we can compile ourselves), and a far more precise description of the behavior you're seeing and the behavior you would like to see instead.

In general you probably shouldn't be surprised if you need different code to get different kinds of input devices to work exactly the way you'd like them to.