* Started with the most complicated game first.
* Struct made up of fixedhoriz class units.
* Append currently outgoing function names with `2` at the end to avoid conflict.
* Determined maximum horizon able to be handed by engine in Q16.16 format is 280039127.
* Re-did pitch math to work on this known maximum and standardised pitch around -90/90 degrees as it should be.
* Because pitch is now -90/90 and not ~-188/188, m_sensitivity_y probably requires re-scaling.
* Blood had this right. It makes sense that the horizon be based around as it's easier to work with.
* Removed all associated game math to deduct default horizon of 100 when doing weapon zvel etc, meaning actual horizon can just be used.
* Re-did return to center function to work on the already converted pitch. Return speed should be 1:1 with previous code.
This time there were 3 additional texts and the notify display, though, except for multiplayer content that wasn't touched yet.
The result is the same: No need to extend the tiny font with international characters
This essentially removes the tiny font which is simply too small to ever be able to receive a proper international extension from the equation for localization because the level name display was the only remaining relevant content using this font.
The only other screen where this font is still being used to draw text requiring translated content is the multiplayer summary which will have to be redesigned anyway if multiplayer becomes functional again.
* Reduce `hidInput->mouseturny` to previous scaling (0.25 of incoming input).
* Change `hidInput->mouseturnx` to be 0.5 of incoming input (33% slower than b57e13ff62, but matches what other ports by providing a 2:1 scale).
* Remove further divisions beyond m_side and m_forward and adjust code in `processMovement()` accordingly.
* Change scaling for `mousevelscale` in `processMovement()` to be 1/160th of keymove. Slightly lower for Duke and a lot faster for Blood where it's needed.
Apparently this is needed by some hires packs to fudge the sprite offsets.
Fortunately, setting sprite offsets is the only thing this was ever used for so it's relatively uninvasive.
This is needed to extend a few fields that are too narrow - e.g. the texture offset fields have no room for interpolating scrolling textures.
Blood not done yet, will also need to be changed to get rid of the limits.
* Duke/RR: Fix `SB_CENTERVIEW` not clearing while `cl_syncinput 1`.
* Duke/RR: Remove superfluous call to `apply_seasick()`.
* RR: Change two calls from `playerSetAngle()` to `playerAddAngle()` Updated version of `playerSetAngle()` doesn't stop setting angle until target is reached, a bit too strict for this and compromised vehicle turning.
* `applylook()`: Remove dead flag. Was only used with Duke, no other game called the function when dead anyway. Since the input helpers are processed outside of `applylook()` now this is not needed.
* `applylook()`: Extend function with a bit of commentary.
* For Blood/SW, exposes `SB_LOOK_LEFT`/`SB_LOOK_RIGHT` to games, hooking up `q16look_ang` and `q16rotscrnang` within.
* For SW, use Duke & Blood's return to center function and remove `PF_TURN_180` bit.
* For RR, replace a few misused bits with some bools inside of `player_struct`.
* Since bulk of functionality is sourced from Duke (30Hz), apply proper scaling so SW speed matches (40Hz).
This is for consistency, otherwise sprites with a palette translation would stand out. Also use shade dependent fog density instead of a single global value.
Currently this only has an effect in true color rendering mode.
* For Duke/SW, we continually apply `SB_CENTERVIEW` only if it was previously a toggled action, similar to Blood.
* For SW, we remove two SW-specific bits (`PF_LOCK_HORIZ` and `PF_LOOKING`) that are no longer needed.
* For Duke, we remove `return_to_center` and just use the `SB_CENTERVIEW` action bit as required.
* For `sethorizon()`, feature set and adjustment speeds are an averaged out accumulation across Duke/SW:
** GameTicRate is factored in for adjustment decisions to provide consistency for SW being the faster game.
** Adjustment amounts are half way between Duke/SW.
* Need SW's input helpers available for Blood but therefore also need an angle delta function that does not seem to exist in Blood.
* Realise that gamecontrol.h/cpp might not be the most appropriate place, but it's a shared location and these will go into binaryangle.h when its utilisation can be more realised.
* Because SW's logic was reversed, in that param #1 was the new angle and param #2 was the current, all calls have been reversed.
* By happenstance, also fixes an issue with multiple 180° turns in quick succession.
