ALT_TAB works at all resolution but NOT desktop resolution?!
Author
Let me start off with a WTF?
My application can ALT+TAB in and out of all resolutions except the current desktop resolution. It took me forever to figure out that this was the problem, but I tested by changing my desktop resolution etc, and this is certainly the problem.
FYI, I can change resolution TO desktop resolution and it works fine as well! Basically this paragraph was to say that I don't think this problem has to do with my releasing/recreating everything.
When I ALT+TAB while my app is at the current desktop resolution, it seems like it ALT+TABs out and back in really quick. Except its not really ALT+TAB'd back in. My mouse gets messed up skipping, and if I hit ALT+TAB again I see the ALT+TAB selection boxes moving by THROUGH my app...
I used the WM_ACTIVATE case to see what's going on, and it is actually registering an ALT+TAB OUT AND BACK IN! SOMEONE HELP PLEASE!
[Edited by - Reepal on September 4, 2004 5:35:06 AM]
Author
Nope, nothing interesting. But I have a feeling that it's either DirectInput (mouse and keyboard (am using unsigned btw)) or something with the Window Class settings.
FYI,
Nothing unusual in there right? I tried removing all style settings as well, but still no go. I'm leaning towards DirectInput somehow getting mixed in, but I just tried destroying the DI objects and recreating them on ALT+TAB and still no go!
FYI,
wc.style = CS_OWNDC | CS_HREDRAW | CS_VREDRAW; wc.cbClsExtra = 0; wc.cbWndExtra = 0; wc.lpfnWndProc = WndProc; wc.hInstance = hInstance; wc.hbrBackground = (HBRUSH)GetStockObject(DKGRAY_BRUSH); wc.hIcon = LoadIcon(NULL, IDI_APPLICATION); wc.hIconSm = LoadIcon(NULL, IDI_APPLICATION); wc.hCursor = LoadCursor(NULL, IDC_CROSS); wc.lpszMenuName = NULL; wc.lpszClassName = cAppName; // Now we need to register this class with Windows. RegisterClassEx(&wc); // Create the window based on the previous class. hWnd = CreateWindowEx(WS_EX_TOPMOST, // Advanced style settings. cAppName, // The name of the class. cAppName, // The window caption. WS_POPUP | WS_SYSMENU | WS_VISIBLE, // The window style. CW_USEDEFAULT, CW_USEDEFAULT, // The starting window position. 640, 480, // The initial window size. NULL, // Handle to parent window. NULL, // Handle to menu. hInstance, // Handle to app's instance. NULL); // Advanced.Nothing unusual in there right? I tried removing all style settings as well, but still no go. I'm leaning towards DirectInput somehow getting mixed in, but I just tried destroying the DI objects and recreating them on ALT+TAB and still no go!
For you WNDCLASSEX styles, try using CS_CLASSDC. And for your CreateWindow styles, try using WS_OVERLAPPEDWINDOW. These are the settings that I use (without any problems) and that the SDK tutorials use.
Author
Used OverlappedWindow and CS_CLASSDC, and still same results.
Also, when I ALT+TAB at the Desktop resolution, I get a small rectangle in the center of the screen for a split second that flashes away...
Another very interesting thing I noticed..my APP keeps running even as its ALT+TABBED out. Like, my Render function keeps calling since my ValidateDevice is NOT detecting failure in the TestCooperativeLevel. As I said before though, this doesn't happen at any other resolution except the same resolution as the desktop is in, so I don't think its actually a problem with the ValidateDevice function. Interesting to note though, when it does this, I can't use my DirectInput devices anymore, but Windows GetAsyncKeysTATE function still works!? Again, at any other resolution, on ALT+TAB my DirectInput devices still come back just fine. =\
Also, when I ALT+TAB at the Desktop resolution, I get a small rectangle in the center of the screen for a split second that flashes away...
Another very interesting thing I noticed..my APP keeps running even as its ALT+TABBED out. Like, my Render function keeps calling since my ValidateDevice is NOT detecting failure in the TestCooperativeLevel. As I said before though, this doesn't happen at any other resolution except the same resolution as the desktop is in, so I don't think its actually a problem with the ValidateDevice function. Interesting to note though, when it does this, I can't use my DirectInput devices anymore, but Windows GetAsyncKeysTATE function still works!? Again, at any other resolution, on ALT+TAB my DirectInput devices still come back just fine. =\
Author
I think the device gets lost when I alt+tab OUT..but it automatically ALT+TAB's back in. (I'm not sure how or why it does that). But once it ALT+TAB's back in from Desktop Resolution (i obviously don't have control over this since it does it automatically), it knows it has the device back (because it keeps rendering, I have a sprite being rotated in the background which gets updated every frame).
Problem is that I can't ALT+TAB out and get it to STAY out at Desktop resolution.
And for whatever reason, when it automatically ALT+TAB's back in AT DESKTOP RESOLUTION ONLY, everything gets released/recreated, but my DirectInput doesn't work anymore even though it should have been destroyed and recreated as well. I also tested this withOUT DirectInput completely, and it does the same thing, so it's not DirectInput causing the problem.
Problem is that I can't ALT+TAB out and get it to STAY out at Desktop resolution.
And for whatever reason, when it automatically ALT+TAB's back in AT DESKTOP RESOLUTION ONLY, everything gets released/recreated, but my DirectInput doesn't work anymore even though it should have been destroyed and recreated as well. I also tested this withOUT DirectInput completely, and it does the same thing, so it's not DirectInput causing the problem.
This sounds suspiciously similar to a problem we encountered on Deus Ex 2 and Thief 3.
We found that Alt-Tabbing away from full-screen mode, but only on Windows XP and only when game resolution was the same as the desktop resolution, had weird problems. Never happened on other OSes, never happened when the game's video mode differed from the desktop's, made no difference whether it was an ATI card or an NVIDIA card or one driver version versus another.
In our case, when you Alt-Tabbed away, one of two things would happen. Half the time the 3D hardware would continue rendering the end of the previous frame, even though GDI had taken over and redrawn the desktop. Typically you would see parts of the HUD (since they were drawn last) on top of Visual Studio or whatever else you had on the desktop. GDI and the 3D hardware were basically stepping on one another.
The other half of the time you would find yourself looking at the previous frame. GDI and User32 believed that they were in control of the primary buffer -- the cursor would change as you moved it around, you could click and everything, you just couldn't see anything because you were actually looking at the game's previous back buffer. And this is because GDI was drawing to the front buffer, which was not visible!
It's 50-50 because we had two buffers. Half the time you were looking at the front buffer and half the time you were looking at the game's back buffer.
This is not rational, understandable behavior, even for a buggy D3D app -- unless perhaps you're interfering with the runtime's view of the message queue, which can only happen by subclassing the focus window, which we were definitely not doing. And even then, why would it be OS- and resolution-specific?
But we were unsuccessful in pleading the case that this might, just might possibly be a runtime bug, not an app bug. And so you'll note that the release notes in these games say that Alt-Tabbing away from the game is not supported.
I'm not sure, but from the description I'm inclinded to think that you've encountered the same bug. And while I can't be 100% sure, I'm 99.9% convinced that this is not an app bug, it is a runtime or OS bug. And I absolutely DO NOT make that sort of judgment lightly. I spent hours and hours trying to narrow this down as our bug before I redirected my suspicion.
You can report this to directx@microsoft.com as a bug, but be prepared to go through the same rigamarole -- are you doing this, are you doing that, and eventually they might give up and stop responding. Perhaps if you include my post here, it will lend some credibility to the possibility -- however remote it may seem to them -- that this is a runtime/OS bug.
If you can send me the code, I'll be happy to take a look and see if it's the same kind of issue. It certainly sounds like it.
We found that Alt-Tabbing away from full-screen mode, but only on Windows XP and only when game resolution was the same as the desktop resolution, had weird problems. Never happened on other OSes, never happened when the game's video mode differed from the desktop's, made no difference whether it was an ATI card or an NVIDIA card or one driver version versus another.
In our case, when you Alt-Tabbed away, one of two things would happen. Half the time the 3D hardware would continue rendering the end of the previous frame, even though GDI had taken over and redrawn the desktop. Typically you would see parts of the HUD (since they were drawn last) on top of Visual Studio or whatever else you had on the desktop. GDI and the 3D hardware were basically stepping on one another.
The other half of the time you would find yourself looking at the previous frame. GDI and User32 believed that they were in control of the primary buffer -- the cursor would change as you moved it around, you could click and everything, you just couldn't see anything because you were actually looking at the game's previous back buffer. And this is because GDI was drawing to the front buffer, which was not visible!
It's 50-50 because we had two buffers. Half the time you were looking at the front buffer and half the time you were looking at the game's back buffer.
This is not rational, understandable behavior, even for a buggy D3D app -- unless perhaps you're interfering with the runtime's view of the message queue, which can only happen by subclassing the focus window, which we were definitely not doing. And even then, why would it be OS- and resolution-specific?
But we were unsuccessful in pleading the case that this might, just might possibly be a runtime bug, not an app bug. And so you'll note that the release notes in these games say that Alt-Tabbing away from the game is not supported.
I'm not sure, but from the description I'm inclinded to think that you've encountered the same bug. And while I can't be 100% sure, I'm 99.9% convinced that this is not an app bug, it is a runtime or OS bug. And I absolutely DO NOT make that sort of judgment lightly. I spent hours and hours trying to narrow this down as our bug before I redirected my suspicion.
You can report this to directx@microsoft.com as a bug, but be prepared to go through the same rigamarole -- are you doing this, are you doing that, and eventually they might give up and stop responding. Perhaps if you include my post here, it will lend some credibility to the possibility -- however remote it may seem to them -- that this is a runtime/OS bug.
If you can send me the code, I'll be happy to take a look and see if it's the same kind of issue. It certainly sounds like it.
Quote:Another very interesting thing I noticed..my APP keeps running even as its ALT+TABBED out. Like, my Render function keeps calling since my ValidateDevice is NOT detecting failure in the TestCooperativeLevel.
Yes, this is even more consistent with my experience. Under these circumstances, the device would mysteriously not be lost.
There definitely seems to be some confusion here between D3D and GDI as to who owns the card. And that is NOT an app bug.
Author
Okay, after more testing, I agree. This is not an app bug.
I put in a generic pause call of 50ms in my ValidateDevice function. Although this severely slows down execution speed, when I ALT+TAB out, I can SEE my desktop for a brief second before it ALT+TAB's back in. According to the debugstrings I'm outputting while running, TestCooperativeLevel is returning true on ALT TAB OUT! (of course it doesn't do that when it's not the desktop resolution)
But there must be a way to get around this or fix this right? Unreal Tournament 2004 has no problem! =\
ANOTHER INTERESTING THING I FOUND! If Desktop is at 1280x1024x16, ALT+TAB at 1280x1024x32 works. If Desktop is at 1280x1024x32, ALT+TAB at 1280x1024x32 does NOT work! This shed some light as to what the problem might be?
I'm also wondering..can I CHANGE the desktop to be say 1280x1024x16 if my app is running at 1280x1024x32? That way the user won't really notice his desktop is changed =D and then I could change it back on exit of the app? Or is there a better work around?
I put in a generic pause call of 50ms in my ValidateDevice function. Although this severely slows down execution speed, when I ALT+TAB out, I can SEE my desktop for a brief second before it ALT+TAB's back in. According to the debugstrings I'm outputting while running, TestCooperativeLevel is returning true on ALT TAB OUT! (of course it doesn't do that when it's not the desktop resolution)
But there must be a way to get around this or fix this right? Unreal Tournament 2004 has no problem! =\
ANOTHER INTERESTING THING I FOUND! If Desktop is at 1280x1024x16, ALT+TAB at 1280x1024x32 works. If Desktop is at 1280x1024x32, ALT+TAB at 1280x1024x32 does NOT work! This shed some light as to what the problem might be?
I'm also wondering..can I CHANGE the desktop to be say 1280x1024x16 if my app is running at 1280x1024x32? That way the user won't really notice his desktop is changed =D and then I could change it back on exit of the app? Or is there a better work around?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
