Hi guy!

Im trying to move a sprite but its flow is good only if I move just 1 pixel per frame, but if I move more than 1, it looks bad like flicking, and moving just 1 pixel per frame is too slow. Thank you for your help!

position += velocity * deltaTime

That's about all I can give you based upon your minimal description of what you're having difficulty with (we can't read minds here).

displacement is the integral of velocity with respect to time.

and velocity is the integral of acceleration with respect to time:

v += a * dt

Combining the two, so that displacement takes into account acceleration, the second integral of acceleration should be, I think (I suck at calculus):

displacement = v * dt + (a * dt * dt) / 2

or

position += v * dt + (a * dt * dt) / 2

Of course, that is assuming constant acceleration across dt, so then you'd have to integrate that too if you really wanted to get nitty-gritty.

AnotherJake Wrote:position += velocity * deltaTime

That's about all I can give you based upon your minimal description of what you're having difficulty with (we can't read minds here).

I think his question is how to move an object smoothly without having to move it one pixel at a time... Maybe I'm pointing out the obvious here.

Hairball183 Wrote:I think his question is how to move an object smoothly without having to move it one pixel at a time... Maybe I'm pointing out the obvious here.

That is correct.

So if you don't want to move one pixel (or multiple whole pixels) at a time, then you'll have to move sub-pixels at a time. But how do you know how many fractions of a pixel to move? One way is to move a set amount of fractions of a pixel per frame, which is called frame-based animation. Frame-based animation is notoriously unstable though because there is no guarantee that the time between frames is going to be the same from frame to frame, which indeed it is not, and you'll get lots of jerkiness and speed-ups and slow-downs. The time between frames is referred to as deltaTime and is simply calculated by subtracting the currentTime from the time you recorded in the previous frame. So to decouple your sub-pixel calculation(s) from what you wished to assume to be a fixed deltaTime between frames, you have to recalculate deltaTime every frame and apply it to all your movements. Then it is called time-based animation. Further, you adjust how many updates are called each frame to match what you want in terms of deltaTime each tick, which is harder to understand, but even more stable, which we call fixed-rate, time-based animation. But either way, you'll apply your movement with the equation I originally gave:

position = position + velocity * deltaTime

Note: If you're doing fixed-rate, time-based animation, you could skip applying deltaTime to all movements because you already compensated for it, but it's not recommended because you might (and probably will) wish to change your step (also called tick) interval.

current_position = starting_position + speed * time

Quartz can render things between pixels (using anti-aliasing)

So can OpenGL

Properly should refer to it as velocity, not speed, since speed doesn't account for direction, only magnitude... but that's just me being picky ;P

Your framerate might be the problem here. You need at least 12 frames per second to make your motion look continuous, and 25-30 is preferable.