Hor + vert + FOV, or adaptive field of view

Hello to all!

Today, when I tested my Quake port on a tablet, I noticed that in portrait orientation it was not very pleasant to watch demos because of the narrow field of view.
')
So I decided to come up with a very simple, but looking good (in my opinion) both in portrait and landscape orientation, a way to fix it.

And I called it Hor + vert + FOV.

What was the problem

Since my desktop has a widescreen monitor, I initially decided to use Hor + FOV instead of Vert- , despite the fact that Quake uses Vert- because it seemed that I was looking at the world through a magnifying glass.

Quake with Vert-FOV on a widescreen monitor.


Hor + worked fine until I had a tablet. Everything looked great in landscape orientation, but in portrait it was no longer an approximation, but simply cramped.

Quake with Hor + FOV in portrait orientation.

Decision

And the solution was the simplest.

Instead of using any of the two types of FOV, I decided to combine these two types.

Since Quake was designed for monitors with a 4: 3 aspect ratio, I began to use this ratio as a base to switch between the two modes.

If the aspect ratio is greater than 4: 3 (wide screen) - Hor + is used.
If the aspect ratio is less than or equal to 4: 3 (the screen is narrow or close to square), Vert- is used.

But since the task was to adjust the FOV to narrow screens, this means that the narrower the screen, the more it should be visible. Therefore, for us Vert- actually turned into Vert +.

The implementation of this method takes a single check on the condition.

I will give all the code to implement this method from WebQuake.

if ((vrect.width * 0.75) <= vrect.height) { R.refdef.fov_x = SCR.fov.value; R.refdef.fov_y = Math.atan(vrect.height / (vrect.width / Math.tan(SCR.fov.value * Math.PI / 360.0))) * 360.0 / Math.PI; } else { R.refdef.fov_x = Math.atan(vrect.width / (vrect.height / Math.tan(SCR.fov.value * 0.82 * Math.PI / 360.0))) * 360.0 / Math.PI; R.refdef.fov_y = SCR.fov.value * 0.82; } 

Explanation:

• SCR.fov is a console variable denoting horizontal FOV with a 4: 3 aspect ratio (ideal aspect ratio for Quake).
• If the aspect ratio is less than or equal to 4: 3, use Vert +. If not, use Vert-.
• In the case of Vert +, we take the horizontal FOV from the console variable, and the vertical one is calculated using a well-known algorithm.
• In the case of Hor +, we take the vertical FOV from the console variable, and the horizontal FOV is calculated.
• 0.82 - the ratio of vertical FOV to horizontal at a ratio of 4: 3. To get the vertical FOV from a console variable, multiply the value of the variable by this constant.

What came out of it:
Landscape orientation - Hor + is used.

Portrait orientation - Vert + is used.


As you can see, there is no approximation, and the review is good.

But there is one small problem.

Error and its solution

As can be seen from the previous screenshot, the weapon model is too far from the player.

This problem is present only when Vert + is used - in Hor + this effect is not observed.

Since the model of weapons in Quake is drawn separately from the other models, nothing prevents us from switching from Vert + to Hor + before drawing the weapon, and after that - back.

The world is drawn in Vert +, and the weapon in Hor +.


Bug fixed.

Outcome and conclusion

As a result, it turned out like in the first screenshot in this post.



Maybe this technique is not new (although I have not yet met a single game using something like this), but it is of great importance. The use of adaptive FOV is very important in the era of web applications and mobile devices, since the browser window can have any rectangular shape, and smartphones and tablets work in both horizontal and vertical orientation.

Thanks for reading.