There are effectively two states - the one in the backend and a local one in the drawer for the render list which is supposed to eliminate some of the more costly repeated calls.
This higher level state was cached globally, which did not work anymore because the real render state could be changed elsewhere without this code realizing it.
All this means that the render list drawer must create a new state cache for each call and also must apply its current pending render state before leaving to ensure that everything is properly reset.
* 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.
(e.g., beginning to jump, or landing on ground);
Reproduced with the input being tied to framerate
while SO interpolation is toggled on.
This involves the following modifications:
- PF2_INPUT_CAN_TURN and PF2_INPUT_CAN_AIM are now additionally set
from various DoPlayerBegin* functions, allowing the player to continue
turning/aiming as usual (right before the next call to domovethings),
even in specific instances of player action changes.
- If PF2_INPUT_CAN_TURN/PF2_INPUT_CAN_AIM was set before and
after calling pp->DoPlayerAction from domovethings altogether,
ensure that the player's oq16ang/oq16horiz is updated by
making an appropriate call to DoPlayerTurn/DoPlayerHorizon. This
is done in case a call to DoPlayerTurn/DoPlayerHorizon is missed.
This change is not applied for a dead player, though.
in 1a3c9e3a15ba788607dfd96ebcc75a2198be6d69 was a mistake.
The interpolation should still apply, albeit not while
the viewing angle is changed via the player's own input.
We should also continue interpolating in coop view.
interpolation of player turning/aiming/movement, while being carried
by a sector object, without SO interpolation. This is a continuation of
73a0aa394e906a65633d61f3c749c9b9b7e66aaa and bf31bc2987a3eccd31d343622327bd4ee0f9c5a1,
aiming to fix a jitter in case the player is continuously
getting pushed by a wall (e.g., on the boat in level 5).
Basically, this moves the relevant assignments from track.cpp:MovePlayer
and MovePoints to player.cpp:DoPlayerMove. Unless a call to one of these
functions has been missed, pushwall and clipmove can be called from
player.cpp in the following instances, which should be covered:
- Via DoPlayerMove, which is the function getting the fix now.
- Via DoPlayerSlide, which is called in the beginning of DoPlayerMove.
- Via DoPlayerCurrent when called from DoPlayerCrawl/DoPlayerWade,
followed by DoPlayerMove.
- Via DoPlayerCurrent when called from DoPlayerDive,
followed by DoPlayerMove if the player doesn't stop diving.
# Conflicts:
# source/sw/src/track.cpp
