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

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

#SelectExpand
2862 int adapter = al_get_new_display_adapter(); 2863 if (adapter < 0) 2864 adapter = 0; 2865 2866 /* Obtain current settings */ 2867 if ( index == -1 ) 2868 { 2869 if ( _al_d3d->GetAdapterDisplayMode ( adapter, &display_mode ) != D3D_OK ) 2870 return NULL; 2871 mode->width = display_mode.Width; 2872 mode->height = display_mode.Height; 2873 mode->format = /* display_mode.Format */ 0; 2874 mode->refresh_rate = display_mode.RefreshRate; 2875 return mode; 2876 }

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?

Trent Gamblin
Member #261
April 2000
avatar

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?

Raidho36
Member #14,628
October 2012
avatar

If you've already created a display

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.

Quote:

Looks fishy to me.
Have you tried it?

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.

Arthur Kalliokoski
Second in Command
February 2005
avatar

Raidho36 said:

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.

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?

They all watch too much MSNBC... they get ideas.

Raidho36
Member #14,628
October 2012
avatar

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.

Arthur Kalliokoski
Second in Command
February 2005
avatar

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.

They all watch too much MSNBC... they get ideas.

Trent Gamblin
Member #261
April 2000
avatar

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.

Luiji99
Member #12,254
September 2010

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.

Programming should be fun. That's why I hate Java.

Thomas Fjellstrom
Member #476
June 2000
avatar

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

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

Trent Gamblin
Member #261
April 2000
avatar

Luiji99 said:

So an API like:

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.

Luiji99
Member #12,254
September 2010

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.

Programming should be fun. That's why I hate Java.

Trent Gamblin
Member #261
April 2000
avatar

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

Thomas Fjellstrom
Member #476
June 2000
avatar

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

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

Trent Gamblin
Member #261
April 2000
avatar

Oops, I had them mixed up.

Raidho36
Member #14,628
October 2012
avatar

I'd be rather miffed if a program went to a fullscreen mode right off the bat with no way to change it.

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.

What you need is ALLEGRO_FULLSCREEN_WINDOW then.

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

Quote:

we need a new function

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.

Quote:

So an API like

Have you tried

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.

Thomas Fjellstrom
Member #476
June 2000
avatar

Raidho36 said:

I can't really tell if that's getting desktop dimensions related to specified monitor or real monitor dimensions.

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

Quote:

when monitor size is 800x480 but desktop is 800x600 and viewport slides across the desktop following the mouse.

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

Quote:

Obviously, setting 800x600 mode on such monitor will crash the program.

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

Quote:

Either way, monitor number and device number don't have to match, which renders this whole approach useless on multi-monitor machines.

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.

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

so its the resolution of the monitor as it currently is

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.

Quote:

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

It crashes before display creation function returns.

Quote:

Yes they do.

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.

Quote:

I have a dual monitor setup

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.

Quote:

append

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.

Thomas Fjellstrom
Member #476
June 2000
avatar

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.

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

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

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

Quote:

should

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.

Quote:

but that is very unlikely

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

Quote:

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

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

Quote:

as I wrote that code

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.

Quote:

its its own index based on the order it probes or gets them from the OS

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.

Quote:

I'm not sure of right now is if the display mode functions act on the 'new display adapter' setting or not.

I have tested it and it's not relevant.

Quote:

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.

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.

Quote:

there is no way to solve this as far as I'm aware

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.

Luiji99
Member #12,254
September 2010

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

Programming should be fun. That's why I hate Java.

Thomas Fjellstrom
Member #476
June 2000
avatar

Raidho36 said:

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.

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.

Quote:

Exactly. It should. But it's not guaranteed.

It is, or its a bug.

Quote:

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.

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.

Quote:

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

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.

Quote:

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.

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

Quote:

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.

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.

Quote:

There's a serious bug with Linux multimonitor support that completely forbids using more than one monitor.

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.

Quote:

Plus none of mobile devices can possibly have any more than just one monitor.

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.

Quote:

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

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.

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

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?

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:

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.

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.

Quote:

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?

Quote:

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

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.

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

Oscar Giner
Member #2,207
April 2002
avatar

Raidho36 said:

It crashes before display creation function returns.

I guess this bug hasn't been fixed yet :P.

pkrcel
Member #14,001
February 2012

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

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: