Official Oculus Rift GZ3Doom thread

[Naitguolf]

Thanks for the update. For whatever reason, i feel much more confortable to my eye playing with 1280x800 than 1680x1050 or higher. More pleasant and the world seems more bigger, real and "close". Try it maybe you can feel the same

But the crash from ACM still happens

[biospud]

But the crash from ACM still happens

Thanks for testing! Your feedback has been magnificent. I haven't yet investigated the resolution issue, but I did finally fix the ACM crash.

Announcing release 1.8.2_f of GZ3Doom:
* Implement Nvidia 3D Vision mode (vr_mode 7, Thanks Torr Samaho!)
* Avoid crash with Alien Colonial Marines wad
* Fix compile problem when Oculus SDK not available

http://rotatingpenguin.com/gz3doom/

[Naitguolf]

Thanks for testing! Your feedback has been magnificent. I haven't yet investigated the resolution issue, but I did finally fix the ACM crash.

You are welcome! Thanks to your for your work!!! I will try it now

Edit: It works perfectly!!! Thanks!! Now, if only the weapon hud can be changed by some variable. Normal weapons doom works great, but for example, weapons from ACM are too hight

Edit 2: I've tried Calls of Dooty 3, and the camera turns crazy once you go to the firing point. Also happened with the shothung, and the place with the statick machine gun. Seems static camera do some problems.

[billhelm]

Fantastic work. I got to try this last night and it was great. What a wonderful way to experience Doom.

Regarding the decoupling of aiming and looking... The reason that it is so important for immersion is that some people use a YEI 3-Space Sensor attached to a Top Shot Elite controller. Once you have this, you can emulate a mouse using FreePIE. There will be some drift if GZ3Doom can't be made to use raw input. This is due to the default Windows7/8 acceleration settings. The MarkC Mouse Acceleration Fix is a workaround for this that works reasonably well, but it adds another step. Finally, there must be a mechanism in place to re-center easily (changing levels typically requires a re-center). This can be done easily by creating a script that changes to a view mode that couples (centers) the view/aim and then changes back to decoupled mode. I've used this method in standard Half-Life 2 with VR mode enabled, and in Quake2VR. It's fantastic, and I'd love to see it here.

For those not using this method, decoupling still adds quite a bit to the experience, but you'd want to decouple the aim and view loosely, not completely (see TF2).

[ibm5155]

sorry for this little bumb but, how does it works with 3D models like monsters and guns?
And this make me want to make another scary game for doom

[Naitguolf]

Hope biospud update, since some issues when camera shakes, for example on Call of Dooty 3...

I was playing today stand up, instead seated. Whoa, much more enjoyable

[biospud]

Hope biospud update, since some issues when camera shakes, for example on Call of Dooty 3...

I was playing today stand up, instead seated. Whoa, much more enjoyable

Yes, standing up is my preferred way to play, until I get tangled in the cables. I'm concerned the second generation Rift DK2 head tracking might not work well when standing and turning. I guess I'll find out when my DK2 arrives in August.

I haven't yet investigated those graphics glitches on custom doom levels. Maybe soon.

[Nash]

Hi biospud, question about camera roll (tilt) - are you manipulating the camera directly based on the input of the player's head tilt, or are you actually making use of the unused roll actor variable?

In my source port, I am actually doing the latter - the OpenGL camera reads the roll actor variable to apply camera tilt, and I have custom A_SetRoll and Set/GetActorRoll ACS commands to make those useful...

My curiosity is how would the two play with each other... would the head input ADD to the camera tilt, or would they overwrite each other?

[biospud]

Hi biospud, question about camera roll (tilt) - are you manipulating the camera directly based on the input of the player's head tilt, or are you actually making use of the unused roll actor variable?

In my source port, I am actually doing the latter - the OpenGL camera reads the roll actor variable to apply camera tilt, and I have custom A_SetRoll and Set/GetActorRoll ACS commands to make those useful...

My curiosity is how would the two play with each other... would the head input ADD to the camera tilt, or would they overwrite each other?

I'm unsure what a "roll actor variable" is. So I cannot directly answer your question. I set the Rift roll value directly into the gzdoom member FGLRenderer.mAngles.Roll. I directly overwrite the Roll value, under the assumption that Roll has no gameplay effect. I set the Pitch and Yaw values using the methods G_AddViewAngle() and G_AddViewPitch(). I set the absolute pitch angle from the Rift, but I make an effort to combine the yaw angle with other contributions from the game controller or wherever. I hope that answers your question.

[Nash]

I see. Yes, that's all I needed to know. :) I remember reading a design doc from Valve (if I recall correctly) and how they say that to reduce motion sickness effects, one thing you NEVER do in a Rift-supported game is force any view changes to the player and always leave the head tracking to the player... so if I ever merge your Rift code into my port in future, I'll definitely have to address my forced camera movement. :D

(This may be related to the issues Naitguolf was having with Call of Dooty... I recall that mod having a lot of forced camera movements)

[DoomRater]

What if your view changes simply caused the HUD to offset instead? I know we don't have force feedback motors to induce roll changes in the headset itself... maybe this would be a "good enough" solution?

[biospud]

I see. Yes, that's all I needed to know. I remember reading a design doc from Valve (if I recall correctly) and how they say that to reduce motion sickness effects, one thing you NEVER do in a Rift-supported game is force any view changes to the player and always leave the head tracking to the player... so if I ever merge your Rift code into my port in future, I'll definitely have to address my forced camera movement.

Yes, I agree with Valve that with the Oculus Rift it is important to avoid forced view movement. That's why I enforce absolute pitch and roll from the head tracking in GZ3Doom. In fact, it might be nice to enforce yaw (left-right-turning) too, but until everyone can use a wireless, standing game experience in which you turn by, you know, turning, we must permit some yaw control from the game controller. But with the Rift on, I prefer to deemphasize controller yaw, to the point of avoiding using a mouse.

[Nash]

Slightly offtopic but: Imagine playing GZDoom with a Rift and one of these treadmill things!

[biospud]

Announcing version 1.8.6_b of GZ3Doom for the Oculus Rift

http://rotatingpenguin.com/gz3doom/

The most significant improvement is the correction of many hall-of-mirrors type graphics defects. If you saw this sort of thing before on certain levels, please try again with this latest version.

Changes in this release:
* Correct hall-of-mirrors defect (Thanks Trisk!)
* Merge changes from gzdoom 1.8.6-ish

[DoomRater]

Slightly offtopic but: Imagine playing GZDoom with a Rift and one of these treadmill things!

[video]

One day I will play Minecraft this way.