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.
a boss, ensure that FinishTimer and FinishAnim are appropriately
updated. This commit bumps GameVersion.
Additionally, the set of FinishAnim to 0 in NewLevel had
to move to a different location (InitLevelGlobals2), so
it doesn't override the value stored in the saved game.
# Conflicts:
# source/sw/src/game.cpp
* Above calculation has some micro variances to it which were leading to strange behaviour like the bike's tilting not working properly with `cl_syncinput 1`.
* Issue doesn't occur with `cl_syncinput 1` because `processinput()` returns when p->newowner >= 0 before `applylook()` is called from within it.
* Fixes#96.
* Need to add `p->horizAdjust` in with `p->q16horiz` because the values passed to that variable are the same as what would have been directly added to `p->q16horiz` in `processinput()`.
* Leaving mouse input to apply after calculating the pitch lets us take advantage of the calculated pitch's accuracy to provide consistent mouse input across the pitch's range.
* 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.
* Also changed `gethalflookang()` to camel case `getHalfLookAng()` for easier reading.
* Also broke a very long if statement down into smaller chunks for readability.
* Divisor of delta is there so smoothratio always starts off with some kind of value. After 10 minutes at 1100 fps, closest final result to 65536 was:
ototalclk: 4573
totalclk: 4576
gametics: 33.333 ms
elapsedTime: 33.331 ms
ratio: 0.999938
result: 65531.941356
* Returns a true double result.
* Also supports fractional input for fractional input. That is, if `sintable[1]` = 50 and `sintable[2]` = 100, `calcSinTableValue(1.5)` = 75.
* Increased precision of `BANG2RAD` define to use double and not float.
* As such, revert addition of `sintablef[]`.
* `displayrooms()` ultimately should be adjusted as well. For now, just relying on integer truncation as this is just a proof of concept.
# Conflicts:
# source/core/gamecontrol.cpp
# source/core/gamecontrol.h
* Serves no purpose in Raze or GZDoom and appears to only have been added to the backend to facilitate the older interpolation code that was excised in 893686709b.
* Hoping the old path being available will allow the new code to be merged.
* Applied offset to sum of `(totalclk - ototalclk)` of 0.5 to ensure calculated smoothratio under legacy path always returns a value.
* For the above, consider Duke 3D with 4 game tics per ticrate, the returned values would be:
0
16384
32768
49152
* With offset of 0.5, the following values are returned depending on how far advanced `totalclk` is from `ototalclk`:
8192
24576
40960
57344
