Monday, May 9, 2011

FOV Fixing Up

Currently working on fixing up DirectQ's FOV support for widescreen resolutions; the old code I had was fairly cruddy and hacked around with over time, so it's good to go back and clean things out.

At this point I think it's reasonable to throw a question out in the open: how do people want FOV to work? There are a number of options and things to consider here:

  • A cvar to switch DirectQ's FOV handling back to the way GLQuake did it seems reasonable and sensible.  This can also serve as a last-resort panic button: if things get terminally screwed up for you then at least it'll get you back to something that works.  It may not be great, but at least it will work.  This is currently present (and has been for the past coupla years) and is called "fov_compatible".
  • In relation to this, what should the default handling be?  This is one clear case where I think "the way GLQuake did it" is not a good default; the new method should be the default.  Everyone agree?
  • Correcting FOV for widscreen aspect ratios requires a baseline aspect ratio to derive the values from.  Should this be software Quake's 320x(200-48) or GLQuake's 640x(480-48)?  (The -48 is for the default status bar size).  I favour GLQuake as the baseline here; it might not be the absolutely "correct" baseline derived from the original Quake engine, but people are so used to it that going back to the original just looks weird.
  • Handling of the gun.  Previously I've (except when I've done it wrong) drawn the gun as if FOV was 90 when FOV is >= 90, but drawn it at the reduced FOV otherwise (with the new handling) or just drawn it the way GLQuake did (with the old handling).  Is there any requirement at all to draw it the way GLQuake did for FOV > 90?  I'm thinking this is another one of those cases where "the way GLQuake did it" is actually crap and - this time - should not only not be a default, but should not even happen at all.
All opinions welcome.

3 comments:

Ron said...

This is one clear case where I think "the way GLQuake did it" is not a good default; the new method should be the default. Everyone agree?

Yep. Absolutely.

...baseline aspect ratio to derive the values from. Should this be software Quake's 320x(200-48) or GLQuake's 640x(480-48).

No real preference. So long as I can dial in on the field of view that feels right to me, I'm happy.

Is there any requirement at all to draw it the way GLQuake did for FOV > 90?

I can't think of any legitimate reason for the old method to be an option.

=peg= said...

[$0,02]

"In relation to this, what should the default handling be? This is one clear case where I think "the way GLQuake did it" is not a good default; the new method should be the default. Everyone agree?"

Agreed..

"Correcting FOV for widscreen aspect ratios requires a baseline aspect ratio to derive the values from. Should this be software Quake's 320x(200-48) or GLQuake's 640x(480-48)? (The -48 is for the default status bar size). I favour GLQuake as the baseline here; it might not be the absolutely "correct" baseline derived from the original Quake engine, but people are so used to it that going back to the original just looks weird."

GLQuake's 640x(480-48) please..

"Is there any requirement at all to draw it the way GLQuake did for FOV > 90? I'm thinking this is another one of those cases where "the way GLQuake did it" is actually crap and - this time - should not only not be a default, but should not even happen at all."

Agreed..

[/$0,02]

Anonymous said...

Make the default be whatever the proper (good) way should be.

When I do a fresh install, it should work out of the box as best and updated as possible.

I shouldn't have to set any cvars in a proper modern engine to take advantage of any modern (better/proper) designs/features.

- Magnus