[GZDoom] OpenVR virtual reality mode

[Rachael]

If this helps you, the cleanest way to do a git merge for a pull request is simply to rebase it on the current master. This can be done the following way: (assuming your 'gzdoom' remote is tracked to https://github.com/coelckers/gzdoom - if not feel free to substitute the URL or whatever you named your remote)

Code: Select all

git pull gzdoom master --rebase
// ... fix any merge conflicts as needed, make sure to continue the merge if it stops ...
git push yourremote branchname -f

This cleans up the pull request, as well as your git history, and generates a tidy display on the pull request screen when a reviewer/developer comes to look at it. Do be careful how you type things, and obviously do not use this on a branch that is intended for downstream for forks or other contributors.

The first command asks Git to checkout GZDoom's current master, directly, and then it rewinds your work and "fast-forwards" your work on top of it, essentially cherry-picking your past deeds and replaying them.

The second command asks Github to accept these changes as-is, because with your local branch missing its 'HEAD' it will reject them unless you force the push. (Again, I emphasize, be careful with that, and don't use it on collab/downstream branches)

[biospud]

If this helps you, the cleanest way to do a git merge for a pull request is simply to rebase it on the current master. This can be done the following way...

Thank you for the advice. This is a skill I need to work on. I believe I figured out how to do the same through tortoisegit. But I already messed up my branch history so I decided to create yet another pull request. Next time I will be more careful.

The new pull request is at https://github.com/coelckers/gzdoom/pull/345

This new pull request includes one new change: the 2D items and the weapon sprite are projected onto quads in the 3D scene, just as dpjudas recommended long ago. https://forum.drdteam.org/viewtopic.php ... =30#p60397

The new projection code is crude but functional. Right now, all of the 2D geometry gets rendered in one burst, and the weapon/player sprite in another. In future, in VR we should separately project each of the following items, in this order (distant to near, painters algorithm order):
* cross hair - should be on its own quad
* other 2D items (automap, menu, console, HUD, messages) - on another quad
* weapon - on yet another quad, should be drawn on top of other 2D items
* blend effects (radiation suit, berserk) - should be full screen

The invulnerability effect already works great in VR.

Other items to be implemented later:
* positional tracking
* render 3D motion controller models
* late scheduled tracking of yaw angle (in menu mode, yaw is not updated)
* always render weapon as if screenblocks was at max
* force/default VR-appropriate settings
* movebob 0
* multisampling on
* gl_billboard_faces_camera true

[Nash]

Will it be possible to use your hand controllers to sort of "aim" where your guns will fire, like in the other VR games?

[biospud]

Will it be possible to use your hand controllers to sort of "aim" where your guns will fire, like in the other VR games?

I believe that will be possible. Not until after we get those other items I listed in. Are you still using a VR headset?

[Nash]

No, not yet. I'd need to upgrade my graphics card first, as I don't even pass the minimum requirement for the Vive headset. A GTX 1080 and the Vive would cost me about 6 months salary (thank you currency inflation) so realistically, it won't be until next year where I can afford to buy the upgrades (and hopefully the Vive would have dropped in price!).

But the idea of playing GZDoom in virtual reality really excites me so I'm making it a point to buy the upgrades - also because I am making a GZDoom-derived standalone game and I want to make sure my game is VR-ready for customers with the appropriate hardware.

[MrDowntempo]

If you have an android phone and a google cardboard compatible headset, you can use software called riftcat to emulate an occulus or steamvr very easily. The software has a trial that just makes you restart your game every 15 minutes and the software is $15 for the ungimped version. Overall it's a much more affordable solution, and if you're not planning on playing anything heavier than doom, it's likely the most sensible. I've got it running minecraft real well, but doom is what I'm really after

[biospud]

In addition to the HTC Vive and Oculus Rift (CV1) headsets that I mentioned before, I now also found that gzdoom with this pull request works with the older Oculus development kit DK2. Which I think dpjudas has one of. I'm using the latest Oculus Runtime. Even though the Oculus software balked during the setup, complaining that the DK2 is obsolete, I was able to eventually view the Oculus home screen. Then when I ran Steam VR, it detected the DK2 and I was able to play gzdoom in VR.

[dpJudas]

A couple of comments of what I've run into so far with my DK 2:

1) First some compile warnings:

Code: Select all

gzdoom\src\gl\stereo3d\gl_openvr.cpp(290): warning C4312: 'type cast': conversion from 'GLuint' to 'void *' of greater size
gzdoom\src\gl\stereo3d\gl_openvr.cpp(297): warning C4311: 'type cast': pointer truncation from 'void *' to 'GLuint'
gzdoom\src\gl\stereo3d\gl_openvr.cpp(297): warning C4302: 'type cast': truncation from 'void *' to 'GLuint'

I know they aren't your fault, but rather Valve that decided to cast integers to pointers (wtf! use an union Valve!). Still, need to do a cast that somehow doesn't create this kind of warning. I think you have to cast it to a ptrdiff_t first or something.

2) Some linker warnings:

Code: Select all

gl_openvr.obj : warning LNK4217: locally defined symbol VR_IsHmdPresent imported in function "protected: __cdecl s3d::OpenVRMode::OpenVRMode(void)" (??0OpenVRMode@s3d@@IEAA@XZ)
gl_openvr.obj : warning LNK4217: locally defined symbol VR_GetVRInitErrorAsEnglishDescription imported in function "protected: __cdecl s3d::OpenVRMode::OpenVRMode(void)" (??0OpenVRMode@s3d@@IEAA@XZ)
gl_openvr.obj : warning LNK4217: locally defined symbol VR_GetGenericInterface imported in function "class vr::IVRCompositor * __cdecl vr::VRCompositor(void)" (?VRCompositor@vr@@YAPEAVIVRCompositor@1@XZ)
gl_openvr.obj : warning LNK4217: locally defined symbol VR_IsInterfaceVersionValid imported in function "protected: __cdecl s3d::OpenVRMode::OpenVRMode(void)" (??0OpenVRMode@s3d@@IEAA@XZ)
gl_openvr.obj : warning LNK4217: locally defined symbol VR_GetInitToken imported in function "class vr::IVRCompositor * __cdecl vr::VRCompositor(void)" (?VRCompositor@vr@@YAPEAVIVRCompositor@1@XZ)
gl_openvr.obj : warning LNK4217: locally defined symbol VR_InitInternal imported in function "protected: __cdecl s3d::OpenVRMode::OpenVRMode(void)" (??0OpenVRMode@s3d@@IEAA@XZ)
gl_openvr.obj : warning LNK4217: locally defined symbol VR_ShutdownInternal imported in function "protected: __cdecl s3d::OpenVRMode::OpenVRMode(void)" (??0OpenVRMode@s3d@@IEAA@XZ)

I think this is happening because openvr_api_public.cpp is compiled inside GZDoom and it defines VR_API_EXPORT at the top, which in turn makes it declare those functions as DLL exports.

3) 64 bit builds are trying to load a 32 bit vrclient.dll (it should load vrclient_x64.dll). It is happening because WIN64 is not defined when openvr_api_public.cpp is being built.

Edit: It might be better to pass /DELAYLOAD:openvr_api.dll to the linker rather than try to bruteforce OpenVR's sourcecode into GZDoom. The delayload feature makes it automatically attempt to load the DLL when you access the functions for the first time. If the DLL cannot be found the function pointers will be null. Basically you can then do this:

Code: Select all

if (VR_IsHmdPresent != nullptr && VR_IsHmdPresent())
{
    // usual init code here
}

Some documentation on /delayload you might find useful: https://msdn.microsoft.com/en-us/library/151kt790.aspx

Edit 2: Reading a bit about /delayload, it unfortunately isn't as straightforward as what I pasted above. It can still be used, though. In any case, I don't think plainly adding the source files of the OpenVR SDK is a particular good idea.

[dpJudas]

Just one last update: It runs great on my computer with the Oculus DK 2 (after I defined WIN64).

Unfortunately I only made it to E1M3 before I started getting physically sick, but that wasn't really GZDoom's fault. All in all I'd say it was pretty fun to see Doom in this way.

[biospud]

Just one last update: It runs great on my computer with the Oculus DK 2 (after I defined WIN64).

Unfortunately I only made it to E1M3 before I started getting physically sick, but that wasn't really GZDoom's fault. All in all I'd say it was pretty fun to see Doom in this way.

Thanks for testing this! That's great news that you got it working. Sorry about the illness problem. I should have warned you (see below).

I'm working on creating a 64-bit build so I can fix the issues you noticed.

To reduce motion sickness in the future:
* Don't play more than ten minutes at a time.
* Set "movebob 0" in the console to prevent up/down motion during locomotion.
* Set "turbo 65" to slow your speed.
* Most importantly, do not turn with the mouse nor the keyboard. Stand and turn, or rotate in your swivel chair. Set the mouse rotate sensitivity to zero. (Eventually we need to implement "comfort" turning controls, which snap the view direction by 45 degrees in a fraction of a second)
* As soon as you feel a bit queasy or sweaty, stop playing. Don't try to "push through".

[biospud]

A couple of comments of what I've run into so far with my DK 2:
...
Edit: It might be better to pass /DELAYLOAD:openvr_api.dll to the linker rather than try to bruteforce OpenVR's sourcecode into GZDoom. The delayload feature makes it automatically attempt to load the DLL when you access the functions for the first time. If the DLL cannot be found the function pointers will be null. Basically you can then do this:

Code: Select all

if (VR_IsHmdPresent != nullptr && VR_IsHmdPresent())
{
    // usual init code here
}

Some documentation on /delayload you might find useful: https://msdn.microsoft.com/en-us/library/151kt790.aspx

Edit 2: Reading a bit about /delayload, it unfortunately isn't as straightforward as what I pasted above. It can still be used, though. In any case, I don't think plainly adding the source files of the OpenVR SDK is a particular good idea.

I think I just fixed those compile warnings and the WIN64 definition. With regard to the /delayload suggestion, I'm concerned that this approach is Windows specific and won't extend to linux and Mac.

[Graf Zahl]

I think I just fixed those compile warnings and the WIN64 definition. With regard to the /delayload suggestion, I'm concerned that this approach is Windows specific and won't extend to linux and Mac.

Correct. That's why the startup for the audio libraries was changed. The main issue I see with OpenVR here is that its makers failed to consider this case and namespaced their entire content for stupid reasons.

[biospud]

I think I just fixed those compile warnings and the WIN64 definition. With regard to the /delayload suggestion, I'm concerned that this approach is Windows specific and won't extend to linux and Mac.

Correct. That's why the startup for the audio libraries was changed. The main issue I see with OpenVR here is that its makers failed to consider this case and namespaced their entire content for stupid reasons.

There might be a available solution here. I could refactor to use the C API for OpenVR instead. https://github.com/ValveSoftware/openvr ... pi.h#L1887
I think using that API might require dynamic loading, to access those seven entry points.

[biospud]

Good news. Refactoring to use the C API for OpenVR has worked well.

I was able to implement dynamic loading of the OpenVR shared library, using cargo-cult programming based on the loading of the OpenAL library. OpenVR mode works when the dll is present, and silently reverts to standard mono when the dll is absent. This is now the default build configuration with the option DYN_OPENVR set to ON. (Though ENABLE_OPENVR still defaults to OFF, so you have to set that first)

I refined the option to statically link OpenVR (STATIC_OPENVR, but only if DYN_OPENVR if OFF). After I switched to the C API and added a compile flag, there are no longer those linker warnings dpjudas noted. This build mode never uses the openvr_api shared library. So this is functional, but arguably weird, build approach.

If you build with both DYN_OPENVR and STATIC_OPENVR set to OFF, the resulting binary directly links to the openvr_api shared library. In this case, openvr mode works if the shared library is present, and gzdoom fails to run if the library is not present. So this build mode is not recommended.

Pull request has been updated.

One more thing that will need to happen to make this new mode more useful: The title and intermission screens are not shown on the headset display. That's no fun. But first we need to nail the build and link infrastructure.

[biospud]

Now that I got the dynamic loading of OpenVR working, I think the next step is to improve the comfort settings. I feel bad that I sickened the one other developer who has a VR headset. To reduce motion sickness in VR I plan to implement

• 1) positional tracking, and
  2) snap turning controls.

I don't love the way I did snap turning in gz3doom, which involved code like this:

Code: Select all

AddCommandString("alias turn45left \"alias turn45_step \\\"wait 5;-left;turnspeeds 640 1280 320 320;alias turn45_step\\\";turn45_step;wait;turnspeeds 2048 2048 2048 2048;+left\"\n");
AddCommandString("alias turn45right \"alias turn45_step \\\"wait 5;-right;turnspeeds 640 1280 320 320;alias turn45_step\\\";turn45_step;wait;turnspeeds 2048 2048 2048 2048;+right\"\n");

I wonder if there is a more elegant approach?