Cosa è cambiato in EDuke32, build per build

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

so OSD commands can have an effect from here

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

Move ratio calculation out of inner loop.

is now required. Previously, it would be called from faketimerhandler, which in turn is called from the engine.

if any of its sectors is impacted by CopySectorWalls. Fixes a possible flicker with the drill at the end of level 2.

separate checks of the form sop->xmid == INT32_MAX

for now, due to possible jitters. Currently leaving remote-controlled SOs.

from faketimerhandler. This should fix the timing of playing an RTS file's sound and sending the corresponding message.

by the player. Make sure looking up/down is still smooth.

don't move as smooth as possible in multiplayer

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.

SW 1.2 after minor adjustments. Originally recreated for sw-src-and-build-addendum-20190129.7z.

and also as currently in use in EDuke32-OldMP.

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.

test for PF_MOUSE_AIMING_ON only if PEDANTIC_MODE == FALSE

one of the players toggled mouse aiming in the middle of a game, and it worked even worse in Master/Slave mode. Additionally, tying input to frame rate made the problem disappear.

related to the definitions of RANDOM_NEG in bunny.cpp, ripper.cpp and ripper2.cpp. Do so in a way that isn't re-introducing compiler warnings. This partially fixes compatibility with demos made for SW 1.2. Additionally, replace the 3 separate definitions of RANDOM_NEG with a common one within game.h.

sintable and radarang. sintable[512] was different in a 32-bit build.

functional with existing demo files, the code is known to be incompatible with demos made for SW 1.2.

brought back in r7873, this should restore the behaviors of DOS v1.2.

Fixes tiled automap rendering in SW, without breaking the status bar as in the case of r8766.

as done in r8766, since this breaks status bar output in tiled overhead map with Polymost. Do add comment about this for now.

Fixes non-deterministic white rectangles rendering bug in PCExhumed.

corresponding variable in rooms.cpp is used if DEBUG is defined to nonzero.

later. This also turns out to fix a Polymost-specific bug revealed in SVN r8711. Further remove a call to PicInView which does nothing.

a bit more usable in multiplayer, hiding the engine's console.

toggling MultiPlayQuitFlag on instead of QuitFlag in multiplayer games if a player tries to close the window. Further update MNU_QuitCustom to use CON_Quit. - In RunLevel, this fixes quit of game for all players. - In MenuLevel, this leads to transmit of PACKET_TYPE_MENU_LEVEL_QUIT. However, the work isn't complete, since the game isn't shut down on the peers' sides, leading to possibly undesired side-effects. Currently known issue: - If the master closes the window, the scores won't be shown for the master. Reason is that waitforeverybody will terminate the app.

use p->TeamColor instead of User[p->PlayerSprite]->spal, since it's possible the player left before the map was loaded.

quitevent in the game, and further call getpackets within StatScreen.

all players after level change. This is done by adding calls to getpackets within the BonusScreen and StatScreen while loops. It is related to a change from the DOS versions of 1997. Basically, dosendpackets immediately sends all packets via the commit driver under DOS, while in the mmulti port in use here, sending might be postponed. This was leading to a problem with the game entering waitforeverybody before showing the stats. In particular, it initially attempted to send a PACKET_TYPE_PLAYER_READY message, which could get postponed in the manner described above. In case it received PACKET_TYPE_PLAYER_READY messages from all other peers before the time arrived for sending pending packets, though, waitforeverybody would return, eventually leading to a call to StatScreen/BonusScreen, without sending the pending message until the user in question continued. Other peers would have to wait for the given player to confirm level change before they could see their own stat screens.

processing multiplayer params or waiting for players. It's been decided that Control won't call TerminateGame in this case, one implication being that voidsw.cfg is not updated.

Thanks to LittleTijn for testing and inspecting.

mostly from JFSW commits 7a95dee807c735de6588372e268af7a5c7cdc533 and 6137b48d6d432c34d94d08fea527b89539cc3adb. In particular, this makes Master/Slave usable for 2-player sessions, with SW's networking code behaving as if these were actually Peer-2-Peer sessions. Thanks to JonoF for his work on the support.

on the frame rate

params, but leave them for documentation. Note that currently, the only use of ComboMissileSeek is in the saveable_weapon_code array.

the functions' signatures (often due to being used as callbacks/hooks)

Note that the passed type is always ct_mainmenu.

with (possible) side-effects is written to an unused var.

used if previously commented out code was uncommented (including a few instances of uninitialized var reads).

packet of type PACKET_TYPE_MESSAGE. This reverts a tiny portion of JFShadowWarrior commit 6b01a4703d55ae3e131d8c11903ff2dcd78c15d8.

video mode change in USE_OPENGL=0 build.

in USE_OPENGL=0 builds, and further make setrendermode usable.

with minor changes.

as well as the wrong aspect ratio in 3D for Ken-Build.