I'm writing a function for my game that, if the game is played in fullscreen mode, automatically tries to find the best available display mode. I'm using al_get_display_mode() for this. However, I don't know what the "format" variable of the ALLEGRO_DISPLAY_MODE structure does. I assumed it refers to the bit depth, in which case I had been looking for 32-Bit display modes. However, I have written some code to print the content of some randomly selected display modes and all of them had either "23" or "13" for their format. Now I'm confused, because I can't really get any sense into that variable. The documentation doesn't say anything about it and I couldn't find anything in the source code. Does anyone know what it's used for? If it does refer to the bit depth, what value represents "32-Bit"?
It represents a pixel format. See al_set_new_bitmap_format for a list of them. There is a al_get_pixel_format_size function that'll return 32, 16 or whatever if you pass it that format you get from al_get_display_mode.
Ah, thanks! How did I miss that function?
Anyways, that's all I wanted to know.
Another related question: Is the order of display modes always the same on all systems or is it hardware dependant? On my system, for example, the display modes are ordered like this:
640x480 32-Bit 85 FPS
640x480 32-Bit 75 FPS
640x480 32-Bit 60 FPS
In my game I want the search function to automatically select the display mode with the highest refresh rate, if the other requirements are met. If the display modes have the same order on any system, I can just select the first display mode that meets the requirements. However, if they don't, I have to search for the display mode with the highest FPS manually.
My bad, the function is al_get_pixel_size and it returns size in bytes. So 32 would be 4 and so on.
Yeah, I just used al_get_pixel_format_bits() instead, which returns 32 or 16.
Anywas, there is another question in the EDIT in my last post.
I don't believe you can rely on the order there. It might be in that order all the time, but it would be bad to assume that's the case unless you can find some documentation on MSDN that says so.
Alright. I'll just have to do two search runs then (or find another solution). Thanks again!
Actually, I think I already got an idea that lets me do it in one run.