hwo to make a game that doesn't use 99% cpu usage?
Author
it seems logical that you have to use some sort of loop for a game to continue. how is it that commercial games don't use 99% cpu usage, but all games i've seen source code for when i run them they use 99% cpu usage? do commercial games not use while loops somehow?
You need to tell your game to play nice with other running processes by suspending execution when there's nothing to be done. Take a look at the Sleep function.
Something like this would work:
Something like this would work:
while(true) { update stuff draw stuff Sleep(0); // surrender the rest of our time slice and give other processes a chance to run}
This is the timer cap I implemented into my SDL pong game just recently. I'm guessing the SDL_Delay() function is similar to the sleep() function, although I know the sleep function just hopes it gets processor time back after the given time - I'm not sure if SDL_Delay() does the same, or if it somehow definitely gets it back.
My cpu went from 100% with no framerate cap, to 6-8% after implementing the above at the bottom of the loop. Also don't forget to implement some kind of timer.start() at the top of the game loop, and perhaps a timer.stop() at the bottom (although this might just be wasted code/processor time depending on your implementation... I think it might be better to omit this if youre using a static timer class... disclaimer: this is only my third time writing a timer, and my first time doing it without any kind of guide, so for all I know I could be killing my computer ;))
Right now I'm trying to find out about game loops that don't cap the framerate, but still don't max out the cpu, I've got a few idea's but I'm having trouble finding any examples (I thought the quake3 code might be a good place to look but it's still a bit too massive for me to grasp such a main concept with).
while(timer.getTicks() < 1000 / timer.FRAMES_PER_SECOND) SDL_Delay((1000 / timer.FRAMES_PER_SECOND) - timer.getTicks());My cpu went from 100% with no framerate cap, to 6-8% after implementing the above at the bottom of the loop. Also don't forget to implement some kind of timer.start() at the top of the game loop, and perhaps a timer.stop() at the bottom (although this might just be wasted code/processor time depending on your implementation... I think it might be better to omit this if youre using a static timer class... disclaimer: this is only my third time writing a timer, and my first time doing it without any kind of guide, so for all I know I could be killing my computer ;))
Right now I'm trying to find out about game loops that don't cap the framerate, but still don't max out the cpu, I've got a few idea's but I'm having trouble finding any examples (I thought the quake3 code might be a good place to look but it's still a bit too massive for me to grasp such a main concept with).
There are many way to free the cpu from processing your game loop.
The idea is to give the control back to the OS after you're done updating your game.
The easiest way is to process it only when theres an input (from the user, from internet, or any internal OS messages)
Its good for card games and suchs, as you dont need to update while the user is idle (only for music or animations etc)
You can also use a timer to call your game loop.. kinda not the best solution except for demos or screensavers ...
The usual way is to use the Vertical-Sync (formely WaitRefresh) from the monitor.
This way, your game give back the control to other process after the current screen have been updated, usually 60 times per seconds.
Who you do that depends on what language and OS you are using.
The idea is to give the control back to the OS after you're done updating your game.
The easiest way is to process it only when theres an input (from the user, from internet, or any internal OS messages)
Its good for card games and suchs, as you dont need to update while the user is idle (only for music or animations etc)
You can also use a timer to call your game loop.. kinda not the best solution except for demos or screensavers ...
The usual way is to use the Vertical-Sync (formely WaitRefresh) from the monitor.
This way, your game give back the control to other process after the current screen have been updated, usually 60 times per seconds.
Who you do that depends on what language and OS you are using.
imho synchronization between processes isn't related to suspending the process. The SO scheduler is responsible to give each process a cpu time. Its natural that a game consumes 99% cpu when in fullscreen and there is no reason to consume less. In your loop you need to check if the game window is active (for example) and minimize if it loose focus and stop the rendering process, while managing other resources, like network and game entities. This way when you switch windows the game is less gpu consumer. Also, you can synchronize the rendering process and resource comunication because this way the SO scheduler can efectivly swicth for other processes distributing the cpu cycles. Its up to the scheduler to choose the process and run it for a while and then for other process. I also suggest threads for better schyncronization (than a single loop) and condition variables. However this introduces some higher complexity on programming design.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
