Acceleration-Effect with sprite-based cursor.

[Perde]

Now that I've found the time to code again, I want to solve an issue that has bugged me ever since. I don't think the code is necessary, since all I'm doing is draw a shape and make it follow the cursor, but there you go.

The problem I have is, that there is an acellerated-mouse efect present when using a sprite-based custom cursor, that gets dramatically amplified by activating vsync. The video shows what I mean. While the effect may become less obvious when hiding the cursor, it is still bothersome.
(The effect with vsync turned off, or an uncapped framerate, however the movement is much more crisp.)

The little game I've set my mind to requires precise and quick mouse input, even while the cursor is moving. This issue however opens up the possibility of registering a click on a location that differs from the one of the cursor-sprite.
Also, but that's a personal opinion, I think the whole acceleration effect is just awful, even if deliberately built in.

(It doesn't even look that bad in the video. But especially when moving in a constant motion, the sprite clearly lags behind. )

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(1280, 720), "Title");
    window.setVerticalSyncEnabled(true);
    sf::CircleShape shape(10.f);
    shape.setFillColor(sf::Color::Green);
    shape.setOrigin(10, 10);
    //window.setMouseCursorVisible(false);

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }

        shape.setPosition(static_cast<sf::Vector2f>(sf::Mouse::getPosition(window)));
        window.clear();
        window.draw(shape);
        window.display();
    }

    return 0;
}

I have considered alternatives already, like using windows-functionality like "LoadCursorFromFile()", but then I'd have to look for equivalent functions on other Platforms, or lose portability (I'd like to avoid both). Also, I'm wondering if getting the input from a different thread would help. (I have yet to try the latter, as I haven't worked with threads before)

Anyway, any input is very welcome!

[eXpl0it3r]

As far as I know, there are other ways to grab the mouse cursor, but that would need an implementation for each OS. However I'm not sure if it would "fix" the issue.

The main issues here is delayed drawing and frame rate. Just think of this: When you move your mouse, the cursor moves there immediately. Now you grab the position and draw the custom cursor to the screen. So there we have the delay, the time between the mouse moving to position X and the time the application gets the position and draws it. By increasing the frame rate the code that grabs the position and draws the custom cursor gets executed more often, thus decreasing the delay between mouse position and custom cursor position.

This issue however opens up the possibility of registering a click on a location that differs from the one of the cursor-sprite.

Is this confirmed or just reasoning? Because I doubt that there will be an issue. When you get around to check a click the mouse will be exactly at the position where the custom sprite is rendered, since you use the same exact data to position the custom cursor and to process the mouse click. The only thing that may happen, is that the system cursor is slightly somewhere else.

Not sure how to make it better though.

[Perde]

Thanks for your quick reply. I'm aware of how the issue is generated. My main concern was that the user might click while moving the mouse and get an off result.

However, while eagerly waiting for a reply, something occured to me and I quickly added a second shape that would be drawn whereever the mouse was clicked. Now, the mechanics that caused the original problem cause the second shape to appear exactly where the first one is displayed. I suppose this means that it doesn't matter at all where the actual cursor is, since the lag applies to all drawn objects, doesn't it?
So the issue really is just a hypothetical one!

That only leaves the undesired visual effect of spongy cursor movement. I fear however, that I'd have to change the system cursor directly to counter that.

[eXpl0it3r]

Now, the mechanics that caused the original problem cause the second shape to appear exactly where the first one is displayed. I suppose this means that it doesn't matter at all where the actual cursor is, since the lag applies to all drawn objects, doesn't it?
So the issue really is just a hypothetical one!

That's what I've been trying to say.

That only leaves the undesired visual effect of spongy cursor movement. I fear however, that I'd have to change the system cursor directly to counter that.

I think so, yeah.

[Perde]

That's what I've been trying to say.

Yes, of course. I was just writing down what I did in the mean-time, and the conclusion I got from it. Thinking out loud, in a way.
Your explanation was very helpful, thanks again.

[dabbertorres]

If you're worried, one thing you could do is set the position of the sprite to the mouse position as you're doing, but when checking for mouse position for other things, use the position of the sprite. It seems like it won't be a big deal, but, I know some people like to be anal about stuff.

[eXpl0it3r]

If you're worried, one thing you could do is set the position of the sprite to the mouse position as you're doing, but when checking for mouse position for other things, use the position of the sprite.

I guess you didn't read the two posts above.
The mouse and the sprite are at the exact same position, since you actually place the sprite at the position where the mouse is.

[dabbertorres]

*facepalm*

I was rushing, thought I read enough for a good enough understanding, obviously that wasn't the case.