Yes as Danny Toledo says you have to move it a little bit every frame.
This isn't an SFML problem as much as it's a game logic flow problem. Typical game loops look something like this:
1 2 3 4 5 6 7 8
while(game_is_running)
{
processEvents();
updateLogic();
drawScene();
waitForNextFrame(); // note: if you use SFML's frame limiter function to set
// the FPS, this is done automatically for you.
}
To move an "object" (such as a player graphic, or an enemy, or something)... you typically assign it a position, and a velocity.
Every logic update... you would add the velocity to the position.
Every draw... you would draw the object at its new position.
What about the move function already provided by SFML? I wouldn't' use setPosition for actual movement lol.
Take in mind what Disch says about the frame problem though. It DOES matter. It's especially noticeable if there are physics in your game. Different computers will have different frames per second. If you don't account for this then on some computers your game will literally run faster, and literally run slower on others. Any game worth it's salt will move objects at the same speed, regardless of FPS.
I wouldn't' use setPosition for actual movement lol
I do.
I keep track of position/velocity etc separately anyway for things like physics/collision detection/etc... so I just compute the final position in my code then pass it to SFML directly in the form of a single setPosition call.
I keep track of position/velocity etc separately anyway for things like physics/collision detection/etc... so I just compute the final position in my code then pass it to SFML directly in the form of a single setPosition call.
Eh, in reality the only difference between move() and setPosition() is that move handles offsets for you I would guess. I've never had much trouble with just using move() but I can see where you're coming from.
move() would be convenient when you only deal with offsets, but Disch always deals with absolute values so move() is a hindrance. Of course, if you dealt with relative values instead of absolute values, then I'd think move() would be useful. And yes, through some kind of weird luck, I've managed to somehow someway get move() to line up four times in a row. No line breaks, just normal text wrapping.