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.