* Calculate game-side mousex/mousey divisions into the calculations performed in `InputState::GetMouseDelta()`.
* Fix mouse speed when `in_mousesmoothing` is true (wasn't factoring in / 3.f division used in non-true vector.
* Standard mouse forward/side movement speeds in Exhumed & SW with that of other games.
* Remove `strafeyaw` code from Duke/Exhumed/RR as it's not necessary and was leading to situations where the player would continually keep moving sideways even without input.
* Change mouse forward/side velocities to -= current value as is done with controller input and the player's angle/aim velocities.
* Convert axes in ControlInfo struct from int32_t to float as what's received from the backend.
* Remove all the scale up/down math since we don't need that with floats and replace with float constants that match old behaviour.
* Store q16mlook scaling as a constant for use with mouse and upcoming controller code.
* Add required controller code to Blood as the only game not to have working controllers.
* Fix typos in (gInput.forward > input.forward) for `ctrlGetInput()` in Blood.
* Remove use of `scaleAdjustmentToInterval()` on Exhumed and Shadow Warrior as they only process forward/side velocities within the game's ticrate.
* Repair angvel/aimvel scaling mistakes from d79a5d256d.
* Scale dyaw and dpitch by 25% for Shadow Warrior as the game runs 25% faster than the other games, leading to faster input.
This also fixes the interpolation for gamefunc_TurnAround and stomping on enemies. Fixesterminx/eduke32#60.
# Conflicts:
# source/duke3d/src/actors.cpp
# source/duke3d/src/game.cpp
# source/duke3d/src/premap.cpp
This is to allow giving them a texture ID so that they can be used from ZScript which has no access to naked textures.
This also consolidates AnimTexture and VpxTexture.
* Repairs https://forum.zdoom.org/viewtopic.php?f=340&t=67239 and https://forum.zdoom.org/viewtopic.php?f=340&t=67933
* Values that come from GZDoom backend are too low to be suitable for the Build games which were dividing by 'analogExtent'.
* Remove definition of analogExtent from all games and define in inputstate.h, then define joyaxesScale as 75% of analogExtent to provide a bit of headroom and not have a scale of 1.0 be full speed.
* Invert the returned results of GetAxes() as the returned floats are reversed for build games.
* Leverage scaleAdjustmentToInverval() on game-side code to consistently scale the input irrespective of frame rate, vsync etc.
Technically, an overflow is still possible, but with unsigned integers
it is highly unlikely to satisfy (sum_squares < 290*290) in practice.
# Conflicts:
# source/duke3d/src/player.cpp
This is so I can tell the difference between actor .t_data[] values that are actually set to something defined in CON versus bullshit arbitrary internal usage of the same variable, which I need for a future commit.
I don't expect anyone to make an EDuke32-compatible WT mod where other enemies shoot FLAMETHROWERFLAME, but if they do the behavior will at least be consistent across enemy types.
This results in far fewer calls to getwalldist(), inside(), and cansee(), which should significantly lessen the performance hit from a large number of A_RadiusDamage() calls in areas with many small detail sectors.
# Conflicts:
# source/duke3d/src/actors.cpp
