Weird sf::Sprite movement

[ResidentBiscuit]

I've been messing around with the input on SFML, and ran into this weird bug. Not sure what's going on. I have an idea, but not sure how to deal with it, and if it even makes. Anyway, what's going on is I have the arrow keys set to move a sprite around. Works fine, but when I start moving the mouse at the same time the sprite moves 2 to 3 times faster. Here's the problem code:

/** Input handling **/
            //Input object for real time input handling
            const sf::Input& input = App.GetInput();
            //Arrow key input for movement
            float speed = 5.f;
            if(input.IsKeyDown(sf::Key::Up))
            {
                background.Move(0, -speed);
            }
            if(input.IsKeyDown(sf::Key::Down))
            {
                background.Move(0, speed);
            }
            if(input.IsKeyDown(sf::Key::Left))
            {
                background.Move(-speed, 0);
            }
            if(input.IsKeyDown(sf::Key::Right))
            {
                background.Move(speed, 0);
            }

This is all in a while(App.GetEvent(event)) loop, which as writing this I realized this may be causing the problem, though I'm not 100% sure why.

EDIT: Forgot to mention it's also in while (App.IsOpened()). I'm gonna try moving this code out of event loop, since I'm using the Input object here anyway.

[ResidentBiscuit]

Ok ok, so moving this code out of the event object loop, into the main loop, it works fine. Though, moving by the same amount moves the sprite much faster. It's the speed I expected before, but it's weird that it moves at different speeds in different loops. I have a feeling it's because the Event loop is just waiting for the app to get an event, which is likely the mouseMove event. But then it doesn't make sense as to why the sprite moved at all.

[Disch]

This is all in a while(App.GetEvent(event)) loop, which as writing this I realized this may be causing the problem, though I'm not 100% sure why.

Yes, that is the problem.

App.GetEvent waits for an event (ie, your program does not get CPU time until there is an event).

If you are holding a key, the OS sends steady keydown events at an even rate. For purposes of this example, let's say 10x per second. If 'speed==1', this means your screen will scroll at 10 pixels per second.

When you move the mouse, that generates more events (mousemove events). So now you have more events coming in per second, which means the above code is going to run more times per second, which means your screen is going to scroll faster.


EDIT: actually GetEvent does not work how I described (got it mixed up with another function), but my post remains mostly true. You were moving the sprite once per event before. So more events = more movement.

[ResidentBiscuit]

That's kind of what I was thinking was going on. So, what you would recommend here? Just abandoning the whole App.GetEvent() loop and using a sf::Input object instead? I definitely don't want to have both, because then my input is split up into two awkward places.

EDIT:
Er I wasn't thinking about everything. I still need a sf::Event object for handling things other than input, dur.

[ModShop]

Moving the mouse generates MouseMoved events, lots of them. This would cause the number of iterations in your event loop to increase, a lot, thus causing the keyboard input to be processed several times more per frame than it was meant to.

EDIT: Major ninjad :/ Just move your keyboard input outside of the normal event loop, and use the normal event loop fir things like window events.

[naraku9333]

@ResidentBiscuit
Off topic but you might want to consider switching to SFML2 before getting used to the 1.6 API.

[ResidentBiscuit]

@naraku,

Yea yea that's what I keep hearing. I was originally delaying it because I heard something about all the functions follow different styles (ie not all capitalized first letters). But, as I don't have a great deal of code the change probably won't be that terrible right now.

I assume the names of the files are all the same?

[ResidentBiscuit]

Aw sf::Input is gone :( I was just becoming friends with that.

[gelatine]

use speed*App.GetFrameTime()
and your problems are solved