Blood: Dynamically scale sky parallax drawing for FOV

[tmyqlfpir]

This PR fixes issue #383 by dynamically scaling the FOV to ensure that the skybox drawing does not overflow.

An example with an FOV of 120 and set to center horizon line.

Before: After:

Fixes #383

[Hendricks266]

I like this idea. I need to mentally run "red team" on it before merging.

Could you post the derivations for the constants you used?

[tmyqlfpir]

The ideal sky yscale at maximum field of view is 1.93 in fix16 units, and 1.0 at the lowest FOV (DOS). What I did was chart every 5 degrees of FOV, find the ideal yscale then used a parabola/hyperbola curve fitting algorithm to get the coefficients.

[Hendricks266]

Should the calculation account for the y-height of the sky tile? What if the user loads replacement sky tiles that are taller, kind of like the skybox version of widescreen weapons?

[tmyqlfpir]

yscaled is ignored when given the 3D version of the skybox (via this).

All the Blood skyboxes appear to be the same height pixel wise, and replacing the texture will still have those out of bound rendering issues, so this PR will fix those cases.

[Hendricks266]

What if you did change the tile, such as to extend it upwards? What about mods, do any have new art with a different height?

Of course cubemap skyboxes are unaffected.

[tmyqlfpir]

What if you did change the tile, such as to extend it upwards?

Creating a new skybox in ART files that has a bigger height will solve the issue, but will conflict with this scaling fix method.

What about mods, do any have new art with a different height?

I am not aware of any mods that have new skyboxes and have a bigger height value. But that doesn't mean nobody might create one in the future, although I don't think this would play nice with DOS.

[Hendricks266]

The calculation needs to account for tilesiz[].y of the paper sky in question.

[tmyqlfpir]

I'm unable to see a reliable method to get the picnum given that tagging a sky area is done by setting the wall texture as parallax.