CM. EDIT UPDATE BELOW. The original question has been changed!
I have a working window that uses a DX11 device. My problem arises when I try to switch to full screen mode using Alt + Enter. If the window is not focused, I get a debug output that says:
'MyGame.exe': Loaded 'C:\Windows\SysWOW64\D3D10SDKLayers.DLL', Cannot find or open the PDB file
and then a warning
DXGI Warning: IDXGISwapChain::Present: Fullscreen presentation inefficiencies incurred due to application not using IDXGISwapChain::ResizeBuffers appropriately, specifying a DXGI_MODE_DESC not available in IDXGIOutput::GetDisplayModeList, or not using DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH
I am sure that the DX11 game SHOULD NOT load D3D10SDKLayers.dll, especially in the middle of execution. From the MSDN docs, I realized that this DLL is loaded when the if a device is created with the appropriate layer flag, this DLL is loaded automatically : if a device is created with the appropriate layer flag, this DLL is loaded automatically . Therefore, I checked that some ways to create my device were called in the middle of execution, but this is not so. I have only 2 places in my game, where there is a device creation, and not a single place falls into it. EDIT: after checking the MSDN, it seems that this DLL is just a debugging DLL and can just be loaded to print the warning itself, without any other purpose.
Explicit breeding events:
1) Alt + Enter 6 times (3 full-screen transition cycles, in both directions, starting from the window), the 7th DLL loads and a warning appears. This happens regardless of the focus of the window.
Summary of the hierarchy of method calls (in full screen mode):
1) ToggleFullscreen () - my method, only the method called Alt + Enter
2) ResizeTargetAndBuffers () - my method, sub-methods below
3) DXGISwapChain-> ResizeTarget (frontBufferDesc) changes the size of the front buffer to the specified res
4) DXGISwapChain-> GetFullscreenState () to determine the full-screen state
5) DXGISwapChain-> SetFullscreenState (TRUE, NULL) for full screen viewing
6) ResizeDXGIBuffers (width, height, TRUE) my method, resize the back buffer, sub-method below
7) DXGISwapChain-> ResizeBuffers (number, width, height, format, flags) for resizing the back buffer
8) DXGISwapChain-> ResizeTarget (frontBufferDesc) prevents problems with the refresh rate. The RefreshRate member is nullified according to MSDN best practices.
9) DXGISwapChain-> GetFullscreenState () to determine the full-screen state
Summary of the method call hierarchy (to be completed):
1) ToggleFullscreen () - my method, only the method called Alt + Enter
2) ResizeTargetAndBuffers () - my method, sub-methods below
3) DXGISwapChain-> ResizeTarget (backBufferDesc) changes the size of the front buffer to the specified res
4) DXGISwapChain-> GetFullscreenState () to determine the full-screen state
5) DXGISwapChain-> SetFullscreenState (FALSE, NULL) for full screen viewing
6) DXGISwapChain-> ResizeTarget (backBufferDesc) to change the size of the front buffer to window resolution (helped to solve some problems with res)
7) ResizeDXGIBuffers (width, height, FALSE) my method, resize the back buffer, sub-methods below
8) DXGISwapChain-> ResizeBuffers (number, width, height, format, flags) for resizing the back buffer
9) DXGISwapChain-> GetFullscreenState () to determine the full-screen state
The consequences are quite serious. My low-level keyboard hook that catches Alt + Enter is no longer called, so windows can do Alt + Enter automatic processing, which completely bypasses my ToggleFullscreen method and sets the window resolution to the desktop. This leads to improper size of the buffers (since I did not install them, made windows), causing an inefficiency warning and messing around with variables in my program that no longer have the correct knowledge of the buffer sizes and regardless of whether the window is full-screen or not.
Any ideas as to what could be causing this?
PS If you want the code samples to be specific in relation to what you want to see, and I will try to put it if possible. I can’t reveal the whole list of codes.
EDIT: device creation code is given below.
hr = D3D11CreateDevice( pAdapter, driverType, NULL, rDeviceSettings.m_CreateFlags, &rDeviceSettings.m_eD3DDeviceFeatureLevel, 1, D3D11_SDK_VERSION, &pGraphicsDevice, &eFeatureLevel, &pDeviceContextI ); if ( FAILED( hr ) ) { pAdapter = NULL;
The first call is made in 99% of cases, namely, when you are not using Remote Desktop, so I will focus only on it. I give it an adapter, driverType as D3D_DRIVER_TYPE_HARDWARE, m_CreateFlags as D3D11_CREATE_DEVICE_DEBUG and m_eFeatureLevel as D3D_FEATURE_LEVEL_11_0. A pretty standard challenge, and it always succeeds.
EDIT UPDATE 1: After some extensive debugging, I found that when loading the dll and the warning about inefficiency appears, some very interesting circumstances arise. They are listed below:
1) The VS2010 debugger no longer causes breakpoints in the key hook.
2) Print output no longer works in key hook.
3) a window may become impracticable if it was re-significant before
4) the window may become non-movable.
5) a trio of output threads.
EDIT UPDATE 2: The first edit update may have incorrect assumptions; if I find him, I will delete him. It turns out that my lower-level hook is no longer called (I think because breakpoints or print statements do not work inside it), so if something in my program accidentally deregisters it, it will cause all of the above problems, Testing it tomorrow. ..
EDIT UPDATE 3: I am not sure what is going on. I tested the same clean project on my home computer and work computer and got different results. At home I can Alt + Enter indefinitely, without any problems, but at work Alt + Enter for the 7th time causes the key hook to no longer be called and buffer problems.
EDIT UPDATE 4: More testing (at work). The key hook is definitely removed after the third transition to windowed mode. It no longer prints inside the key binding method, and breakpoints do not start, no matter which key is pressed. I think I'm going to open a separate question about this, since all the other problems described above are the result of this key hook that does not call ToggleFullscreen (). For reference, I have provided the key hook code below.
LRESULT _stdcall MyClass::WindowsKeyHook( s32 nCode, WPARAM wParam, LPARAM lParam ) { printf("Key hook called, nCode: %d. ", nCode); if( nCode < 0 || nCode != HC_ACTION ) { // do not process message return CallNextHookEx( MyClassVar.GetWindowsKeyHook(), nCode, wParam, lParam ); } printf(" Key hook status ok.\n"); BOOL bEatKeystroke = FALSE; KBDLLHOOKSTRUCT* p = ( KBDLLHOOKSTRUCT* )lParam; switch( wParam ) { //NOTE: Alt seems to be a system key when it is PRESSED, but a regular key when it is released... case WM_SYSKEYDOWN: if(p->vkCode == VK_MENU || p->vkCode == VK_LMENU || p->vkCode == VK_RMENU) { MyClassVar.SetAltPressed(TRUE); } if(MyClassVar.IsAltPressed() && p->vkCode == VK_RETURN) { bEatKeystroke = TRUE; MyClassVar.SetAltEnterUsed(TRUE); printf("Alt+Enter used.\n"); } break; case WM_SYSKEYUP: //NOTE: releasing alt+enter causes a SYSKEYUP message with code 0x13: PAUSE key... break; case WM_KEYDOWN: break; case WM_KEYUP: { if(p->vkCode == VK_MENU || p->vkCode == VK_LMENU || p->vkCode == VK_RMENU) { MyClassVar.SetAltPressed(FALSE); } bEatKeystroke = ( !MyClassVar.IsShortcutKeysAllowed() && ( p->vkCode == VK_LWIN || p->vkCode == VK_RWIN ) ); break; } } if( bEatKeystroke ) { return 1; } else { return CallNextHookEx( MyClassVar.GetWindowsKeyHook(), nCode, wParam, lParam ); } }
The printf statements show that the key hook is only called after the 6th Alt + Enter. This is the third transition to windowed mode. I don’t need to go into full screen for the 4th time, as I thought before, to cause the problem. All methods called MyClassVar are built-in to make the key hook as fast as possible, since I know that there is a timeout on the Windows keyboard keys. Actual handling Alt + Enter is handled by the thread in MyClass.
Also, can someone do this by a non-wiki community? I think this question is too specific to use as a wiki. The only reason he has become is to regularly update it with changes.