

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


The timer-offset- theory is a whole philosophy for itselfTheCoop wrote:wouldnt that cause a pause every second (or so) if the computer is very fast?
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 purposeTheCoop 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...
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!Bill Cosby wrote:The timer-offset- theory is a whole philosophy for itselfTheCoop wrote:wouldnt that cause a pause every second (or so) if the computer is very fast?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.
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 purposeTheCoop 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...
