Jump to content

  • Log In with Google      Sign In   
  • Create Account

Smooth sprite movement


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
11 replies to this topic

#1 FreedomDive   Members   -  Reputation: 105

Like
0Likes
Like

Posted 17 July 2014 - 04:15 AM

The pixel data and game logic is both refreshed and handled respectively at 60Hz , and the sprite is moved by using arrow keys:

 

if I move the sprite 1 pixel a tick (60 ticks in 1 second, 1 tick = 0.016~ s, so 1 tick = 16 ms), it is smooth, however the sprite only moves 60 p/s, which is slow for the gameplay. If I move it, say 4 pixels per tick (4 pixels every 16 ms), it is certainly fast for gameplay, as it moves 240 p/s,  however the animation is not smooth, and looks like the sprite is teleporting small distances (basically, the animation is choppy).

 

I feel like I cannot achieve a smooth and fast animation and have to make a trade off. Is there a solution to this problem? I've heard about frame independent sprite movement but I don't understand it fully.



Sponsor:

#2 Buckeye   Crossbones+   -  Reputation: 6251

Like
0Likes
Like

Posted 17 July 2014 - 07:14 AM

You could use a motion blurred texture, perhaps several pixels larger than the stationary texture.


Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.


#3 bwhiting   Members   -  Reputation: 814

Like
0Likes
Like

Posted 17 July 2014 - 07:25 AM

I have a feeling something else is at play here, can you log the time on each tick to ensure you are indeed hitting a steady 60 frps. Sounds like some frames are being dropped, hence the jumps... just need to work out why.



#4 FreedomDive   Members   -  Reputation: 105

Like
0Likes
Like

Posted 17 July 2014 - 10:10 AM

I tried logging the time (before regulating the FPS) in milliseconds for each frame, and it gives a steady range of 0 to 1 ms.

After regulating FPS, the time is ~16 ms , which gives about 60 FPS. As far as I've observed there are no frames being skipped.

 

The motion blurred texture idea sounds cool, but I'm sure there is a more straightforward solution to the problem.


Edited by FreedomDive, 17 July 2014 - 10:16 AM.


#5 megadan   GDNet+   -  Reputation: 655

Like
0Likes
Like

Posted 17 July 2014 - 11:03 AM

Are you using ints or floats for the sprite position?  If using ints you will see some skipping because you actually need to move 3.84 pixels per 16 ms.  240 pixels/sec = 0.24 pixels/ms.  0.24 pixels/ms * 16ms = 3.84 pixels.  But, you still might see skipping with floats if it's moving too fast.



#6 FreedomDive   Members   -  Reputation: 105

Like
0Likes
Like

Posted 17 July 2014 - 12:20 PM

Are you using ints or floats for the sprite position?  If using ints you will see some skipping because you actually need to move 3.84 pixels per 16 ms.  240 pixels/sec = 0.24 pixels/ms.  0.24 pixels/ms * 16ms = 3.84 pixels.  But, you still might see skipping with floats if it's moving too fast.

I'm using ints for everything (using SDL so I cannot use floats no matter what).

 

Also, the changing factor is frames per second (sometimes framerate drops by 1 so it oscillates between 59-60) and not the amount of pixels moved every second. 240 p/s is an approximation too, I would say 220 - 250 would be a decent range for the pixels moved every second by the sprite to be a good gameplay.



#7 megadan   GDNet+   -  Reputation: 655

Like
2Likes
Like

Posted 17 July 2014 - 12:27 PM

You can still use floats for your internal representation of the sprite position, and then cast to int when passing to SDL for rendering.  Otherwise you are losing precision in movement which can make the animation less smooth.



#8 FreedomDive   Members   -  Reputation: 105

Like
0Likes
Like

Posted 17 July 2014 - 12:40 PM

You can still use floats for your internal representation of the sprite position, and then cast to int when passing to SDL for rendering.  Otherwise you are losing precision in movement which can make the animation less smooth.

 

Why should I use floats for internal representation then? say instead of increasing 4 per tick, I increased 4.5, it would be truncated to 4 always, and if rounded, to 5 always, so I can't really see why would you want use floating point values.



#9 Chris_F   Members   -  Reputation: 2460

Like
4Likes
Like

Posted 17 July 2014 - 12:49 PM


Why should I use floats for internal representation then? say instead of increasing 4 per tick, I increased 4.5, it would be truncated to 4 always, and if rounded, to 5 always, so I can't really see why would you want use floating point values.

 

Because if you use floats internally then you will get 4.5 + 4.5 = 9 instead of 4.5 + 4.5 = 8. You are accumulating error.



#10 megadan   GDNet+   -  Reputation: 655

Like
1Likes
Like

Posted 17 July 2014 - 12:58 PM

Think of it as what distance do you want the sprite move every second.  If you want it to move 240 units per second (in this case units are pixels) and your time step is 0.016 seconds, then every time step, it must move 3.84 units for a constant velocity.  After 4 time steps, you will move 15.36 units (in pixels you will have moved 15 pixels).  If you ignore the fraction part and round to 4 units, then after 4 time steps you will have moved 16 units (or 16 pixels). Now your sprite is 1 pixel off from where it should be.  These errors will then get worse the farther you move.


Edited by megadan, 17 July 2014 - 01:00 PM.


#11 racarate   Members   -  Reputation: 135

Like
2Likes
Like

Posted 17 July 2014 - 01:14 PM

sprite movement will definitely look better when you use fractional values for position, otherwise you are snapping to the grid and getting the "jerky-feel".  

 

rasterizers for line-draw and poly-fill can work with fractional position values to determine which pixels to light up.

 

the snap-to-grid problem is exacerbated if you are using scaled up pixel art for that chunky look, so beware.


Edited by racarate, 17 July 2014 - 01:22 PM.


#12 FreedomDive   Members   -  Reputation: 105

Like
0Likes
Like

Posted 17 July 2014 - 02:43 PM

I now see what you meant, thanks for the pointers, I'm sure I'll be able to fix the problem with this information, thank you.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS