Fix gamepad axis brake behaviour

- It was actually ACCELERATION axis input that was predominantly broken!
    - It was inexplicably slightly under double what it should be (98 instead of the digital value of 50), which meant brake analog input struggled to dampen it.
    - Analog brake deceleration also gets a slight buff, from 24 to 25 (previously off from the digital value of 25 due to integer division rounding)
- Remove a pointless, always-true condition for brake handling.
    - Checked whether accel was held down OR whether `cmd->forwardmove` was less than or equal 0...
    - But further up the same function, `cmd` was invariably overwritten with a blank `I_BaseTiccmd`!
    - Therefore, `cmd->forwardmove` would always equal 0, and the `forwardmove` subtraction would always occur.
This commit is contained in:
toaster 2022-12-15 21:21:43 +00:00
parent 5008558633
commit 99c1a51772

View file

@ -1503,22 +1503,20 @@ void G_BuildTiccmd(ticcmd_t *cmd, INT32 realtics, UINT8 ssplayer)
{
cmd->buttons |= BT_ACCELERATE;
// JOYAXISRANGE is supposed to be 1023 (divide by 1024)
forward += ((axis * forwardmove[1]) >> 10)*2;
forward += ((axis * forwardmove[1]) / (JOYAXISRANGE-1));
}
axis = JoyAxis(AXISBRAKE, ssplayer);
if (InputDown(gc_brake, ssplayer) || (gamepadjoystickmove && axis > 0))
{
cmd->buttons |= BT_BRAKE;
if (cmd->buttons & BT_ACCELERATE || cmd->forwardmove <= 0)
forward -= forwardmove[0]; // 25 - Halved value so clutching is possible
forward -= forwardmove[0]; // 25 - Halved value so clutching is possible
}
else if (analogjoystickmove && axis > 0)
{
cmd->buttons |= BT_BRAKE;
// JOYAXISRANGE is supposed to be 1023 (divide by 1024)
if (cmd->buttons & BT_ACCELERATE || cmd->forwardmove <= 0)
forward -= ((axis * forwardmove[0]) >> 10);
forward -= ((axis * forwardmove[0]) / (JOYAXISRANGE-1));
}
// But forward/backward IS used for aiming.