2nd monitor, but still loosing device on lost focus
Author
Good day.
Here's multimonitor setup, again.
So I succesfully launched my app to display *full screen* on a second monitor. But when I try to do anything on the first desktop (like clicking mouse _anywhere_ there), the app immediately looses device.
Now, this is understandable with one monitor, but with two? I heard that you can debug full-screen apps with that method, so it surely is possible.
I don't know, maybe it's something with my window initialization code... or not. There's a lot of setup going on there, so sorry, but I'm not posting my code - just yet ;)
Anybody managed to do that and mind sharing some valid code, for comparison? I would be grateful for any advices, too.
~def
Quote:Original post by deffer
So I succesfully launched my app to display *full screen* on a second monitor. But when I try to do anything on the first desktop (like clicking mouse _anywhere_ there), the app immediately looses device.
Yea, that is standard behavior. I'm not sure how most people do fullscreen dual-screen debugging - I don't do it. If anything, try making your app windowed.
The incentive for using dual monitors for me isn't for the debugging, it's for the productivity increase.
Quote:Original post by circlesoft
The incentive for using dual monitors for me isn't for the debugging, it's for the productivity increase.
Agreed - when it comes to actually debugging a fullscreen application, dual monitors have never been much fun.
I had my app. streaming data to a console on the second monitor, but I only watched it rather than interacted with it - so it didn't cause the same problem you're describing.
My preferred tactic (that also works great with MultiMon setups) is to run the debug builds in windowed mode, that way they tend to play nice (provided D3D doesn't straddle both monitors!).
hth
Jack
I had this problem a while ago. I have dual monitors set up also. I think that the dual-screen debugging only works if you have two graphics cards, so you have two devices (Well, you could have two, you'd usually only have one and leave the other one for Windows to play with).
I also noticed that on my second monitor, Windows or the display driver doesn't seem to like my apps. Where I get 500fps on my first monitor, when I move the window onto my second monitor, I get around 20fps...
As circlesoft says; that's standard behaviour.
I also noticed that on my second monitor, Windows or the display driver doesn't seem to like my apps. Where I get 500fps on my first monitor, when I move the window onto my second monitor, I get around 20fps...
As circlesoft says; that's standard behaviour.
Author
Thanks. Guess I'm not alone in my missery ;)
The deal is, however, I'm not interested in debugging my single-monitor app. It's supposed to be dual-monitor app, that's displaying a full-screen presentation on one monitor (or using a projector), and has a control-console on the second one.
Now, I could quite easily (well, not *that* easily) construct a keyboard-based console controlling system, that is displaying on the primary monitor, while the focus is still with the full-screen window. But it's not very handy, I (and most of the people, I suppose) would rather use mouse for that...
I was digging through DXSDK documentation and found out this:
It's the most descriptive part I could find about the problem (not very descriptive, is it?[grin]). Does it actually mean something, or is just blabbering, because I cannot decipher it completely?
The deal is, however, I'm not interested in debugging my single-monitor app. It's supposed to be dual-monitor app, that's displaying a full-screen presentation on one monitor (or using a projector), and has a control-console on the second one.
Now, I could quite easily (well, not *that* easily) construct a keyboard-based console controlling system, that is displaying on the primary monitor, while the focus is still with the full-screen window. But it's not very handy, I (and most of the people, I suppose) would rather use mouse for that...
I was digging through DXSDK documentation and found out this:
Quote:The concept of exclusive full-screen mode is retained in Microsoft DirectX 9.0, but it is kept entirely implicit in the IDirect3D9::CreateDevice and IDirect3DDevice9::Reset method calls. Whenever a device is successfully reset or created in full-screen operation, the Microsoft Direct3D object that created the device is marked as owning all adapters on that system. This state is known as exclusive mode, and at this point the Direct3D object owns exclusive mode. Exclusive mode means that devices created by any other Direct3D9 object can neither assume full-screen operation nor allocate video memory. In addition, when a Direct3D9 object assumes exclusive mode, all devices other than the device that went full-screen are placed into the lost state.
It's the most descriptive part I could find about the problem (not very descriptive, is it?[grin]). Does it actually mean something, or is just blabbering, because I cannot decipher it completely?
In the DirectX SDK Properties (from the control panel) go the the "Direct3D" tab and tick the "Enable Multi-Mon Debugging" box.
I never tried it myself as I don't have a multi-mon setup, but I guess it should work.
I never tried it myself as I don't have a multi-mon setup, but I guess it should work.
Quote:Original post by Kamikaze15
In the DirectX SDK Properties (from the control panel) go the the "Direct3D" tab and tick the "Enable Multi-Mon Debugging" box.
I never tried it myself as I don't have a multi-mon setup, but I guess it should work.
Nifty! That does the trick, thanks. I guess it just overrides the standard minimizing behavior.
Author
Quote:Original post by circlesoftQuote:Original post by Kamikaze15
In the DirectX SDK Properties (from the control panel) go the the "Direct3D" tab and tick the "Enable Multi-Mon Debugging" box.
I never tried it myself as I don't have a multi-mon setup, but I guess it should work.
Nifty! That does the trick, thanks. I guess it just overrides the standard minimizing behavior.
Already tried it. Didn't make any difference, in both relase and debug mode [sad]
Windowed mode is not "that" bad. We get hundreds of frames per second on both monitors with it, and there is no focus problem.
Also, you can easily make your windows with no borders, so users won't even know it isn't fullscreen. The hit on FPS might be more significant for an FPS (lol!), but for a game without too much bleeding edge graphics detail, windowed is fine.
Also, you can easily make your windows with no borders, so users won't even know it isn't fullscreen. The hit on FPS might be more significant for an FPS (lol!), but for a game without too much bleeding edge graphics detail, windowed is fine.
Quote:Original post by deffer
It's supposed to be dual-monitor app, that's displaying a full-screen presentation on one monitor (or using a projector), and has a control-console on the second one.
It's a long-shot, but how's this for an idea...
Keep your "fullscreen" D3D component in windowed mode - but set up the window class (pre D3D initialization) to have no title/border and to cover the entire area of the screen (e.g. faking fullscreen). No border/title should also mean that it can't be resized/moved). After the window is created you can make it "always on top" so you shouldn't get anything else interfering with the rendering.
Now because it's still, technically, windowed mode you should be free to mess with the other monitor(s) as you'd normally expect - and have them play nicely together as you so desire.
hth
Jack
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
