Ok, I'm actually having 2 issues, I'm going to post them together, because I suspect the could possibly be related. Issue #1 is with CreateDevice. I'm calling it as follows (irrelevant code removed): d3dpp.BackBufferWidth = width; d3dpp.BackBufferHeight = height; d3dpp.BackBufferFormat = D3DFMT_A8R8G8B8; d3dpp.BackBufferCount = 1; d3dpp.MultiSampleType = D3DMULTISAMPLE_NONE; d3dpp.MultiSampleQuality = 0; d3dpp.SwapEffect =D3DSWAPEFFECT_COPY; d3dpp.hDeviceWindow = m_hWnd; d3dpp.Windowed = FALSE; d3dpp.EnableAutoDepthStencil = TRUE; d3dpp.AutoDepthStencilFormat = D3DFMT_D16; d3dpp.FullScreen_RefreshRateInHz= D3DPRESENT_RATE_DEFAULT; d3dpp.PresentationInterval = D3DPRESENT_INTERVAL_IMMEDIATE; d3dpp.Flags = D3DPRESENTFLAG_LOCKABLE_BACKBUFFER; r = m_pD3D->CreateDevice( D3DADAPTER_DEFAULT, D3DDEVTYPE_REF, m_hWnd, D3DCREATE_SOFTWARE_VERTEXPROCESSING, &d3dpp, &m_pDevice ); Ok, now here is the problem. As you can see I'm using D3DDEVTYPE_REF, needless to say, not pretty. I'm on a multi-headed system (GeForceFX 5200, latest NVidia drivers loaded, running in DualView Mode). If I call CreateDevice with D3DDEVTYPE_HAL, I get D3DERR_NOTAVAILABLE, and as you can see, none of the parameters I'm using are anything fancy, so there is no reason it should be having a problem. To further throw a wrench in the works, if I go into Windows display properties and disable my second display, the above code works just fine with D3DDEVTYPE_HAL. I've noticed that since at least the 6.1.1.7 version of the NVidia drivers, a number of commercial games will only run if I disable the second monitor, but since quite a few will run correctly without turning the second display off, I know there has to be a workaround for this problem. Ok, now onto problem #2, the dreaded Alt-Tab... Yes, I've read all the FAQs, and every other resource I can find, still no love... Here is what is happening... First a little code... Just a few lines.. void AppObject::DoFram(float timeDelta) { if(!GraphicsObject()->HasFocus()) { hr = GraphicsObject()->GetDevice()->TestCooperativeLevel(); if (hr==D3DERR_DEVICENOTRESET) { GraphicsObject()->ResetDevice(); } else { return; } } // rest of drawing code here } I think the object encapsulation here is pretty obvious, so I'm not going to explain it unless I really need to... If I Alt-Tab out of the app, GraphicsObject()->HasFocus() gets sets to false as it is supposed to, so when rendering I hit this little structure and just bounce out of the render code until I get TestCooperativeLevel() == D3DERR_DEVICENOTRESET... The problem is, if I click on my app in the taskbar after Alt-Tabbing out, I get the little windows maximizing graphic, and never receive D3DERR_DEVICENOTRESET. I have verified this by throwing a OutputDebugString into the loop to show the status every pass, and then scrolling through the 10 pages of Debug messages I get and making sure the status never actually changes. Again, not sure if these problems could both be related, but they both strike me as something driver related. Any thoughts on either or both?

I don't really have a very conclusive answer, so I'm just going to throw out a few things you might try:

If your desktop is in 16-bit colour rather than 32-bit colour, and you select a 32-bit backbuffer format, I've seen problems (I recall Morrowind did this).

I'm not really sure if/why you need a lockable back buffer or a copy swap effect, I don't use them myself. If you turn them off does it work? (if you can't because they're required for your app, nevermind about it, just a thought).

On your alt-tab code, you say it never returns DEVICENOTRESET, what does it actually return? success, or DEVICELOST?

-Mezz

Quote:
If your desktop is in 16-bit colour rather than 32-bit colour, and you select a 32-bit backbuffer format, I've seen problems (I recall Morrowind did this).

Nope, both displays are set to 32-bit, 1024x768 in windows.

Quote:
I'm not really sure if/why you need a lockable back buffer or a copy swap effect, I don't use them myself. If you turn them off does it work? (if you can't because they're required for your app, nevermind about it, just a thought).

Required or not it was worth trying. Disabled locakable back buffer and changed swapeffect to D3DSWAPEFFECT_DISCARD. Same problem, Can't CreateDevice with D3DDEVTYPE_HAL.

Quote:
On your alt-tab code, you say it never returns DEVICENOTRESET, what does it actually return? success, or DEVICELOST?

It returns DEVICELOST.
For reference, the program does not stop responding. When I try to maximize the window, I can hit my exit hotkey (ESC), and the game exits. This is handled by the Windows message pump portion of the code, so I know its not a problem like some I've seen where they suspend the game, and forget to keep handling Windows Messages.

Ok, some additional information based on stuff I found via Google.

I added this line:

r = m_pD3D->CheckDepthStencilMatch(D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, D3DFMT_A8R8G8B8, D3DFMT_A8R8G8B8, D3DFMT_D16);

before my CreateDevice, and I consistently receive D3DERR_NOTAVAILABLE. I've tried it with different combinations of formats, and none of them seem to work. Don't know if this will help at all, but I figured more information never hurts.

The plot thickens...
Ran dxdiag.

Display 1 tab shows my video card
NVidia GeForceFX 5200 yada yada yada
All DirectX Features are not available.
this is my primary display, so should have all the features.

Display 2 tab shows the dummy Dualview display adapter that is created when you put the NVidia card into dualview mode. This has all the features enabled.

Is this an issue with the was NVIDIA is enumerating the displays within their driver? I suppose I can switch my monitors around and see if that provides me with a workaround for the time being.

Hmm weird.

Since you say you've tried many format combos, I'll assume you've tested the 32bit varieties (D24S8 etc.) as well.

May I suggest having a look in the DirectX Caps Viewer, and checking the 'adapter formats' section for both the graphics adapters listed, it will tell you whats available, which might help determining if there is a problem with your code or if it's something else, like dodgy driver installation. If it can't get HAL 32-bit colour with a D24S8 depth/stencil buffer something is almost definately wrong, and it's not your code :)

-Mezz

*grumbles something about poorly written drivers*

Its got to be something with my configuration, I doubt NVIDIA would have let the drivers out the door if this was a typical problem. If I set my secondary display as primary (the one on the Dummy adapter that the drivers create for DualView mode), both problems automagically disappear.

Oh well, maybe this thread will help someone else with a similar configuration problem ;)

Endurion I think is onto an issue possibly, but instead of backbuffer format I think he means adapter format, as I just checked the caps viewer and the adapter formats are only X8R8G8B8, but they allow you a backbuffer format of A8R8G8B8.

I'm out of suggestions apart from messing with your h/w config, because as you say problems disappear/reappear depending on how you configure your multi-mon setup, which seems to indicate something else amiss.

-Mezz

As long as I run it with display #2 set as my default display, it has no gripes with A8R8G8B8 for both... I was under the impression that in full screen mode you just set the back buffer type and DirectX picked the adapter type that best matched it automatically. Am I mistaken in that assumption? Either way, it is working just fine like this.. Now I need to pull up some of the commercial games I was having problems with and see if their problems went away. *wonders if some of them have been running in REF mode all this time*