[GZDoom] OpenVR virtual reality mode

[biospud]

Graf Zahl some time ago performed the chore of updating all the license headers in the gl renderer, so I decided to do my part and update these newer files just now.
I also updated the cmake rules to choose the correct platform library. And install that library, in case anyone is using the cmake install functionality at the moment.

[Rachael]

I went ahead and updated my source tree, but since there isn't anything done in the actual VR code, itself, other than header changes, I did not see an immediate need to dispatch a new devbuild. The current one is still pretty much up-to-date.

[Gez]

It should be made to load dynamically, though, even if it'll end up part of the official distribution.

Do you mean that openvr_api.dll should be distributed as a shared library, rather than statically linked? If so, that's how it's working now.

A shared library, but dynamically loaded so that the program can run without it (just disabling any VR-related stuff in that case).

For example, set your MIDI device to FluidSynth, then remove the FluidSynth DLL and start GZDoom. It'll still work, you just won't have MIDI music (and there'll be error messages about it in the console log).

[biospud]

It should be made to load dynamically, though, even if it'll end up part of the official distribution.

A shared library, but dynamically loaded so that the program can run without it (just disabling any VR-related stuff in that case).

I understand now. That's not how it is working right now. If I rename the dll, qzdoom refuses to run.
It looks like it might be rather complicated to get the dynamic loading behavior you describe.

[Graf Zahl]

There's one important thing to be resolved first:

Is the OpenVR DLL XP compatible? I cannot test that. But unless it is completely dynamically loaded I cannot merge a PR that depends on code that isnÄt guaranteed to work on XP. A DLL loading failure at runtime will result in a disabled feature, a DLL loading failure at launch time will prevent the program from running at all.

[Rachael]

There's one important thing to be resolved first:

Is the OpenVR DLL XP compatible? I cannot test that. But unless it is completely dynamically loaded I cannot merge a PR that depends on code that isnÄt guaranteed to work on XP. A DLL loading failure at runtime will result in a disabled feature, a DLL loading failure at launch time will prevent the program from running at all.

Or maybe we could just use that to sound XP's final death knell.

[/wishful thinking]

[Graf Zahl]

If I had to choose between XP and VR I'd pick XP.
Sorry, but in this case greater market share wins by default.

[Rachael]

At any rate I am attempting to locate my XP virtual machines now, to test. It appears that the .dll file is marked for Windows Version 5.00, which is Windows 2000, though, so this should be fine. But I will test it to be sure.

[Rachael]

Confirmed to work just fine in Windows XP. I was able to start the latest QZDoom dev build in both software and OpenGL mode and played through the first level of Freedoom2 with no problems. This is with this submission compiled in and turned on.

[biospud]

In response to Gez's concern about what happens if the OpenVR dll is missing, I spent a few hours trying to build the infrastructure necessary to load OpenVR dynamically. I quickly realized that this would be an onerous task.

So this morning I tried the opposite approach: statically linking the public OpenVR API sources into gzdoom. With only about 5 new lines of CMake, I got a working executable that no longer requires the OpenVR dll. I'm inclined to proceed with this approach. I'll amend the pull request with one more commit once I get things cleaned up a bit.

[biospud]

I pushed my recent static-by-default OpenVR changes. For some reason the automated clang build seems to be taking forever, after the others completed successfully. It finished in 6.5 minutes previously, but is now at two hours and counting.

[biospud]

Good news! I just tested one of the recent QZDoom dev builds on another computer with an Oculus Rift and SteamVR installed. It worked just as well as the Vive. In other words, both the Oculus Rift and HTC Vive virtual reality headsets can be used with the OpenVR mode.

The menu and weapons look terrible and there is no positional tracking on both headsets. But that's because we haven't refined those bits yet. The basic infrastructure is working.

[Nash]

I'm so happy to see VR progress in GZDoom. I'm looking to upgrade to a GTX 1080 and get the Vive VR set soon so I can enjoy Doom in virtual reality. :D

[Rachael]

I saw a bunch of commits (looks like a merge that went awry) and then the pull request was closed.

Unfortunately there aren't any developers right now who can give this a proper test, as we do not have the hardware.

What is the status of this, now?

[biospud]

I saw a bunch of commits (looks like a merge that went awry) and then the pull request was closed.

Unfortunately there aren't any developers right now who can give this a proper test, as we do not have the hardware.

What is the status of this, now?

Yeah sorry I closed it after I messed up the merge with some improvements in the menu and weapon appearance. I'm planning to open a(nother) new request with a clean commit. Sorry I'm not very nimble at creating clean git history.

I was hoping too someone else would have the hardware to help test this (Oculus Rift or HTC Vive). I heard dpjudas has an old Oculus DK2. But I haven't taken the time to prove whether the DK2 could work for this or not, so I cannot say whether setting that up might be worth dpjudas' time.