time vs frame based

Java 2D
#1

Correct if I’m wrong please ;D

If I want to limit my game to 30FPS for example I can use frame based timing for update the position and the animation of my sprites.


public void update() {
 x += dx;
 y += dy;
 // updates the animation (go to the next frame)
 anim.update();
}

But if I want to run my game at full speed I will use time based instead of frame based, so:


public void update(long elapsedTime) {
 x += dx * elapsedTime;
 y += dy * elapsedTime;
 // updates the animation (go to the next frame)
 anim.update(elapsedTime);
}

Questions:

  1. Is that correct?
  2. Is time based suitable for 2D games?
  3. How can I mantain the smoothness of the movement and animation of the sprites in time based?

Tks

#2

If you have sprite animation sequences I would suggest frame based. You can make it work ok, but say you have 10 animation frames for 1 second, and you render at 50 frames a second, you’ll see the same frame 5 times each. If you render at 100 frames a second, you’ll see each frame 10 times. Visually you won’t be able to see a single bit of difference. So it doesn’t really help you to draw that fast. Also if you get off times where an animation frame is supposed to be shown for fractions of frames, you can’t actually pull that off so you’re forces to make it look uneven. Frame based when you have animations like that will give you the least problems.

#3

does anybody else has a different opinion about this topic?

#4

I’m now the opinion you should consider both things during development. Make all your updates time (delta) based but cap the frame rate at some limit.

  • It makes sense to cap the frame rate since there ain’t not point rendering much faster than vsync

  • However, you might change the frame rate cap later so delta based animation/movement is safer.

  • Or worse still someone might be on a weird configuration that prevents your frame cap work correctly (slow machine, no vsync, something odd).

Either way, it costs very little to do both as long as you’re aware from the start.

Kev