Handling FPS / time...

Hello, so this is about handling frames per second.
I know *logically* how to handle them, but the problem
is being accurate with thw win32 function named "Sleep()".

You know, when you want to handle fps you just check for times
differences between frames and just need to Sleep() for the amount of time remaining before you reach your actual framerate...

So if I want 60fps, I'll have to do 1000ms/60fps = ~17ms
So I have to use Sleep(17 - time elapsed)...

Here the problem is the way Windows handle time for every running application. You know, like it will give ~10ms of execution for each opened program in order to look like everything is running at the same time... So the preoblem is that if you need to Sleep() for let say only one millisecond, its possible that you'll be waiting in the end for about 11 ms because of the time given to each program... You get what I mean?

So I want to know if there was something, function, that could tell to the CPU: I really want to wait 1ms, not more!
Or some other function that would make it's running process more important, so that the CPU would almost only work for this appl and not on the other, like it could maybe run it for a second before switching to another app...

You get the idea? I'm sure there's a solution to that, because our actual video games have no problem handling fps!

Why are you waiting to get Frame Rate? Sleeping will only slow down your frame rate because you pause before you render the next frame. Frame Rate should just be a monitor of how fast your computer is rendering the application.

There are two ways, I could think of to do this. Every frame, get the time it took to render that frame, then divide one second by that number. Output that as your framerate. Another way is to take a running total of how many frames your rendering, and output and reset that number every second.

Quote:

---

Originally Posted by SlyMaelstrom

Why are you waiting to get Frame Rate? [...] Frame Rate should just be a monitor of how fast your computer is rendering the application.

---

Not entirely true. There are a lot of cases where it is more imprtant to have a constant frame rate rather than a varied fast(er?) one. A frame that takes 8 ms followed by one that takes 40, followed by 15, is going to create a noticeable stutter in the animation/gameplay. This stutter is often more visually irritating than a game running at a low constant, say 25 fps.

I lock my FPS at the highest value likely able to be maintained by the detected hardware consistantly. During frames which complete faster than required, I spend the extra time performing operations which will speed up further frames. The app performs memory management, list sorting, potential set updating for textures and models, etc. So in short; Theres no Sleep() for the wicked.

Slymaelstrom, I though I told in first place how I already knew that you should Sleep() once the rendering is done... I know that! thanks anyway

Lightatdawn, I had never thought about this! I like your idea! Its a good idea to prepare next frames while you still can...!

I must add that in the mean while I found a solution to fps... you can also change the global speed for every thing in your game depending on the framerate. But I suppose that in 3d animations, it can get a little tricky...

Quote:

---

Originally Posted by mikahell

I must add that in the mean while I found a solution to fps... you can also change the global speed for every thing in your game depending on the framerate. But I suppose that in 3d animations, it can get a little tricky...

---

This works, but the main problem is that every movement/action/animation has to be modified by the framerate value. This is irrelevant if you're only doing a single action, but it becomes VERY relevent if your scene is complex and you have say, particle effects colliding with other dynamic objects and animated models, etc, etc. That one mult operation applied hundreds of times over the physics and animation of possibly hundreds of thousands of objects per frame can have an impact on framerate that may be undesirable.

So basically, whether this affects you depends on what kind of game (I assume its a game we're discussing, though its not actually been said) you're working on, and what your scene is going to constist of.

well, actually I am working on a game :p , but it's in 2D! (SDL)
It's certain that there are less lines of codes an more fps, but...
I found some problem even with my speed changing motion thing:

on 2D games, (from tests...) if you have a speed variable at 1.000
when you have 60fps, it sure won't really affect the calculations, but if your game is really optimised and you reach some 2500fps, (2D), then the calculation of motion will be less accurate depending on the floating point precision of that variable:
var = 1 when 60fps,
var = 60/2500 when 2500fps (could be some complex number...)

so we could opt for a variable of type "double", but in the end, after allllll our hard work, we will lose the gained fps because of the high floating-point precision calculation time :( :( :(

In an other order of idea :) , I don't think that (yet) we can make some games with high per-particle effects and collisions, but in the near future, maybe we'll have no limit to adding details in scenes without abusing of our lil' computers memory! :cool:

Thanks again