I as an amateur programmer have been learning to make games in the old 13h mode and encountered a problem with the speed the game runs. It runs incredibly fast, and putting a delay of about 1 ms will prevent the game to run smoothly. How can I make my game runs slower based on the CPU speed?
I can give you an example of what i use in my SDL game. Not sure if you use SDL though. You'll just have to substitute the timing functions if you dont use SDL.
Add this code in the main loop.
If you do not use SDL than you need to use functions that are equivelant to SDL_GetTicks() (measures the milliseconds since the game started or when the comp started) and SDL_Delay (freezes the game for a certain amount of milliseconds)Code:const unsigned int MAX_FRAMERATE = 1000 / 60; //we want to limit to 60 fps unsigned int frameStart = SDL_GetTicks(); //Do game stuff (drawing, update characters, etc) //Update(); //Redraw(); //Measure the duration and limit the fps unsigned int frameDuration = SDL_GetTicks() - frameStart; if(frameDuration < MAX_FRAMERATE) SDL_Delay(MAX_FRAMERATE - frameDuration); //Call delay (like Sleep() in windows)
Last edited by 39ster; 05-28-2008 at 01:26 AM.
I hate fps limiting. You should be using time based movement.
Better to use fps limit than eating up the entire cpu and gpu.
Originally Posted by Adak
Suggestions only,
- Synchronize your drawings with monitor retraces.
- Calibrate based on how much time each frame drawing takes.
- Now select an ideal frame rate and decide how much time to be in suspended mode.
- Sleep for that time to save processor time.
If you want to still develop ancient DOS games, run them under DOSBox
I use both in my game.Than just multiply all the movement stuff by deltaTimeCode:const float DELTA_RATE = 1000 / 60; const float MAX_FRAMERATE = 1000 / 60; //main loop unsigned int frameStart = SDL_GetTicks(); //do stuff //Update(deltaTime) //Redraw() //Measure the duration and limit the fps float frameDuration = SDL_GetTicks() - frameStart; if(frameDuration < MAX_FRAMERATE) SDL_Delay(int(MAX_FRAMERATE - frameDuration)); //Now measure the duration after frame rate limiting to calculate delta time frameDuration = SDL_GetTicks() - frameStart; deltaTime = frameDuration / DELTA_RATE;
Meh. I'm in the "make use of everything you can" camp when it comes to writing games. Doesn't every game use 100% CPU (according to task manager)?
Good class architecture is not like a Swiss Army Knife; it should be more like a well balanced throwing knife.
- Mike McShaffry
50% if it's dual, but yes, most do, and it's bad™. Waste of resources.
Even worse in today's world where using many resources is bad (power saving all over the board, especially related to lower resource use).
You want 100% usage of the CPU in your games. When Direct3D goes full screen I'm fairly sure CPU jumps to 100% regardless of what you are doing. This is because the main loop is constantly executing which sucks up cycles. So the CPU is never really idle.
If you are below 100% then something is amiss since in a game you have basically told Windows to take a hike while you hog the system resources. Funny thing is Windows actually lets you do it. Multi-threading will change this usage as well as the number of cores you have which has been mentioned already.
The one suggestion that will severely limit the number of frames is the wait for vertical retrace suggestion. If you v-sync the renders then the max frames you will ever get is the refresh rate of the monitor.
60Hz - 60 FPS
75Hz - 75 FPS
85Hz - 85 FPS
100Hz - 100 FPS
But you should not have to limit the frames if you are using delta times from frame to frame. You need to know how much time the previous frame took to render and pass that delta to your update function. This way your object movement's are in sync with your framerate.
Im not sure but how would limiting the fps with SDL_Delay/Sleep hog resources? Wouldnt that give cpu back to other programs running? Why not limit the FPS to 60 and use delta timing (for when the FPS goes below 60)?
Last edited by 39ster; 05-28-2008 at 11:30 PM.
Theoretically, of course, but if the framerate is limited, there is a also a limit as to how much the program can do while the graphics aren't progressing. Thus it should be able to sleep until it gets some work to do.
That's what I call saving cpu and gpu cycles. And that's something I very much like to see. Just because it's a game doesn't mean you can get away with inefficient programs.
> there is a also a limit as to how much the program can do while the graphics aren't progressing.
Not really... There is always something to be done. Such as checking input, other misc. events.
> Thus it should be able to sleep until it gets some work to do.
Problem with sleeping is, what if Windows is busy? And doesn't return for a while... are you going to sleep every frame also?
Sleeping is a bad idea
Well, if the priority is knocked up and a few sleeps here and there are done, then it shouldn't knock any time slices off.
Just a few milliseconds is enough to bring cpu use down to reasonable levels.
Is it possible? Certainly. Is it easy? Well, that's another matter, but certainly one they should proceed to solve I think.
There is no problem with 100%. Games take over the system as they should. Hence the whole concept of full screen is to immerse the player in the game. They could care less about IMs, Word, or anything else running in the background.
Games take 100%. Sleeping is absurd. The reason there isn't a rush to correct this 'problem' is because it is not viewed as a problem. All of my modern games push my CPU usage to 100%.
