cancel
Showing results for 
Search instead for 
Did you mean: 

Unable to get OpenGL working in Direct HMD mode

jherico
Adventurer
Neither my own applications nor the SDK examples appear to work in OpenGL mode if I enable DirectHMD with a DK1 (no DK2 to test with yet).

In my own example code, if I create a context with glfw and don't specify any special attributes (like the GL version or the profile) then the window is created on my primary monitor at the resolution of the Rift (in the upper left hand corner). If I attempt to specify the GL version and profile type, I get an error that the context could not be created.

In the OculusWorldDemo if I set the OpenGL renderer as the primary renderer, then the example crashes. This is because the wglCreateContextAttribsARB call in Render_GL_Win32_Device.cpp is returning NULL and the application isn't checking for that. The crash occurs a little later when glGetString(GL_VERSION) returns null (because there is no context active) and the SDK attempts to call strstr() with the null pointer.

I'm wondering if this is related to this thread and the behind the scenes voodoo that Oculus is using to render to a non-existent monitor surface.

If I set the Rift mode back to 'Extend Desktop', rendering in OpenGL works properly in both my application code and the Oculus SDK examples.
Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action
47 REPLIES 47

rupy
Honored Guest
"renderingpipeline" wrote:
"rupy" wrote:
the plastic case for DK1 was polled if it should be one for DK2. This setup is getting more and more complicated for developers and consumers. I vote for extended only and each developer fixing portrait mode on their own. Of course you can keep all your stuff but don't force people to install stuff. It should all fit in the games drivers. Config if you want but don't force it on developers, I have my own IPD settings. etc. etc.

Bottom line don't force us into your software chain; oculus is not the only platform we need to cater! I for one have to support VR (not only Oculus), normal screen and Android. Make my job easier!


I think Oculus is going in the right direction here, for costumers it's better if the Rift is not visible as a screen (how to configure this? 2D windows end up on that screen, the OS menu bar (OSX) could end up on that screen, etc etc., also: the games start on the correct screen automatically!). Tracking and distortion can get updated without having to touch the applications.
It's less complicated for the users, just a bit more complex for the developers, but this is fine.


Sure, If it was a standard and properly implemented yes. But there has to be a way to write your own platform and that it doesen't punish you by making your users have to go through loops to get your game running!
"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.

renderingpipeli
Honored Guest
"rupy" wrote:


Sure, If it was a standard and properly implemented yes. But there has to be a way to write your own platform and that it doesen't punish you by making your users have to go through loops to get your game running!


Unless your application is the only Rift application your costumers have installed, they already will have the runtime installed. It's not so uncommon for users that they have to install drivers when they buy new hardware.

rupy
Honored Guest
Yes, but if it means more work for me AND more work for all consumers it's a bad leverage. Say I need to tell the users to (to be extreme) uninstall the Oculus driver to play my game and then reinstall it afterwards, do you get where this is heading.

Facebook is not a nice granma, they're gonna squeeze us where they can. I need them to first deliver an unbiased simple hardware that works perfectly. Second they can build all the software they want, commended they don't force it down my throat.
"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.

Anonymous
Honored Guest
"rupy" wrote:
I vote for extended only and each developer fixing portrait mode on their own.I have my own IPD settings. etc. etc.


How does what you're asking for make things easier for anyone? It's not easy for Oculus as there would be no way to delegate access to the Rift. It's not easier for developers since they're left on their own to implement much of what will be routine as the hardware kinks are worked out, and it's not easier for users as their configurations are ignored for every single VR app they own.

jherico
Adventurer
"deanbeeler" wrote:
It's not easy for Oculus as there would be no way to delegate access to the Rift. It's not easier for developers since they're left on their own to implement much of what will be routine as the hardware kinks are worked out, and it's not easier for users as their configurations are ignored for every single VR app they own.


I'm down with the idea that access to the tracker information is delegated through a centralized service in order to allow multiple applications to access the Rift and the potential for allowing seamless transitions from application to application. However, it seems like this relatively straightforward functionality is orthogonal to the new (much more fragile and experimental) direct HMD code. The two things shouldn't be tied together in the same service.
Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action

2EyeGuy
Adventurer
Did you try what I said?

Anonymous
Honored Guest
"jherico" wrote:
However, it seems like this relatively straightforward functionality is orthogonal to the new (much more fragile and experimental) direct HMD code. The two things shouldn't be tied together in the same service.


One USB sensor, one display, one camera = One Rift. There's quite a bit being tied together in the service, along with HMD virtualization, hot plug, hardware matching, etc.

Afuerg
Honored Guest
"deanbeeler" wrote:
Are you attempting to use OpenGL on AMD hardware? With this release that's presently unsupported though it will be in the next update.

Wait, what???
I'm developing with OpenGL on AMD hardware, so I won't be able to do that until the next update?

renderingpipeli
Honored Guest
I also have problems with OpenGL and direct mode on Windows 8 (at least for DK1 on Windows 7 it works), details in this thread: https://developer.oculusvr.com/forums/viewtopic.php?f=20&t=11081&p=148172#p148172.

PathogenDavid
Honored Guest
"Afuerg" wrote:

Wait, what???
I'm developing with OpenGL on AMD hardware, so I won't be able to do that until the next update?


No, you just can't use direct mode. You have to use the legacy extended mode.