🐛 Fix Macro D-Pad inputs being dropped & clearly separate physical vs processed D-Pad checks#1650
Open
Niconiconi-OwO wants to merge 1 commit into
Conversation
🎨clearly separate physical vs processed D-Pad checks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Describe the bug
This PR fixes a bug introduced by the recent hotkey D-pad fix (PR #1635 / Issue #1634),addons (such as Input Macros) that inject D-Pad inputs were having their directional outputs completely overwritten and ignored. This occurred because recent hotkey/UI fixes relied on state.dpadOriginal for masking and checking inputs. Since state.dpadOriginal is captured before PreprocessAddons(), any D-pad inputs injected by macros were being erased during Gamepad::process(), and the USB output was blind to them.
Root Cause
In PR #1635, state.dpadOriginal = state.dpad; was moved to Gamepad::read() to ensure hotkey processing uses unmodified physical inputs. This successfully fixed the hotkey issues.
However, Gamepad::process() was still using state.dpadOriginal to calculate dpadOnlyMask and dpadModeMask.
The execution order in the main loop is:
Because state.dpadOriginal does not contain the Addon-injected inputs, state.dpad = dpadModeMask; completely overwrites and erases any D-pad modifications made by macros/addons.
The Fix
This PR cleanly separates the "processed game output" from the "raw physical input". It fixes the macro direction issue while keeping hotkeys, LEDs, and UI strictly tied to physical presses:
gamepad.cpp: Introduced a local currentDpadSnapshot in process() to calculate dpadOnlyMask and dpadModeMask. This carries macro-injected D-Pad states safely through the masking pipeline without erasing them.
gamepad.h:
Restored pressedDpad() to return state.dpad (so the USB driver outputs the correct macro inputs).
Added a new pressedDpadPhysical() method returning state.dpadOriginal.
Updated pressedHotkey() to use pressedDpadPhysical().
reactiveleds.cpp & GPButton.cpp: Updated the Reactive LEDs and OLED display to explicitly use pressedDpadPhysical().
Result
Macros injecting D-Pad inputs now correctly output to the game.
Hotkeys continue to safely ignore macro inputs (preventing accidental mode switches).
Reactive LEDs and OLED displays continue to honestly reflect only raw physical button presses, preserving the original intent of previous display/hotkey fixes.
Testing
Compiled and tested locally. Verified that macros fire correctly, hotkeys work as intended, and displays/LEDs react only to physical inputs.