Locking FPS

Here is ONE way to do it...

float delay; delay = (float) GetTickCount(); while(!done) { ... delay += 18.2/60; // run at 60 FPS while (GetTickCount() <= delay); }

Hope this helps!

..-=ViKtOr=-..

Too many frames per second? A high FPS is a GOOD thing. Clamping your program''s speed with a loop that just burns off a few CPU cycles is a waste of your expensive hardware''s ability.

TheHoff, you need to lock the frame rate so it runs at the same speed on all computers, no matter what... imagine you make your program on a PI - 133MHz... well, it runs at 60fps on your compy... now you give it to your friend who''s got a PIII - 500MHz... well... it''s gonna run so fast you wont be able to see it.. (exhagarating a bit here)... that''s why you need to lock it at the frame rate that runs well on your computers...

..-=ViKtOr=-..

>>>>lock the frame rate so it runs at the same speed on all computers


That''s not correct. To correctly program a game, all animation is tied to time not framerate. Never tie your animation to framerate and never limit framerate. That is bad programming.

I''m not sure I agree with Hootie on that one. On occasion, I''ve deliberately locked a program to a specific frame rate for two reasons: 1 - the remaining time is used for AI, and 2 - the human eye is much better at detecting changes in framerate as opposed to high/low framerate. So if you have a program that''s going to average a comfortable 60+ fps, but will drop to 30 fps in some taxing areas, you may be better off clamping the framerate so as to avoid the appearance of slowdown. I probably wouldn''t do this in a twitch-shooter (yawn), though.

I''ve tied my animations to time in my game, as Hootie said, for quite a while now and i''ve always thought it was the best way until Bracket''s post.

However, a few thing puzzle me in your post Bracket.

1-Isn''t AI calculations part of the game loop (i haven''t done AI programming yet so i could be wrong ), so wouldn''t capping the fps actually slow down these calculation?

2-In taxing areas when the fps changes drastically wouldn''t capping the fps give the same result as capping the animation rate? Remember the animation rate is controlled so it''s not like the animations are running at, say 200 fps, only the game loop is. So say the animations are running at 60fps and the game is running at 200 fps, only if the fps drops below 60 would a change be noticed.


+AA_970+

Thanks for all your help, but I actually got it to work right after I posted this. =P Anyway, at least it resulted in a friendly discussion. hehe

-.Brandon.-

AI does go in the main loop, but there is more than one way to structure your main loop. :-) Basically, mine usually look like this:

(message loop calls GameMain)
Do some non timespecific AI
Check timing - update anything time related (animation frames, movement)
If its time for another frame, render it (otherwise keep going)
If we didn''t render, do some "bonus AI"
(return to message loop)

I always try and write AI routines so that they are divided into time-specific stuff (actual movement, etc.) and decision making. In a wargame, for example, the AI will ideally build up a bit of knowledge about the map as it develops - while units themselves may have to make immediate (timely) decisions. If the knowledgebase gets better in idle (easy to render) areas, the player gets a better overall experience.

I don''t recommend this for every type of game (or even programming style), but it works for me. [The downside of this is that people with low-end machines won''t get quite as interesting an opponent, so it may be best to limit this section of processing for incidentals/niceties that aren''t strictly needed].

Onto your second question. Yes, capping animation rate gives you the same result as capping frame rate, for models within the scene. If you have some sort of mouselook going (and haven''t time capped that), you get the Quake effect of higher precision for those with better machines unless you cap frame rate. If you simply limit the mouse responsiveness, players seem to complain a bit (some Quake players go so far as to use utilities to up their mouse sampling rate, and complain about regular mice). If, however, everything keeps going at a steady pace you don''t notice the "aarrgh, I have less control here!" syndrome quite so much.

That said, there really is some enjoyment to be had from finishing writing an MD2 viewer that draws multiple (4 in the current demo) Quake II models at > 60 FPS (1600x1200) with lightmaps and just enjoying the feeling of wonder that comes from such a framerate. :-p I''ll wait a bit before I cap the frame rate on that!

Here's the best way to do it. I learned this from "Game Architecture and Design", and as we all know, it's a very good and respected book.

1. There is no need to have more frames then AI updates. Player will never notice this.
2. Draw a frame after each AI update.
3. Update AI based on frequence. Say you want your character to move 10 pixels per second. Draw the frame. Depending on how much time it took, adjust the AI. So, if you have 10 frames per second, the AI will move 1 pixel per frame. If you have 5 frames per second, AI will move 2 pixels frame. It won't be as smooth, but it will be accurate.

This way, on a better hardware you'll have great framerates, and smooth AI. On slower machines you'll have less frames per second, which means the game won't run as smoothly, but the gameplay would still be very accurate. This is the best way to do things.

Edited by - kill on July 7, 2000 12:31:41 AM

I've always thought locking the fps meant locking the entire game loop to a certain fps?

Anyway, i think i'll stick with only capping the animation rate

+AA_970+

Edited by - +AA_970+ on July 8, 2000 6:30:16 PM

I do not think you can tie any animation or physics to frame-rate. Maybe I should explain how to avoid this:

Say you have a guy moving at some velocity. You're probably doing this every frame:

guy.position += guy.velocity; // these are probably 2D or 3D vectors

That is bad. You should do this instead:

guy.position += guy.velocity * deltaTime;

Here, deltaTime is the elapsed time since the last frame; you need to recalculate this value every frame. I find that deltaTime ends up being involved in every movement/physics-related aspect of my game. Note: all position variables need to be floating-point for this to work.

Bracket pointed out that it is annoying when your framerate suddenly plunges, because you lose input precision. This is a good argument for frame-rate capping, but consider this:

Let's say a P166 runs your game at 30 fps, but sometimes drops to 15 fps; You want your game to run smoothly on this machine, so you decide to cap your game to 15 fps. But now some other guy w/ a P733 runs your game; he could probably be getting 90 fps (occasionally dropping to 45 fps), but instead he's capped to 15 fps.

So my point is obvious; it might be good to cap the framerate, but only on a per machine basis, at run-time. This means your animation, movement, and physics still need to work at any framerate.

And guys, when Bracket talked about devoting "extra" time to AI, he meant considering more paths in his path-finder AI, considering more moves in his chess AI, etc. (right?). (Bracket, that sounds like more trouble than its worth, because, like you said, you can't have your AI opponents acting noticably dumber on slow machines anyway...)

Edited by - Eric on July 8, 2000 10:30:06 PM

quote:

---

To correctly program a game, all animation is tied to time not framerate. Never tie your animation to framerate and never limit framerate. That is bad programming.

---

Does this mean that the old 2D console programmers -- NES, SNES, GB, Sega Genesis, etc. -- were programming incorrectly? No. They just had a different target system. So it's not really bad programming. In our case, it's just inappropriate programming.

Anyway, I'm having a similar problem with framerate & motion. Some of you have seen my Kirby PC game. Originally, it was just going to be a little private project, so I didn't worry about it working on other computers. But now that I posted it on my site, I'm having to do very *painful* conversions in the code that are causing major problems. Locking the framerate is sounding very appetizing

As for the lock / don't lock argument, I pose a happy medium: The framerate could be locked at different settings that the user chooses, like "slow", "average" and "fast." That way there would be no framerate fluctations but the user could take advantage of their hardware. Of course, there are ways to refine this (the user could set a *specific* framerate), but that might be too complicated or abstract for the average end user. (No offense to any end users )

lntakitopi@aol.com - http://www.geocities.com/guanajam

Edited by - SHilbert on July 8, 2000 10:52:47 PM

Programming for a single, set-in-stone platform like a console is a big difference to programming for a home computer and do you really know for sure they did that.

Anyway, I think, with the large amount of newbies here, that it''s a very bad idea to advocate a poor programming practice.

the way hootie saiz is the correct way. its the only way think about it play quake youre staring at a wall getting 100fps next thing u turn around and all hell breaks loose, or the os decides to take over the cpu for a while,or u enter a new area and the textures have to be loaded off disk causing the fps to drop to 5.
with the higher fps u can animate smoother by lerping in between frames where as if youre stuck at a framerate the characters will be jerking around like robots.

Gamedev just seems to breed misinformation sometimes. Where did you all get the idea that locking the frame rate is a good idea? It's not.

quote:

---

Original quote by Gladiator
imagine you make your program on a PI - 133MHz... well, it runs at 60fps on your compy... now you give it to your friend who's got a PIII-500MHz... well... it's gonna run so fast you wont be able to see it.. (exhagarating a bit here)... that's why you need to lock it at the frame rate that runs well on your computers...

---

No. Firstly it's stupid to deliberately waste clock cycles. All this will mean is if you have a fast machine it'll look just as jerky as it does on a slow machine, and if the frame rate drops below 60fps (which it will do from time to time, even on a fast machine), all the animation in the program will become slow.

Secondly, if the frame rate goes up it does not mean the speed of the game goes up - if you do it correctly. Let me explain:

Velocity is distance over time; therefore distance travelled= velocity * time.

Let me repeat that:

distance travelled = velocity * time

Another example:
bullets fired= rate of fire * time

And another:
rotation = rate of rotation * time

All time based stuff should be tied to time. All you do, as Eric said, is get the time elapsed since the previous frame (use QueryPerformanceCounter() if TimeGetTime() isn't accurate enough) and multiply by this when you're doing anything in your game based on time.

Here's some pseudo code. I have a model rotating on the spot, and I want it to rotate at a constant speed no matter what the frame rate is.

//timeElapsed is in seconds. timeElapsed = currentTime-previousTime; //make the model rotate at 10 degrees per second model.rot[1]+=10.0*timeElapsed; model.draw();

BTW, this method applies to all real-time animation, not just 3D.

I hope that clarifies things.

BTW, People come on these boards to learn the right way of doing things, and it doesn't help when people come and spout ill-informed bullshit all over the place - so please, think before you reply "do I know what I'm talking about?", and if the answer is "no" then don't.










http://www.geocities.com/ben32768



Edited by - benjamin bunny on July 9, 2000 5:21:21 AM