Time-based vs. frame-based animation

[baegsi]

This might be a basic question, I surfed quite a time about this issue but couldn't get a satisfying answer yet. I'm thinking about how to realize the animation in a 2D game. So far as I understand it there are basically two approaches:

1.- Time-based animation (tba) where movement and animation depend on the elapsed time, meaning that at a given time an object will be at a specific position displaying a specific frame. Tba is independent of any frame rate, so that on slow machines the animation might skip frames but the movement will not slow down. Drawbacks are possible chunky animations and a more difficult collision detection.

2.- Frame-based animation(fba) where movement is constant and no frames of an animation are skipped. Fba depends on a constant FPS. On slow machines the animation will be slow but smooth.

I'm not sure if I miss some important points to consider. So far I would prefer fba because it is easier to realize (and my game will be a round-based strategy type), but would like to know your opinions about this. Is this more a question of personal preference or does this depend on the type of game? What do you do?

Any comments or pointers to a more thorough discussion are very appreciated!

[kevglass]

You might be better posting this sort of thing in a more appropriate section say "Java 2D" ?

As to the question, you seem to have understood both methods. Time based animation is always my preferred option. Its just more flexible in the long run.

Kev

[baegsi]

You might be better posting this sort of thing in a more appropriate section say "Java 2D" ?

Oh, sorry, but my question was meant independent of 2D, especially Java2D (I'm using lwjgl anyway).

Thanks for your feedback. To be a little more annoying: in what way is time-based more flexible?

Games published by our own members! Check 'em out!

[Malohkan]

For a round-based strategy game will you even need active rendering?  Perhaps you could even consider getting away with passive rendering at least for parts of it.

[baegsi]

It's round based, but with many nice animations. It's kinda round-based...

But most of all, I would like to understand the pros and cons of it in general, regardless what I'm going to implement next.

[princec]

If you have total control over your framerate, I advise frame based animation. If you have no real control over it, then time based.

Cas

[wmjoers]

I use this formula to decide if I'm going to use FB (frame based) or TB (time based).

* If 2d and movement are going to be steady and smooth: allways use FB. For example If you are going to do a simple scrolltext you better stick to FB because even the smallest miss in the update will be noticed.

* If 3d or 2d with a high amount of movement and action use TB. For example if you play a FPS 3D game you will not notice an occasional tear or flicker.

A problem when using FB is that you HAVE TO be done with all calculations within a small timeframe..otherwise the effect wil be huge.

[Matzon]

another simple way to decide is that any game that relies on fba tactics is susceptible to cheating, since a player can just run a program that uses 99% cpu and the game will run slower.

[William Denniss]

true, and conversly the game may run insanely fast on later computers (Jazz Jack Rabbit anyone?).  Locking the frame rate isn't great either as then there are no advantages to a newer computer and your game still looks the same.

Will.

[Matzon]

Locking the frame rate isn't great either as then there are no advantages to a newer computer and your game still looks the same.

Doom3 is locked to 60 FPS - so if it's good enough for John Carmack, it's good enough for me
Locking to a framerate isn't all that evil - it actually makes a whole lot of sense in a lot of games. Games don't nesecarrily get more fancy or add new features just because you have a fast machine. Take any classic FPS - going from 60 to 125 FPS won't make any change (some might claim) - going from 250 FPS to 500 certainly won't!
But yes, a lot of old games are wickedly fast to play because of fba.

Games published by our own members! Check 'em out!

[wmjoers]

The trick with frame based timing is of course to allways lock at a fixet rate. If the game can't lock on that rate it has to fall back to time based.

[princec]

Alien Flux and Super Elvis always do both - they change the screen mode to 60Hz and enable vsync and whether it succeeded or not they have a yield() loop to cap the framerate to 60Hz. It seems to be foolproof. There are almost no game machines left that can' t manage 60Hz for these games so I'm more or less getting it as smooth as a smooth thing everywhere.

Cas

[oNyx]

>Take any classic FPS - going from 60 to 125 FPS won't make >any change (some might claim)

*claim*

Well, yea there is a difference, but you need 1. vsync 2. a mouse with a high polling rate (usb or ps2@100|200hz) and 3. the game physics should be written rather well.

However, for a 2d game 60hz are usually enough (because you don't have such extreme screen content changes like you have in a first person shooter).

Btw the "eye pixels" asynchronously refresh at crappy 7hz (it's like spraying new images over the "buffer" without clearing it ever). That's the reason for persistence of vision.

Having said all that... Q3 looks less smooth with vsynced 100fps@100hz than cpma (a Q3 mod) with vsynched 75fps@75hz, because they removed a silly bug there (snapping the players position to units each frame... ). So it's really worth spending some minutes thinking about how to get the movement as continuous as possible. It will look better than something jerky at high fps.

> going from 250 FPS to 500 certainly won't!

True. If you can't sync that high it's a waste of cpu/gpu cycles. You won't get anything (except bleeding eyes) from crippled frames (eg one frame containing the stuff of 2-3 frames [=tearing]).

Well, with Q3 you get "connection interrupted" with 500fps+ and all quake engine games lockup/crash if you ever reach >=1000 fps

[snowmoon]

The only thing to think about ( things to make you go hmmmm )...

PAL is 50hz, so if you do frame based animation and then try and release the game commercially you MIGHT want to support 50 or 60 fps for those pesky PAL people.  For the most part though I would agree with people that 60 is all that is necessary for gameplay in a twitch game.

[princec]

Most people don't use PAL monitors for PCs
And those that use PAL TVs generally automatically switch to 60Hz mode.

Cas

[William Denniss]

I'm using Odejava which also has a "frame rate".  It isn't a visual frame rate as in you don't "see" it, but the more frames the more accurate the physics simulation.

So for my game - if you can run the physics at 500 frames per second, it will be more accurate than if you run it at 250 frames per second.

Capping the frame rate, while the easy approach means that in ten years time the game won't run any smoother (physics wise).  Increasing the cap rate once it is finished would be a near disaster - everything would have to be tweaked.  As this is a fairly CPU heavy game - I would either have to pick a high frame rate which made the game look great but lock out lower spec computers, or pick a low frame rate and degrade the quality of the game for everyone.


Will.

[oNyx]

It's usually enough to run the physics at 20-60 fps (step size of 50-16ms). Using a modern integrator (like verlet velocity) means that you get high precision for slow moving objects and less precision for things, moving at high speed. That's perfect for games, because precision doesn't really matter.

It's only important that it *looks* correct and no one will be able to tell if a ragdoll's arm moved a bit incorrectly when it's slammed against a wall with 1000kmh.