QUAKE [DK2 Support]

[mindabuse]

I've just pushed up changes to my fork of QuakeSpasm-Rift.

v1.91: release post details
v1.90: release post details
v1.85: release post details
UPDATE: See this post on how to configure the Rift DK2 to work properly.

Look for the latest releases here:

https://github.com/jeremiah-sypult/Quakespasm-Rift/releases

This fork is using SDK v0.4.1 with a modified distortion shader to eliminate black smearing (when overdrive is enabled). Both DK1 and DK2 HMDs render with orientation and position tracking.

With your HMD configured in extended mode and as the primary display, fire up the game with:

quakespasm -vr

Configure settings in the Options > VR/HMD Settings menu, or check out the README for all of the cvars, as all the various HMD & Distortion flags can be toggled (multisampling, low persistence, dynamic prediction, vsync, timewarp, etc.).

https://github.com/jeremiah-sypult/Quakespasm-Rift/blob/master/README.md

You must provide the pak files. The free shareware (pak0.pak) as well as registered (pak0.pak + pak1.pak) files must go in a directory called 'id1' inside the folder that QuakeSpasm.app|exe resides in.

./Quake/QuakeSpasm.app|exe
./Quake/id1/pak0.pak

OS X: Since the DK2 appears as 1080x1920, you'll want to rotate it 90 degrees in System Preferences.app. I would suggest making the rift your primary display by dragging the white menu bar in the Arrangement settings to the rift. Then, cleverly find a way to launch the app full screen at 1920 x 1080 with the launcher. It's not the easiest thing to do, but it's not impossible....

Windows: The HMD must be in extended mode and configured as the primary display at the time of launching.

UPDATE: The game originally defaulted to a capped frame rate of 72 fps. To change it, you'll use:

host_maxfps xxx

where 'xxx' is a higher value (as high as you want, if you're interested in keeping vr_vsync disabled). The update is now 240.

There is also joystick/gamepad support. I've tested it with both PS3 and Xbox 360 controllers. The default 'joy_sensitivity' for aiming may be low, so make sure to experiment with different values. I've also added a vr_aimmode 6 which decouples the pitching of the weapon/view. Lastly, vr_deadzone set to 180 will entirely decouple the view + aiming (requested here), but I have no input controllers to test that kind of rig out.

Sounded like a few people were looking forward to this. I apologize I'm only been able to provide OS X binaries thus far, but I hope that folks on the other platforms might be able to help. Please fork on Github and feel free to hit me up with pull requests if any changes are needed.

[mouja]

I don't know what I'm doing wrong.
Service stopped, Extended mode, rift as primary monitor. When I launch the game, by default I already have the good 3D in the rift, but no head tracking. and when I set "vr_enabled 1", I get head-tracking, but also another side by side view inside the rift.

[knapman]

Just giving this a try myself, seems to be working quite nicely after doing a few console commands, mainly just missing the positional tracking at the moment

something that stands out is the double barrel shotgun seems to be tiny compared to the other guns, is there any way to scale that up?

having trouble getting music working, tried putting the tracks into id1\music and the console still says it can't find the cdrips - filenames are different for this version of quake track02 instead of track002

[sth]

I don't know if there is a way to do it in SDL1, but to get fullscreen on the Rift with SDL2, even if it is not the primary screen, just move the window to the coordinates reported by the Rift before setting fullscreen mode:

    ovrHmd_GetDesc(hmd, &hmdDesc);
    bounds.x = hmdDesc.WindowsPos.x;
    bounds.y = hmdDesc.WindowsPos.y;
    bounds.w = hmdDesc.Resolution.w;
    bounds.h = hmdDesc.Resolution.h;

    SDL_SetWindowPosition(window, bounds.x, bounds.y);
    SDL_SetWindowSize(window, bounds.w, bounds.h);
    SDL_SetWindowFullscreen(window, SDL_WINDOW_FULLSCREEN);

Maybe it works on SDL 1 as well if you specify the coordinates on SDL_SetVideoMode(). (not possible)

The window position for SDL1 can be influenced by the SDL_VIDEO_WINDOW_POS environment variable.

"http wrote:
If you want to control the position on the screen when creating a windowed surface, you may do so by setting the environment variables SDL_VIDEO_CENTERED=center or SDL_VIDEO_WINDOW_POS=x,y. You can also set them via SDL_putenv.

PS: ovrHmd were ovrHmdDesc have merged in 0.4.0, so ovrHmd_GetDesc() is unnecessary there.


[edit]: Doesn't work 😞 It always goes fullscreen on the primary monitor. Damn...
Let's hope that the next SDK release will re-introduce cross-platform support and will fix direct mode for OpenGL apps.

[bhenderson]

Good work. It worked for me after some fiddling.

By default, I don't think Quake displays out to 1920x1080.

I made a batch file that runs .\quakespasm -width 1920 -height 1080 . Make sure you have the Rift set as your primary display and the service disabled. Happy hunting!

You also want to run the console command vr_enabled 1, of course, to enable it all.

[mindabuse]

Been hacking on things some more tonight. I'm having a hard time pulling myself away. It's 3am.

So I have a small joystick/gamepad fix that allows some console commands to assign the player move/look axis of analog thumb-sticks. This gets the Xbox360 controller working mostly on Windows. No progress on the Xbox360 triggers, though (they are analog in Windows and digital in OS X with an open source driver).

What's been keeping me up is that I have a decent pass at full DK2 support with functioning positional tracking. I just need to do some clean-up and then I can post the code + Windows binary. I'm still blown away at what a difference it makes.

At first I had an issue with looking around corners and having the opposing wall culled from drawing, but found a fix by updating the stereo view before that other rendering voodoo happens.

The last bit I was mucking with was two different ways of positioning the camera. The first is simply by moving the camera, which is separate from the actual player entity + view model. This feels kind of neat and fluid in that you can move around your gun in 3D space — and when you move far enough away its weird to have it floating there where your "body" is supposed to be (and technically is from a gameplay standpoint)... The other method is by moving the view entity which tethers your gun to your view when you move. This feels more natural that your gun follows you around. However, there is definitely some strange behavior where it doesn't feel as fluid and unrestricted. I made it a cvar to toggle between the two and will do some more digging tomorrow.

[sth]

"mindabuse" wrote:
What's been keeping me up is that I have a decent pass at full DK2 support with functioning positional tracking. I just need to do some clean-up and then I can post the code + Windows binary. I'm still blown away at what a difference it makes.

At first I had an issue with looking around corners and having the opposing wall culled from drawing, but found a fix by updating the stereo view before that other rendering voodoo happens.

The last bit I was mucking with was two different ways of positioning the camera. The first is simply by moving the camera, which is separate from the actual player entity + view model. This feels kind of neat and fluid in that you can move around your gun in 3D space — and when you move far enough away its weird to have it floating there where your "body" is supposed to be (and technically is from a gameplay standpoint)... The other method is by moving the view entity which tethers your gun to your view when you move. This feels more natural that your gun follows you around. However, there is definitely some strange behavior where it doesn't feel as fluid and unrestricted. I made it a cvar to toggle between the two and will do some more digging tomorrow.

Great stuff. Keep up the good work!

"mindabuse" wrote:
No progress on the Xbox360 triggers, though (they are analog in Windows and digital in OS X with an open source driver).

What driver are you using?
http://tattiebogle.net/index.php/ProjectRoot/Xbox360Controller/OsxDriver should have analog triggers.

[bhenderson]

"mindabuse" wrote:

The last bit I was mucking with was two different ways of positioning the camera. The first is simply by moving the camera, which is separate from the actual player entity + view model. This feels kind of neat and fluid in that you can move around your gun in 3D space — and when you move far enough away its weird to have it floating there where your "body" is supposed to be (and technically is from a gameplay standpoint)... The other method is by moving the view entity which tethers your gun to your view when you move. This feels more natural that your gun follows you around. However, there is definitely some strange behavior where it doesn't feel as fluid and unrestricted. I made it a cvar to toggle between the two and will do some more digging tomorrow.

Ha, I didn't even notice that it didn't have positional tracking last night. I was having too much fun. Yeah, that is good to have a choice between the two types of positional tracking.

[knapman]

just as a general tip for people just getting started with this, to get things setup a bit easier you can create a text file in the id1 folder, name it autoexec.cfg and enter any console commands you want and these will run automatically at launch

for the rift its nice to at least set these commands

vr_enabled 1
map start

by default the game launches directly to the menu and the menu is not in vr mode, these commands will launch the game directly to a rift friendly state

i've added these settings to mine, they seem like common commands that are good to experiment with, tweak to what works best for you, if anyone else has found other commands that give nice results it would be good to know

vr_enabled 1
+mlook
vr_ipd 66.5
vr_lowpesistence 1
host_maxfps 75
vr_aimmode 3
vr_crosshair_alpha 0.4
map start

[mindabuse]

I just uploaded the latest v1.85, and the Windows build supports SDK v0.4 position tracking!

https://github.com/jeremiah-sypult/Quakespasm-Rift/releases

UPDATE: To dismiss the HEALTH & SAFETY warning, wait a few seconds and 'tap' your HMD to give it a slight shake. It should dismiss it. I need to dig in to how to disable it properly...

There is a new VR/HMD menu under the options menu to configure most of the console variables/commands.

Notes about positional tracking: there is a console command 'vr_reset' that will reset the "home" position based on your current physical location. The way this is done is different than the Oculus demo for now, but I may make it act that way in the future. Just getting my feet wet with developing this, but wanted to get it out there....

You can bind the vr_reset command to the keyboard or joystick input with:

bind xxx vr_reset

...replacing 'xxx' with your key or JOYx/AUXx input of choice (joysticks with unmapped buttons will print out while playing.

On the topic of joysticks, I've added some joy_axis* commands for reassigning move x/y and look x/y. joy_axis_debug 1 will show the axis numbers printed to console, with respect to the deadzone. Look at the values for a clue as to which axis is dominant in order to identify the axis "index number". This is absolutely developer-centric support, as adding customizable axis support to QUAKE could be a lot of work, and I'm much faster working with getting support tossed in with Cvars...

joy_axismove_x #
joy_axismove_y #
joy_axislook_x #
joy_axislook_y #
joy_axis_debug 0/1

Also, make sure you enable mouse look in the options menu as it's tied to the joystick look support. Hacks. :d

I wanted to push this out ASAP and have to take off for a bit. I'll check in when I get back and see how things are going for anyone who can try things out.

Sincere thanks for the kind works of encouragement and for helping each other out with issues!

[knapman]

just trying the update, seems to be working really nicely, interesting that host_maxfps set to 250 reduces judder, much better than when i had it set to 75

now with the new menu i've dropped most of the autoexec commands, just using

vr_enabled 1
map start

as the vr option doesn't seem to save between launches and initial menu is stuck in 2d, so these commands are still useful for now, looking forward to future updates

edit - im finding that im using the vr_reset option as a make shift way of offsetting the gun models off to the side, i've never been bothered about having the guns in the middle vs modern style fps gun positions, but in vr its a different experience, I just have the feeling of having a gun stuck to my nose, so its comfortable being able to push it to the side, could there be an option for that?