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.
draw.cpp: Fix the lack of interpolation while walking on a sector
object, like the bus roof or the floor of the train in Seppuku Station.
track.cpp: Make sure the player's location and angle aren't mistakenly
interpolated while standing on a moving sector object as a consequence.
While it is understandable that avel and horz came from Duke3D,
having both q16horiz and q16horz in the updated SW_PACKET struct
can be confusing, and the alternative notation is more consistent
with the original struct field names of angvel and aimvel, as well
as the differing uses of the name angvel still present in player.cpp.
for them to modify the player's camq16ang/camq16horiz field
instead of q16ang/q16horiz. Additionally, pass to them the
change in angle/horiz via a parameter, as an alternative
to direct access to the corresponding player input field.
Add the camq16ang and camq16horiz fields to the player struct.
With the exception of DoPlayerTurn and DoPlayerHorizon, whenever
code in player.cpp updates player's q16ang/q16horiz, also write
the updated values to camq16ang/camq16horiz. These variables'
preceding values are never used in these functions.
