# How to Handle frame rates and synchronizing screen repaints

I would first off say sorry if the title is worded incorrectly.

Okay now let me give the scenario

I'm creating a 2 player fighting game, An average battle will include a Map (moving/still) and 2 characters (which are rendered by redrawing a varying amount of sprites one after the other).

Now at the moment I have a single game loop limiting me to a set number of frames per second (using Java):

Timer timer = new Timer(0, new AbstractAction() {

@Override
public void actionPerformed(ActionEvent e) {
long beginTime; //The time when the cycle begun
long timeDiff; //The time it took for the cycle to execute
int sleepTime; //ms to sleep (< 0 if we're behind)
int fps = 1000 / 40;

beginTime = System.nanoTime() / 1000000;

//execute loop to update check collisions and draw
gameLoop();

//Calculate how long did the cycle take
timeDiff = System.nanoTime() / 1000000 - beginTime;

//Calculate sleep time
sleepTime = fps - (int) (timeDiff);

if (sleepTime > 0) {//If sleepTime > 0 we're OK
((Timer)e.getSource()).setDelay(sleepTime);
}
}
});
timer.start();


in gameLoop() characters are drawn to the screen ( a character holds an array of images which consists of their current sprites) every gameLoop() call will change the characters current sprite to the next and loop if the end is reached.

But as you can imagine if a sprite is only 3 images in length than calling gameLoop() 40 times will cause the characters movement to be drawn 40/3=13 times. This causes a few minor anomilies in the sprited for some charcters

So my question is how would I go about delivering a set amount of frames per second in when I have 2 characters on screen with varying amount of sprites?

It may not be a direct answer to your question, but it is my advice ;)

Do not move your sprites based on the number of frames, but do it based on wall-clock time. Why? Oh well, it is very easy for a game to have a variable frame-rate, so, imagine your character is jumping from platform to platform, and the PC lags for some reason. If his movement is based on frame-rate, he could slow down in middle jump and die :( Prepare to be murdered by the player on the next day.

So, the idea behind a time based game logic is: no matter the amount of FPS the game is currently running, the results will be the same for the user, with the only variation the screen being "janky" :P

This post (Link!!!) may help implement a time based game logic o/

Hope it was helpful and sorry if it was not the answer you seek...

Edit: There is a question in this sites FAQ regarding this, very interesting read: When should I use a fixed or variable time step?

• +1 Thank you this sounds like a great idea, and here I was thinking about syncrhonizing threads and timers :O – David Kroukamp Nov 8 '12 at 9:17

You might want to consider using a variable frame rate. This way, you can cap the framerate at whatever the monitor's refresh rate is without changing the speed of the game.

AranHase has a valid point about glitches resulting from variable frame rates, but you can avoid this by skipping the update loop if the time between the current and previous frame is too high.

You're using Sleep calls to control your framerate - this is a BAD idea and you should get a proper timer in as mentioned in the other responses; I'll elaborate some on use of Sleep for this.

The big problem with Sleep is that on most platforms it only guarantees a minimum time to sleep for - the actual time spent in a Sleep may be longer than that. This is true even if you use Sleep with a high resolution timer.

There are plenty of questions and answers on this site relating to this; see https://gamedev.stackexchange.com/search?q=sleep and see especially http://www.altdevblogaday.com/2012/06/05/in-praise-of-idleness/ for a more in-depth discussion on the evilness of Sleep (among other things).

So the main thing to expect if using Sleep is framerate anomalies galore.

What Sleep is great for is reducing CPU usage, and if that goal is more important to you than an even framerate, then by all means go for it, but not before considering if you have more appropriate solutions available.

• using a spinlock with nanotime can get you very accurate timing, but it will burn up one processor. – Ray Tayek Nov 8 '12 at 21:34