Skip to content

Conversation

bslenul
Copy link
Contributor

@bslenul bslenul commented Oct 16, 2025

Description

As mentioned here: #17954 (comment) the added interval added in the XInput rumble mechanism breaks rumble (e.g. when a game/core requests start/stop for both weak and strong rumbles at the same time).
This PR simply removes that interval while keeping the "if rumble hasn't changed, return before calling g_XInputSetState()" logic which was the main reason for improved performances.

edit: Unrelated but also silenced a warning about has_active_ports being initialized but not used.

Related Issues

Fixes #18172

Related Pull Requests

#17954

Reviewers

@Ryunam @sonninnos would you mind testing on your end? I tested with multiple cores (especially mGBA as mentioned in Ryunam's PR) and didn't notice any difference in FPS.

@sonninnos
Copy link
Collaborator

Seems fine here, as in rumble issue is gone, and no noticeable change in FF speeds with and without controller connected.

@Ryunam
Copy link
Contributor

Ryunam commented Oct 17, 2025

Thank you so much for taking the time to investigate this and devise a fix!
I'll have time to test this today in the evening (in about 8 hours from now) and will report back here.

@Ryunam
Copy link
Contributor

Ryunam commented Oct 18, 2025

@bslenul Okay, I took the time to test this. For the most part - pretty much 99% of the core-content combinations that I have tried so far - I do not see performance regressions, so that's great!

There's just one very niche situation though that I have found, which might be a core-specific issue and not really a frontend one.
Using the mgba core and playing the game "Drill Dozer", notable for having native rumble compatibility, try to go past the introduction sequence and reach the first in-game section.
Then, mash/press/hold the R button to activate the drilling ability of the character (which also triggers a rumble effect), all while holding the fastforward hotkey.

This is the FF framerate before this PR:
image

This is the FF framerate with the changes introduced in this PR:
image

I wonder if, instead of outright removing the interval, it could be reworked differently to accommodate both the strong/weak motors?

@bslenul
Copy link
Contributor Author

bslenul commented Oct 20, 2025

I wonder if, instead of outright removing the interval, it could be reworked differently to accommodate both the strong/weak motors?

Idk how to handle that OOT case tho, if there's any kind of interval it won't stop rumbling on boot/area change, or we'd have to change it to microseconds but I doubt it'd make any difference with no interval at all at that point :p

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.

Possible rumble regression in post-1.21 nightlies in mupen64plus

3 participants