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.

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

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

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!

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)

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

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)

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

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?

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

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.

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.

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();

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