* 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
(with SO interpolation turned on). It would be nicer to have something
better structured than the given hack, but this currently seems to work,
while not breaking the sprites on the boat in the beginning of level 5.
of change that camq16ang/camq16horiz gets. Such an update is possible
after making sure that UpdateInputs (faketimerhandler) is
never called from domovethings.
# Conflicts:
# source/sw/src/game.cpp
and ready2send and the call to timerUpdateClock, which are now done
before calling UpdateInputs itself from RunLevel.
# Conflicts:
# source/sw/src/network.cpp
from EDuke32-OldMP. Main difference from EDuke32-OldMP is that this is
done even while staying in the menu; Behaviors will otherwise break.
We should also call timerUpdateClock() before the loop, especially
after removing the call to this function from faketimerhandler soon.
of the secret rotating pillar in level 1 with SO interpolation.
The drill in level 2 is also covered. So far, SetVatorActive seems
to be the only place where interpolation of ceiling/floorz
may be set, outside of the SO interpolation code.
