[GZDoom] OpenVR virtual reality mode

[biospud]

I added a new VR mode, for the first time, this one is actually virtual reality.

Adds "vr_mode 10", which uses the OpenVR API. I have tested it with the HTC Vive headset. It will probably also work with the Oculus Rift, with the right configuration (You must have SteamVR installed and configured).
Warning this mode is very primitive at the moment. I do not consider it polished enough to be fun and playable. But the remaining problems are sorta hard, and solving them might reach further into the gzdoom code than this already somewhat complex pull request does.
This begins implementation of "Phase 4" of the VR roadmap I outlined a while back viewtopic.php?f=35&t=50349
Interested developers must install the OpenVR SDK https://github.com/ValveSoftware/openvr and set the CMake variable "ENABLE_OPENVR" to TRUE before building gzdoom. Other developers should not experience build problems as long as the ENABLE_OPENVR Cmake variable remains at its default value of FALSE.

EDIT(again): updated pull request at https://github.com/coelckers/gzdoom/pull/345
EDIT: renamed cmake variable

[Rachael]

To facilitate testing on this feature, I am going to direct this to QZDoom, first, to give it a chance to be tried out before it is merged into the master. That will also give Graf some time to hopefully come back when he does.

This is the merge: https://github.com/raa-eruanna/qzdoom/c ... a4b906a4f1

I'll try and set up a build system for this later on with the SDK and option enabled.

[biospud]

Thank you Rachael for taking the time to look at this.

I'm planning to clean up my pull request a bit an resubmit. So you might want to wait before diving in.

Do you happen to have a VR headset?

[Rachael]

I do not. Unfortunately, someone who does is going to have to be the one to look into this.

I'll go as far as installing the SDK for the official devbuilds - so that this can get some proper testing before it gets merged - but that's all I can do.

When you do your clean-ups, I will adjust the QZDoom master branch accordingly.

[biospud]

I submitted a revised pull request at https://github.com/coelckers/gzdoom/pull/338
I cleaned up some minor things in response to a code review.
Plus I cleaned up a change to the framebuffer format that was starting to bother me.
I opened a new request because I squashed everything back down to one commit, as requested in the review.

[biospud]

I do not. Unfortunately, someone who does is going to have to be the one to look into this.

I'll go as far as installing the SDK for the official devbuilds - so that this can get some proper testing before it gets merged - but that's all I can do.

That's great actually. I have not properly tested the scenario where gzdoom is built with the openvr SDK, but there is no headset and (presumably) SteamVR is not installed. I'd like to ensure that scenario runs gracefully before widely distributing OpenVR enabled builds.

[Rachael]

I'm building it, now. I should have proper devbuilds out, soon, if it seems to work.

[_mental_]

Sorry but I forgot to ask one thing.

I'm not a lawyer nor licensing expert but I guess your changes are under BSD license.
Since GZDoom switched to GPLv3 recently I'm curious is it intentional or is it just leftover from initial implementation of VR support?

[Rachael]

As far as I know GPL allows the use of BSD code/projects as long as such code/projects do not link to non-free libraries that are not directly related to the OS. (I could be wrong) - so even with my understanding of it, I am not 100% sure what the case here is, since OpenVR is not part of the OS and I am not sure how deep the BSD-licensed code goes for this. If OpenVR is 100% BSD licensed we should be okay.

[Rachael]

The devbuild test is successful - there's two things to note, however:

- First thing: CMake needs to detect the OS type for the "hints" and distinguish between win32/win64 and select the proper library. Otherwise this will produce linker errors. This needs to be updated in the PR. (Please keep commit history for this - don't squash)

- Second thing: If this is merged and GZDoom is built with OpenVR support, openvr_api.dll will now have to be included in all distributions. (Hopefully, the ABI is compatible that someone can drop in an updated dll file later on down the road if they need to) The DLL appears to be statically loaded and will produce errors if not present. The good thing is, though, that the DLL is so small it barely makes a blip in the overall distribution size.

[Gez]

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

[biospud]

The devbuild test is successful - there's two things to note, however:

- First thing: CMake needs to detect the OS type for the "hints" and distinguish between win32/win64 and select the proper library. Otherwise this will produce linker errors. This needs to be updated in the PR. (Please keep commit history for this - don't squash)

- Second thing: If this is merged and GZDoom is built with OpenVR support, openvr_api.dll will now have to be included in all distributions. (Hopefully, the ABI is compatible that someone can drop in an updated dll file later on down the road if they need to) The DLL appears to be statically loaded and will produce errors if not present. The good thing is, though, that the DLL is so small it barely makes a blip in the overall distribution size.

Thanks for working on this. I'll implement those changes.

Yes, openvr_api.dll would need to be included in OpenVR-enabled distributions. While it would be great to eventually distribute OpenVR-enabled versions for Mac and Linux, the support for OpenVR itself on those platforms is shaky at the moment, so we would need some developer who is very motivated to get this working on one or both of those. Even on Windows, I'm ambivalent about building OpenVR-support into the official builds until the VR gameplay is a bit more refined.

[biospud]

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.

[biospud]

Sorry but I forgot to ask one thing.

I'm not a lawyer nor licensing expert but I guess your changes are under BSD license.
Since GZDoom switched to GPLv3 recently I'm curious is it intentional or is it just leftover from initial implementation of VR support?

As far as I know GPL allows the use of BSD code/projects as long as such code/projects do not link to non-free libraries that are not directly related to the OS. (I could be wrong) - so even with my understanding of it, I am not 100% sure what the case here is, since OpenVR is not part of the OS and I am not sure how deep the BSD-licensed code goes for this. If OpenVR is 100% BSD licensed we should be okay.

It was not intentional. I think it's OK to distribute BSD code in a GPL project. But I'd like to change the headers to set a more consistent example for others.

[Rachael]

GZDoom contains lots of BSD-licensed code as it is - this is all code that has not yet been updated to the new license, including a lot of ZDoom-originated code.

The BSD license is much more permissive than GPL and is downgrade-compatible (to GPL) - so in this instance, it should work.