0

I am trying to understand the concept of speed in a game which supports different screen sizes (in android).

Let's say I have a Sprite that should take 10 seconds from the right end in landscape mode to the left end. The Frame Rate is not steady so sometimes it's 30 for a while and then all of a sudden it changes to 10. But I still want my Sprite to take 10 seconds from one end to the other. How would I do that?

final int time = 10; //time from one end to the otehr
float baseSpeedX = screenWidth / time;
float currentFrameRate = 30.0; //just as an example
float baseFrameRate    = 50.0; //the frame rate we want
float factor = baseFrameRate / currentFrameRate;
playerSpeedX += baseSpeedX * factor;

This is what I understood:
You get the base speed by dividing the screen width by the time you want to get the sprite from one end to the other. The base speed is the speed your Sprite should add to your current location every second if a steady framerate is available. However, I don't know how to achieve that so I just get the current frame rate and divide the base frame rate, the frame rate we really want for our game, to get the factor we multiply our base speed with.

This would, if it really works, make the Sprite reach the other end in 10 seconds, right? Even if we have a frame rate of 10 for 2 seconds and then 50 after that for 8 seconds. The higher the frame rate now, the lower the Sprite increases in distance and the lower the frame rate, the higher the Sprite increases in distance.

If this all works, would it be something I could use in a game? Or is it totally wrong approach for getting the sprite speed?

Davlog
  • 2,162
  • 8
  • 36
  • 60
  • "*The Frame Rate is not steady so sometimes it's 30 for a while and then all of a sudden it changes to 10. But I still want my Sprite to take 10 seconds from one end to the other*" Seems as if you should be attempting to stablize the frame rate, rather than have it force you to change your game's implementation. Take control of your app; don't let it take control over you. Frame rate should be independent of the actual game; if the frame rate is low, and the game is causing it, then thats something you gotta fix. Other than that, it's their computer, which you have no control over. – Vince Jan 02 '15 at 00:42
  • @VinceEmigh I think my GameLoop has a stabilized Frame Rate. About 30 fps. However, it is not always like that. Sometimes a background progress or something kind of interrupts a little bit and the fps decreases. You know what I mean? For cases like that (from 30 fps to 10 for a while) I want to make sure that the sprite still moves the same on all devices. Even though the screen size is much higher or lower on other devices. – Davlog Jan 02 '15 at 02:20
  • And that's the "*it's their computer, which you have no control over*". You *could* implement a system like that, but that's VERY bad practice. You should instead set a spec recommendation for playing your game. Games lag, that's just how it goes. If you try to make your game adjust to the *actual* framerate, you'll find yourself doing more processing (and wasting more frame time) than you thought you would. There are many game loops that check for certain discrepancies in render/update times. Either the test computer has bad specs, or the game loop needs work – Vince Jan 02 '15 at 02:26

1 Answers1

1

You are on the right track

Generally when you are moving sprites, you need to make a way so that the sprite moves slower when there is a higher fps, and move quicker when there is a lower fps. This can be done by multiplying another variable called delta to your baseSpeed. Delta in this case is the time it takes from the current frame and the previous frame. With this, games with high fps will have a low delta because it takes a short amount of time to go from one frame to another. Following this pattern, a low fps game will see a high amount of delta. By calculating the delta, you can have uniformity that your sprite will be the same speed at different fps targets. You can usually calculate delta by subtracting the current time and the last rendered time.

In theory, if you use your baseSpeedX formula (from first glance, it seems sound) and multiply it with the delta, you will have your speed:

double delta = currentTime - timeOfLastFrame; // I don't know specifically what time libraries there are on your platform
double speed = baseSpeedX * delta;
Hayden
  • 2,902
  • 2
  • 15
  • 29
  • "*Generally when you are moving sprites, you need to make a way so that the sprite moves slower when there is a higher fps, and move quicker when there is a lower fps*" Wanna tell me where you got this information? Cause last I checked, `delta` was responsible for ensuring you only update at a certain rate; manages how quick and often your game updates. Mind giving the source for the information you're giving? – Vince Jan 02 '15 at 18:00
  • @Vince Emigh en.m.wikipedia.org/wiki/Delta_timing – Hayden Jan 02 '15 at 21:48
  • The idea is that if your game loop is updating slowly (or low fps) then you have to compensate that with high delta so that the game objects move at the right speed ( I admit I use delta wrong and should use delta timing). – Hayden Jan 02 '15 at 21:50