Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » The age-old 100% CPU usage problem - but still no solution

Credits go to BAF, CGamesPlay, gnolam, Goalie Ca, GullRaDriel, Hard Rock, Kibiz0r, Kitty Cat, Kris Asick, Steve++, and Thomas Harte for helping out!
This thread is locked; no one can reply to it. rss feed Print
 1   2 
The age-old 100% CPU usage problem - but still no solution
jamyskis
Member #6,557
November 2005
avatar

Hi all,

I'm back on the forum after a long absence due to (ahem!) illness, this time with an age old question which I see posted on this forum dozens of times but never really explained in a way I could understand. I've managed to fix the speed of my game, but performance is choppy because, for whatever reason, the CPU is taking up 100% of the time. I've made the game logic updates event-based, so they are called by an interrupt at regular intervals, and I've tried cutting out the game_display() (the function that contains all the code dealing with drawing the screen) completely to see if the drawing was taking too much time (it throws around 50-60 sprites at a time so it would be understandable, especially under Linux with no GFX hardware acceleration). Without any drawing functions, the game still swallows up 100% CPU time.

This is the main.cc as it stands:

1/* Open Invaders
2 * (c) 2006 Darryl LeCount
3 *
4 *
5 * This program is free software; you can redistribute it and/or modify
6 * it under the terms of the GNU General Public License as published by
7 * the Free Software Foundation; either version 2 of the License, or
8 * (at your option) any later version.
9 *
10 * This program is distributed in the hope that it will be useful,
11 * but WITHOUT ANY WARRANTY; without even the implied warranty of
12 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
13 * GNU General Public License for more details.
14 *
15 * You should have received a copy of the GNU General Public License
16 * along with this program; if not, write to the Free Software
17 * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
18 */
19 
20#include "allegro.h"
21#include "functions.h"
22//#include "./alogg/alogg.h"
23#include <iostream>
24
25int fullscreen_mode, frames_missed;
26 
27using namespace std;
28 
29void interrupt_time_control()
30{
31 frames_missed++;
32};
33 
34END_OF_FUNCTION(interrupt_time_control);
35 
36int main(int argc, char *argv[])
37{
38 LOCK_FUNCTION(interrupt_keys);
39 LOCK_FUNCTION(interrupt_time_control);
40
41 LOCK_VARIABLE(frames_missed);
42
43 frames_missed=0;
44 fullscreen_mode=0;
45
46 if(argc>1)
47 {
48 if(argv[1][0]=='-')
49 {
50 fullscreen_mode=0;
51
52 switch(argv[1][1])
53 {
54 case 'f': fullscreen_mode=1; break;
55 case 'w': fullscreen_mode=2; break;
56 };
57 };
58 };
59
60 initialise_game();
61 cout << "Allegro initialised...\n";
62
63 display_setup(fullscreen_mode);
64 cout << "Allegro display established...\n";
65
66 predefine_variables();
67 create_bitmasks();
68 cout << "Collision bitmasks initialised...\n";
69 
70 cout << "Have fun!\n";
71
72 intro_sequence();
73
74 while(program_still_active())
75 {
76 title_screen();
77 predefine_variables();
78 reset_enemies_position();
79 reset_enemies_state();
80 initialise_ingame_music();
81 install_int(interrupt_time_control,4);
82
83 while(game_still_active())
84 {
85 for(int repeats=0;repeats<frames_missed;repeats++)
86 {
87 update_logic();
88 };
89
90 game_display();
91
92 frames_missed=0;
93
94 rest(1);
95 vsync();
96 };
97 };
98
99 cout << "Thank you for playing!\n";
100
101 allegro_exit();
102};
103END_OF_MAIN();

Interrupt_keys() looks thus:

1void interrupt_keys()
2{
3 char nameext[20];
4
5 if(key[KEY_LCONTROL]&&key[KEY_S])
6 {
7 sprintf(nameext,"oi_screen_%d.bmp",(rand()%8998)+1000);
8 save_bitmap(nameext,screen,gamepalette);
9 };
10
11 if(key[KEY_LCONTROL]&&key[KEY_C])
12 {
13 program_active=false;
14 game_active=false;
15 abort();
16 };
17};

Interrupt_time_control() is just this:

void interrupt_time_control()
{
  frames_missed++;
};

I've been playing with this for months and am just about ready to chuck it in and delete the lot. Can anyone give me a hand as to why I can't stabilise the frame rate and drop the CPU usage? If there's anything else I should paste in let me know.

Thanks!

Darryl

__________________________________________________________________
In a world without fences and walls, who needs Windows and Gates?
http://www.jamyskis.net

Hard Rock
Member #1,547
September 2001
avatar

Thats because by default your program will use 100% of the cpu even if its just repeating a loop. Thats because it's not just repeating the loop, but repeating it as fast as possible.

To give up CPU cycles for other programs you need to call rest or you can also use sleep although I'm not sure which header the latter is in, too much java programming :S

Anyway more on rest: http://alleg.sourceforge.net/stabledocs/en/alleg005.html#rest

[edit]

Woops just noticed you had a rest. Drop vysc. I believe some forum posters mentioned that vysnc would allow timing, but also consume 100% cpu usage while it did. As vsyc doesn't return until its done, rest literally only gets called 60 times per second, if that.

[edit2]
There was also just recently a post on sample game loops, though it's not 100% relevant, and looking through it I didn't really find any stellar examples (most of it is psuedo code) it might help. http://www.allegro.cc/forums/thread/590871

[edit3]
If neither of these helps, I'll take my GWARA Tins entry, and modify it so it doesn't use 100% cpu and post the updated code. Or try to at least. Just let me know.

_________________________________________________
Hard Rock
[ Stars Dev Company ][ Twitter ][Global Warming: ARA My TINS 07 Entry][Pong Ultra Website][GifAllegS Ver 1.07]
"Well there's also coolwebsearch but we'll let that be an IE exclusive feature" - arielb on the New Browser Plugins "What's better, HTML or Variables?"

Kris Asick
Member #1,424
July 2001

Your frame dropping algorithm fails to take into account if the logic processing is taking too long. Frame dropping cures when the rendering takes too long, but if the logic is taking to long, more logic updates will be requested while logic is being processed, resulting in potentially large amounts of logic loops per frame, which is possibly the source of your framerate troubles and your 100% CPU usage.

What you need to do is put a limit to how many logic updates you'll allow on one game loop. 4 is a good limit. This prevents your logic loop from over-processing, which will result in slow-down if your system can't handle the amount of logic that needs to be processed, but that will be true of any game using fixed-time logic.

You may also want to check and make sure you're not running 32-bit graphics. 16-bit graphics will run almost twice as fast as 32-bit on any system. Also, avoid strange colour depths such as 15-bit or 24-bit which may invoke compatability layers if your video card can't handle them by default.

Also, vsync() will not eat up so much CPU time that you'll get 100% usage so long as you have rest() or Sleep() statements to give time back to the OS. However, you should place your rest() statement immediately after rendering, not right before vsyncing.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

--- Kris Asick (Gemini)
--- http://www.pixelships.com

Goalie Ca
Member #2,579
July 2002
avatar

While your program is running it counts towards using cpu's. Yielding/resting will tell the operating system to stop running your program for the time being. While its doing nothing it is using 0%.

Here is a fix that shouldn't affect any thing. It works exactly the same except that when the count is 0 it returns to the operating system. When the count goes back above 0 it wake the process up. Just replace sdl_semaphore with one from your operating system be it windows or linux (i can help you if you need).I used the evil sdl because allegro has nothing similar/portable IIRC.

//the timer function. basically SemPort will "increment" the tick variable. 
Uint32 SDLTimer_Callback(Uint32 interval, void* param)
{
  SDL_SemPost(sleepSemaphore); //will wake up the other thread. "increments" the count
  return interval;
}  

//the main loop
while ( !quitMe )
{
  SDL_SemWait(sleepSemaphore); //sleeps if count = 0, when it is no longer 0 it wakes up and decrements the count
  gameLogic();
}

edit: i should explain that sleepSemaphore is basically just a counter. It is used for synchronizing between threads but this works perfectly fine in a situation like this. This uses < 1% of my cpu in most cases (also opengl for hardware drawing helps!)

edit2: rest(1) doesn't sleep 1ms esp on windows. Windows is not a real-time operating system. You'll only get accuracy to ~ 10ms or so. SO like 10ms 20ms 30ms etc...

-------------
Bah weep granah weep nini bong!

Kitty Cat
Member #2,815
October 2002
avatar

Quote:

I used the evil sdl because allegro has nothing similar/portable IIRC.

But there's aready a perfectly valid and portable way to do it already...

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

gnolam
Member #2,030
March 2002
avatar

And where might semaphore.h be in MinGW? In MSVS?

--
Move to the Democratic People's Republic of Vivendi Universal (formerly known as Sweden) - officially democracy- and privacy-free since 2008-06-18!

Kitty Cat
Member #2,815
October 2002
avatar

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Goalie Ca
Member #2,579
July 2002
avatar

Actually that's pretty good thing. Windows is the only platform (other than embedded) that doesn't support pthreads). The only reason why i didn't use sem_wait was because almost all n00bs who post use windows. It's a fact! But I hope that works for vc (or whatever they used).

If it does... then its about time to make a wiki entry and end this line of threads once and for all!

-------------
Bah weep granah weep nini bong!

Steve++
Member #1,816
January 2002

Quote:

The only reason why i didn't use sem_wait was because almost everyone who posts uses windows.

Fixed :)

A game with real-time performance requirements using 100% CPU time isn't a problem in itself. In fact, when your game yields its current timeslice to the OS, it must wait until the OS's next round of scheduling. That may be ok for tic-tac-toe. How demanding do you think your game will be on the CPU?

Goalie Ca
Member #2,579
July 2002
avatar

Putting the thread to sleep and then waking it up is not a problem. In fact since timer is run in a seperate thread it gets woken up, then you have to reschedule the main loop thread anyways. When the sem_post occurs it changes the threads state to ready... the same as it would be if it was pre-empted because its time slice expired.

Windows is not real-time, not anything close... so you have to live with what you get i suppose. I guess this is why the thread about delta timing came up where you use getTimeOfDay() and find out how much time really elapsed (in milliseconds). But there are problems with pausing and scheduling (if you're relying upon small differences rather than averages then you'd need to lock everything up during that computation sequence)

-------------
Bah weep granah weep nini bong!

Thomas Harte
Member #33
April 2000
avatar

Quote:

A game with real-time performance requirements using 100% CPU time isn't a problem in itself.

If your game is going to make my fans come on, it had better look like Half-Life 2 or I won't be loading it again.

Goalie Ca
Member #2,579
July 2002
avatar

I sucked it in and wrote an allegro wiki entry under timers. http://wiki.allegro.cc/Timers#Yielding_the_CPU

edit: and some simple test code to measure performance. Here's what time outputs:
real 0m59.941s
user 0m0.040s
sys 0m0.012s

So it spends 1 minute of real time.. It spends 0.012 seconds doing system calls. It spends 0.040 seconds actually executing my code! I think that's a pretty good start :D

That gives a cpu usage of basically 0% (it uses 1.2% of a single second.. now divide that by 60 to get the actual rate)

1 
2#include <allegro.h>
3#include <semaphore.h>
4//for printing seconds since 1970 or whatever
5#include <stdlib.h>
6 
7//number of cycles per second
8#define BPS 60
9 
10//create the mutex
11sem_t timer_sem;
12 
13void ticker(void)
14{
15 sem_post(&timer_sem);
16}
17END_OF_FUNCTION(ticker);
18 
19 
20int main(int argc, char** argv)
21{
22 sem_init(&timer_sem, 0, 1); //initialize the semaphore, set the tick count to 1
23 allegro_init();
24 
25 LOCK_FUNCTION(ticker);
26 
27 install_timer();
28 install_keyboard();
29 set_color_depth(24);
30 set_gfx_mode(GFX_AUTODETECT_WINDOWED, 640, 480, 0, 0);
31 install_int_ex(ticker, BPS_TO_TIMER(BPS));
32 unsigned char doLoop = 0xFF;
33 
34 while(doLoop)
35 {
36 sem_wait(&timer_sem);
37 if (key[KEY_ESC])
38 doLoop = 0;
39 //do stuff here
40 rectfill(screen, 1, 1, 200, 20, makecol(0,0,0) );
41 textprintf_ex(screen, font, 10, 10, makecol(255, 100, 200),-1, "Time: %d", time(NULL) );
42 //end of loop!
43 }
44 
45 return 0;
46}
47END_OF_MAIN();

-------------
Bah weep granah weep nini bong!

CGamesPlay
Member #2,559
July 2002
avatar

The thing about sem_wait is that if it gets behind, you get really funny speedups as it plays catch-up.

--
Tomasu: Every time you read this: hugging!

Ryan Patterson - <http://cgamesplay.com/>

Kibiz0r
Member #6,203
September 2005
avatar

Like when you alt-tab back to Diablo 2 after leaving it minimized for a few seconds?

GullRaDriel
Member #3,861
September 2003
avatar

Kibizor said:

Like when you alt-tab back to Diablo 2 after leaving it minimized for a few seconds?

Like that.

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

jamyskis
Member #6,557
November 2005
avatar

OK, this is the third time I've typed this answer...Allegro.cc keeps logging me out for whatever reason and the answer gets lost...

Anyway, the only solution I've found that effectively yields the CPU is to omit the vsync() and include rest(1). However, update_logic() was then executed so seldomly that frames_missed got really high and as a result I had frame rates of around 1 frame every five seconds. I tried limiting frames_missed to four, but that just made the game extremely slow and extremely choppy, although CPU usage was at about 80% there.

Edit: I've just noticed that the title screen, which displays a large sprite in the middle of the screen, two textout_ex's and 500 pixel "stars" in the background is chomping up 90% CPU time on an Athlon 2400 - is Allegro's Linux graphics driver really that bad?

Edit 2: OK, I have the game running doing everything except blitting the backbuffer to the screen, and it runs at a fairly respectable 45% CPU usage. As soon as I do blit(display,screen,0,0,0,0,800,600) though, it just flats out to 90-95%...isn't there a faster way to blit display to screen?

__________________________________________________________________
In a world without fences and walls, who needs Windows and Gates?
http://www.jamyskis.net

Goalie Ca
Member #2,579
July 2002
avatar

clippy says It looks like you are trying to profile a program. Would you like help?

a) use a profiler to actually determine how much time is spent in each function
b) understand how cpu time is measured and improve your yielding (rest doesn't cut it!)

-------------
Bah weep granah weep nini bong!

jamyskis
Member #6,557
November 2005
avatar

Thanks - I'll give it a go, if only to bring the 45% down a bit. Still, I'd love to know why a single Allegro function call is chomping up 50% of my CPU time. Just chopping out that single blit call brought it down from 95% to 45%...

__________________________________________________________________
In a world without fences and walls, who needs Windows and Gates?
http://www.jamyskis.net

Kitty Cat
Member #2,815
October 2002
avatar

Quote:

The thing about sem_wait is that if it gets behind, you get really funny speedups as it plays catch-up.

How so? Can't you do frame dropping?

sem_wait(&my_sem);
do {
    logic();
} while (sem_trywait(&my_sem) == 0);

draw();

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Goalie Ca
Member #2,579
July 2002
avatar

Quote:

I'll give it a go, if only to bring the 45% down a bit. Still, I'd love to know why a single Allegro function call is chomping up 50% of my CPU time. Just chopping out that single blit call brought it down from 95% to 45%..

What i actually mean is that how can you really be sure you're actually spending that much cpu time in a single blit. I really doubt it.

Rest is not an accurate function. Windows is not a real-time operating system (though linux has patches). This means that if you rest(1) it may take 20ms to return to the program or it may return right away, execute a loop, go to sleep, return right away, etc... This is all scheduling dependant.. so many adding a blit changes how windows schedules your process.

A profiler will actually tell you how much time you spend in each function. In my example code above. i have a simple rectfill.. When i change rectfill to cover the entire screen (with a gray colour) my cpu usage becomes:

real    1m0.350s
user    0m0.884s
sys     0m0.052s

So.. there's some expense in rectfill. Blitting should be comparable in runtime.

Now gprof (my profiler!) outputs: Clearly you can see that after just a

  %   cumulative   self              self     total           
 time   seconds   seconds    calls  Ts/call  Ts/call  name    
  0.00      0.00     0.00     4149     0.00     0.00  rectFill
  0.00      0.00     0.00     4149     0.00     0.00  textFill
  0.00      0.00     0.00        1     0.00     0.00  mainLoop

Now that's funny. The time spent is too small to accurately measure. :D

edit: there must be a way to do fixed width fonts in this forum!

edit2: thanks baf! and weird.. the post-preview doesn't use the same font.

-------------
Bah weep granah weep nini bong!

BAF
Member #2,981
December 2002
avatar

You can use the [pre][/pre] tags.

Pretty fixed widthness!

CGamesPlay
Member #2,559
July 2002
avatar

Quote:

How so? Can't you do frame dropping?

No, there's no way to set a semaphore to 0 again (aside from repeatedly polling it, so this would work, but looks ugly):

sem_wait(&sem);
while(sem_trywait(&sem) != -1);
logic();

--
Tomasu: Every time you read this: hugging!

Ryan Patterson - <http://cgamesplay.com/>

Kitty Cat
Member #2,815
October 2002
avatar

Frame dropping doesn't mean dropping logic frames, it means dropping rendered frames :P If you want to implement a maximum-allowed skip:

sem_wait(&my_sem);
do {
    logic();
while (sem_trywait(&my_sem) == 0 && ++skip < MAX_SKIP);

if (skip >= MAX_SKIP)
    while (sem_trywait(&my_sem) == 0) /* do nothing */;
skip = 0;

draw();

Alternatively, instead of the empty sem_trywait loop, you could destroy and re-init the semaphore, but that's likely not efficient.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

jamyskis
Member #6,557
November 2005
avatar

OK, I've profiled it, and I'm still trying to make head or tail of the output. The interesting bit seems to be:

  %   cumulative   self              self     total           
 time   seconds   seconds    calls  us/call  us/call  name    
 81.27      0.13     0.13                             pmask_load_func
  6.25      0.14     0.01     1762     5.68     5.68  check_for_next_level()
  6.25      0.15     0.01      875    11.43    11.43  display_background()
  6.25      0.16     0.01                             main
  0.00      0.16     0.00     1762     0.00     0.00  read_input()
  0.00      0.16     0.00     1762     0.00     0.00  process_ufo()
  0.00      0.16     0.00     1762     0.00     5.68  update_logic()
  0.00      0.16     0.00     1762     0.00     0.00  check_if_game_over()
  0.00      0.16     0.00     1762     0.00     0.00  collision_detection()
  0.00      0.16     0.00     1762     0.00     0.00  move_automatic_items()
  0.00      0.16     0.00     1762     0.00     0.00  check_if_extra_life_due()
  0.00      0.16     0.00     1762     0.00     0.00  process_enemy_projectiles()
  0.00      0.16     0.00      876     0.00     0.00  game_still_active()
  0.00      0.16     0.00      875     0.00    11.43  game_display()

pmask_load_func obviously belongs to pmask although I can't imagine why it reports it as taking up 81.27% of the processing time. Commenting out the call to collision_detection() (which contains the only references to pmask.h in the entire loop) does nothing for the performance, commenting out the blit call reduces usage by around 50%.

__________________________________________________________________
In a world without fences and walls, who needs Windows and Gates?
http://www.jamyskis.net

CGamesPlay
Member #2,559
July 2002
avatar

It looks like you just started the game and quit it and called it "profiling". You have to actually run the code for a while.

--
Tomasu: Every time you read this: hugging!

Ryan Patterson - <http://cgamesplay.com/>

 1   2 


Go to: