Agree. I was talking about my turn based game and also solo games.
When computer is fast enough, both mine and yours works perfectly.
When computer is too slow for the fps rate:
- mine: skips logic and frames -> slow game = entire timeline rendered
- yours: skip frames -> normal game = timeline complete, but only pieces of the timeline shown
Think mine option is better for turn based and solo games.

could be, dunno.

1st so = os (sorry, spanish SO -> english OS (Operating System))
It should read as: "The problem is that timeslice size changes from O.S. version, so its like rest(variable) IMO." you will rest un uncertain time, you dont know timeslice size and how far you are from the end of the timeslice.

Dont see why 'active' means 'inside logic', explain please

Yea, depends on who consumes the time, render or logic, and what you want to show.

Agree. Im using yield_timeslace.

Ok. My mistake then.

Nice thread by the way!

Actually that's the big problem with hardcoding the ticks per second in the game. Playing a game coded at 60fps on a 85Hz display mode looks very jerky (this is most noticeable in 3D games or 2D games with fast scrolling). One solution is to force display frequency, but not all video drivers allow it, or the user may have disallowed it, so it's not a perfect solution.

That's why most comercial games use a variable timing interval (they check how much time has passed since the last logic, using WinAPI's GetPerformanceTimer()). I haven't tried this method yet, but I'll certainly do. The general algorithm to move an object this way would be something like this:

Well I'm more confused now.

For example, to show a circle that change it color per loop.
If I want 60 different colors per second, how is the code?.

@ImLeftFooted

...
if(timer) {
timer-- // vs ++ 
...

This code works (some mistakes on lucaz code). Take it and play with RATE param (set to 60 or whatever u want).

Not exactly. Timers are events thrown 'n' times in a sec. Those 'n' times are also known as ticks. What the program is doing is firing 60 ticks per second.
Every tick (=every 16,6ms) you call timer++.
Every 'while' iteration is supposed to run faster than 16,6, so you get timer == 1 every 16ms, process it (thats if(timer) which means if(timer!=0)) and set timer to 0 again (timer--) inside the condition.
You wont enter the if(timer) condition again till a new tick is fired (and timer++ is done) -> you will enter it 60 times in a sec.

change

textprintf(screen, font, 10, 10, makecol(255,255,255), "Frame %d", color);
with
textprintf(screen, font, 10, 10, makecol(255,255,255), "Timer %d", timer);

you will notice that timer is always 1.

Don't draw in the logic loop.

while(playing) {
     while(timer > 0) {
            color++;
            timer--;
      }      
     circlefill(screen,screen->w/2,screen->h/2,50,color);
     rectfill(screen, 10, 10, 50, 20, 0);
     textprintf(screen, font, 10, 10, makecol(255,255,255), "Frame %d", color);
     while(!timer)
            yield_timeslice();
}

Because the rendering is usually the most expensive (system-wise) in your program. You want it seperated out so you can skip it if you fall behind (ie. frame skipping). Even you absolutely have to draw for your logic to properly run (which is rare), you still don't need to draw to the screen (unless you're using direct dirty rectangles like Allegro's GUI). It also helps the CPU cache when you access larger buffers, since the CPU wouldn't have to try to cache the buffer everytime you draw something more after doing a bit more logic. As well, WIndows and X don't really like mixing drawing to VRAM and using other input functions at the same time.

I bet it doesn't do a thing for CPU usage that way either.

It does!

Ok, this is one of the best threads I ever read.
I love you ALL!!

My code currently looks like this and it works very good!

THX!

I wonder how much confused can I be!

I have done some experiments with timeBeginPeriod() and rest() and such. First, thanks to all for these really interesting infos.

So now I can understand my measurements much better, which relate internal CPU counter and the CPU usage indicated in the task manager. Now, using timeBeginPeriod(1) in the start of my program changes the confusing behaviour I saw before into some understandable behaviour now.

Well, I was forced to include winmm.dll and stuff into my main program, so I tried to move timeBeginPeriod() into the implementation of rest(). That was a good idea! Works perfectly well for my program, and also better than changing the main program only.

So how can I propose this change for consideration for the next allegro change?

Next I have again analysed the behaviour of dlg, which uses 100% CPU on doing nothing, but not all the time. I think I should write the results in an extra thread, but again I have two little changes to propose here, one for allegro and one for dlg. How do I do that?