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.
similar manner to what's done in Duke3D (with the addition of the angle).
There seem to be some jitters with this, mostly in Master/Slave mode.
Decreasing PAKRATE in mmulti.cpp might also increase the frequency
of this occuring in Peer-2-Peer mode.
less dependent on the frame rate.
It would probably be better to update this from the game loop side,
like in Duke3D, but it's still better than the preceding situation.
DoPlayerTurn/DoPlayerHorizon while input is tied to the frame rate:
Introduce the new player flags PF2_INPUT_CAN_TURN and PF2_INPUT_CAN_AIM.
Set PF2_INPUT_CAN_TURN if DoPlayerTurn can be called outside
of getinput. Similarly set PF2_INPUT_CAN_AIM if DoPlayerHorizon
can be called in this manner.
getinput will only call DoPlayerTurn/DoPlayerHorizon
if PF2_INPUT_CAN_TURN/PF2_INPUT_CAN_AIM is set. These flags are reset
right before the call to the player's current DoPlayerAction function.
For one example in which this assists, it's not always the
case that DoPlayerDeathFollowKiller may call DoPlayerTurn,
even if we assume that pp->input.q16angvel is never zero.
This fixes truncations of q16ang in MovePlayer. One known
fixed issue is a minor micro-shaking effect, reproduced
while standing on a non-moving SO (e.g., the bus in level 1).
The latter is also related to the use of camq16ang.
Based in idea on patch from mjr4077au.
is non-null seems to resolve the newly introduced interpolation
issue for looking up/down while controlling a sector object.
We can also remove the PF_DEAD test, since
game.cpp:getinput should lock any kind of aiming.
src/src/game.cpp:getinput: We now, however, need to further
lock turning here while controlling a sector object.
sector. This re-introduces the angle interpolation in drawscreen
while sector object interpolation is in use.
A side-effect of this is that looking up/down is now less smooth
while controlling a sector object (e.g., a turret).
PACKED macro. This is more consistent with the current Duke3D codebase,
and further fixes build with older versions of MinGW GCC, in which
attribute packed is broken without specifying -mno-ms-bitfields.
