Page 1 of 1

Programming games to not use 100% CPU

Posted: Wed Jun 20, 2007 9:53 pm
by TheCoop
I've got a opengl/glut game that im touching up that always uses 100% of both CPUs whatever happens. How can I reduce the amount of CPU time the game uses?

Re: Programming games to not use 100% CPU

Posted: Wed Jun 20, 2007 10:44 pm
by Bill Cosby
TheCoop wrote:I've got a opengl/glut game that im touching up that always uses 100% of both CPUs whatever happens. How can I reduce the amount of CPU time the game uses?
Basically it is your game loop, if you run the loop unrestricted it will simply loop as fast and as often as possible, thus requiring the full CPU capabilities, so the idea is to run a check how often the game loop has been executed within a second or so, and define a frame rate (e.g. 30) and put the process (the loop) to sleep for the rest of the second, another advantage of this is that it will run on every PC with the same speed.

Posted: Wed Jun 20, 2007 10:58 pm
by TheCoop
wouldnt that cause a pause every second (or so) if the computer is very fast? What I've just put in is a timer that measures how long it takes to draw a frame, and calculates how long it should take to achieve a specific frame rate, and sleeps every frame for the difference between the two. Unfortunately, even with a high FPS (60) I still get slightly stuttery behaviour using this...

Posted: Wed Jun 20, 2007 11:35 pm
by Bill Cosby
TheCoop wrote:wouldnt that cause a pause every second (or so) if the computer is very fast?
The timer-offset- theory is a whole philosophy for itself :D I am not totally familiar with it, but you should be able to gather lots of information on this with google ;)
I remember reading about it in "Killer Game Programming in Java" from OReilly, if you can get your hands on it, it is interesting in this regard, but there surly are more sources for this information.
TheCoop wrote:What I've just put in is a timer that measures how long it takes to draw a frame, and calculates how long it should take to achieve a specific frame rate, and sleeps every frame for the difference between the two. Unfortunately, even with a high FPS (60) I still get slightly stuttery behaviour using this...
This can't be because of the sleep times though, it has to be the code that simply needs more time than it actually has, if you have 60 pictures per second which are periodical, the human eye can't see any stutter. As far as I remember your method to calculate the sleep times is right, another thing might be your timer, it might be that the timer gives inexact results, or better put not exact enough for your purpose :)

Posted: Fri Jun 29, 2007 12:34 pm
by o43
Bill Cosby wrote:
TheCoop wrote:wouldnt that cause a pause every second (or so) if the computer is very fast?
The timer-offset- theory is a whole philosophy for itself :D I am not totally familiar with it, but you should be able to gather lots of information on this with google ;)
I remember reading about it in "Killer Game Programming in Java" from OReilly, if you can get your hands on it, it is interesting in this regard, but there surly are more sources for this information.
TheCoop wrote:What I've just put in is a timer that measures how long it takes to draw a frame, and calculates how long it should take to achieve a specific frame rate, and sleeps every frame for the difference between the two. Unfortunately, even with a high FPS (60) I still get slightly stuttery behaviour using this...
This can't be because of the sleep times though, it has to be the code that simply needs more time than it actually has, if you have 60 pictures per second which are periodical, the human eye can't see any stutter. As far as I remember your method to calculate the sleep times is right, another thing might be your timer, it might be that the timer gives inexact results, or better put not exact enough for your purpose :)
Actually, it could be because of the sleep. When you sleep, your app tells the scheduler to let someone else execute code. It will only have the CPU back when the scheduler gives back the execution to your app. At that moment only, your app will test if the sleep is finished. That means that a sleep will last at least the minimal time that can be allocated by the scheduler to a process. I don't know the current value, but last time i checked, it was 50ms on one of my computers, which is 1/20 of a second!

Posted: Fri Jun 29, 2007 2:47 pm
by bobobo
Since you are programming in opengl/glut, there is a handy function called glutTimerFunc()

Typically, you'll want to compute how much time has elapsed since the last frame, and then call this function accordingly.
For example, if you want 50fps, each frame will last 20ms. Suppose that only 5ms have elapsed, then you need to wait 15ms. If your frame drawing/calculating function is called update(), then you'll call glutTimerFunc like this :
glutTimerFunc(15000, &update, 0)
This will make glut call your function update() after 15ms have elapsed.

SUbject

Posted: Sat Jun 30, 2007 6:52 pm
by nitinchaurasia09
Hi this is nitin i will tell you a lot in gaming