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.
* Current setup was broken and unusable.
* Fixed interpolation issues.
* Only call `GetInput()` at frame-rate when `cl_syncinput` is 0.
* Create `oq16look_ang` and interpolate it for enhanced smoothness.
* Always reset `horizAngleAdjust` and `horizSkew` in `processinput_d()`.
* Don't pre-scale `sb_avel` in `processinput_d()` and `processinput_r()`.
* Promote `p->angvel` from short to fixed_t.
* Don't descale `sync[snum].q16horz` in `processinput_d()` and `processinput_r()`.
* Ensure `false` bool is provided to `sethorizon()` call in `processinput_d()` and `processinput_r()`.
* Reset `p->q16angvel` in `resetplayerstats()`.
This also refactors the animateptr array into something serializable. This kind of pointer lookup is virtually unrestorable without creating platform locked savegames.
If this is supposed to be made customizable it has to be done very differently.
# Conflicts:
# source/games/duke/src/game.cpp
# source/games/duke/src/sbar.cpp
