Stereo 3D stuff

[Rachael]

I actually worked with the aspect ratio code back before ZDoom went Git. I think my old code submission is still buried in the ZDoom forum somewhere from back when Graf and Randi were still accepting code patches in the form of Diffs.

At any rate, what I would do at this point is remove all the CheckRatio code and do a simple W/H division - and then add in the 320x200 and 640x400 hacks - and then add in the v_aspect override - and call it done.

The code should be sensitive to whether it is called by the hardware/window setup code, or the Camtex code (as far as v_aspect and legacy resolution checks go) - the best way to do this would obviously be to pass a new parameter to CheckRatio. Then you have to search for every single instance of CheckRatio and add in the parameter (unless you overload the function and set a default, I guess, which may seem a bit hacky but would require less code change).

This would probably fix a whole slew of bugs in ZDoom. And yet, it may cause a bunch of new ones too, I guess we'd just have to try it and see what happens.

As far as the menu code concerning display ratios - obviously the aspect ratio thing will need to be re-implemented in some way but I think it can focus on doing "closest" ratios rather than exact ones. In fact, I think the menu is the main reason the code has been left the way it is right now.

[Graf Zahl]

Indeed.

About the aspect ratio, just refer to this comment:

// Make this ratio known and map to itself
// In the future, should another aspect ratio get added, you'd want
// to also make any wider ratio remap to this one if suitable.

Of course the command needs to be deprecated and replaced by something sane. It's already broken to begin with. The 21:9 ratio is never checled and not even mapped to one of the constants and would cause an array overflow because its index 6 is beyond the map array!
I see no need to waste any thought on this utterly broken function. Map it as good as possible and forget about it.

By default it should only know 5:4, 4:3, 16:10 and 16:9 and map anything wider to the respective one. Only if "17:10" is found in the SBARINFO, this should also be added.

And if someone wants something better, let them think about a new implementation.

[dpJudas]

Okay, I added a PR on the zdoom forum that switches the main aspect ratio handling from that CheckRatio integer to an aspect ratio float. I couldn't fully remove the CheckRatio function as there's a few limited places that still need it (video menu code mostly), but generally the software renderer no longer uses it. I think this might even make the camera textures use the correct aspect ratio now - at least if I understand the code correctly they will.

I didn't touch the cvars and such because I don't really want to deal with the nightmare it would involve with regard to video mode handling. As for that command thing, I updated the code so it at least didn't do a buffer overrun. There's so many hacks in this part of the code base that I'm not volunteering to clean them all up, but at least this patch should allow any new code to see aspect as a ratio and not some hacky enum.

[Graf Zahl]

Ok, so far. But this will need a corresponsing PR for GZDoom or I'll block my merging abilities.

[dpJudas]

You mean you're getting a merge conflict? How is that best solved? First time I'm using git in such a distributed way.

[Graf Zahl]

No, not a merge conflict. The stuff you changed gets used in some places of the hardware renderer as well and that also needs changing.

[dpJudas]

Ah, right. Was planning on a PR anyway to remove the black bars from gzdoom. What is the best way to do it? That I merge zdoom into a local gzdoom branch and then create a PR for that?

[Graf Zahl]

Merge your PR as it is into GZDoom and work from there. That will avoid commit duplication.

[dpJudas]

Pull request, gzdoom version: https://github.com/coelckers/gzdoom/pull/98

No more black bars in windowed mode.

[biospud]

I have begun sketching out a feature branch for an OpenVR HMD 3D Mode. As expected, I have identified some unexpected issues, and I'd appreciate some advice on how to handle these issues. My new branch is located here: https://github.com/cmbruns/gz3doom/tree/gzdoom_openvr

I'm adjusting the player view direction using the HMD orientation, and it's working correctly. But I'm concerned that I'm not using the gzdoom API in the best way.
The task flow is as follows:

• a) read the virtual reality headset orientation as a set of yaw, pitch, and roll angles, in units of radians
  b) update the playsim to adjust to this new player camera view orientation, as quickly as possible, using methods G_AddViewAngle(...) and G_AddViewPitch(...)
  c) update the rendered view angles immediately, by directly modifying GLRenderer->mAngles.Pitch/Roll/Yaw, to avoid the latency of waiting for the playsim to eventually update the view direction on the next tic.

From https://github.com/cmbruns/gz3doom/blob ... r.cpp#L363

Code: Select all

	G_AddViewAngle((int)(-32768.0*dYaw / 3.14159)); // determined empirically
	// Pitch
	double hmdPitchInDoom = -atan(tan(hmdpitch) / glset.pixelstretch);
	double viewPitchInDoom = GLRenderer->mAngles.Pitch.Radians();
	double dPitch = hmdPitchInDoom - viewPitchInDoom;
	G_AddViewPitch((int)(-32768.0*dPitch / 3.14159));
	// Roll can be local, because it doesn't affect gameplay.
	GLRenderer->mAngles.Roll = -hmdroll * 180.0 / 3.14159;
	// Late-schedule update to renderer angles directly, too
	bool doLateScheduledRotationTracking = true;
	if (doLateScheduledRotationTracking) {
		GLRenderer->mAngles.Pitch = RAD2DEG(-hmdpitch);
		GLRenderer->mAngles.Yaw += RAD2DEG(dYaw); // "plus" is the correct direction
       }

What I don't like is those constants "-32768.0" and "3.14159" I hacked in there when updating the playsim. There must be a more correct way do accomplish this, yes?

[Graf Zahl]

Those two functions take a binary angle in the range [0..65535] as their parameter and your multiplication reflects exactly that.

[Gez]

Isn't there a PI constant defined? You could use that instead of 3.14159.

[biospud]

This is tricky. The zdoom part that issues 2D drawing commands relies on SCREENWIDTH and SCREENHEIGHT. They always stay the same unless the resolution is changed and I have no idea how the code will react to you changing them on the fly.

If you want to experiment with it, change the OpenGLFrameBuffer Width and Height members to what you set the mScreenViewport size to. Something ala this in AdjustViewports:

GLRenderer->framebuffer->SetSize(GLRenderer->mScreenViewport.width, GLRenderer->mScreenViewport.height);

and then add this to the OpenGLFrameBuffer class in gl_framebuffer.h:

void SetSize(int w, int h) { Width = w; Height = h; } // What could possibly go wrong..

The good news is I made some more progress on the full/wide side-by-side 3D mode. I added a new virtual function Stereo3DMode->AdjustPlayerSprites(), which is called within the FGLRenderer::DrawPlayerSprites(...) method. By fiddling the projection matrix in there, I was able to render a nice chunky full width weapon in the final view.

But the bad news is that getting the status bar to look perfect still eludes me. I see that, in general, your aspect ratio update causes the status bar to look great no matter what the window shape is. But the status bar still looks the same bad way in my full side-by-side mode. I tried the scary hack to the framebuffer size that you suggested, and the result was, as you might predict, just a horribly garbled display. I'm tempted to render the 2D stuff to an intermediate texture, just like everyone keeps warning me not to do...

I'm revisiting this now because I'm also closing in on the rendering of weapon and 2D elements into the OpenVR HMD mode view.

[dpJudas]

Sorry, I should probably have told you about the aspect ratio changes. Basically what I did there was to add that SetSize function myself: https://github.com/coelckers/gzdoom/blo ... r.cpp#L187 (the Resize function is the SetSize function). In detail, this code does the following:

1. Changes the DFramebuffer size (SCREENWIDTH/HEIGHT, via Resize).
2. Tells various things in zdoom that the size changed (via V_OutputResized). This includes notifying the statusbar and the HUD.
3. Updates gzdoom's fixed vertices (mVBO->OutputResized).

In the link I provided I'm doing this based on the client area of the window. Theoretically, you should be able to do the same using the eye dimensions. The main thing to watch out for should be where you're doing it - I've only confirmed it is safe to do it at this exact location: the end of a frame. Also make sure you only size things once (i.e. check if Width/Height is already the right value) or you may risk getting performance problems due to memory reallocations.

One last thing I wanted to mention. You said earlier that the texture sent over the VR SDK had to be the photosomething light values. That means a linear buffer, but Doom's textures and gzdooms rendering is all sRGB as far as I know. The gamma controls thus specify additional gamma on top of sRGB, which means that you'll have to apply inverse 2.2 gamma when presenting the eye texture.

[biospud]

Sorry, I should probably have told you about the aspect ratio changes. Basically what I did there was to add that SetSize function myself: https://github.com/coelckers/gzdoom/blo ... r.cpp#L187 (the Resize function is the SetSize function). In detail, this code does the following:

1. Changes the DFramebuffer size (SCREENWIDTH/HEIGHT, via Resize).
2. Tells various things in zdoom that the size changed (via V_OutputResized). This includes notifying the statusbar and the HUD.
3. Updates gzdoom's fixed vertices (mVBO->OutputResized).

In the link I provided I'm doing this based on the client area of the window. Theoretically, you should be able to do the same using the eye dimensions. The main thing to watch out for should be where you're doing it - I've only confirmed it is safe to do it at this exact location: the end of a frame. Also make sure you only size things once (i.e. check if Width/Height is already the right value) or you may risk getting performance problems due to memory reallocations.

I played with Resize() but I'm not getting any traction on this problem. On the other hand, this problem with the narrow taskbar and menus is a minor cosmetic issue. Now that the 3D scene and the weapon look good in wide-side-by-side mode, I'm about ready to put a ribbon on the side-by-side modes and submit a pull request for this pair of modes, leaving the minor cosmetic issue until an actual player complains about it. I don't forsee this particular problem arising in any of the other 3D modes I have in mind for the future.

One last thing I wanted to mention. You said earlier that the texture sent over the VR SDK had to be the photosomething light values. That means a linear buffer, but Doom's textures and gzdooms rendering is all sRGB as far as I know. The gamma controls thus specify additional gamma on top of sRGB, which means that you'll have to apply inverse 2.2 gamma when presenting the eye texture.

Thanks; that's good to know. I now see that OpenVR has an API for specifying whether the texture is sRGB or linear. Perhaps I was remembering an earlier version, or getting confused with the Oculus Rift SDK.