Skip to content
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

InputSettings: Fix controller type counter to restore WPAD limit #1118

Merged
merged 6 commits into from
Mar 20, 2024

Conversation

goeiecool9999
Copy link
Contributor

@goeiecool9999 goeiecool9999 commented Mar 11, 2024

get_emulated_controller_types always returned zero for the number of wpads. It was able to count VPAD's because EmulatedController::VPAD is the only enum value that evaluates to false.
Additionally, create all pages of the input settings menu when it is first opened, so that the counter can see controllers on different pages before the user viewed those pages.
This restores the WPAD limit of 7.

@goeiecool9999 goeiecool9999 marked this pull request as draft March 11, 2024 14:10
@goeiecool9999 goeiecool9999 marked this pull request as ready for review March 11, 2024 14:37
@Squall-Leonhart
Copy link
Contributor

whats the chance of this fixing pro pads in black ops 2?

@Exzap
Copy link
Contributor

Exzap commented Mar 18, 2024

Additionally, create all pages of the input settings menu when it is first opened

I didn't look at the code yet but is this change necessary? As far as I remember this was a deliberate optimization by Petergov to make the loading of the input window faster. Giving your PR a quick test I can indeed see that opening the window now takes about half a second on my Windows system, whereas it used to be near instant.

@goeiecool9999
Copy link
Contributor Author

goeiecool9999 commented Mar 18, 2024

Additionally, create all pages of the input settings menu when it is first opened

I didn't look at the code yet but is this change necessary?

The function that counts the types of currently configured controllers, InputSettings2::get_emulated_controller_types(), uses page_data->ref().m_controller->type(); So if you for example set controller 7 and 8 to a Wii U gamepad, then close and reopen the window, then only page one is initialised so when the dropdown calculates what controller types should be selectable it can't see that on pages 7 and 8 a Wii U game pad was configured and lets you select another one. Only after the user opened each page individually does get_emulated_controller_types return accurate results.

Fixing this problem without initialising every page when opening the input settings would require a bit more complicated restructuring.

@goeiecool9999
Copy link
Contributor Author

goeiecool9999 commented Mar 19, 2024

It turns out that InputManager has the same function that the input settings window has, but instead of looking at the pages it looks at the actual state of InputManager. That InputManager function was unused. I think someone prepared this function to replace the InputSettings function but forgot to actually patch it in. I've now done that. Hopefully that's faster than initialising all pages. (which was instant on linux so I didn't notice)

@goeiecool9999 goeiecool9999 marked this pull request as draft March 19, 2024 16:12
@goeiecool9999 goeiecool9999 marked this pull request as ready for review March 19, 2024 16:16
@goeiecool9999 goeiecool9999 marked this pull request as draft March 19, 2024 16:19
@goeiecool9999 goeiecool9999 marked this pull request as ready for review March 19, 2024 16:28
@goeiecool9999
Copy link
Contributor Author

goeiecool9999 commented Mar 19, 2024

Sorry for spamming draft to ready for review. But I thought I saw a mistake.
I got tricked in the same way a bug was introduced. wxNOT_FOUND and disabled aren't the same thing. So that's why the extra && selected != 0 is necessary. Otherwise you could pick an extra wpad by selecting "Disabled" instead of Wii U gamepad. I thought about changing selected != 0 to selected_value != _("Disabled") but as long as disabled remains the first option I think this is fine

@Exzap Exzap merged commit 4d609f0 into cemu-project:main Mar 20, 2024
5 checks passed
@goeiecool9999 goeiecool9999 deleted the fixcontrollercounter branch March 27, 2024 15:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants