Jump to content
  • Advertisement
Sign in to follow this  
Micah Carrick

Time-based movement slower than FPS

This topic is 2271 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm relatively new to game-specific programming and I'm playing in C/SDL and pygame. Many of the samples and tutorials use the time since the last frame, delta, to calculate the movement for a sprite. However, as far as I can tell, this would only work if the speed of the sprite is greater than the framerate.

My solution would be to store and manage the last time that particular sprite was updated, separate from the general delta on each game frame, and only move the sprite when the pixel movement is greater than 1. Is that how this would normally be handled? Should I be storing different deltas for every sprite that *may* be moving slower than the FPS? Or is it just standard practice to cap the FPS and remember to keep speeds faster than that?

Share this post


Link to post
Share on other sites
Advertisement
Um, how about using floats as position?
Only round the values when it's necessary. Pretty much when rendering the sprites.

Share this post


Link to post
Share on other sites
Yeah, I was thinking about that, but, I was trying to keep the Python version simple by using only the pygame.Rect class: http://pygame.org/docstest/ref/rect.html which stores the position as integers. Perhaps using the Rect in my case is not meant to be. I guess I'll try storing the values in floats and then convert them to the pygame.Rect when needed (as the pygame.Rect still has some nice conveniences when dealing with other pygame classes).

Thanks

Share this post


Link to post
Share on other sites

I'm relatively new to game-specific programming and I'm playing in C/SDL and pygame. Many of the samples and tutorials use the time since the last frame, delta, to calculate the movement for a sprite. However, as far as I can tell, this would only work if the speed of the sprite is greater than the framerate.

My solution would be to store and manage the last time that particular sprite was updated, separate from the general delta on each game frame, and only move the sprite when the pixel movement is greater than 1. Is that how this would normally be handled? Should I be storing different deltas for every sprite that *may* be moving slower than the FPS? Or is it just standard practice to cap the FPS and remember to keep speeds faster than that?

You should store the position (or placement in general) distinct from the geometry. Using floats for the position (as szecs suggested) is meaningful. Even if you find definitions that work on your computer, a way that depends on the screen resolution would obviously be dangerous.

In the case that the movement is predetermined up until the end position, you can also compute the current position by interpolation between the start and end positions rather than by accumulation of steps.

BTW: The dimension of FPS is "1 over time", while the dimension of speed is "distance over time". Hence saying that the speed need to be greater than the FPS is somewhat senseless. Edited by haegarr

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!