Problem: Too fast FPS in demo's from tutorials

Started by
14 comments, last by Joni-Matti 17 years, 12 months ago
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]
Advertisement
Quote:Original post by mapster
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%...


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 :/).
Killers don't end up in jailThey end up on a high-score!
Quote:Original post by nife
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.

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 nife
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.

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


Quote:Original post by lc_overlord
Quote:Original post by nife
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.

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]
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.
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]

This topic is closed to new replies.

Advertisement