-
Notifications
You must be signed in to change notification settings - Fork 142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Full button remapping with native adapter #348
base: slippi
Are you sure you want to change the base?
Conversation
switch string_view to string since we are only on C++14
this is functionally identical to mainline even if it is a bit different in code
* add linux deploy used for 2.3.0 release * always chmod tools
* feat: don't default Render to Main Window true on Linux * feat: default fullscreen to true
* WIP: Committing changes to test on windows * Use DELETE key instead of C with Cedilla since it crashes on std wstring * Remove testing flags * Run formatter and disable logs * Revert any changes to this EXI Device SLippi * Revert any changes to this EXI Device SLippi 2 * Remove weird line changes * run formatter
* Validate incoming chat and player selection packets - Reject all but the expected 16 chat IDs - Validate that each parameter of each packet exists
* On macOS 11.0 I noticed that the libusb hotplug event was getting called on the read thread. This seemed to be different behavior than my windows platform where the hotplug event was happening on it's own thread * when a hotplug detach event happens the reset thread waits for the in and out threads to error out with "join" * however, on macOS 11.0 (when started with an adapter plugged in), the detach event would attempt to join itself causing a crash. * To get around this before trying to join threads reset will try to see if it is one of those threads and start a new reset thread if so. * If we wait attempt to join the reset thread from the caller they will both be trying to join each other which will also result in a crash
* Remove WebView support from Windows/Linux. - Specifies the Externals/wxWidgets build to not link any WebView control on those platforms. - Blocks off the code on the various DolphinWX components to only link and/or run on macOS. - Restores `xgd-open` on Linux for the increasingly rare cases where that code path should be getting hit. The reasoning for keeping this around on macOS is somewhat selfish - it's just easier for me to pass a test build for a one-off change to users who might otherwise not understand the macOS bundle and AppSupport architecture. * Minor clarification in the root CMakeLists.txt for linking an external wxWidgets setup * Formatting pass.
* Force CAMetalLayer to disable vsync. I have zero clue at the moment why this works. MoltenVK sets this property during initialization of the swapchain, and logging confirms it's set, but setting the proprty ahead of time seems to actually disable vsync and result in the expected rendering smoothness. At worst, this change does nothing that wouldn't be done by MoltenVK anyway. At best, it seems to provide much smoother render on a number of tested macOS setups (Intel 2015 MBP/Mojave, Intel 2015 MBP/Catalina, 2020 M1 MBP/Big Sur). * Inject a custom CALayer rendering target to avoid wxWidgets drawRect * ENV feature flag this * Formatting
Co-authored-by: Robert Peralta <[email protected]>
* Change macOS to default to Vulkan in 10.14+. This mirrors a change in mainline Dolphin, so should be relatively safe to do. Slippi's MoltenVK setup is a bit older than modern Dolphin's, but most users still see a jump in performance in comparison to Apple's broken OpenGL API. High Sierra remains defaulted to OpenGL, as Metal on that platform lacks critical pieces that Dolphin requires.
* Change config pane option to be a dropdown and refactor usages of previous options to check for Enable Chat first. + Moved Auto disabled chat message to ExiDeviceSlippi instead * Fix logic that checks if Chat is Enabled (I missed a break so I crashed, get it?) - Fix bug preventing message Id for Chat is Disabled when doing chat message validations. * Run formatter * make map static * wording, variable name, and formatting updates Co-authored-by: Nikhil Narayana <[email protected]>
prior to this change if someone loaded really slow the other clients could actually get very far ahead and potentially cause crashes
this will only be used in situations where Slippi is experiencing database outages
…or the other buttons
Would be nice if it'd zero out analog L/R if they're rebound to some other button: diff --git a/Source/Core/InputCommon/GCAdapter.cpp b/Source/Core/InputCommon/GCAdapter.cpp
index 1e82201ed..125a91351 100644
--- a/Source/Core/InputCommon/GCAdapter.cpp
+++ b/Source/Core/InputCommon/GCAdapter.cpp
@@ -855,8 +855,22 @@ GCPadStatus Input(int chan, std::chrono::high_resolution_clock::time_point *tp)
pad.stickY = controller_payload_copy[1 + (9 * chan) + 4];
pad.substickX = controller_payload_copy[1 + (9 * chan) + 5];
pad.substickY = controller_payload_copy[1 + (9 * chan) + 6];
- pad.triggerLeft = controller_payload_copy[1 + (9 * chan) + 7];
- pad.triggerRight = controller_payload_copy[1 + (9 * chan) + 8];
+ if (SConfig::GetInstance().m_LChoice[chan] == PAD_TRIGGER_L)
+ {
+ pad.triggerLeft = controller_payload_copy[1 + (9 * chan) + 7];
+ }
+ else
+ {
+ pad.triggerLeft = 0;
+ }
+ if (SConfig::GetInstance().m_RChoice[chan] == PAD_TRIGGER_R)
+ {
+ pad.triggerRight = controller_payload_copy[1 + (9 * chan) + 8];
+ }
+ else
+ {
+ pad.triggerRight = 0;
+ }
}
else
{ I'm not sure if 0 is the proper default value to use, but it does seem to work ingame. Swapping L and R will disable analog shields, not sure if that's ideal. This is solvable without this by triggertricking, but it'd be nice to not require that. Maybe a triggertrick option could be cool too? |
AFAIK switching L and R is completely pointless in Melee (it doesnt matter for shielding or quitting out of a match) so I don't think this will bother anyone. |
…mp button that you dont want to use, for example)
I've had people ask me for multiple button-swapping Slippi builds (X-Z swap, Y-Z swap, and X-Y swap) so I made a build which lets you remap all of the digital buttons.
FYI there isn't any kind of enforcement against illegal remapping here (in most Melee rulesets, you aren't allowed to have multiple buttons with the same button action mapped).