# Problem: Too fast FPS in demo's from tutorials

## Recommended Posts

Mapster87    122
It was hard to fiind a subject to describe my problem properly. Anyways, my problem is that when I run the examples you get in the tutorials they tend to run extremely fast, that is so fast that it's beyond 999fps. Is there anyway to solve this? I'm now on lesson 11 and the waves on the texture are so fast that it's damn ugly to look at.

##### Share on other sites
nefthy    184
mesure the time it took to render the last frame (lets call it delta), then sleep for 1 / FRAME_RATE - delta.

Note that you need both sleep and time quering functions with good precisission for this to work (getimeofday, usleep on Unix systems).

alternatively you can calculate when the next frame should be drawn and add an idle loop at the end of you rendering code that does nothing as long as the current time is less than what you calculated for the next frame.

##### Share on other sites
Mapster87    122
Thx... I solved the problem, I made a simple function using the time.h header.
It doesn't contain any calculation of current framerate, all it does is run a loop for a given number of milliseconds, the given number is of your choosing. It works fine in theese simple turtorials at least. You just guess your way to a fitting number, to obtain the framerate you want.

void SlowdownFPS(int fps){		clock_t endwait;	int waitMs = 1000/fps;	endwait = clock() + utvid;	while (clock() < endwait) {}}

##### Share on other sites
nefthy    184
Oh, by FRAME_RATE I meant the limit you want to set for the framerate. For more complicated sceens (or if you target a wide array of hardware) it makes sence to take the time that the last frame took to render into account. Calculating the delta ist equivalent to 2 cals to clock and a substraction. So it isn't that much of an overhead.

busy wait is considered ok for games, but I still prefere sleep. Its nice if some long running process that runs in the backround still gets the uneeded processor time.

##### Share on other sites
Kalasjniekof    246
Quote:
 Original post by Mapster87Thx... I solved the problem, I made a simple function using the time.h header.It doesn't contain any calculation of current framerate, all it does is run a loop for a given number of milliseconds, the given number is of your choosing. It works fine in theese simple turtorials at least. You just guess your way to a fitting number, to obtain the framerate you want.void SlowdownFPS(int fps){ clock_t endwait; int waitMs = 1000/fps; endwait = clock() + utvid; while (clock() < endwait) {}}

For demo's/tutorials your solution is good enough. For games this would be a waste, as you are just throwing your cpu-cycles away. Most games use time-based animations, try searching for it on the forums.

##### Share on other sites
Boder    938
Just force vsync on your graphics drivers.

If you need help doing this, do you have ATI or NVIDIA?

##### Share on other sites
mapster    122
I don't have much experience in programming and I ran into a problem with measuring the time it took to render the last frame. I don't know how to convert the clock_t form to an int.

Anyways, I know it isn't good enough for a game, but at the moment I don't know a percent of what I need to make a game, though that's my goal.

edit:
Ahh.. that was another solution. worked fine that too Boder.

[Edited by - mapster on April 18, 2006 1:17:27 PM]

##### Share on other sites
VSync will be better for you, the method you were using works fine, but won't behave well on different hardware (or even on your own hardware if other tasks are taking up system resources as well).

##### Share on other sites
mapster    122
This sleep function you speak of nefthy, where do I find information about it?

##### Share on other sites
lc_overlord    436
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/sleep.asp

##### Share on other sites
mapster    122
Thx :D

Nice performance improvement with a sleep function instead of a while loop :D
My game's cpu usage went from 90-94% to 1-2%...

[Edited by - mapster on April 27, 2006 3:23:53 PM]

##### Share on other sites
nife    235
Quote:
 Original post by mapsterThx :DNice performance improvement with a sleep function instead of a while loop :DMy game's cpu usage went from 90-94% to 1-2%...

That's not a good thing, and you'll learn that later on. 100% cpu time only means you're using all the power, you can get, which is also what you should be doing, not throwing cycles away. Normally you'd only be doing a fixed physics update (or updates based on delta-time, but that will cause even more instabilities in the long run because of the floating point accuracy), while the rendering and the main loop processing itself will run as fast as possible to acheive the fastest fps possible.

Not that it's a problem now, I'm just informing you about it, so you are aware of it, when you start to dig deeper into the games ;)

EDIT: Oh btw, a call to Sleep(0) (when timeBeginPeriod(1) and timeEndPeriod(1) has been called in init/exit functions) would be a good thing to have when you're using 100%, since other threads then get a timeslice if they need it (otherwise you could risc to stall the users' computers, if they're running other programs, and that certainly wouldn't be the best option :/).

##### Share on other sites
lc_overlord    436
Quote:
 Original post by nifeThat's not a good thing, and you'll learn that later on. 100% cpu time only means you're using all the power, you can get, which is also what you should be doing, not throwing cycles away.

But you allready are, a program that runns at a higher speed then the monitor refresh rate do waste a lot of cycles, so adding a small sleep function there to cap the max fps is not a problem, just don't cap it to much.
It's better to use v-sync here though if you know how to.

Quote:
 Original post by nifeNormally you'd only be doing a fixed physics update (or updates based on delta-time, but that will cause even more instabilities in the long run because of the floating point accuracy), while the rendering and the main loop processing itself will run as fast as possible to acheive the fastest fps possible.

Would you see a diference if you ran the rendering loop at the speed of the physics updates or faster than the physics updates?

##### Share on other sites
Joni-Matti    138
Quote:
Original post by lc_overlord
Quote:
 Original post by nifeNormally you'd only be doing a fixed physics update (or updates based on delta-time, but that will cause even more instabilities in the long run because of the floating point accuracy), while the rendering and the main loop processing itself will run as fast as possible to acheive the fastest fps possible.

Would you see a diference if you ran the rendering loop at the speed of the physics updates or faster than the physics updates?

You would, if it is implemented correctly. For example, if physics update is limited to 30 fps and rendering is unlimited, you can update particle systems and time-based animations as fast as possible while the physics is updated only 30 times per second. You would certainly see a difference.

[Edited by - Joni-Matti on April 29, 2006 12:50:00 AM]

##### Share on other sites
lc_overlord    436
Sure, if you go that low, but physics behave badly when advanced in large timesteps, i would guess that at least 60 FPS is needed for physics.

Besides physics and timebased animations are better done at the same time since they are kinda conected to eachother.

##### Share on other sites
Joni-Matti    138
It was just an extreme example. Of course, 60 fps is practically minimum for the physics, which I use for my projects also. I think you could see the difference even if physics would be updated 60 fps.

[Edited by - Joni-Matti on April 29, 2006 1:04:17 AM]