I've had a bit of code for many years that simply counts how many screen refreshes occur for, say, 3 seconds. You could be displaying a splash screen during this wait.

Just use al_get_time inside your game loop. So something like:

t = t2 = al_get_time();
while (1) {
    dt = t2 - t;
    do_logic(dt);
    do_rendering(dt);
    t = t2;
    t2 = al_get_time();
    al_flip_display();
}

Now your logic and your rendering will get passed 0.16666 with 60Hz and 0.00833 with 120 Hz and you can use that to adjust for it in whatever way you think is best.

This is a bad idea. It over-complicates network programming, precludes replaying demos, invites the possibility of differing gameplay depending on which monitor you use, and doesn't play well with disabled vsync. Decoupling the game logic from the frame rate while maintaining smooth, tear-free rendering isn't particularly hard, and should be the preferred method.

No, it is very unnatural. It's just happens particularly simple to code so people erroneously reach out for it first.

Anyway, I think you enumerate the display modes (`al_get_display_mode`) and then force one of them via al_set_new_display_refresh_rate. I'm not sure how this works for non-true-fullscreen displays.

I have no idea how you can conclude this from just the game loop model.

Actually know about what the thread is about please, I'm asking how to get the current refresh rate specifically to prevent this.

I can't deny this, but it's going to be a requirement for this model. Not that it's an unreasonable one.

So tell me how this works for getting the refresh rate of the current graphics mode configuration?

Floating point errors happen not only because of frame rate -- the problem lies within floating point itself. That's why I'm using rational numbers instead.

I've hacked Allegro to support what I want, I'll probably post a feature request on the mailing list for a more complete implementation.

Person A and person B have different monitors. Person A records a demo and sends it to person B. A simple implementation of demo replay functionality will produce erroneous replay on B's computer because the simulation runs at a different rate. Similar issue with the networking.

It does very little to prevent it. Consider the following game world: player falling in a gravitational field (acceleration = 100) with initial velocity (1, 0). The initial position is (0, 1). When the player hits the ground (Y = 0), he stops falling... however if he goes past (0.15, 0) he will die, as there is lava there. Examine how the coordinates evolve for two different values of FPS:

FPS = 50

t       vy      x       y
0        0      0       1
0.02    -2      0.02    1
0.04    -4      0.04    0.96
0.06    -6      0.06    0.88
0.08    -8      0.08    0.76
0.1     -10     0.1     0.6
0.12    -12     0.12    0.4
0.14    -14     0.14    0.16
0.16     0      0.16    0

Result: Death

FPS = 100

t        vy     x       y
0        0      0       1
0.01    -1      0.01    1
0.02    -2      0.02    0.99
0.03    -3      0.03    0.97
0.04    -4      0.04    0.94
0.05    -5      0.05    0.9
0.06    -6      0.06    0.85
0.07    -7      0.07    0.79
0.08    -8      0.08    0.72
0.09    -9      0.09    0.64
0.10    -10     0.1     0.55
0.11    -11     0.11    0.45
0.12    -12     0.12    0.34
0.13    -13     0.13    0.22
0.14    -14     0.14    0.09
0.15    -15     0.15    0

Result: Barely made it

That sounds like a gameplay difference to me.

For each refresh rate you obtain by enumerating the graphics modes, you try to create a display. Assuming I understand how its supposed to work, it'll fail if you chose a refresh rate incompatible with what is currently set.

Yes, they exist, but they are more complicated than they would have had been they not been dependent on the refresh rate (which is exactly what I said originally).

This has relatively little to do with collision detection, it has to do with how the position is calculated over time. It is impossible in the general case to make this independent of the integration timestep (for some restricted systems it is possible, but again... the restriction is unnecessary if the timestep was independent of the refresh rate).

Those are Y coordinates. Them changing to 0 means that the player has landed on the ground. In the first case, the X axis at the time of landing is 0.16, which means the player is in the lava. In the second case the X axis at the time of landing is 0.15 which means that the player is not in the lava just yet.

This has nothing to do with tearing, you only get tearing when disabling vsync (which nobody would ever recommend I hope). What SiegeLord is saying is that there's no point synchronizing the amount of game state updates with the amount of screen refreshes - because it will cause the gameplay to depend on the used monitor (unless you do something very complex).

Instead, make it so you always have the exact same gameplay and try to adjust the rendering to account for the different refresh rates. (There's many different ways to do the latter.)

Depends on how you coded your "game loop." If you only update your game state between drawing frames, then yes. If your updates are independent of your drawing loop (which is the preferred approach these days) then no.