Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (579)
games submitted by our members
Games in WIP (500)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Time-based vs. frame-based animation  (Read 3885 times)
0 Members and 1 Guest are viewing this topic.
Offline baegsi

Senior Newbie




Java games rock!


« Posted 2004-10-21 13:27:01 »

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!
Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #1 - Posted 2004-10-21 13:52:37 »

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

Offline baegsi

Senior Newbie




Java games rock!


« Reply #2 - Posted 2004-10-21 14:11:59 »

Quote
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!
Legends of Yore - The Casual Retro Roguelike
Offline Malohkan

Senior Member




while (true) System.out.println("WOO!!!!");


« Reply #3 - Posted 2004-10-21 14:12:31 »

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.

Admin and Game Developer at
GameLizard.com
Play Rimscape!    |    Play Conquer!
Offline baegsi

Senior Newbie




Java games rock!


« Reply #4 - Posted 2004-10-21 14:14:17 »

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.
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2004-10-21 14:57:09 »

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 Smiley

Offline wmjoers

Senior Newbie




Nobody can be uncheered with a balloon.


« Reply #6 - Posted 2004-10-25 06:19:46 »

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.

Offline Matzon

JGO Knight


Medals: 19
Projects: 2


I'm gonna wring your pants!


« Reply #7 - Posted 2004-10-25 08:44:38 »

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.

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #8 - Posted 2004-10-26 04:31:23 »

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.

Offline Matzon

JGO Knight


Medals: 19
Projects: 2


I'm gonna wring your pants!


« Reply #9 - Posted 2004-10-26 05:31:32 »

Quote
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 Wink
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!
Legends of Yore - The Casual Retro Roguelike
Offline wmjoers

Senior Newbie




Nobody can be uncheered with a balloon.


« Reply #10 - Posted 2004-10-26 06:08:09 »

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.
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2004-10-26 09:20:56 »

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 Smiley

Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #12 - Posted 2004-10-26 12:30:39 »

>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... Roll Eyes). 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 Smiley

弾幕 ☆ @mahonnaiseblog
Offline snowmoon

Senior Newbie




previosly known as TheLorax


« Reply #13 - Posted 2004-10-26 13:43:16 »

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.
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #14 - Posted 2004-10-26 14:40:43 »

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

Cas Smiley

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #15 - Posted 2004-10-26 23:51:45 »

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.

Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #16 - Posted 2004-10-27 01:50:43 »

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.

弾幕 ☆ @mahonnaiseblog
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (42 views)
2014-04-15 18:08:23

BurntPizza (38 views)
2014-04-15 03:46:01

UprightPath (54 views)
2014-04-14 17:39:50

UprightPath (36 views)
2014-04-14 17:35:47

Porlus (53 views)
2014-04-14 15:48:38

tom_mai78101 (75 views)
2014-04-10 04:04:31

BurntPizza (134 views)
2014-04-08 23:06:04

tom_mai78101 (234 views)
2014-04-05 13:34:39

trollwarrior1 (195 views)
2014-04-04 12:06:45

CJLetsGame (203 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!