cancel
Showing results for 
Search instead for 
Did you mean: 

DirectHMD mode still broken for OpenGL in 0.4.1

jherico
Adventurer
Both my own examples and the OculusWorldDemo fail if I attempt to use them with OpenGL in Direct HMD mode. This is on a GeForce 650 Ti running driver version 340.52.

In the OculusWorldDemo the failure occurs on line 141 of Render_GL_Win32_Device.cpp:


HGLRC context = wglCreateContextAttribsARB(dc, 0, attribs);


The context returned here is NULL, but the code doesn't actually check the return value, so the crash occurs much later in Render_GL_Device.cpp, where the code attempts to perform a strstr on the value returned from glGetString(GL_VERSION). Again, the return value here is null, but the SDK isn't checking for it, so the strstr is attempting to read from the NULL pointer.
Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action
29 REPLIES 29

dghost
Honored Guest
Both my projects and a minimum viable SDL test harness fail too.

Edited to add: interestingly, with the minimum test harness SDL doesn't appear to fail to create a context - it just simply doesn't work. Other projects crash when trying to call SwapBuffers on the device context, though.
Current Quake II VR stable release: 1.3.1 DK2 support: see this post

Anonymous
Not applicable
Yep, similar issues here.

OculusWorldDemo (when switched to OpenGL) fails for me (on a Radeon 7950) at the line jherico mentioned.

The OpenGL SDL demo (from here ) and Duke VR (work in progress with SDK 0.4.x) both fail at glGenFramebuffers / glBindFramebuffer, when using Direct Mode.

grodenglaive
Honored Guest
Me to - I get BSOD when I try to run tuscany in direct mode. Works fine in extended mode though.
I have an AMD radeon 7870.
GA-Z97X-gaming gt; i5-4670k; Nvidia780Ti; 16GB PC3-17066; win7-64 bit; DK2

Anonymous
Honored Guest
OpenGL is still crystalizing. Further fixes for OpenGL missed the last release train but will make it into the next release. I'm confident most, if not all, of your OpenGL issues will be resolved by then.

jherico
Adventurer
"dghost" wrote:
Both my projects and a minimum viable SDL test harness fail too.

Edited to add: interestingly, with the minimum test harness SDL doesn't appear to fail to create a context - it just simply doesn't work. Other projects crash when trying to call SwapBuffers on the device context, though.


Previous experimentation has shown that if you create a context via wglCreateContext it works. The downside is that this function doesn't allow you to specify things like the OpenGL version or profile. Hence if I use GLFW3 to create a context without specifying anything (thus not triggering the use of wglCreateContextARB) then the context is created successfully. It still doesn't show on the HMD device in DirectHMD mode though.

Similarly, if I create an OpenGL window with a version and a profile, but I defer initialization of the SDK until after the window has been created, I get a window, but no output on the HMD device.
Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action

Fraxul
Honored Guest
"dghost" wrote:
Other projects crash when trying to call SwapBuffers on the device context, though.


I had this problem with crash on SwapBuffers in my custom GL4.1 engine -- it would crash on the second rendered frame. I managed to solve it by clearing all of the VAO and buffer binding state before passing control to the Oculus SDK (calling ovrHmd_EndFrame):


glBindVertexArray(0);
glBindBuffer(GL_ARRAY_BUFFER, 0);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, 0);
// now safe to call ovrHmd_EndFrame(...)


Figured it out when my app managed to run once without crashing but the last thing that was rendered (UI overlays) had corrupted vertex data. I think the Oculus SDK rendering must be accidentally changing the state of a bound VAO or buffer object, though why that leads to a crash in SwapBuffers is a mystery.

For initialization, the exact sequence that I use (raw Win32 calls for windowing + GLEW for extensions) is:

  • ovr_Initialize

  • ovrHmd_Detect + ovrHmd_Create + ovrHmd_SetEnabledCaps

  • use DwmEnableComposition to turn off Aero, though I might not actually need this for Direct-to-HMD mode -- still need to test

  • CreateWindow

  • ovrHmd_AttachToWindow

  • ShowWindow

  • Create bootstrapping GL context -- ChoosePixelFormat, SetPixelFormat, wglCreateContext, wglMakeContextCurrent

  • glewInit() to pull the WGL extension function addresses

  • wglDeleteContext to delete the bootstrapping GL context

  • Create "real" GL context -- wglChoosePixelFormatARB, SetPixelFormat, wglCreateContextAttribsARB, wglMakeContextCurrent

  • glewInit() again to ensure updated extension information from the new context

  • ovrHmd_ConfigureRendering and ovrHmd_ConfigureTracking

dghost
Honored Guest
"jherico" wrote:
"dghost" wrote:
Both my projects and a minimum viable SDL test harness fail too.

Edited to add: interestingly, with the minimum test harness SDL doesn't appear to fail to create a context - it just simply doesn't work. Other projects crash when trying to call SwapBuffers on the device context, though.


Previous experimentation has shown that if you create a context via wglCreateContext it works. The downside is that this function doesn't allow you to specify things like the OpenGL version or profile. Hence if I use GLFW3 to create a context without specifying anything (thus not triggering the use of wglCreateContextARB) then the context is created successfully. It still doesn't show on the HMD device in DirectHMD mode though.

Similarly, if I create an OpenGL window with a version and a profile, but I defer initialization of the SDK until after the window has been created, I get a window, but no output on the HMD device.


Interesting. I haven't had time to keep on top of this stuff, so that's good to know. Thanks.
Current Quake II VR stable release: 1.3.1 DK2 support: see this post

c3
Honored Guest
"deanbeeler" wrote:
OpenGL is still crystalizing. Further fixes for OpenGL missed the last release train but will make it into the next release. I'm confident most, if not all, of your OpenGL issues will be resolved by then.


Is there a general timeframe for when we can expect this next release?

jherico
Adventurer
"c3" wrote:
Is there a general timeframe for when we can expect this next release?


In the history of software engineering, when has this ever been a useful question?
Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action