I suggest a patch for _al_d3d_get_display_mode that would retreive current settings when -1 is passed (which works that way with OpenGL on Windows natively):

I'm havinga trouble with figuring relation between d3d_formats and allegro_formats to set up format field properly though, so it needs to be replaced with something meaningful.

. . .

Is this even the place to post it?

If you've already created a display, you can get all of this information from al_get_display_width/height/format/refresh_rate. Or is this supposed to get the desktop mode? If so, are you sure you can do that this way? Looks fishy to me. Have you tried it?

Well, that's exactly the reason why I suggest this patch: you can't get current monitor settings without creating a window first, and even if you create one you submit width and height in advance of creating it which renders obtaining current mode meaningless - it is the one you just set up. In fullscreen mode best luck if it doesn't crash, which is quite possible.

Once again, I want to know monitor current resolution in advance of creating a fullscreen display, so I could create it without changing monitor settings in real fullscreen mode.

The reason for that is very odd, specifically I run a videocapture software that would halt receiving frames if monitor mode has changed in any fashion. Apart from being inconveinence itself, I have software's viewport on another (dedicated) monitor specifically to be always monitored, but when monitor mode changes it halts receiving new frames from device and the picture freezes and it have to be manually restarted.

According to D3D manual it's perfectly fine. Though no, I had not. I don't work with D3D without big reasons to. Plus, I would need massive amount of work to get Allegro to compile because I don't have most of required tools.

Lots of games have a little dialog box thing on startup to ask which mode etc. It's not that hard to switch from a generic 640x480 window to a specific fullscreen mode, is it?

You don't seem to get the idea. I don't want this to set up manually. I want this to be obtained from OS or video driver or whatever.

I'd be rather miffed if a program went to a fullscreen mode right off the bat with no way to change it. Right now I'm watching a movie in a window so I can see when a new post shows up here. Earlier today I was playing a game in a window for the same reason. And I have several games that can set fullscreen modes that the monitor won't display. I have to admit I'm using an cheap SVGA cable instead of an HDMI cable.

What you need is ALLEGRO_FULLSCREEN_WINDOW then.

al_set_new_display_flags(some_other_flags | ALLEGRO_FULLSCREEN_WINDOW);
ALLEGRO_DISPLAY *d = al_create_display(0, 0);

Now you have a fullscreen mode the same as the current monitor resolution. You can get the size after this by:

int width = al_get_display_width(d);
int height = al_get_display_height(d);

If that's not good enough, we need a new function, as the one you're modifying is internal and for D3D only.

So an API like:

enum { ALLEGRO_DEFAULT_MONITOR = 0; }
int al_get_monitor_width(int monitor_id);
int al_get_monitor_height(int monitor_id);

?

EDIT: I also hate anything that goes to fullscreen by default, BTW.

Have you tried:

ALLEGRO_MONITOR_INFO info;

for(int i = 0; i < al_get_num_video_adapters(); i++) {
   al_get_monitor_info(i, &info);
   printf("monitor[%i]: %ix%i", info.x2 - info.x1, info.y2 - info.y1);
}

Something like that but may not be able to use an enum, but an integer instead. It may have to take a struct pointer and return values in that so you could get various different things like refresh rate and color depth.

Fjellstrom's API should work. Also, my use of enum was really just defining constant. I prefer those over #define and const int directives. Enumerating displays wouldn't make sense.

"Thomas's api" already exists but it won't tell you the current resolution, just all of the supported ones. You can guess the biggest one but I'd rather not guess.

Nope. That api tells you the current monitor geometry/geometries. Gives you the rectangle of each plugged in monitor in its current mode. The mode stuff gives you lists of modes.

Oops, I had them mixed up.

You don't get it. This feature is handy by itself. Speaking of utilizing it, I don't force fullscreen whatsoever, instead I want there to be "fullscreen" button that would take you to the (real) fullscreen mode right away without changing monitor settings. See, I don't want player to get into monitor settings stuff. I want it to be "just works". Also I assume that current monitor settings are optimal and player don't normally want to change them to play the game. Either way, I don't need to change monitor settings because to my games exact monitor resolution is irrelevant: ones use something about 256x224 resolution which is not supported by any monitor whatsoever therefore needs to be emulated, and others scale smoothly that only noticeable difference is smaller or bigger pixels.

No. I want real fullscreen mode, not a somewhat similar replacement of it.

No, we practically don't. It is enough to build in a feature of using -1 to get current settings. In another thread I described as I figured out that with OpenGL under Windows you can fetch current settings by passing -1 as mode index number. Obviously that's not enough to even think of actually using it because only OpenGL+Windows would handle that. This is why I suggest a patch that would make D3D behave similar way. To make it entirely usable there's still need to make it also work with Mac (which I'm not familiar with) and Linux (which unit's code is real a mess, I can barely comprehend one third of it, once again comments are only exist by name). I'm not confident, but I'm pretty sure that it is entirely possible to get current monitor settings on any OS.
Well, maybe having a separate function for that is kind of more straightforward than using specific keys to make function do specific and not really related job.

I can't really tell if that's getting desktop dimensions related to specified monitor or real monitor dimensions. Chances are that they're different, but they still present. For some machines, this is default. I.e. when monitor size is 800x480 but desktop is 800x600 and viewport slides across the desktop following the mouse. Obviously, setting 800x600 mode on such monitor will crash the program. Either way, monitor number and device number don't have to match, which renders this whole approach useless on multi-monitor machines. That's exactly the reason why I even started this whole thing in the first place.

Its not in mm so its the resolution of the monitor as it currently is.

I don't know that we care to support viewport modes.

Only if you don't check to see if the display creation failed before using the display.

Yes they do. The api is a bit funnily named, but monitors are equivalent to adapters in A5.

I had a hand in the multi-monitor support, it was somewhat of a priority for me since I have a dual monitor setup.

append: If you look at the ALLEGRO_MONITOR_INFO struct, it returns the rectangle of each monitor. Meaning you can get both offset, and size of each monitor in relation to the larger viewport. This can be important with multi monitor.

Can you point out precisely at the (possibly all 6) function that perform such measurement for certain (possibly all 6) video driver? Because as I said, it is entirely possible that it would be desktop dimensions rather than monitor dimensions and it is also entirely possible that those two doesn't match.

It crashes before display creation function returns.

No they don't. My monitor #0 is connected to device #1 and monitor #1 connected to device #0. Only because I have two devices, because they could've been, like, four of them if I had 2 GPUs. That's the reason why I have even discovered the fact that they don't have to match in the first place. I'm very confident about the fact that 0 doesn't match 1.

Let me guess, they're both same dimensions? Well, even if you have complicated setup that involves one regular monitor and another being supermegahd-portrait monitor and all works fine for you, it doesn't work that way for me, so you can't assume it works correctly. It's just you being lucky to have it works.

Yes, thanks. I was aware of it, though I would not use it because I only use single-display layout. Mostly because this is default setup. For some games having another screen to display some current data would be really handy, but due to mentioned earlier reason I shouldn't implement that.

On my tablet, so I'm skipping the inline quoting.

The monitor info should give you the current rectangle of the queried monitor. Yes it might be possible that the desktop and monitor modes don't mach but that is very unlikely, and I somewhat doubt the code returns the desktop size. I know it doesn't on X as I wrote that code.

Mode sets shouldn't crash. That's a bug and should be fixed.

When allegro talks about monitors and adapters, its its own index based on the order it probes or gets them from the OS. This process is inherently platform specific, and neigh impossible to make perfectly logical. I've had a setup where screen 1 was left of screen 0. Meaning screen 1 actually has a negative offset Allegro really can't do anything about that. The Allegro adapter and monitor APIs use (or should use) the same index to mean the same physical display. To allegro they are the same thing. An adapter in allegro is just a unique output, not some kind of identifier for an individual graphics card that may have many separate displays attached.

I've had a few different multi-monitor setups. My oldest one used a 17" LCD @ 1280x1024, and a 21" CRT @ 1600x1200. Left lots of unused/unviewable space. But currently yes, I have 2 monitors of the same dimension. What the monitor info should give you in either case is the physical rectangle of each monitor based on its mode and position in the larger combined screen space. If the functions in the monitor section of the display docs don't agree on what their index arg means, its a bug and needs to be fixed. What I'm not sure of right now is if the display mode functions act on the 'new display adapter' setting or not. If they do, then it's index should also be consistent with the monitor functions. Something makes me think they need a current display set though.

If there are no serious bugs in the multi-monitor support, then there is no reason not to support using multiple monitors in your game/app. You will absolutely need to make that configurable though, many things can make your screens be detected in a different order, ie: The GPU driver, if the os supports parallel device probing (ie: Linux), and maybe if the moon is full. One person's monitor/adapter 0 may well be someone else's monitor/adapter 4. And there is no way to solve this as far as I'm aware.

It forbids you from using right angle brackets? Or it deliberately hides them beneath dozen of sub-menus just to be inconvenient? Well sorry about that.

Exactly. It should. But it's not guaranteed. And on top of that, when you create a window you specify device, not a monitor, which, as I already estabilished, don't have to match. You can't create a window on specific monitor not device anyway.

Doesn't mean that such minor inconvenience to developer should be big inconvenience to end user.

Well, okay, but it is unrelated to ability to obtain current monitor settings.

Can you please explain how that hell's clockwork performs? I can't track it any further than down to getting system driver object set up function, which being completely opaque to me.

Well, obviously. And OS enumerates them in order the hardware provides. And for some reason, the OS I use (W7) doesn't think it's convenient for monitor number to match output device number. And something is giving me big hints that monitor #0 is the "current" in terms of which one has focused desktop.

I have tested it and it's not relevant.

There's a serious bug with Linux multimonitor support that completely forbids using more than one monitor. At least the manual says so. Plus none of mobile devices can possibly have any more than just one monitor.

There is. With using of obtaining current monitor mode by passing device number, which is (I am fairly sure of) entirely possible with any OS.

Isn't it possible to get multi-monitor support on iOS via Apple TV?

The right angle brackets aren't too bad, but add that to the copy and paste mechinism being annoying as well, and I didn't want to spend the time on it.

It is, or its a bug.

They mean the same thing to allegro. If they didn't it would be horribly broken. Again allegro has NO concept of "GPU". The "Device" you're talking about is the monitor.

Games and apps have system requirements. One of allegro's is to not use panning modes Well, not really. Just I don't think its been tested, and I don't think any of the devs give a rats-ass about it. I sure don't.

I didn't write all of the X code. But if you're looking for the multi monitor and fullscreen support code, its in the xrandr.c and xfullscreen.c files under src/x of the source release. Both the xrandr and xinerama code will hand you the absolute rectangle of the given monitor, regardless if its panning or not (at least I'm about 90% sure on that, again I haven't tested panning and I don't want to either).

Now try swapping your monitors. And tell windows that the now #1 monitor is on the left (or where ever you put your primary monitor) and it is the primary monitor. Now your #1 is actually the primary and the one you might expect to be #0 but isn't.

Bullcrap. Last I checked it worked fine. And I can't see where in the docs that is written. I and Peter Wang have tested it pretty extensively, or at the very least, he's done a fair bit of work on that code as well. If it doesn't work, this is the first I've heard of it. Certain WMs like to make things hard, but we can't really do anything about broken WMs.

iOS has AirPlay, which I think trentg has working with one of his games. I'm not sure that code is stable atm, I recall someone having issues with it recently. Android currently doesn't have a built in api to support multiple displays, but some devices come with their own SDK which we could probably add support for if someone wanted to do the leg work.

This is not what I was talking about. The problem that isn't solvable (as far as I'm concerned) is making complete sense out of the order and positions of the monitors the OS gives you. You just can't expect #0 to be the primary, "in your face" monitor.

I should note (again), that the index retrieved from al_get_new_display_adapter is the same index you pass to al_get_monitor_info. There is no need to extend al_get_display_mode since al_get_monitor_info does the exact same thing, with the exact same data.

First:

Thomas, there's an indication of " Fix multi monitor support once NVidia's driver isn't horribly broken" in the X11 paragraph of the Allegro5 TODO list you link in your sig.

I think that's terribly outdated but still...

Second:
Don't wan't to derail the thread in OTverse but....is there a way to get on WHICH adapter your display is being created/is currently shown?

Not that I am anywhere close to test it, but in the docs I wasn't able to find info on that (prolly my bad eh) and this thread is vaguely related...

EDIT: of course it was my bad, i guess al_get_new_display_adapter() does it, right?

Pretty much, the NVidia binary driver recently got proper XRandR support, and the ability to control each screen attached, rather than the old BigDesktop bullshit they claimed was the only way they could possibly do it under linux without certain patches to the linux kernel, that haven't quite happened yet.

The nice thing about the way we put together the multimon X code, was that it was made to default to XRandR if it can, with some heuristics that tell the XRandR code to fail to initialize if it detected settings it didn't like. Like if the Xinerama an XRandR settings don't match (ie: with the older NV binary drivers, you'd get one big XRandR screen, and more than one Xinerama screen in the Big Desktop style setup). With the old NV driver, you get dumb Xinerama support, and no way to set modes (because in NV's big desktop mode, there is no way to change modes on individual monitors, can only change both at the same time using the combined mode of all monitors, its a mess). With the new NV drivers, you get full XRandR support with full mode setting capabilities on all attached screens With no stupid "if driver == nvidia" hacks that have to be removed. woot.

Yup. That will tell you which "adapter" or monitor your display will be created on. That said, the default is probably -1 or something, which means Allegro will try to intelligently guess at which is the best default or primary monitor. The X code actually tries some really odd looking code to try and guess at it. It's a pain, but now that XRandR seems to be widely enough supported, we may be able to never have to run much of the evil multi-mon X code ever again \o/ And XRandR I think has a way to tell which is the primary screen (not 100% sure atm, but I think so). Though I'm not entirely sure that XRandR's primary is the same thing as your Desktop Environment's Primary. If it isn't, well we'll have to figure out some way of asking the DE for this info, rather than the crude hacks I put in.

I guess this bug hasn't been fixed yet .

Sorry for continuing my OT, but I was looking around A5 implementation (just out of curiosity)
About the 2nd part of my question, how to determine the adapter on which the Display is currently shown...I've found that under D3D you can do this cast (thou ALLEGRO_DISPLAY_WIN is inaccessible through the Allegro5 API, is it?)

ALLEGRO_DISPLAY_WIN *win_display = (ALLEGRO_DISPLAY_WIN *)display;

I guess this means the adapter is being stored in the DISPLAY_WIN superstruct upon creation....haven't checked...but is it UPDATED by the sytem interface if moved onto another monitor?

I suspect not, but still this info is not exposed by the API anyway....so I tought that the only way to check the monitor in which the display is currently shown is by comparing the window position (got thorugh al_get_window_position ) to the x-y coordinates you get from al_get_monitor_info and storing the corresponding adapter index.

Is that it, or am I missing/misreading something?

BTW, having looked a bit into it it seems that a function that wraps it up and returns the current desktop mode could come in handy, but I haven't understood if A5 supports (meaning "detects" prolly) viewportmodes or not.

EDIT: fixed horrible typos.

No. I don't want to change my hardware configuration just to play a game unless it's a game that I want to play really bad. If that's about requirements then they should be adequate. Having monitors plugged in specific way does not qualifies as such. As for "monitor" number, you can't rely on such data under Windows, because it does whatever the hell it wants with it. I would've provided an evidence, but all of the sudden linker started to miss _al_set_new_display_flags and complain about it, which makes for an obvious conclusion that the reason is because Allegro's binaries are for 4.6.2. and I have 4.7.2, so I tried to install an appropriate version which killed my compiler at all and after several futile attempts to get it to work right I just have quit that and because without that specific function it works fine, I just install newest version and use it, and each installation takes long to accomplish which is why I couldn't even start anything for many hours, but now that it is installed and oh come on you've got to be kidding, the freaking thing requires C++ libraries to run while being written in C so I assume it only requires C-only compiler installation which I have, but just because it has (precisely) three C++ files I can't get freaking thing to run because there's a bunch of C++ libraries missing, which then turned out to be the reason why compiler even complained in the first place (Allegro's build compiler version is irrelevant unless there's static linking, good ideas come late) that made me go through all this, what the hell? Figures that this is because GDI+ and D3D doesn't have C interface, so all files working with them must be C++. I know that Microsoft had never followed any standards whatsoever, but forcing people to use specific things? Any library ever must have C interface, period. It might also have loads of other interfaces, but C interface is mandatory. This is ridiculous. Come to think of forcing, Microsoft does that since forever and right now the scale is ultra-massive, so that should've not surprised me at all.
Anyway, would you kindly upload A5 build for mingw-4.7.2 plox, because this GCC version is default now.

Well, good to know that. One problem less. But I clearly remember that I have read it somewhere, and it's either manual or sources.

Oh I didn't knew that. I don't follow Apple products.

The only problem, as I mentioned earlier, is that Windows disagrees with you about that. Either way, it is true that you cannot assume physical locations of monitors. But all OS has something like "default device". It is the one which has login screen, for example. It is safe to assume that this device is the best place to put your window on, or to occupy it's entire space for a fullscreen mode.

No. Prior fetches all data related to an output device (with D3D also fetches color mode), while latter only fetches desktop rectangle, which is not even guaranteed to have valid dimensions.

You got point. It should be renamed to "desktop" rather than "monitor" in future releases.

Once again, it's only a couple of lines of code. Maybe some more for Linux, but it's still not like someone would need to write a whole subsystem from scratch. And it's not like "there you go my idea go do it", I'm trying to contribute with thatever I can supply. As I said, this feature is handy by itself, so all of this DUNNEADIT attitude does not apply.

I've finally gotta ask. What game is it that your creating that uses more than one desktop?

Dude... That wasn't what I was saying. I was trying to explain how hard/impossible it is to properly number screens.

Indeed, and thats what I've been saying all along.

What we have is what you get. You can query the attached+enabled screens, and get their geometry. What more do you need?

If that's the case, then in my opinion, that's a bug in allegro's windows code.

I agree. That's a bit of an oversight in allegro's code imo. The default of -1 for the current adapter should create the display on the primary monitor. That's about the only thing that makes sense to me.

What exactly would you need that for before you create your display? Allegro will happily default to the current colordepth iirc, which is generally the best one to use.

It should fetch the screen's actual size/mode, not the desktop size. 99% of the time these are the same. If they aren't... well, that sucks.

I don't see the point of it myself. It's also extending an already defined function to doing something it wasn't meant to do.

Maybe a al_get_monitor_mode function would make sense, if you absolutely need all of the extra info that al_get_monitor_info doesn't include. But then, you can always just get that info after you create a display. Sooo. Yeah. I personally need some more convincing. I have my doubts as to Peter thinking this patch is a good idea in its current form.

Concerning this:

I did a little experiment with in my office setup (Win7 Laptop with attached an external 16:9 Philips 17" LCD - Allegro 5.1.4 binary precompiled).

Once you have more than 1 monitor plugged in, windows 7 lets you setup your "primary" monitor at will with a checkbox "This is my primary monitor" and this has (to my limited observations) the following effetcs:

- places the taskbar on that monitor
- top-left corner of that monitor becomes the orgin of the viewport axes (0,0)

Launcing allegro in these conditions has the first index [0] adapter to be always the "This is my primary monitor" checked display.

Independent on how the OS enumerates them, or so it seems: they are numbered "1" and "2", and when "2" is the OS primary monitor, it is the index [0] adapter in Allegro.

Seems to me that when querying the OS, Allegro receives the adapters in order starting from primary display and then the others following.
I can't say in which order from there, but I suspect that it is related to geometry (i.e. "anti-clockwise starting from (0,0)")..too bad I haven't a 9 monitors setup handy

On a related note:

- ALLEGRO_DISPLAY_WIN::adapter does NOT change when dragging the window across monitors...seems it stores only the adapter into which display is created.

- seems to me that al_get_num_display_modes returns the display modes of the al_get_new_display_adapter adapter only....If I want modes for EACH adapter I need to cycle through them calling al_set_new_display_adapter...is that correct?

Hope this is not all that much OT.....;D

Are you sure about that? If you place the other monitor, say on the left of your primary, is it before or after the primary?

I suppose it would make sense that the primary is always first, but I'm not sure we can count on that.

Yeah, thats a bit harder to get right. I was thinking of managing that for X, but it was a bit too much of a headache from what I remember.

Yes indeed.

Thinking about that, I'm only sure that the default display adapter is the checked one (both num_modes is consistent and new displays are created there), but since I had to stop abruptly I could not check that adapter index is "0".....I had that for given but I should check in the debugger.

Maybe tonite...maybe tomorrow

BTW: is there a way to retrieve the current display_mode index? (Guess not, otherwise it would also be possible to query the current mode itself....)

EDIT PS: I tried putting the secondary display LEFT, RIGHT and on TOP of the primary in both cases. Each time the "default" adapter is the checked one.

Modes are currently tied to a display. That is you need a current display for the mode functions to work, afaik. And it'll grab the modes from the monitor that display is on. (at least I think thats how it works, I can't remember)

But is that mapped to allegro's adapter 0?

Not sure, as I said....have to check but cannot right now, not even sure this matters if I didn't get it horribly wrong and what I wrote does not stand.

The more I think about it, the more I feel that something is indeed missing:

I can fetch the current adapter geometry, but I need to know the index
I can fetch ALL the display modes for the current adapter AND the index.

Getting the current default adapter geometry BEFORE creating the first display smmes indeed possible with the current API:

- Initialize allegro al_init ( sys interface gets filled, default adapter index is stored)
- get current adapter index with al_get_new_display_adapter
- use that to fetch current geometry with al_get_monitor_info

Given that for allegro adapter != viewport (needs confirmation!!!) one should safely assume that can go fullscreen effectively maintaing current mode.

As usual, am I missing something? (Of course! me moron)

Found the gotcha...the current display adapter index defaults to "-1" and al_get_new_display_adapter returns that, even after creation of the first display.

I'd say to scan all modes for all adapters/monitors you'd need to do something like this (untested)

As for the original question, giving -1 a special meaning seems like a hack. If we need to know the current display mode it should also be possible to get and set that using a new api so it matches the index of al_get_display_mode.

`al_get_new_display_adapter` just says what adapter/monitor to create the next ALLEGRO_DISPLAY on, and -1 is a stand in for "Default" or "Primary", so you don't have to figure it out yourself.

In some cases, -1 will also allow allegro to guestimate which monitor you want the display on, based on which monitor/adapter is active (has input focus, or a selected/focused window). You don't always want your window to pop up on the primary screen. If you had a shortcut to your app on your non primary monitor, would you expect the window to open up on the primary? I wouldn't. And this is something that is incredibly hard for the user to figure out without us providing an api for it.

Okay, now that I've seen some other point, I need to clearify one bit:

Desktop geometry is generally irrelevant to a game because it's very arbitrary matter. Say, if you have two monitors, you could've use them as two viewports - one to the left and one to the right, if they had their rectangles touching (for the lack of better term). Or one might be on top of another for that matter. My setup includes secondary monitor being at bottom-right edge of main monitor. But physically it is located far above main monitor. Bottom-left locating is just for the sake of convenience: the only point on the monitor where my mouse could leave main screen is bottom-right-most corner, which I never use, while in "natural" placement my mouse would skip to secondary monitor whenever I throw my mouse to the "x" button; you know, having to aim with mouse is really an inconvenience, especially if a software does not designed with keyboard use in mind. This is why desktop geometry is highly irrelevant, instead what should be relevant is display geometry. I already suggested one way to do that, in the original post. There might be a specific function, too. But the point is that there needs to be a way to get current monitor geometry with allegro, I REPEAT: MONITOR GEOMETRY, making stress on the "monitor" word, not "desktop" or "viewport" or whatever, specifically monitor, because this is entirely possible on any OS. I mean it's not like there's an X-Box supported platform where you don't get to know target resolution; be it PC or Mac or iPhone it is always possible to query monitor geometry (and color mode).

Now that I think of it, why request (with suggestion of possible solution) to having possibility to obtain current monitor mode even raised any necessarity questions? Like "oh why even bother if here we have this it's not what you need but it's almost the same and will probably work all right".

I'm not sure of what you mean here. What you get from al_get_monitor_info is the info we get from the OS about the geometry of your attached monitors. That is the intent of the api, if a given platform doesn't actually do that, its a bug in allegro and should be fixed.

Thats just it, it IS what you need, and works exactly as you need (if it doesn't that's a bug in allegro and needs to be fixed).

Another option is to just give up on getting the current res, and use ALLEGRO_FULLSCREEN_WINDOW and let allegro do it for you. It will create a window that covers the entire screen with which it was created on, and you don't have to pass in a valid width and height, it ignores those parameters of al_create_display.

Seriously though, al_get_monitor_info is supposed ^[1] to give you the current size (ie: mode geometry) of each attached monitor. Period. Full Stop. End of story.

The reason we give the offset's as well, is well, so people can tell where the screens are in relation to each other, say for a multi-monitor config setup in a game or app, or you want to programmatically move a window to a given screen, you want to know its origin and size, not just its size. So the function returns more data than you may care about, not a big deal.

No. I want to get current device display mode. Also known as monitor mode. This includes frequency, color mode and dimensions. Size of a desktop and it's relative position against the default one is not related here for obvious reasons, and specifically, it has it's own function.

There is getting device display mode by number. Why isn't there getting device display mode by default, being first obvious extension to prior? And why the fuck would you argue that it's not needed? This is what I completely don't get. I can almost draw a parallel to a supermegaartist-retards who claim their projects to be ultimately perfect as is. Unfortunately, I had to deal with these. Sorry for breaking my attitude down like this, but that's just what your attitude about that matter makes to me.

The reason is because OS provides a rectangle instead of just X:Y pair and throwing out the other two coordinates would've been a waste.

It returns less data than I may care about, and it can also return invalid data by specific occasions.

Speaking of invalid data. Windows' OpenGL implementation would only return modes of default screen and will not return color mode whatsoever (though with PC it's narrowed down to RGB565 and XRGB32 so can be deduced), and D3D implementation returns shitloads of impossible modes among couple of those that can actually work.

I don't see the point myself. Why do you need anything more than the size/mode of the monitor? Once the display is created, you can then get the modes, if you needed to display them.

Give me a good reason you need that information, and maybe we can add an api to grab display modes before a display is created. Maybe.

Oh, if you don't feel to bother over writing something about 100, maybe more, lines of code, then how about I do that on my own? I just need to get all tools set up so I could fetch nightly Allegro and modify it and build it and test it, because right now all I have but Allegro is MinGW C and C++ installation. Though it will probably won't happen until a month later for a very specific reason, but I can suggest patches (without proper testing, i.e. based on the manual) even right now. The one that I have already suggested should work fine. There you go another one, for Windows' OpenGL implementation, it should work perfectly fine too:

A function to get current mode is made as easy as replacing index with -1 (and cutting out bunch of things).

The reason why I would suggest without testing is because my style of programming does not involves testing much, I'd rather said hardly involves at all, and things turn out to work perfectly well, unless there's bunch of pitfalls in libraries. Unless there's a pitfall in al_get_new_display_adapter it should work perfectly.

I have to admit I derped on saying that the get mode stuff requires a display.

The current X code treats the -1 default from al_get_new_display_adapter as a standin for the "default" monitor, which currently means whatever screen/adapter the current active window's center is located on. Which I think is more correct than always picking the primary monitor. That can be changed however, or at least we can provide a "get_primary_adapter" function to help with picking the primary.

That isn't the problem. The problem is I don't care about this feature. I don't personally see why you'd want that information. And you haven't provided me with a good reason, like I've been asking for over and over. I can't really think of one.

Not that I'm 100% against it. After looking at the x code, it'd be pretty easy to return the current display mode if passed -1 into get_display_mode.

Also:

if ( adapter < 0 )
   adapter = 0;

May not be the ideal solution.

OK, Raidho36, now understand what you want. Now, we have a API to get the real hardware resolution of all the available MONITORs (adapters). And for each of these adapters' we can get all available modes that can be set. The fact that with some drivers some modes that are reported as available cannot actually be set is a separate issue. But what you want is a way to see, for every monitor, what mode it is set to NOW, before opening the allegro window.

SDL 2 seems to support this support this with SDL_GetCurrentDisplayMode
(http://wiki.libsdl.org/moin.cgi/SDL_GetCurrentDisplayMode) or SDL_GetDesktopDisplayMode (http://wiki.libsdl.org/moin.cgi/SDL_GetDesktopDisplayMode), the docs aren't completely clear. So I'd say that such a function could be useful. At last the the SDL developers seemed to think it was. Something like

int al_get_desktop_display_mode(int adapter, ALLEGRO_DISPLAY_MODE *mode)
OR
int al_get_current_display_mode(int adapter, ALLEGRO_DISPLAY_MODE *mode)

It returns he index of the current display mode (as per the al_get_display_mode), or negative on error, and fill in mode with the details of that mode.

Of course, personally, I wouldn't use such functionality, since I just greedily switch to the mode I want, and don't care about whatever mode was used before I started my program. But I could see why it could be useful, for example, for utility programs like Aseprite, etc, to pick a mode that corresponds well with the one the user was using when starting the program.

Isn't the suggested function itself proclaims the reason to have it? To obtain current display mode? Just because you can't think of using this data doesn't mean nobody ever needs it. It's like having "peek" function in the stacks. I can't think of using it whatsoever (except for cases of misusing), but it doesn't mean it shouldn't be there: maybe someone needs to know stacks' top value without clearing it out. If you haven't get the answer yet, I need it because I want real fullscreen mode, and I want to have it without having to perform voodooistic rituals to make sure the data supplied by other functions is even valid and I can use it. All I want is to fetch current mode and make my fullscreen mode to use it rather than substitute it's own.

That's what I have found in D3D code, so I just reused it as is. Not my fault if there's something wrong with it.

Yes, exactly. Allegro should have it, too.

Now note that there's a difference. Monitor functions should fetch specifically monitors' data. Just because desktop would typically match monitor doesn't mean that it's always work that way on all OSes and all machines.

Well, then, please implement al_get_desktop_display_mode and al_get_current_display_mode. You could borrow the code for X Windows and OS X, etc, from SDL 2 since that's now also ZLIB license. In other words let's not change old API's in iffy ways, but work on add new ones for missing functionality. I'm willing to test this for you if you implement it.

In other words, if you say this functionality should exist, then make it so. Please don't complain, but code!

Well that's constructive, I'm for!

It was actually what I have started with, but whatever, the result is what matters, right?

I come back to answer this: NO, I had the chance to check today (as I got a 18.5" widescreen LCD to attach to my Laptop yay) and actually the Adapters are numbered in the same order as in the OS, [0] is what windows identifies with a big 1 and [1] is the one with the big 2 on it. Consistently.

Either one, when being the primary has (0,0) top-left coords.

The rest of my observations stand, meaning that the "checked" primary display in windows is the one on which new ALLEGRO_DISPLAYs are created, ALLEGRO_DISPLAY_WIN::adapter does not automatically update (even thou a way to peek into this struct field by the API woudl be nice I think)

(Un)related question:

Following a convoluted callstack, I see that calling the al_create_display ends eventually through:

why isn't that 'cScreen' stored somewhere? To my understanding this is ran through each time a display is created (or maybe manipulated in some way?) iif one never ever sets the new display adapter via al_set_new_display_adapter.

This anyway answers my question about determining the primary display, even thou if I want to do it in my code I basically have to rewrite this function. I guess this is heavily platform-dependent?

The primary screen can be changed in between calls to that function.

I think so. But I'd have to check to make sure. I don't know if the new xrandr stuff on X lets the desktop tell xrandr what monitor is primary, or if the "primary" monitor is just a desktop level thing.

Right out of the aforementioned function, wouldn't something like this be platform-independent? (indentation may be a bit off due to copypaste, sorry for that)

int pk_determine_prolly_prim_adapter(void)
{
   int a = 0;
   int num_screens = al_get_num_video_adapters();
   int cScreen = 0;
   ALLEGRO_MONITOR_INFO temp_info;
   for (cScreen = 0; cScreen < num_screens; cScreen++) {
      al_get_monitor_info(cScreen, &temp_info);
      if (temp_info.x1 == 0 && temp_info.y1 == 0) { // prolly primary display?
            return cScreen;         }
      }
   return a;
}

Could do for me right now....

I was just saying that 0x0 may not mean the monitor is the primary monitor. I'd have to check. And I'm far too lazy at the moment

Ah ok, I got it wrong ...anyway on Win7 seems to invariably mean that ...you get the login screen on whichever dispaly has (0,0) origin.

"Primary" is way subjective matter anyway (when I reguraly had two LCDs, I worked "primarily" on the right one, on which i DID NOT (purposedly) have the taskbar...