What changed in EDuke32, build by build

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.

Achieved by hex-editing libSDL2.a to change a JE (0x74) to JMP (0xEB). This should improve micro stuttering-issues on Windows. My settings: r_vsync 2 r_maxfps 0 win_systemtimermode 1 win_performancemode 1

Patch from Nuke.YKT.

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

Includes the new weapon, enemy projectiles, and breakable objects. Patch from Nuke.YKT. I edited it some, mostly to add the proper "if (WORLDTOUR)" checks.

This was split from another commit to make the other commit clearer. These changes don't really do much of anything.

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.

This also normalizes the scale sliders to a displayed range of 0 - 1.0, and adds in_mousexscale and in_mouseyscale cvars to hold the values.

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.

This also adds a menu option for OPL3 stereo mode. Windows MME output device selection is probably next (this can already be done through the console).

This changes the code formatting and style of driver_winmm to better match our style guidelines.

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.

Backported from Rednukem.

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