search

SpiritQuaddicted / reQuiem

reQuiem is a custom OpenGL Quake engine for Windows and Linux. It's designed for maximum compatibility with all things Quake - past, present and future. It's fast, reliable, and easy to configure. In short: it fixes what was broken, improves what needed improving, and leaves the rest alone. It was developed by jdhack.
GNU General Public License v2.0
17 stars 2 forks source link

Handle FOV automatically for widescreen #15

Closed SpiritQuaddicted closed 10 years ago

SpiritQuaddicted commented 10 years ago

Some users like the engine to handle the FOV for them, so that the resolution defines the "internal" FOV it uses. It makes eg "fov 90" look correctly with more visible stuff on the sides instead of horizontally scaling the image. At least Darkplaces does this.

neogeographica commented 10 years ago

DarkPlaces, Fodquake, QuakeSpasm, Fitzquake Mark V, and Engoo are all in the auto-FOV camp now.

In QuakeSpasm it looks like this behavior is localized to SCR_CalcRefdef calling (new function) AdaptFovx for horizontal FOV instead of just using scr_fov.value.

The latest Fitz Mark V source looks odd... I should check the current build to see if its auto-FOV still works. It does show though that math-wise you can arrange this part of the code to just use CalcFovy again instead of defining a new function, which is tidy.

neogeographica commented 10 years ago

I've got something on the fov_adapt branch that looks good at first glance. I'ma test it more before actually doing a pull request, but feel free to checkout fov_adapt and try it yourself if you like.

As in QuakeSpasm, the auto-FOV behavior is controlled by the fov_adapt cvar, which defaults to 1.

SpiritQuaddicted commented 10 years ago

Works like a charm for me. Thanks!

neogeographica commented 10 years ago

Going to reopen this for a bit more consideration. I noticed that the upcoming QuakeSpasm release makes this change: http://sourceforge.net/p/quakespasm/code/872/

And it's related to this bug report from MH: http://forums.inside3d.com/viewtopic.php?f=3&t=4239&p=50296#p50296

The fundamental thing is to take into account potential difference between the screen dimensions and the viewport dimensions (which may be vertically shrunk because of statusbar shenanigans). I need to think more about this, but I'm pretty sure the current code needs to change one way or another, because I'm using viewport dimensions for the calculations but also using a 4:3 screen aspect ratio as the baseline.

Edit: The QuakeSpasm solution looks (unsurprisingly) like the right thing. I.e., first calculate a horizontal FOV based on screen dimensions (vid), not viewport dimensions (r_refdef.vrect). Then use that FOV for the viewport's horizontal FOV, even if viewport is not as wide as screen -- same as original Quake does (I think; will verify). Finally, calculate the viewport's vertical FOV using the horizontal FOV and the viewport dimensions.