11-15-2014 01:37 AM
return (*oldProcExW)( lpLibFileName, hFile, dwFlags );
lpLibFileName = 0x000007fef8b34648 L"gdi32.dll"
hFile = 0x0000000000000000
dwFlags = 0
lpLibFileName_cstr = 0x000000000012b770
targetAPI = DirectX (0)
HRESULT hr = DX11::D3D::LoadDXGI();
hr = DX11::D3D::LoadD3D();
IDXGIFactory* factory;
IDXGIAdapter* ad;
//Oculus SDK Bug: Once OpenGL mode has been attached in Direct Mode,
//running the next line will cause a crash in Oculus SDK. Seems to work
//If you never ShutdownVR() the OpenGL mode, and never InitVR() for the
//Direct3D mode, but that is very hacky. Running ovr_Initialize(); here stops
//crash, bug kills Direct Mode. Wait until SDK fixes this issue?
hr = DX11::PCreateDXGIFactory(__uuidof(IDXGIFactory), (void**)&factory);
11-17-2014 09:47 AM
11-17-2014 10:11 AM
11-17-2014 10:26 AM
"rezanourai" wrote:
Can you clarify if you are fully shutting down the entire process in between, or just shutting down LibOVR and then reinitializing it for D3D within the same process?
ovr_Initialize must be called prior to creating any D3D or GL objects, and shut down only after destroying all D3D/GL objects. I believe we've added an error return + debug output message when these conditions aren't met.
I'm currently trying to reproduce your issue here to investigate. Thanks for reporting this.
11-18-2014 09:15 AM
11-18-2014 09:35 AM
"shaver" wrote:
To be super clear, does the process exit between GL and D3D?
"rezanourai" wrote:
It appears the issue is if the same process tries to tear down one rendering stack (ex: GL) and then reinitialize with another (ex: D3D) we don't fully work in all cases (ex; Gl -> D3D, but we work the other way).
I've created a task to track this, but given that it's not a common case for apps to use 2 rendering architectures and expect hot-swap between them, it doesn't meet the bar for squeezing into this release. Exiting the application and relaunching it afterwards should work around the problem.
We'll get this prioritized accordingly and fixed in a future release. Thanks again!