FOV: fix rare CalcFov+viewsize glitches #1004
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
3.0 added more math to mostly classic, GLQWCL CalcFov to try and derive FOV from a reference 4:3 ratio.
This accomodated everything above 4:3, which was becoming the norm at the time.
3.0.1 also added a letterbox option which somewhat "maintains" FOV for
viewsize < 100
- for ratios 4:3+.Viewport size is not always strictly proportional to the vid size, due to the varying margins that are added - i.e, the aspect ratios do not always match.
However, classic GLQWCL CalcFov always worked on viewport size, whether it was the screen size or not - so there was never a problem.
3.0.1+ passes the viewport size and the vid size and takes both into account for 4:3+, but still only works from vid size under 4:3.
Result: in some rare combinations at those narrow ratios, the viewport and screen ratios will go out of whack and Calcfov gives a horizontal fov too wide for the viewport (glitches!)
This patch adds the same 3.0.1
height/width
vsview_height/width
viewsize fix to the existing "anything under 4:3" clause.Everything else remains unchanged.