Storing this in the player_struct is pointless and a relic from having to use real hardware palette switches.
With this now just being a translation index being passed to the backend it can be cheaply retrieved right when used and nowhere else.
Also making some changes to how RRRA's psychedelic cactus handles the projection. This fixes issues with occasionally passing a bad matrix.
The main problem here is that there's two data arrays representing an actor - sprite and hittype and the engine only uses indices for reference.
By setting up hittype to contain a sprite reference, the function and iterator interface can be rewritten to use a single pointer instead to represent an actor.
The main objective is to reduce the number of accesses to the global arrays which constitute the biggest refactoring blocker.
* 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.
* 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.
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 includes loading a level and busy-waiting for a sound to play.
Also block these loops and the sounds they wait for in network games to avoid problems from longer delays here.
The problem seems to be directly inherited from ZDoom which shows the same issue with screen wipes.
Fixes#297
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.
* 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
* 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()`.
