a boss, ensure that FinishTimer and FinishAnim are appropriately
updated. This commit bumps GameVersion.
Additionally, the set of FinishAnim to 0 in NewLevel had
to move to a different location (InitLevelGlobals2), so
it doesn't override the value stored in the saved game.
# Conflicts:
# source/sw/src/game.cpp
* 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 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.
(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.
of sector objects as whole groups of points and sprite angles.
The following goals are intended to be achieved with this code:
- Make it easy to let the user toggle sector object interpolation.
- Interpolate the angles of sprites carried by sector objects.
- Use the right amount of samples for interpolating a sector object,
depending on the players' locations, as done in the checks within
DoSector. Unfortunately, modifying DoSector itself to
unconditionally call MoveSectorObjects(sop, synctics) technically
changes the way sectors move (in the logical sense), and was
found out to make a specifically constructed user map unbeatable.
- Make it easy to disable interpolation of a whole sector object in
case of a need. This is especially important if such an object
is controlled by a player in multiplayer, mostly since this
isn't compatible with the way player prediction is working.
A known issue, which also applies to existing settings like the voxel
toggle, is that its value gets written to the saved game, and when such
a game is loaded, the its value gets overwritten by the one in the
saved game. Options should move to settings.cfg later, anyway.
