Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Patch for _al_d3d_get_display_mode

This thread is locked; no one can reply to it. rss feed Print
 1   2 
Patch for _al_d3d_get_display_mode
Raidho36
Member #14,628
October 2012
avatar

Now try swapping your monitors.

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.

Bullcrap.
NVidia binary driver recently got proper XRandR support

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.

iOS has AirPlay

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

Quote:

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.

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.

Quote:

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.

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.

The api is a bit funnily named

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.

Luiji99
Member #12,254
September 2010

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

Programming should be fun. That's why I hate Java.
http://www.entertainingsoftware.com/

Thomas Fjellstrom
Member #476
June 2000
avatar

Raidho36 said:

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.

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

Quote:

As for "monitor" number, you can't rely on such data under Windows, because it does whatever the hell it wants with it.

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?

Quote:

The only problem, as I mentioned earlier, is that Windows disagrees with you about that.

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

Quote:

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.

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.

Quote:

No. Prior fetches all data related to an output device (with D3D also fetches color mode),

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.

Quote:

while latter only fetches desktop rectangle, which is not even guaranteed to have valid dimensions.

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.

Quote:

As I said, this feature is handy by itself, so all of this DUNNEADIT attitude does not apply.

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.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

pkrcel
Member #14,001
February 2012

Concerning this:

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 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 :P

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

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

Thomas Fjellstrom
Member #476
June 2000
avatar

pkrcel said:

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

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.

Quote:

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

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.

Quote:

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?

Yes indeed.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

pkrcel
Member #14,001
February 2012

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 ;D

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.

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

Thomas Fjellstrom
Member #476
June 2000
avatar

pkrcel said:

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....)

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)

Quote:

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.

But is that mapped to allegro's adapter 0?

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

pkrcel
Member #14,001
February 2012

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.

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

beoran
Member #12,636
March 2011

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

#SelectExpand
1void scan_all_adapter_modes() { 2 int mode, adapter, modes, adapters; 3 adapters = al_get_num_video_adapters(void); 4 for (adapter = 0; adapter < adapters ; adapter++) { 5 ALLEGRO_MONITOR_INFO monitor_info; 6 al_get_monitor_info(adapter, &monitor_info) 7 /** Do something here with the adapter info. */ 8 al_set_new_display_adapter(adapter); 9 modes = al_get_num_display_modes(); 10 for (mode = 0; mode < modes ; mode++) { 11 ALLEGRO_DISPLAY_MODE mode_info; 12 al_get_display_mode(mode, &mode_info); 13 /** Do something here with the mode info */ 14 } 15 } 16}

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.

Thomas Fjellstrom
Member #476
June 2000
avatar

pkrcel said:

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.

`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.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Raidho36
Member #14,628
October 2012
avatar

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".

Thomas Fjellstrom
Member #476
June 2000
avatar

Raidho36 said:

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'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.

Quote:

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".

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.

References

  1. and as I mentioned above, if it doesn't do so, its a bug in allegro which needs to be fixed

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Raidho36
Member #14,628
October 2012
avatar

Thats just it, it IS what you need

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.

Quote:

The reason we give the offset's as well

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.

Quote:

So the function returns more data than you may care about, not a big deal.

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.

Thomas Fjellstrom
Member #476
June 2000
avatar

Raidho36 said:

And why the fuck would you argue that it's not needed?

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.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Raidho36
Member #14,628
October 2012
avatar

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:

#SelectExpand
1619int adapter = al_get_new_display_adapter ( ); 1620if ( adapter < 0 ) 1621 adapter = 0; 1622if (!EnumDisplaySettings(adapter, index, &dm))

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.

Thomas Fjellstrom
Member #476
June 2000
avatar

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.

Raidho36 said:

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?

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.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

beoran
Member #12,636
March 2011

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.

Raidho36
Member #14,628
October 2012
avatar

I can't really think of one.

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.

Quote:

May not be the ideal solution.

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.

beoran said:

SDL 2 seems to support this support this with SDL_GetCurrentDisplayMode

Yes, exactly. Allegro should have it, too.

Quote:

or SDL_GetDesktopDisplayMode

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.

beoran
Member #12,636
March 2011

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! :)

Raidho36
Member #14,628
October 2012
avatar

Well that's constructive, I'm for!

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

pkrcel
Member #14,001
February 2012

Thomas said:

But is that mapped to allegro's adapter 0?

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:

wwindow.c#SelectExpand
1237int _al_win_determine_adapter(void) 1238{ 1239 int a = al_get_new_display_adapter(); 1240 if (a == -1) { 1241 int num_screens = al_get_num_video_adapters(); 1242 int cScreen = 0; 1243 ALLEGRO_MONITOR_INFO temp_info; 1244 for (cScreen = 0; cScreen < num_screens; cScreen++) { 1245 al_get_monitor_info(cScreen, &temp_info); 1246 if (temp_info.x1 == 0 && temp_info.y1 == 0) { // ..probably found primary display
1247 return cScreen;
1248 } 1249 } 1250 return 0; // safety measure, probably not necessary 1251 } 1252 return a; 1253}

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? ???

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

Thomas Fjellstrom
Member #476
June 2000
avatar

pkrcel said:

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.

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

Quote:

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?

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.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

pkrcel
Member #14,001
February 2012

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.... ::)

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

Thomas Fjellstrom
Member #476
June 2000
avatar

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 ;D

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

pkrcel
Member #14,001
February 2012

Ah ok, I got it wrong ;D ...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... ::)

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

 1   2 


Go to: