* 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.
* 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.
* the palette shader was not bound.
* the palette textures were not bound.
* palette mode still used regular lighting on top of the palette emulation
This works a lot better than before but is still not complete.
The new main loop code cannot handle that. Instead set a start value for gameclock so that gameclock can be based on an arbitrary time value instead of directly representing global time.
* moved the part that alters the input before queuing it to GetInput
* moved moveloop into the main function
* reshuffled a few things for better grouping by task.
None of this was really working anymore, but will have to be rethought once a network stream exists again.
But even then, this is better sent as a separate command, and in MP only.
This needs to be called unconditionally for every frame being rendered, not all of the game modules did that.
Placing this call here ensures that it is independent of anything the games do.
