Quote:Original post by intrest86
Everything is going 60 because that is as fast as they can run. They are not arbitrarly limiting ther games to 60, they are making games go as quickly as they can and being able to go 60.

What is going to happen to your game when the framerate dips to 30? That is still in the playable range, but if you are updating everything based on a "change per frame" method everything is going half as fast!

No, that's not as fast as they can run. My computer, not even a top-of-the-line machine, can get hundreds of FPS when unleashed on 3d-intensive tasks. The main reason 60 FPS is aimed for (in the US) is that NTSC signal transmission is 60hz. In any case, I intended that more as a sidenote to the fact that it's best to use the v-sync method. Of course you'll notice that I said "at most once for every vertical retrace". My poor little laptop can only get 30-40 fps on the engine I'm designing right now, so of course rendering occurs less often and of course I have to account for that. Actually, you can't tell much of a difference since the movement is still the same per unit time, and for the most part is still less than a pixel difference.

Oh, and @helix - Any compiler worth its salt will do the divide at compile time for you...not that it makes a nanosecond difference on a P4/Athlon...

By limiting the FPS to the refresh rate, you are making sure the program doesn't consume unnecessary CPU time, instead returning it to the OS where it can be used for other processes running in the background. Rule 1 of Programming: Always play nice with multitasking :) (well, maybe not rule 1, but pretty important nonetheless). And of course I'm not advocating that you code with a constant game state update frame rate in mind, but with a constant delta vs. time in mind. Two different cats, and a million ways of skinning each.

there is nothing wrong with limiting frame rate. Sometimes, it's necessary, when the game runs so fast, you get FP inacuracies (mostly on the delta time) so severe it will brake the game. I'd limit it to 100hz personnaly. [grin]

Meh, I guess what I said didn't come out quite right. What I mean to say is, framerate can be limited by the programmer not to be higher than the user's refresh rate. There would be absolutely no difference in what is displayed onscreen at a framerate of 75 and at a framerate of 105 if the user has a 75hz refresh rate from their video card to their monitor. So anything above 75 FPS (in this case) is "unnecessary CPU time". That's not to say that every draw should necessarily be v-synced -- because if you're running at BELOW 75 FPS, there will be a difference. So all I'm saying is, have the refresh rate as a maximum -- in my case, by implementing a 3-state system that only renders if the v-sync indicator is 1 (which means we're getting max FPS equal to or greater than refresh rate) or 2 (which means we're not matching the refresh rate). Each v-sync EVENT increments the state (up to 2); each render decrements it.

Oh, and always keep in mind that the end user is a complete idiot who will destroy their computer if you make it easy enough for them. Not this is something that could destroy a computer...but what I mean is, if render FPS above and beyond the refresh rate is completely meaningless, help the user out with more CPU time for other processes instead.

World update time, as we all know, is a completely different story. It can be fixed, tied to the renderer, or in a whole different thread, or whatever. Nobody really cares, as long as it works correctly. Keeping it in the same loop as the renderer is the easiest. Just have to make sure you calculate everything based on frame time.

Ta,
Twilight Dragon