I apologise that I probabily will not able to create this patch myself, but I am primarily an OS X user nowadays and I have always favoured MSVC on Windows. I will endeavour to get a working GCC compiler under Windows and have a go at creating the patch I describe, but this may not be for some while.

I note in src/win/wddmode.c line 395 that the Windows/DirectX response to a request_refresh_rate is that if the exact rate requested isn't available, then Allegro just allows Windows to provide the default. Conversely under OS X, XDGA and VESA 3.0, if the exact rate isn't requested then the closest available is used.

I therefore think it would be more consistent, and more useful to the end user, if IDirectDraw2::EnumDisplayModes was used to find the closest available refresh rate - in a manner broadly analogous to the existing DGA implementation.

Out of curiousity, why does the DGA implementation only accept a refresh rate that is at least what the user requested? If they ask for, e.g. 71, wouldn't they rather have 70 than 85?

The DX change makes sense to me.

I wonder if we also should extend get_gfx_mode_list to include the refresh rate.

I'd prefer to be able to know when its been changed to something i did not request.

Having it set a rate i did not request will appear to be a bug to some people.
Is there a way to set a flag or something like
set_refresh_rate(75,ONLY); and
set_refresh_rate(75,CLOSEST_MATCH);

I can't think of many situations where you'd need a specific refresh rate. The user can have their system set to only run in a specific refresh, and it'd cause set_gfx_mode to fail if something else is set (especially applicable in windowed modes, where you can't change the refresh, AFAIK). Once you get past 60hz, the smoothness of motion becomes a very small issue (though screen flickering/headaches may). Even if your game is running in 85hz @ 100fps (fairly badly mis-matched), any vsync-caused jitter is barely going to be noticeable (if at all) since a proper timing method will keep the speed self-adjusted.

And, if you need to know if you got the refresh you wanted, you can use:

request_refresh_rate(blah);
set_gfx_mode(...);
if(get_refresh_rate() != blah)
  /* improper refresh detected */;

Well, adding support for it to get_gfx_mode_list would solve this as well..

In my opinion, get_gfx_mode_list remains completely useless while there is no get_gfx_driver_list. I guess it's intended for people who are aware that Allegro is a cross platform library but have no interest in writing platform neutral code.

Oh, I see.. you have to pass a specific driver. Does indeed not make much sense at all. I had assumed in my previous posts you can pass GFX_AUTODETECT.

I wonder if it makes sense to change this for 4.2.1 (either add a get_gfx_driver_list function, or allow GFX_AUTODETECT). 4.3 already does/will do it in a sane way.

Well, wouldn't having a refresh rate explicitly set make it easier to get smoother animation/no tearing?

Saying that, if you are using paging then it waits for a refresh anyway and on double buffering you'd have to rely on vsync working anyway. I guess the best setting a refresh would do would allow you to have a more tightly coupled fps limiting loop without waste.

Either way, it makes sense what Thomas is saying, in that if this is cross-platform then the least it can do is be consistent in it's approach to the most fundamental things.

I use allegro to output to video projectors, that have a specifc refresh rate.
I've like to be able to explicitly set a refresh rate, without allegro guessing it and/or changing it to whatever it likes.