hi again.
ok, this is surely once again THE CLASSICAL QUESTIOn about CPU weight and allegro and blablablabla.

I begin without the app:
{"name":"state0.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/0\/5076464c4a2ed765dbb2a2fdd59a9e3a.jpg","w":511,"h":500,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/0\/5076464c4a2ed765dbb2a2fdd59a9e3a"}

The old version, without any rest(1) nor timer function:
{"name":"schwz3_state.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/3\/83af845627c7ee305ada2bea96a85b09.jpg","w":992,"h":468,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/3\/83af845627c7ee305ada2bea96a85b09"}

I have put in my main loop a rest of 1 sec, and putted in volatile funct activated by the timer all my printing to screen.
Notice here that I have only a poor bmp of 32k and less for mouse cursor...

Modification to the program with a rest and timer function, FPS 100:
{"name":"fps100.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/5\/45dac6f09ba88ffcdcb54dd614e4603a.jpg","w":962,"h":435,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/5\/45dac6f09ba88ffcdcb54dd614e4603a"}

FPS 50:
{"name":"fps50.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/d\/ad05f6a1c21056bbebca180a3c788b4b.jpg","w":955,"h":447,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/d\/ad05f6a1c21056bbebca180a3c788b4b"}

Here is part of the code, I do not arrive to do less to not charge the CPU. Any idea ?

umpf !!!

Chris, n'appelle install_int_ex qu'une seule fois ! et en dehors de la boucle while !

Apres quoi tu pourras boucler sur ton rest(1); tranquillement !

First of all you shouldn't be doing so much work in a timer function. Setting a flag or incrementing a counter and responding to it in the game loop is the preferred (and feasible) approach. I'm not sure why you repeatedly call install_int_ex, but that seems shifty as well...

I'm surprised that doesn't outright crash, what with Allegro's notorious thread unsafety and all.

You can attempt to rest() for more than 1ms at once.
Try 5, 10, 15, 20.

edit
As for the drawing part, chances are the biggest job for the CPU is the

blit(buffer,screen,0,0,0,0,442,442);

Considering that less than 10% of the screen surface may have changed, you could just blit these parts individually, like a "dirty rectangles" system.

(Additionally, you can memorize if these screen parts HAVE changed at all. For example, the top text: No need to redraw the paragraph if it has the same content as when it was last redrawn.)

Is it Tuesday again?

Voyez: http://wiki.allegro.cc/Timers#Yielding_the_CPU

Are there any advantages of using semaphores over normal high-res timers?

ooooups, i didn t know it was an error, I have an hudge programm wich is running with install_ex inside of the main loop since 4 years of dev... without any error i mean errors of timers (and its real time manipulation)...

but its still doing nothing o my troubles of CPU...
with:

     while (index_quit==0)
     {
     rest(1);
//nothing... but refreshment is done in the volatile as previous and first code

     }

CPU weight is still from 41 % and up to 70%

{"name":"outofloop.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/3\/032ede2c76a20c40b9e54221cb2392ea.jpg","w":983,"h":510,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/3\/032ede2c76a20c40b9e54221cb2392ea"}

so? I mean install_ex is there tomake use of timer in an easy manner, to avoid calculations of tclock ?

install_int* granularity can vary from 1 msec to 14-20 msec

Yay. Someone asked the RIGHT question.

Why did i use a locking semaphore? Because allegro timers spawn their own thread, wake it up, run user code (increment value), and then go back to sleep.

I used a semaphore because i wanted to put the mail loop to sleep and have the timer wake it up like it should happen. You only want your main loop to execute when the timer beeps! Allegro timer simplifies this possibility away but certain operating systems (not all) libraries can handle this without a problem.

Rest is basically a way to stop constant spin locking by taking shifts. It will tell the operating system to put the thread to sleep... but only for a really short time. It then checks again.. whenever the operating system feels like it. It may check almost right away (bad because more cpu wasted) but the general rule of thumb is that rest is only accurate to within 15ms.

To summarize: rest still wastes tons of cpu. It constantly wakes up and goes back to sleep.

With my locking mechanism i can get my own (graphically simple) allegrogl games to use < 1% cpu.

That's really cool Goalie Ca, but how portable is it...? Will your example work on Windows and Linux? Do you need to install third party libraries or anything?

If your OS is posix then you have it. All linux, mac, and older winnt. For new windows you need to download pthread. http://sourceware.org/pthreads-win32/
If you really wanted to you could use windows locking mechanism. It is in winapi and does the same thing.

I guess I will attempt to learn to use semaphores then. Until then, here is my revised raw timer template...

To compile it the following commands should work (you must have Allegro installed).

Windows/MinGW: gcc -O2 fps.c -o fps.exe -lalleg

*nix/GCC: gcc -O2 fps.c -o fps $(allegro-config --libs)

Simple. A semaphore is like a locking counter. I've pasted the code i wrote to the wiki and have added a few useful comments. Basically main goes to sleep, ticker wakes it up. No wasted cycles, no extra context switches, no spinlocks.

OK finally I founded why it was taking so many weight in memory:
im using

   if(set_display_switch_mode(SWITCH_BACKGROUND))
  {set_display_switch_mode(SWITCH_BACKAMNESIA);}

to enable the visual refreshing of information if I m not on its window.
... oups !

while(game_on){
    sem_wait(&ticks); //decreases count, goes to sleep if count < 0, wakes back up when count >= 0 (through sem_post)
    update_stuff();
    draw_stuff();
}

If you want to do frameskipping, this should work:

while(game_on){
    sem_wait(&ticks);
    do {
        update_stuff();
    } while(sem_trywait(&ticks) == 0);
    draw_stuff();
}

MAOUW its nice, but it need to run , while its not on nor selected.
So in fact putting in an install_ex routines enable not to freeze the tasks, just the screen refreshment is not done ( wich take a HUDGE place in mem)

A lot of the crashieness was "fixed" in the last release or two. But it means theres a ton of locking and unlocking going on, slowing things down and potentially using lots of cpu. That doesn't mean you should use the same allegro resources from multiple thread (in fact you probably shouldn't), unless you're absolutely sure you know what you're doing.

To compile it the following commands should work (you must have Allegro [and pthreads installed - Windows users, this probably means you]).

Windows/MinGW: gcc -O2 fps2.c -o fps2.exe -lalleg -lpthreadGC2

*nix/GCC: gcc -O2 fps2.c -o fps2.exe $(allegro-config --libs) -lpthread

never crashed... 4 years this damn calling inside main loop... hundred of performances and theatre play without crash...

well, or people have made studies, and better than say'until you know what you are doing' they can explain WHY and HOW ( more constructiv), or they didn t ... no ?

I don't understand a thing you just said.

However, what i meant was, if you know the issues inherent with threading, and know what to work around them, do as you please.

On a side note, should a semaphore (sem_t) be volatile?

No. Just ignore that keyword. It doesn't do what most people think it does.

Actually it relies on a special CPU instruction called (roughly) "test and set lock". It is an entirely atomic operation. sem_t itself is a struct.

Is this not what it does?

He must be referring to the fact that people assume volatile is atomic. That is it reads, processes, and writes back.

I think of Volatile as the (sort of) opposite of "register". That is, this is not to be cached in a register. Write-through!!! Read too!

Thanks, Goalie Ca! My raw Allegro timer example uses approximately 20% CPU. The modified version implementing pthreads/semaphores is using 3-5% CPU.

** EDIT **

I may have spoken too soon. The 20% CPU usage was seen on another system. My home system is actually using a very similar amount of CPU with raw Allegro timers...

Also, see this: http://kerneltrap.org/Linux/Volatile_Superstition

rest() will vary from system to system. It is dependant on the operating system scheduler. It may even vary from session to session. Might vary if you run it in win2k instead of vista.

I also wonder about pthread performance on windows. Windows does not have native posix threading. Windows threads will have to be "Wrapped" in order to have the necessary behaviour.

I can take my code and run it on a junker linux system and it will use < 1%.

BTW, is there a way to do this without relying on an Allegro timer? It's just that if you're trying to move away from a while(waiting) rest(1); loop, that's basically what Allegro's timers do. Though the timer thread does attempt to use precise resting, and calculating the rest time 'til it needs to wake up next, it still won't get any more accurate than 75 to 100 fps (since once it goes to sleep, the thread won't wake up again for about 10ms, which maxes you out at 100 tics per second; and if you're trying for 100fps, then you're not getting any better than a rest(1) anyway.. or worse, rest past the intended wakeup time causing an additional 10ms delay; then add the overhead of the callback loop itself, plus other timers trying to run..).

Obviously there'd be no portable way to do it, but I think having the system interrupt and call into your process at specific intervals to do a simple sem_post wouldn't be too hard to wrap.

Hmm.. that's good food for thought. I would have thought the allegro timers would use the underlying operating system ones (eg: windows highperformance timer). Granted.. none are "real-time" but they are pretty accurate nonetheless.

Allegro is in desperate need of threading tools and primitives. Not to be the devil here but SDL has a built-in pthread-like interface. Allegro5 better hurry up. DNF depends on it! I think DOS support is the real problem here holding a lot of this stuff back. Please correct me if i'm wrong.

Allegro has an internal cross platform'ish api.

They do use the high-precision timing methods when possible, but the granularity of the sleep method is the problem. Whether it tries to sleep 1 nanosecond* or one millisecond, the thread will stay down until it gets a timeslice again, which would be in about 10ms. Having the system interrupt your process on time would be the only way to break that.

(*) Sometimes nanosleep will actually busy wait on really small rest values (a few nanoseconds) depending on the system configuration.

So i've gone ahead and wrote a windows/linux/mac timer file that doesn't use allegro. The *nix one uses real-time posix extensions and the windows one uses the multimedia timer set to 1ms accuracy. Both use a semaphore mechanism to wake/sleep.

I've posted it here.
http://www.allegro.cc/forums/thread/594745

edit: no need for windows pthread anymore. THe windows version uses windows own locking mechanism.

At your service.
Allegro 5 doesn't have DOS support, unless someone comes along and wants to do the work to try to fit it in somehow.