[GZDoom][pull request]Stereoscopic 3D in gzdoom

[Skermoth]

Any progress with this fork?

[Gez]

It's waiting for Graf's review and approval.
https://github.com/coelckers/gzdoom/pull/31

[Graf Zahl]

There's one problem here: I cannot review it at all because I lack the necessary equipment.

[biospud]

There's one problem here: I cannot review it at all because I lack the necessary equipment.

Graf I have extra pairs of red/cyan and green/magenta paper 3D glasses I could mail to you, if that would help. These simple anaglyph glasses are used by the first two new modes exposed by pull request #31. Of course, those glasses won't help if you don't have good binocular depth perception.

To be clear, Oculus Rift and nvidia 3D vision hardware are NOT supported in this pull request, in the interest of keeping the pull request to a managable size.

[Graf Zahl]

Of course, those glasses won't help if you don't have good binocular depth perception.

... and there lies the problem. I'll have a look anyway in the next few days.

[_mental_]

I merged stereoscopic 3D into OS X fork and tested it with red/cyan glasses.
This mode looks OK for me with default settings, at least the same as other red/cyan stuff like pictures and videos.

[Graf Zahl]

I think it's ok, except for 3 things:

1. none of the new files contain a copyright/license notice. At least the .cpp files should.
2. I'm not too fond of using std::vector here, because the codebase intentionally avoids using this in favor of its own TArray.
3. Using of glGet... for the color mask. It doesn't harm performance on my system but I don't really know how other drivers behave. Some may actually stall the render pipeline on a glGet call. I think this should better be cached locally, that's what gl_RenderState is there for.

[biospud]

I think it's ok, except for 3 things...

Good. Thank you for taking the time to review the code. I will make these changes, then report back when I've finished.

[biospud]

I think it's ok, except for 3 things:

1. none of the new files contain a copyright/license notice. At least the .cpp files should.
2. I'm not too fond of using std::vector here, because the codebase intentionally avoids using this in favor of its own TArray.
3. Using of glGet... for the color mask. It doesn't harm performance on my system but I don't really know how other drivers behave. Some may actually stall the render pipeline on a glGet call. I think this should better be cached locally, that's what gl_RenderState is there for.

I have fixed all three of these issues. The first two were trivial, and won't require much review.

In the third case, I refactored gl_RenderState to track glColorMask state, and refactored the stereo 3D code to use that state. The 3D modes are working. But I worry that maybe I did not use gl_RenderState quite the way it was meant to be used, since this is my first serious look at gl_RenderState.

I merged stereoscopic 3D into OS X fork and tested it with red/cyan glasses.
This mode looks OK for me with default settings, at least the same as other red/cyan stuff like pictures and videos.

Thanks _mental_ for testing this. Would you be willing to test whether these latest changes also compile correctly, at least, on OS X?

[Graf Zahl]

Looks ok, although the ApplyColormask call in RenderState:Apply seems unnecessary, since all uses of the color mask need to apply immediately.

[_mental_]

It's impossible to test your changes directly because the old renderer is still used on OS X. After merging and conflicts resolution they seem to work fine.
Also, I can say that this branch compiles without a problem.

[biospud]

... this branch compiles without a problem.

...including the changes to that branch from yesterday?

[biospud]

Looks ok, although the ApplyColormask call in RenderState:Apply seems unnecessary, since all uses of the color mask need to apply immediately.

True, all current code paths apply the color mask immediately. But I felt that ApplyColorMask() is semantically part of Apply(), and during development I thought maybe I might rely on Apply() occuring automatically in some cases, but that did not end up happening. It still seems to me that ApplyColorMask() "belongs" in Apply(), but I agree that it is not currently required for the correct functioning of the program, so perhaps as a minor optimization it should be removed.

[Nash]

This sounds cool! Can you suggest any brand of glasses where I can see this effect work? Is it like one of those glasses they give you at the cinema for 3D movies?

[Gez]

You need red-cyan or magenta-green anaglyph glasses.
https://en.wikipedia.org/wiki/Anaglyph_3D

Cinemas in my experience have moved to polarized 3D glasses or active shutters
https://en.wikipedia.org/wiki/Polarized_3D_system
https://en.wikipedia.org/wiki/Active_shutter_3D_system