Cosa è cambiato in EDuke32, build per build

and use it in MovePoints. This will be used for interpolating the angles of sprites carried by SOs soon.

Using pp instead of ppp seems to work better with prediction.

debug messages unless NET_DEBUG_MSGS is defined

modes. This uses SVN r1135 and r1143 as a reference.

Thanks Dynamo for spotting the bug.

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.

GamePaused within game.h. Do the same with ReloadPrompt.

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.

at a remote-controlled SO. In case PedanticMode == FALSE, this leads to small improvements with aiming at the car in EXAMPLE.MAP.

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).

Note that this angle is currently not interpolated, as done for the sector.

the SO's midpoint. Fixes aiming at a remote controlled SO.

Synthesis builds are now kicked off with a post-commit hook.

This seems to fix memory corruption issues with .xm playback... ???

I'm hoping this is OK now that the issues with SDL and GetClipCursor() have been worked around.