-
Notifications
You must be signed in to change notification settings - Fork 15
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
Mouse Control Issues #107
Comments
Thanks for your bug report. Feel free to open a PR, so we can accept it, or suggest further improvements. |
pdaderko
added a commit
to pdaderko/attractplus
that referenced
this issue
Feb 9, 2025
Change mouse axis priority as discussed in this issue: oomek#107 (1)
pdaderko
added a commit
to pdaderko/attractplus
that referenced
this issue
Feb 9, 2025
Fix for mouse getting "stuck" when moving too fast as discussed in this issue: oomek#107 (2)
pdaderko
added a commit
to pdaderko/attractplus
that referenced
this issue
Feb 9, 2025
Fix for mouse getting "stuck" when moving too fast as discussed in this issue: oomek#107 (2)
Just submitted the PR. Let me know if you'd like any clarification, etc. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've got a cabinet with spinners and buttons only, so I'm using the spinners (mouse emulation) to select games. I've come across a couple issues - both appear to be the same in Attract-Mode and Attract-Mode Plus, so I'd guess these issues have been around for a while, but maybe nobody noticed since mouse control probably isn't very popular. I'm running this on Windows 10 (Linux MAME doesn't support multimouse :( ).
I've tracked down the issues and recompiled with my own hacks, but I didn't simply open a PR since there's probably a more proper fix.
1: The priority of the mouse moved event feels inconsistent: https://github.com/oomek/attractplus/blob/master/src/fe_input.cpp#L375 . Note that with the else-ifs, it checks left, then up, then right, then down. So if you move the mouse left and up, it goes left, but if you move the mouse right and up, it goes up. In my case, I'm only using left/right, so what I noticed was that I could always move left, but if I moved up, I couldn't move right.
My "fix" was to move the else if at line 386 to line 381, so it gave priority to L/R, then U/D, which at least makes the directions consistent.
Though it seems that there should be two events, like MouseMovedX and MouseMovedY, or m_code could be an OR of the bits, allowing (for example) MouseLeft | MouseUp, since L/R and U/D aren't mutually exclusive. But looking at the other code, it appears that all events assume only one thing happened, so maybe that'd be too much of a change.
2: If I spin the spinner too fast, it gets "stuck", where it stops and I can no longer turn until I spin the other way, or move the Y axis. I only have the X axis mapped, so the Y axis affecting it was a major clue to the problem. If I move the spinner slowly, I never see the issue.
What appears to be happening is that the mouse "cursor" gets to the edge of the screen, but for some reason the setPosition in main ( https://github.com/oomek/attractplus/blob/master/src/main.cpp#L353 ) didn't move it back to the center when it got outside its box. Then once it's at the edge, it can't move anymore, so it never gets another MouseMoved event.
My "fix" was to move the if block from line 353 to line 341 so it checks if the cursor is outside the box, regardless of an event. I don't know if it misses the event, or if the mouse cursor moves again between it checking the position and it clearing the event... but this makes it work correctly. The code change seems very hacky though.
While I'm here, I'll throw in a feature request - multimouse support would be great. :)
I'd be happy to clarify any of this, or test any new fixes. Thanks!
The text was updated successfully, but these errors were encountered: