New to the forums? Click here to read the "How To" Guide.

Developer? Click here to go to the Developer Forums.

Unable to get OpenGL working in Direct HMD mode

2»

Comments

  • sth wrote:
    Tried all these configurations in my SDL2-based application and none of them works, not even the OVR->window variant.
    The (D3D-based) Oculus demos work fine with direct mode, though.

    Windows 7 64bit + nVidia GPU.

    Thanks for testing, I assume, you are using the same window/SDK initialisation order (and methods) as in this example (viewtopic.php?f=20&t=11067) ?
  • sthsth Posts: 113
    Brain Burst
    sth wrote:
    Tried all these configurations in my SDL2-based application and none of them works, not even the OVR->window variant.
    The (D3D-based) Oculus demos work fine with direct mode, though.

    Windows 7 64bit + nVidia GPU.

    Thanks for testing, I assume, you are using the same window/SDK initialisation order (and methods) as in this example (viewtopic.php?f=20&t=11067) ?
    Not the exact same code but it's pretty similar.
    I tried ovr_Initialize() before SDL_Init(SDL_INIT_VIDEO) / SDL_CreateWindow() and afterwards; both with DK1 and DK2. The result is always an empty window frame on the desktop and no signal on the HMD, usually followed by a crash on shutdown.
  • 2EyeGuy2EyeGuy Posts: 1,084
    Trinity
    edited July 2014
    jherico wrote:
    It's triggered in ovrHmd_EndFrame 637 (hmds->pRenderer->EndFrame(true);) 284 (ReleaseDC(RParams.Window, dc);) and then it's dying in C:\Windows\System32\OVRDisplay64.dll (Unhandled exception at 0x000007FEF4418D08 (OVRDisplay64.dll) in sdl_glew_ovr.exe: 0xC0000005: Access violation reading location 0x0000000000000008.).


    You're zeroing out the memory in ovrRenderAPIConfig before calling ConfigureRendering, right? If you don't the HDC and HWND members of ovrGLConfigData will likely have garbage and could trigger such a crash.
    I made that mistake before. Forgot to initialize DC.
  • rupyrupy Posts: 517
    Brain Burst
    jherico wrote:
    ... I've said before that one of the biggest hurdles Oculus had to overcome would be the issues inherent in the Rift being treated just like another monitor by the OS.

    Yes, but until they create 1) a completely stable workaround (this can take 10 years because of unknown unknowns, see steam, and they only had windows for many years) or 2) their own hardware graphics pipeline standard based on PCIe (this might take them also 10 years); they MUST use exisiting HDMI/DVI and then it's VERY simple to just say:

    The standard for Oculus is extended mode, like they now have done (because the screen is in portait mode).

    I will look for both portrait and landscape, then rotate the views 90 or 270 degrees if you are in portrait depending on a setting, so if you are upside down that's fixed too.

    The bottom line is that the user should not have to select "direct" or "extended" mode. If my app is only compatible with extended, then that should be automatic. Thus removing the service.

    If you need forwarding of the sensor data, you should write your own, unless of course everyone will forward the data. The service is over-engineered without adding anything, it's a m&m (managers and meetings) decision. Nobody said "no", or at least we don't know why anyone said "yes" yet!
    aeon.svg
    "It's like Homeworld in first person."
    Disable Aero and vSync for a completely simulator sickness free experience with 2xHz FPS.
    Keep the config utility open for tracking to work.
  • I had some luck getting a correct rendering on Win7 / NV / DK2 with this init order:

    ovr_Initialize
    ovrHmd_Create
    glfwCreateWindow
    ovrHmd_AttachToWindow
    ovrHmd_ConfigureRendering

    Creating the window before creating a HMD did fail as did calling ovrHmd_AttachToWindow after ovrHmd_ConfigureRendering (which I would have expected after reading the docs on page 29 as ovrHmd_AttachToWindow is explained after ovrHmd_ConfigureRendering...). The docs also note, that ovrHmd_AttachToWindow is needed for the direct HMD mode, however, after reading some of the tuscany code I suspect that it should be called always...

    Remaining bug: I don't get keyboard input in this mode, but gamepad events.
  • The init order:

    ovr_Initialize
    ovrHmd_Create
    glfwCreateWindow
    ovrHmd_AttachToWindow
    ovrHmd_ConfigureRendering

    seems only to work on Windows 7 (with the remaining bug of not getting keyboard events).

    On Windows 8 however it fails:
    When creating a GL context higher than 1.0 you normally create one context to get function pointers needed to generate your final context. When GLFW creates the second window and thus the second GL context, it fails. OculusWorldDemo forced to GL does the same: the final context is defective and thus the glGetString call in Render_GL_Device.cpp:723 returns a NULL pointer, comparing that with the known GL strings via strstr fails (passing NULL to strstr leads to undefined behaviour). So it crashes because of a bug in OculusWorldDemo with not testing for failed context creation but the real problem is that we don't get a valid second context on Win8 (but on Win7).
  • sthsth Posts: 113
    Brain Burst
    (with the remaining bug of not getting keyboard events).
    Okay, I give up. If this is the best I can expect with direct mode in 0.4.0, I won't waste any more time on this and wait for the next release. Thanks for the info and the time you put into this.
  • sth wrote:
    (with the remaining bug of not getting keyboard events).
    Okay, I give up. If this is the best I can expect with direct mode in 0.4.0, I won't waste any more time on this and wait for the next release. Thanks for the info and the time you put into this.

    Sorry, my bad. The keyboard bug was on my side and introduced by when I reordered the init code to work with DK2.

    So with the correct init order (and resetting the changed GL states) at least the extended mode should work for testing (even if it has judder) and only using the rift should be ok for testing without judder. Better than nothing and enough to start porting but I hope we will see a working direct HMD mode for GL on WIn7 & Win8 soon!
  • sthsth Posts: 113
    Brain Burst
    Extended mode is working fine for me (I don't even get judder), it's just direct mode that's giving me a headache.

    The only thing I haven't tested yet is calling ovrHmd_Create before window creation because it would require some truly horrible hacks in my code.
  • dghostdghost Posts: 165
    Brain Burst
    Has anyone actually gotten this to work with client distortion rendering?

    I've verified DirectHMD mode works on this system with SDK rendering, but with client rendering any attempt to operate on the device context or rendering context (e.g., wglSwapBuffers or wglDeleteContext) after calling ovrHmd_AttachToWindow causes a fatal crash in OVRDisplay<32/64>.dll. It doesn't matter which order things get called in or where they get called - it always crashes.

    I've even tried changing some of my code to more closely resemble the way libovr handles buffer swaps when it performs SDK rendering, but to no avail.

    Am I completely missing something here?
    Current Quake II VR stable release: 1.3.1
    DK2 support: see this post
  • sth wrote:
    The only thing I haven't tested yet is calling ovrHmd_Create before window creation because it would require some truly horrible hacks in my code.

    That's the only was it works for me on Win8.
  • dghost wrote:
    I've verified DirectHMD mode works on this system with SDK rendering, but with client rendering any attempt to operate on the device context or rendering context (e.g., wglSwapBuffers or wglDeleteContext) after calling ovrHmd_AttachToWindow causes a fatal crash in OVRDisplay<32/64>.dll.

    I haven't used client rendering since 0.2.5 as I switched to SDK rendering but you can look up in the source how Oculus does it and see what you do differently.
  • kokonutkokonut Posts: 27
    Brain Burst
    I am getting the same issue with Windows 8.1, NVIDIA 340.52, Direct Mode as jherico with SDL2. If I don't set anything special, then I get a not so useful MS OpenGL 1.1.0 context. Trying to request anything higher gets me a failed context creation. Tracking down the issue, when finally calls wglCreateContext(), I see that that D3D10 and D3D11 and DXGI stuff is getting called in the stack trace when I just want OpenGL :shock: Pretty sure this is wrong unless NVIDIA implemented OpenGL by translating it DirectX (reverse Wine) :lol:

    http://i.imgur.com/UaeIn0L.png
  • sthsth Posts: 113
    Brain Burst
    So I put ovrHmd_Create() before window initialization but still unsucessful.
    One thing I haven't seen posted here yet: When running in non-working direct mode, I get the following message printed to the console:
    OVRCreateDXGIFactory result 0x0
    
  • dghostdghost Posts: 165
    Brain Burst
    I was looking at some of this stuff again and have come across an even more bizarre issue.

    If I am in the Direct Mode and I call ovr_Initialize() at all before creating a window and OpenGL context it will either not display anything or will crash when trying to operate on the device context unless I am using SDK rendering. And this is without ever calling ovrHmd_Create() or ovrHmd_AttachToWindow() - all you have to do is call ovr_Initialize() at some point before creating a window and everything after will fail. Strangely, SDK rendering will still actually work despite this.

    Anyone else seeing this behavior?
    Current Quake II VR stable release: 1.3.1
    DK2 support: see this post
  • jhericojherico Posts: 1,420
    Nexus 6
    dghost wrote:
    I was looking at some of this stuff again and have come across an even more bizarre issue.

    If I am in the Direct Mode and I call ovr_Initialize() at all before creating a window and OpenGL context it will either not display anything or will crash when trying to operate on the device context unless I am using SDK rendering. And this is without ever calling ovrHmd_Create() or ovrHmd_AttachToWindow() - all you have to do is call ovr_Initialize() at some point before creating a window and everything after will fail. Strangely, SDK rendering will still actually work despite this.

    Anyone else seeing this behavior?

    Yes, this is what I've found and reported on somewhere in this thread. It seems to be related (on my system at least) to attempting to call wglCreateContextARB.
    Brad Davis - Developer for High Fidelity
    Co-author of Oculus Rift in Action

  • dghostdghost Posts: 165
    Brain Burst
    Welp, that answers that. Should have paid more attention then :P
    Current Quake II VR stable release: 1.3.1
    DK2 support: see this post
Sign In or Register to comment.