* Struct made up of binangle class units.
* Create signed clone of binangle for use with look_ang and rotscrnang.
* Append currently outgoing function names with `2` at the end to avoid conflict.
* 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.
* 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.
* 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).
* 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.
They created different code depending on the passed index, this was changed to always emit the optional parameter, even when not needed, so that the interpreter does not need to second-guess.
Not everything will do something, though. This was some incredibly careless code operating without a safety net allowing uncontrolled write access to the map structure.
Most of the critical fields have been made read-only, which has been the only mode of access in the mods I checked.
Note that this does not enable scripting of the weapon sprite drawer, only the gameplay related features were done.
This timer only gets incremented by the main game ticker when the playsim is running.
This timer gets used for all playsim-related timing and animations so that these are decoupled from imprecisions in the global timer.
* On the fence about this. Lower makes the game harder, and higher could mean the difference between life and death. I do think that if we're showing amounts in the magazine, full ammo should constitute a full magazine. I think the max of 200 is an oversight from the original devs as all other games have proper defaults that reflect the magazine or cylinder capacity.
* Build timer still requires initialisation due to multiple `timerSetCallback()` that still need to work.
# Conflicts:
# source/core/menu/menu.cpp
# source/games/duke/src/game.cpp
Previous attempts at leveraging `applylook()` and `sethorizon()` in different spots had pros and cons, but ultimately changing where these functions were called from was a net negative and had hard to diagnose issues.
Maintaining two types of player input is considerable work. Lessons have been learned and will be beneficial when it comes time to re-doing the other games. Ideas from PR #98 for optimising RRRA vehicle experience while `cl_syncinput 0` is in use have been implemented here.
* For RR, `processweapon_r()` was performing angle and horizon changes directly which provided a harsh experience with the default `cl_syncinput 0` mode.
* Added `angAdjust` variable to `player_struct` for use with ticrate angle adjustments.
* Renamed `horizAngleAdjust` to `horizAdjust` so that there is less confusion with the new `angAdjust` variable.
* Removed `horizSkew` variable, can just use `horizAdjust` for this.
* Replaced all calls to `addang()` and `addhoriz()` with the appropriate additions/subtractions to `angAdjust` and `horizAdjust` respectively.
* Removed now unused `addang()` and `addhoriz()` setters from `player_struct`.
* Define new function `resetinputhelpers()` to eliminate code duplication between `processinput_d()` and `processinput_r()` functions.
* Remove `p->q16ang` and `p->q16horiz` direct setting from `FinalizeInput()`.
* Change `applylook()` to accept an `fixed_t adjustment` for changing the player's angle. This can either be `input.q16avel` when `cl_syncinput` is 0, or `sync[snum].q16angvel` when `cl_syncinput` is 1.
* Change `sethorizon()` to accept an `fixed_t adjustment` for changing the player's horizon. This can either be `input.q16horz` when `cl_syncinput` is 0, or `sync[snum].q16horz` when `cl_syncinput` is 1.
* Re-work `sethorizon()` to always adjust `p->q16horiz` using the true pitch code. This closer resembles the EDuke32 implementation as per SVN 7342.
* Re-work returning to center to work off the true pitch code and always ensure that the player returns to center.
* Implement work-around for RR where we need to call `sethorizon()` before the call to `fi.doincrements()` like the original game, but also after the call to `processweapon()` to apply any angle or horizon changes due to weapon recoil, etc. We work around this by calling `sethorizon()` from within `doincrements_r()` only if `cl_syncinput` is 1 and only if `doincrements_r()` is to return 1.
