07-31-2001, 10:20 AM
after i managed some beginners problems (thanks to some of you) i wonder if this is "normal":
I draw my frame - and every second i update my fps-counter.
i wanted to turn around completly in 4 seconds.
i adden to my frame render function:
frametime = (float) (gettime - lasttime);
frametime /= 1000.0f;
i added to my keyborad handling function:
heading -= 90.0f*frametime;
if (heading < 0.0f) heading +=360.0f;
okay here is the "problem":
if my frames are doing a big jump (say from 150 down to 40 or the other way round) i stuck for a millisecond and then make a bigger jump.
it is nearly unnoticable but it is there.
any suggestions how i can fix this.
is the way i calc the stepping ok?
thank you in adv.
I think you are making everything correct, but are experiencing a downside with that technique. The thing is, you don't know the time taken for a frame until after the frame has been drawn, and you have to compensate for the long/short time in the next frame (one frame too late). There isn't anything you can do about it. If you could predict the time for a frame to be drawn it would work, but it's too bad you can't do that.
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.2*360 degrees or 0.2*M_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.
07-31-2001, 09:00 PM
hat was a long paragraph.
i had some problems reading an dunderstanding all - I read it 3 times. so it mean to my situation (moving the camera around) that i need the time the user pesses the "move-around-key" and then interpolate based on time of my turn speed.
if this will work out fine i will give you a credit in the end demo http://www.opengl.org/discussion_boards/ubb/wink.gif
heh, sorry 'bout that. I sometimes get too carried away. <nods>
but you're exactly right. To make an event, you get its base time and because you know how long that event will take place you can interpolate the action for a given frame.
<laughs politely> no need for credit, really. Just money. I accept cash, cheques, credit cards, ... http://www.opengl.org/discussion_boards/ubb/smile.gif
Powered by vBulletin® Version 4.2.2 Copyright © 2014 vBulletin Solutions, Inc. All rights reserved.