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

DolphinQt/ControllerEmu: Add stick calibration "wizard". #7792

Merged
merged 1 commit into from Feb 13, 2019

Conversation

9 participants
@jordan-woyak
Copy link
Member

jordan-woyak commented Feb 7, 2019

Replaced Input Radius/Shape settings with an input calibration "wizard".

NEW demonstration showing me try to defeat the calibration procedure.
https://giant.gfycat.com/IgnorantSaltyKingfisher.webm

Recent changes:
The "Calibrate" button flashes red if input is significantly outside the calibration radius (miscalibration)
"Cancel Calibration" is the default action until something somewhat sensible has been detected.
If the user fails to move their input 50% after 2 seconds into calibration a message is displayed: "For best results please slowly move your input to all possible regions."
Set the "popupMode" of the QToolButton to "MenuButtonPopup" so the little arrow is a separate button.
Cleaned up code per reviews.

A superset of functionality is provided over the "Input Radius" and "Input Shape" settings which I've removed.
Not only could they only define shapes that were perfectly square, circular, octagon, or somewhere in-between their behavior was too obscure for the average user to wrap its head around without a tutorial and required too much ambition to play with and figure out.

I think the word "Calibrate" will draw users attention and they will be apt to click it even before they run into issues caused by their mis-configured stick.

This also de-clutters the UI a bit. (before I add a bunch of MotionPlus mappings)

A "Calibration" setting is generated containing a variable-length space-separated list of maximum radii at evenly spaced angles around the neutral value.

Added a Vec2 class to Matrix.h to complement Vec3.

I'm not entirely happy about having to override ControllerEmu::Load/SaveConfig but I plan on cleaning up how ControllerEmu handles settings to make this unnecessary in another PR.

@jordan-woyak jordan-woyak changed the title DolphinQt/ControllerEmu: DolphinQt/ControllerEmu: Add stick calibration "wizard". Feb 7, 2019

@jordan-woyak jordan-woyak force-pushed the jordan-woyak:auto-calibration branch 3 times, most recently from c8a64fa to 746a401 Feb 7, 2019

@8times9

This comment has been minimized.

Copy link
Contributor

8times9 commented Feb 8, 2019

I think renaming “Complete Calibration” to “Stop Calibration” would be more clear to the average user.

@jordan-woyak

This comment has been minimized.

Copy link
Member Author

jordan-woyak commented Feb 8, 2019

I think renaming “Complete Callibration” to “Stop Callibration” would be more clear to the average user.

Maybe. I was worried users might think a "Stop" would cancel everything (and some other unknown action they are supposed to do would complete their calibration).

@8times9

This comment has been minimized.

Copy link
Contributor

8times9 commented Feb 8, 2019

True, what do you think about “End Calibration”?

@Techjar

This comment has been minimized.

Copy link
Contributor

Techjar commented Feb 8, 2019

I'm in favor of either "Complete Calibration or "Finish Calibration". I'd also like to add that this feature is great and something more emulators should have.

@jordan-woyak jordan-woyak force-pushed the jordan-woyak:auto-calibration branch 2 times, most recently from a47815d to 0408fda Feb 8, 2019

@8times9

This comment has been minimized.

Copy link
Contributor

8times9 commented Feb 8, 2019

+1 for Finish Calibration

@Helios747

This comment has been minimized.

Copy link
Contributor

Helios747 commented Feb 8, 2019

Anything but stop calibration pls.

Beyond that, don't care about wording

@MayImilae

This comment has been minimized.

Copy link
Contributor

MayImilae commented Feb 8, 2019

Quick question: how does this handle accidental or bad input? Like if someone presses the button and then presses "complete calibration", without moving the stick, what happens? Or what happens if they fail to rotate the stick properly? Like, how robust is the fail state handling on this?

Obviously garbage in garbage out, but there should at least be some wiggle room in extreme cases for the calibration to be like "hey you screwed up, I'm throwing out this data".

@jordan-woyak

This comment has been minimized.

Copy link
Member Author

jordan-woyak commented Feb 8, 2019

Quick question: how does this handle accidental or bad input? Like if someone presses the button and then presses "complete calibration", without moving the stick, what happens? Or what happens if they fail to rotate the stick properly? Like, how robust is the fail state handling on this?

Obviously garbage in garbage out, but there should at least be some wiggle room in extreme cases for the calibration to be like "hey you screwed up, I'm throwing out this data".

Right now it will use any garbage data they create.
We could check the "area" of the shape that the user created for something far less than typical and ask the user if they really want to use it.

@MayImilae

This comment has been minimized.

Copy link
Contributor

MayImilae commented Feb 8, 2019

That would be nice, so it would at least be smart enough to reject accidental presses.

As for complete calibration text, as long as it does what it says, I don't think complete or finish is any better, imo. I'm fine with either.

"Rotate stick now" on the other hand, I think is very inadequate. For calibration, the quality of the calibration depends on the quality of the data the user gives it, and we don't want the calibration process to make things worse. So we need to give the user instructions on how to give the calibration good data, like "Rotate the stick in a circle several times". You'll often see wording like this in calibration screens on consoles. For example, the Nintendo Switch uses "Rotate the control stick in a large circle two or three times."

Of course that uses way more text space than is available here, but I don't really see a way to cram decent instructions into that tiny little box. So it might be worthwhile to change the UI approach to a calibration pop up window. That's asking a fair bit, but I think the quality improvements for calibration can be worth it.

This has the perk of avoiding translation issues too.

@ghost

This comment has been minimized.

Copy link

ghost commented Feb 8, 2019

It seems "Finish" would make more sense over "Stop". Technically not wrong but "Stop" can indeed convey a "cancellation" type of context, depending on the person.

I ran Display Color and ClearType calibration on Windows10, both buttons were labeled "Finish". It may also be due to wizard it self, wizards usually end with "Finish", and there's a lot of installers with such wizards out there, ending on "Finish".

@BhaaLseN

This comment has been minimized.

Copy link
Member

BhaaLseN commented Feb 8, 2019

Does any button press on the controller accept (or rather, continue) the calibration? Like the Windows calibration thingy that goes "center, press button", then "circle around, press button" (at least once for every stick and axis) and "center, press button" to finalize?

@jordan-woyak

This comment has been minimized.

Copy link
Member Author

jordan-woyak commented Feb 8, 2019

Does any button press on the controller accept (or rather, continue) the calibration? Like the Windows calibration thingy that goes "center, press button", then "circle around, press button" (at least once for every stick and axis) and "center, press button" to finalize?

No. We can't really use "any" button because their stick might be mapped with buttons (not extremely unusual). Even if we used their "A" button mapping it could potentially overlap with their stick.

@jordan-woyak jordan-woyak force-pushed the jordan-woyak:auto-calibration branch 2 times, most recently from b6a2600 to 5cc0c62 Feb 9, 2019

@jordan-woyak jordan-woyak force-pushed the jordan-woyak:auto-calibration branch from 5cc0c62 to 0064f70 Feb 10, 2019

@mbc07

This comment has been minimized.

Copy link
Contributor

mbc07 commented Feb 10, 2019

Nitpicking here, but the "button flashing red" thing seems out of place for me. I never saw any other program doing anything similar and I hoped we could drag user's attention to the calibration button in a more elegant, less "archaic" fashion, although I can't think of anything better right now =/

@8times9

This comment has been minimized.

Copy link
Contributor

8times9 commented Feb 10, 2019

We already use red text for the mapping buttons to indicate a button press...that red is just showing a button has been pressed (and no further action needs to be taken), but the red for the calibration button is showing there's an issue and the user needs to click "Calibrate". Two different meanings for red text on the mapping window might blend in together and be confusing.

If anything, I think the red for the mapping buttons should be changed to a different color. For the calibration button, red fits to show there's an issue that requires attention.

My two cents ¯\_(ツ)_/¯

@BhaaLseN

This comment has been minimized.

Copy link
Member

BhaaLseN commented Feb 11, 2019

Thoughts on drawing some sort of "Not enough data", "Please move your stick" (or whatever) right inside the indicator that would only go away once the calibration is good?

@Tilka

This comment has been minimized.

Copy link
Member

Tilka commented Feb 13, 2019

Let's keep UI details for another PR.

@Tilka Tilka merged commit 131f493 into dolphin-emu:master Feb 13, 2019

9 checks passed

default Very basic checks passed, handed off to Buildbot.
Details
lint Build succeeded on builder lint
Details
pr-android Build succeeded on builder pr-android
Details
pr-deb-dbg-x64 Build succeeded on builder pr-deb-dbg-x64
Details
pr-deb-x64 Build succeeded on builder pr-deb-x64
Details
pr-freebsd-x64 Build succeeded on builder pr-freebsd-x64
Details
pr-ubu-x64 Build succeeded on builder pr-ubu-x64
Details
pr-win-dbg-x64 Build succeeded on builder pr-win-dbg-x64
Details
pr-win-x64 Build succeeded on builder pr-win-x64
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment