1. It's in the FAQ

2. I think timers are implemented in a thread, so they shouldn't slow down your system too much.

Isn't better to let all the logic update at 60 fps and render at the best speed the computer can? I think human eye can still feel the difference between 60fps and 75fps, so if I can run at 75fps why not?

I'm not sure of this but if you only update the logic 60 times per second there is no point (and no graphical improvement) in reblitting the same image over and over... better use this time to yield to the OS or whatever

Yea, Marco and Mithrandir got the answer. No sense in drawing if no logic changes.

For sprite animation its better if you know that you will display 60fps and no more than that, so you can set your animations to the movement rate you want, and test them the same rate that they will be drawn in every computer (every computer that can do your 60fps) IMO.

But it depends on the game. You can also set considerations about the game time if you are making a real time game (time lost due to drawing, ...).

You can read this article from Javier Arévalo (Commandos saga) for nice example.

---
rest(1) didnt work for me, so i moved to yield.

If you rerender the same screen again(not just blit or flip it) it may still be rendering when the next logic step should have been running. This leads to small skips in the game that make fast moving objects look jerky.

you can lock the fps this way :

I didn't know about the yield_timeslice function, but don't understand what it does, so i will continue with this stuff instead

On Windows rest() is implemented using Sleep().

And why should rest(1) wait for 10ms? My measurements indicate that rest(1) waits fpr 1ms average - slight variations possible, so that's not too exact. You have approx. 1000 rest(1) calls within a second.

I don't see why use Rest would resolve the problem because, regardless of
the computer speed, sometimes you'll have to rest 10 ms, sometimes 0, ...
I think the only thing you have to do is to look at if logic has to be implemented, so just do nothing while timer_counter==0
just add one line after the drawing should do the trick :

while (!game_over) {
            while (speed_counter > 0) {
               update_game_logic();
               speed_counter--;
            }

            update_display();
     
            while(speed_counter == 0){/*do nothing*/}
         }

I know about this but I don't think it's a good solution to have the logic and the drawing dependant. Imagine you have a computer playing your game at 30 fps. Another computer will play it at 60 fps (which is what you want). if logic and drawing are dependant, the game will be two times slower in the first computer ( I mean here the moving of characters,...), so this won't be the same game. In the other hand ("my way") the game will always be the same, exept a bad drawing if the computer is too slow.

I don't think so because the incrementation of speed_counter is done via a thread so is independant of the main loop

[EDIT] *lock the FPS* means do nothing as I corrected it the second post [/EDIT]

This only happens if computer is too slow, which is the same performance in your case. Its normal that it will be two times slower, thats in the case that cpu and video card do the stuff at half the speed from the minimum requirements.
If computer is fast enough to run 60fps it will (thats the concept of minimum requirements).

Hope the comment above applies to this sentence. Mine will have reduced performance only if it cannot draw 60fps, which is equal to "slow computer".

What i mean is that its better using speed_counter = 0; instead of speed_counter--; if you are not going to consider the lost frames.

If computer is slow at a certain moment (54 fps):
your code will do spped_counter to reach 6 (value) (60 ticks - 54 times)
When computer restores its normal speed your code will have speed_counter = 6, so next time it will try to do 66fps, what is not they right vehaviour (you want the computer to run 60fps all the time, not more than that).
6 frames is not a problem, but imagine the case that antivirus suddenly starts to scan (slow computer) or p2p running, or any kind of background program, (downloading tasks, etc.) that can make your game to lose 60 frames (this would make your game to try 120fps next second, animations at double speed). Frames sould be discarded, so speed_counter should be set to 0, losing the 6 frames.

The other point is a behaviour for the 6 frames (look at the javier arevalos' article (link some messages above), there they have a good way to control (using interpolation) the lost frames):

// Easy but not very useful way
if(speed_counter > 0) {
   speed_counter--;
    // losts
   while(speed_counter > 0) {
     // frame lost, do X
     speed_counter--;
   }
}

Neither
- while(speed_counter == 0){/*lock the FPS*/}
nor
- while(speed_counter == 0){rest(1);}
worked for me. speed_counter was always 0 on the first case, and dont remember what, but bad behaviour with rest()
yield_timeslice() gives up the rest of the current scheduler timeslice. The problem is that timeslice size changes from so version, so its like rest(variable) IMO.

Maybe the problem with rest is:
***** start manual info

void rest(unsigned int time);

This function waits for the specified number of milliseconds.

Passing 0 as parameter will not wait, but just yield. This can be useful in order to "play nice" with other processes. Other values will cause CPU time to be dropped on most platforms. This will look better to users, and also does things like saving battery power and making fans less noisy.

Note that calling this inside your active game loop is a bad idea, as you never know when the OS will give you the CPU back, so you could end up missing the vertical retrace and skipping frames. On the other hand, on multitasking operating systems it is good form to give up the CPU for a while if you will not be using it.
****** end manual info

I never said to use rest to keep framerate constant; what i was suggesting was to use yield_timeslice to play nice with multitasking. Since in a previous allegro WIP there was a bug that didn't make yield_timeslice work under windows, Marco introduced rest, but only as a mean to yield, not for fps.

sorry Mithrandir I misunderstood you

Nunca Ese :

I think Evert explained it well : Logic has to run at a constant rate on every computer.