* 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.
* Determined maximum horizon able to be handed by engine in Q16.16 format is 280039127.
* Re-did pitch math to work on this known maximum and standardised pitch around -90/90 degrees as it should be.
* Because pitch is now -90/90 and not ~-188/188, m_sensitivity_y probably requires re-scaling.
* 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.
* Reduce `hidInput->mouseturny` to previous scaling (0.25 of incoming input).
* Change `hidInput->mouseturnx` to be 0.5 of incoming input (33% slower than b57e13ff62, but matches what other ports by providing a 2:1 scale).
* Remove further divisions beyond m_side and m_forward and adjust code in `processMovement()` accordingly.
* Change scaling for `mousevelscale` in `processMovement()` to be 1/160th of keymove. Slightly lower for Duke and a lot faster for Blood where it's needed.
* 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.
* rewrote all uses of timerSetCallback. Most were unnecessary or long obsolete, the sound updates need to run per frame, not per tic and the UI tickers need to be handled in the main loop anyway.
* Use a more precise timer to animate the menu transition.
* uncouple other menu animations from the game timer.
This removes most of the InputState class because it is no longer used.
The only remaining places still checking scan codes are the modifiers for sizeup and sizedown.
All the rest was remapped to safer methods. The multiplayer taunts are currently inoperable, they will need support of shift-bindings to get proper support.
* use a CVAR to decide whether to show them at the top or bottom
* draw them on top of the screen border so that they don't get overdrawn on smaller windows.
It will no longer depend on the game state when the menu was opened but the current game state - only on the dedicated menu screen there's no dimming - everywhere else a dim gets applied.
Also renamed GS_DEMOSCREEN to GS_MENUSCREEN for clarity
* 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
* `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
* 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
