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?

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.

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.

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.

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);
}

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.

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.

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.

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.

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.

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.

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.

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.