During some implementation of enumerating display modes I accidentally found, that _al_wgl_get_display_mode does not set the format field in ALLEGRO_DISPLAY_MODE... which seems to be by design, but I would suggest to set the format at least to ALLEGRO_PIXEL_FORMAT_ANY to have the field be initialized.

I put in this code:

so the caller can at least identify the number of bits for the color values of the selected display format. The parameter format is the result of some routine trying to indentify the pixel format - in my case that value was 0, because the format couldn't be identified.

I just tried ex_display_options, it displays the correct color size (32 in my case). Is there another way to see the problem?

I'm using something like this

    const int n_display_modes = al_get_num_display_modes();
    for(int i=0; i<n_display_modes; ++i)
    {
        ALLEGRO_DISPLAY_MODE mode;
        al_get_display_mode(i, &mode);
        if(addElement(mode.width, mode.height))
        {
            if(write_log)
                gfw_log(2,1, "display mode %d: %d x %d at %d Hz, format %d = %d bits", i, mode.width, mode.height, mode.refresh_rate, mode.format, 8*al_get_pixel_size(mode.format));
        }
    }

and there it turns out that mode.format is uninitialized, if the current display was created with ALLEGRO_OPENGL.

Edit: I have modified the proposed change a bit, to only set a format when there's nothing else set. A patch is attached.

Another edit: I'll bump this a last time now, maybe someone is willing to look at it and add it, or tell me that it's not going to be added and maybe why.

Hey tobing, why don't you post your patch to the A5 mailing list? You'll probably get a better response. IDK, maybe, doesn't hurt.

Maybe worth a try.

The 24 bit case looks weird, doesn't it? I'm not familiar with this part of the API though.

I'm not sure this is helpful, but I'll say something. When we were first implementing this stuff I noticed this too... IIRC the explanation I got from Milan and/or Elias was that OpenGL displays don't actually have a color depth (on Windows only?) or that you can't detect it. I didn't and still don't understand that... but I think that's why it is this way. Not sure if that's true or not, but it'd be nice to find out so we can do what's appropriate.

Your patch seems fine to me but I'm hesitant to apply it because I don't understand that "doesn't have a color depth" tidbit I got when I asked a few years ago.

EDIT: Ah, I think it's come back to me. They said you can't get a pixel format, not a color depth. So if that's the case the patch should be ok.

Yes, I have tried to find out from the documentation, you can find out the color depth but not the pixel format. That's where the constants with ANY come in handy.

Thanks for looking at this.

I've applied your patch. Thanks!

Thanks from my side.