Howdy,
this is another of those questions that manifest itself in one way or another, quite often. The simple answer is: you’re thinking bottom up, rather than top down. You should never be concerned about your frame rate when doing these kind of animations. An analogy, if you will: suppose you have two people in a dark room, and a third person outside the room. One person in the dark room is a dancer, and she’s dancing to some song (ie. the song is providing the timing for her dancing). The second person in the room is a photographer with a flash, and the third person wants to know what the dancer is doing. The dancer dances to the music, and the photographer periodically takes a picture with the flash, has it magically and instantly developed, and slides the frame under the door to the third person.
Now, the question is: does the dancer modify her routine dependent on how quickly the photographer can take happy snaps?
Aaaand the answer is (envelope, if you please): No. The third person and the dancer can both hear the music, and the third person wants to see what is happening in the room right NOW, not a slower down delayed version based on how competant the photographer is.
Yes, yes, you can shoot this analogy down in frames (but what if the dancer is doing it for a magazine, or something?), but that’s not the point, now, is it? No. =) The point is the dancer is doing her own thing, the photograpger is taking happy snaps when he can, and the third person gets to see the status of the dancer as soon as the photographer is ready… so <deep breath> the dancer doesn’t care what the photographer is doing.
Righty. That’s the analogy. Now, the moral of this story is: the dancer is your game world. She represents the state of your Amazingly Cool Quake Engine in all its polygon finery. The third person is you, the games player. You don’t want to see a sluggish, slowed down version of whats going on in this virtual world; you want it here and now. The second person in the analgoy is the OpenGL card, pumpin’ out frames as fast as its little legs can carry it. Now, following the analogy, the game world is never concerned with how fast the opengl pipe is pushing verticies along. If the enemy 'bot is rushing towards you as the fearsome pace of 10 metres a minute, then the 'bot is rushing towarsd you at 10 metres a minute, regardless if your GeForce IX is merrily churning out 1000 frames a second or one frame every 5 seconds. (yes, yes, you can argue it MIGHT be concerned for things like LODs, turning on/off rendering features, etc etc for an acceptable frame rate, but we’re talking solely about animation here, so my point is valid).
The solution, then, intrepid animator: you need to base your animations on time, not frame rate. If you want your Earth to orbit the sun once every 5 seconds, then you’re going to have to pinpoint some base time where you know where the earth is at time 0. Right? You have to be able to say that at such and such a time, you KNOW the earth is HERE, and you KNOW that in 5 seoncds time its going to end up here again. That’s your initalisation for this earth example. Fast forward some arbitrary time later… and we’re at frame 192384822. What we do is ask the computer what the time is. The computer says “well, its 123456 seconds since you started the game”. Where is the earth now? Well 12345/5 == 24691.2 revolutions around the sun. We’re not interested in how many revolutions that is (in this example), so we can discard the 24691; we only want to know how far around it is. Well, .2 == one fifth of its way around the 24692nd revolution, ie. is 0.2360 degrees or 0.2M_PI*2.0 radians around the sun. And you know all of that without knowing 1) the frame rate, 2) how many frames we’ve done in the game time, or 3) anything to do with the frame rate at all.
But, you protest, thats all very fine and well for the sun and the earth and orbits. What about monsters, ‘n’ bullets ‘n’ stuff? It’s the same story, but the init is more involved and it changes. Your AI engine might suddenly decide that it’d be a REALLY good idea for the fearosme 'bot to make a right turn, ending up 90degrees from its current orientation. Right. Since you know when the decision was made (38347 game seconds, say), you know how fast the bot turns (because thats something you’ve defined in the game; this is a very fearsome 'bot , after all, so it might me able to turn one degree every 4 seconds), and you know how MUCH you want the bot to turn/move/jump/crouch/twiddle-its-thunbs, then you can know the state of the bot for a given frame some arbitrary time in the future.
I hope this helped.
cheers,
John
