RInput, gyro emulation #3
Conversation
old discussionsThese pages contain old discussions about this patch that have been copied here
Commit organisation@_RachelB
The GC pad radius patch is in this PR because
If the patch is approved it can be
I don't object to this patch because the differences (see attachment) in this patch are few (but the removed changes might have introduced bugs)
Do you have reservations about the changes you have marked with *?
Then it's probably better to wait for a consensus on all changes, before splitting the patch into pieces.
Can you pick one? because there's multiple issues brought up and some are fixed.
The changes are split into separate commits
the m+ changes affect primarily one game, these changes affect me more.
What is unrelated?
I invite more opinions.
Same point as previous comment.
Same point as previous comment.
These changes match the commits in this branch.
Same point as previous comment.
Same point as previous comment.
What comments and parameters?
Same point as previous comment.
What things? @tommyhl2.SS
Told me what?
About what? @NeoBrainX
What should be in a separate commit?
What contributions?
Talking about what?
What's dumb?
Ask about what?
What deserves no attention? |
Adding stick radius settingProblemThe stick hardware max range is around 0,65 of the the max value according to
The optimal radius is directly outside SolutionAdding stick radius setting because
Adding visual aid for the hardware range because
The default value is
The radius is applies after the deadzone because
This should be added even when considering that the range setting for the axes allow a similar effect because
DiscussionReference
If there are no objections for one day I'll merge the stick radius, because your approval is adequate
There RefactorI want to change |
Fixing gyro emulationPatchThe commit in this branch with the same title as this post Discussion
This occur around 1/20 calibrations at the Zelda SS start screen The solution is
Rotation g-forceRed Steel 2 require accelerometer values that indicate g-forces in addition to gyro values to swing the sword Rotation fast mode yaw and pitch swing the sword Adding deceleration to forceA deceleration is added after acceleration to force because
Merge status@tommyhl2.SS
This comment approve the purpose of the patch Refactor"Tilt" should be changed to "rotate" because
"Force" (also called swing) should be changed to "thrust" because acceleration followed by deceleration is
This is the refactor string table |
Adding option to save input settings to ISO iniPatchThe commit in this branch with the same title as this post ProblemInput settings are sometimes different between games because the optimal settings for one game is different from that for another game Especially emulated Wii (compared to GC) input often use unique settings because the accelerometer and gyro input allow many input setting combinations It's slow to manually load game settings (through profiles) SolutionAdding an option to save input settings to the ISO ini because
FunctionWhen emulation is started input settings are read from the ISO ini (and the input dialogs are updated if they are open) When emulation is stopped the settings are restored to the the default settings During emulation the buttons "User Default"
read and write to
If the ISO ini lack input settings they are copied from the default input settings files the first time a game is booted ProfileThe profile ISO ini keys are changed from to because that's better organisations because that reduce string duplication because the strings GCPad1 and Wiimote1 exist The This is a description of the profile function in b8691df it read /Config/Dolphin.ini in e32b152 it read /GameConfig/ID.ini It doesn't write the section, it's added manually by the user This solution isn't altered because it doesn't conflict with the entries added in this patch, f.e. TestThe patch is tested with
Discussion
The following communcation is about an abandoned idea to only load non-set settings
Saving input settings to the isoini is made optional because the function has been challenged The loading of only non-set keys (rather than all as in the usual profile function) is removed in favor of wxNotebook drawing bugThe drawing bug described here is
Unhandled exceptionProblem
SolutionMoving LoadConfig to the Discussion
|
Changing the input dialog from modal to non-modalPatchThe commit in this branch with the same title as this post ProblemThe input configuration is modal This is a problem because
SolutionMaking the input dialogs non-modal because
Thread safe controller interfaceThe CI is made thread safe because it's possible to call ControllerInterface::Initialize twice simultaneously by opening the GC and Wii input dialog simultaneously Moving DInput HWND variableThe DInput HWND variable is moved because that's better organisation Discussion
|
Default DInput mouseProblemThe DInput axis (relative) mouse input is less accurate than cursor (absolute) mouse input because
SolutionChaging the default DInput mouse input from axis to cursor because it's more accurate This has an effect when CIFACE_USE_RINPUT is undefined so that both axis and cursor is present |
Fixing input dialog roundingPatchThe commit is in this branch with the same title as this post ProblemThe wrong value is sometimes saved because of rounding The is rounded to 116 when cast to int TestThis is tested with
The minimal code to produce the problem is SolutionRounding the non-exact float representation of and integer (f.e. 117) to an exact float representation before casting to int because
Alternative solutionwxSpinCtrl::GetValue it's rounded to 116 when cast to int Saving as this instead doesn't solve the problem because
Discussion
Because of this transformation (betweeen IniFile::Load and wxSpinCtrl::SetValue)
It's in
It's loaded at
No, PadSetting::value should have the type
SavingPatchThis problem isn't solved in this branch ProblemThe value is saved with limited precision, f.e. 117 is saved as this value in This is a problem because
|
Changing the device combo box text to read onlyPatchThe commit in this branch with the same title as this post ProblemThe profile combo box test is cleared when pressing "Save" which is a problem because
The device combo box text
SolutionFixing this by
|
Adding capture cursor functionPatchThe commit in this branch with the same title as this post ProblemWhen using a non-fullscreen window it's benefical to capture the cursor in the window SolutionAdding a capture cursor
Compatibility with a separate device per mouseThis patch is compatible with "Creating a separate device per mouse" in the sense that ClipCursor confine the system cursor regardless of which device control it X Window implementationThe HAVE_X11 code is referenced from
tested with It use XGrabPointer rather than
wxWidgetsThere isn't a wxWidgets function to confine the cursor
TestHolding the hotkey and running this in CFrame::CaptureCursor i.o.w. observing
Discussion
Yes because I don't know the Linux code for it Update: a X Window implementation is added
No
Do you mean this function exist in the Linux build? Where?
It's not meaningful to use XIGrabDevice instead of XGrabPointer even if there's a separate device per pointer because
Hotkey "Action, Key" headerProblemThe "Hotkey Configuration" dialog header line "Action, Key" is a problem because it's apparent
SolutionRemoving the "Hotkey Configuration" dialog header line because
wxWidgets' grab useThis information about wxWidgets' grab use can be of interest wx use grab in these functions Menu option
What do you mean with a menu equivalent?
Do you mean that capture mouse should be a menu option? That is only useful for capturing the cursor because when captured it can't be moved to the menu to release it
A menu item is added [15:30] @skid_au JPeterson, looks ok now
This is in opposition to skid_au's opinion Track grabbed state in X server rather than in clientSummaryTracking the grabbed state in the X server (with X11Utils::IsPointerGrabbed) has been opposed in favor of
because
However,
IsPointerGrabbed doesn't remove a grab
It's true that IsPointerGrabbed return true if a menu is open (because that grab the cursor for the menu with wxWindow::CaptureMouse because the menu should be closed if it lose focus) It's not true that this is a problem for the hotkey because
Yes it's true
It's true that a grab doesn't disable hotkeys, but an open menu or dialog does The implementation is thread safe
It's not possible for
It's true that another process can grab or ungrab between IsPointerGrabbed and XGrabPointer It's true that "Capture Cursor" release the existing pointer grab and confine the cursor to the window in this scenario This isn't a problem because the user probably expected the cursor to be confined to the window when this occurs the user is unlikely to intentionally request another program to queue a grab in that time because it's short (around 3 ms according to a log message at the start and end of CFrame::CaptureCursor) the result from possible scenarios aren't important problems f.e. the scenario
the opposite scenario
isn't a problem because
The alternative of tracking the pointer grab state in a variable (called f.e. CFrame::m_bPointerGrabbed) doesn't handle this better because
f.e. in the scenario
which isn't a problem because
and
which is a problem because
This isn't true because
XGrabServer isn't an appropriate solution
XGrabServer isn't used because
wxWidgets doesn't track all its grabs
It's true that wx doesn't run XGrabPointer to test if there's a grab, but it's not true that it track a grab in a variable F.e.
It's more reliable than the alternative
It's better to retrieve this information from the X server because
No this doesn't result in a problem with this patch because when CaptureCursor is called it will grab the cursor again as the user expect (because it's ungrabbed) because
It's good organisationIt's better organisation to track the GUI state in the GUI library than in the GUI client
With GUI library I mean the X server function IsPointerGrabbed call Automatic capture
"Capture Cursor" doesn't consider input configuration because
Despite an automatic pointer grab there's a use for a hotkey because
|
Delay ControllerInterface and InputConfigDiag changesProblemThe problem is
SolutionDelay refactoringA solution is
Merge this branchA solution is
Your approval of patches in this branch has value because
commit of the patches has value becuse
Commit unmodified commit or branchHowever
Discussion
The reason the ControllerInterface change in input@john-peterson isn't merged is because it isn't approved
I want you to
That's wrong because
StatusSince 2011-11 around 30 hours have been used to resolve merge conflicts when rebasing this branch with master There are changes to ControllerInterface and InputConfigDiag that create a merge conflict with this branch in They will take 1 - 10 hours to resolve |
Adding a device per mouseCommitIn this branch with the same title as this post Commit messagebecause
ProblemMultiple mice can't be used because they're combined in one (DInput) device Multiple mouse input is useful in multi player games that use IR input SolutionCreating a separate device per mouse because
Backend selectionThe Windows mouse backend is RInput because
System mouseThe system mouse is enabled because
DInput conflictCIFACE_USE_RINPUT disable the DInput mouse axis (the cursor is not disabled) because
|
Adding technical name for ISO regionDiscussion
Write the filename and row of where it should be moved because it's not clear Do you mean GetRegion should be in IVolume (in Volume.h) instead of SCoreStartupParameter? [01:01] @Matt_P if those were your requirements As the interpretation described in my question [01:02] @Matt_P where is GetCountry currently ? In IVolume |
because a build test is useful
Adding gyro controlsIR and gyro synchronisationIR isn't synchronised with gyro because of these problems with doing so Horizontal cursorProblemThe Zelda SS horizontal cursor is stuck when IR is visible SolutionHiding IR for < -0,25 and > 0,25 when gyro input is active reduce this problem but
Pitch implied from IRProblemThe Zelda SS vertical cursor is stuck without gyro input which is a problem if mouse input isn't bound to gyro input SolutionApply accelerometer pitch when IR isn't centered Problem
Fast modeThe fast gyro mode control is manual rather than
because
SettingsThe accelerometer and gyro range is separate because it should sometimes be different IR"IR → IR Sensitivity" adjust
"IR → Hide" return 0 from GetState
The cursor works well if IR is hidden, i.o.w. "Hide IR" should be bound to a key because it allow efficient cursor movement This is described in the issue Gyro emulation Toggle keys for binary settings
Yes Name"IR Range" and "Gyro Range" use the word range instead of sensitivity despite
because
Names for numbers
Names are added for numbers in
Describe why this should
|
Changing extension during WM_SPEAKER_DATAProblemDisconnecting the Nunchuk during
leave the Wiimote in a permanently unconnectable state with the output SettingsThis occur with because otherwise there aren't any WM_WRITE_SPEAKER_DATA regardless of the code that change |
because that information sometimes not meaningful
because * color makes it faster to identify elements of a log message
because color can indicate type of message
because it doesn't have meaning
because it's sometimes useful to copy sections between files
because it describe the technical difference between ISO regions more directly than the region name
because it's useful for cursor input
because it's not meaningful to change it
because that remove empty space
because that allow adjusting the force
because to test settings during emulation it's useful to have it open without blocking the main window
because that automate saving and loading ISO adjusted input settings
because * that allow using the mice for different controllers
because * it's sometimes more efficient to use an emulated rather than real gyro
because it's expected by some programs
because that's expected by some programs
* range setting for tilt and force * fast gyro toggle * IR toggle option because it's useful with gyro input * toggle keys for binary settings
gyro emulation
files
https://www.dropbox.com/sh/rrd5iy2jivzrapq/AACMW-TeC1D5VE17u42PZIsFa?dl=0 contain
input_*.zip: builds of input@john-peterson
test/user/Config/Profiles/Wiimot: Zelda SS gyro input profiles in "Zelda SS*.ini"
Pics/m+: pictures
gyro log
the gyro log output
emulated input
gyroscope and accelerometer input
https://github.com/john-peterson/dolphin-emu/blob/input/Source/Core/Core/Src/HW/WiimoteEmu/WiimoteEmu.cpp
in the input settings
"swing" is a force in the X, Y, Z directions that affect the accelerometer
"tilt" is a force in the pitch, roll, yaw directions that affect the accelerometer and gyro
Settings
Axis mouse input
Relative mouse input (called "Axis" in the mouse input configuration) should be used because that allow mouse movement input regardless of where the system cursor is compared to absolute input (called "Cursor" in the input configuration) who's input won't change when the cursor is at the screen edge
Range
Range, Gyro Range and Acc Range multiply the output by 0.01 x to 10 x (by setting its range 1 to 1000). The fast modifier activates the gyro fast mode for all three rotation directions, the fast and slow mode is explained here
gyro settle
https://github.com/john-peterson/dolphin-emu/blob/input/Source/Core/InputCommon/Src/ControllerEmu.h#L491
gyro settle determine after how many frames the gyro will return to zero after the wiimote stop moving (the wiimote is constant but not necessarily nonzero)
a high setting, for example 9999, will keep the gyro in constant motion if input is nonzero
Mouse and keyboard
Gyro Sensitivity: 200 works with a standard sensitivity mouse
IR sensitivity: 20 to move the vertical accelerometer position relatively slowly.
Gamepad
Gyro Range: 0.1 provide smooth aiming and a smooth cursor, the range modifier is set at 1000 (10x)
If the Gyro Range is 0.2 the Range modifier should be 500 (5x) to reach 1.0 with max input
Zelda SS
Moves
Swing sword left/right: yaw left/right
Swing sword up/down: pitch up/down
Stab attack: thrust forward + show IR
Spin attack left/right: yaw left/right + nunchuk thrust in any direction
Land/water spin attack up/down: pitch up/down + nunchuk thrust in any direction (or wiimote thrust forward/backward + nunchuk thrust in any direction)
Skyward charge: pitch accelerometer back (gyro range must be lowered enough that it doesn't trigger a swing)
Fatal blow: lock on enemy + wiimote thrust forward + nunchuk thrust forward
Shield: nunchuk thrust in any direction
Roll: dash and nunchuk thrust in any direction
Leap on vine: Nunchuk stick left/right + tilt fast left/right
Balance on the tightrope: Strong yaw input (slow 0.5+ or fast 0.1+)
Key binding
Have the Gyro Range low by default, for example 0.1, to control the cursor and view, and assign a 10 x (range 1000) Gyro Range modifier to a gamepad trigger (or keyboard button or analog stick button) and hold it to perform fast moves; slash sword, leap on vines, swing on rope, shake rope etc.
On the gamepad, bind roll and yaw to the same axis, roll and yaw is used independently in rare occasions only (the boss key for example) so it doesn't hurt, and lets you control the bird or the beetle that use roll.
Use the
| ORoption with the modifier keys and moves that require multiple input. For example assigningA|Bto yaw left and B to Nunchuk thrust makes A yaw left and B do the spin attack."Hide IR" should be enabled (and Thrust forward and B should be bound to IR→ Show) because IR restrict horizojntal cursor movement and doesn't have rotation use besides resetting the gyro rotation matrix forward direction
FAQ
Q: Why's the aiming or cursor sensitive
A: Lower the sensitivity setting
Q: Why's the aiming or cursor jumpy
A: Disable Tilt accelerometer input with "Acc. Range"
Q: The cursor is locked along the horizontal axis
A: It's because the cursor can't go to the edge of the screen if IR is visible, turning off IR solve that. Without IR data, 45° yaw move the cursor from one edge of the screen to the other, if additional yaw is applied to cursor move along the screen border
Q: The cursor drift vertically to the center (doesn't affect aiming mode)
A: Too little accelerometer pitch is applied because the IR pointer position is not at the end of the screen, possibly because of too low IR sensitivity, the IR implied pitch code is here, as the IR is pointing at the end of the screen (mouse input -1 or 1) the pitch is pi/4 rad (45°).
Q: Why is the item selection cursor difficult to control?
A: Bind "Thumb R" or B to "Gyro Range 1" that's set to 1000 (10× multiplier) so that adequate gyro range is applied when selecting item. Because the item selection cursor work the same way as the map cursor so that good IR position data control it. Without IR data a 360° degree pitch rotate the cursor past the whole item circle. In the example gamepad configuration and bound to
Q: Why's the Bird, the Beetle and Swimming hard to control? Sometimes the unit moves sideways on its own.
A: Showing IR (that you may have set to the stab attack key) makes these controls easier, just showing IR for for a moment (at the center of the screen position) will reset the gyro rotation matrix so that the unit swim or fly straight again. To gain altitude with the Bird repeatedly dive and immediately call the Bird.
Q: Why is it hard to rotate the sword to enable the Skyview Temple Eye Switch?
A: A perfect circle can be created without IR data but IR data is important to reset the gyro rotation matrix forward direction
Q: How do I reset the sword neutral position (gyro rotation matrix)?
A: Show IR for a moment
Q: How do I pull the Goddess Sword out of the stone in the Goddess Statue?
A. Tilt 90° (full tilt input at 100 acc. range) downward and thrust backward
Red Steel 2
Moves
Swing sword left/right: yaw left/right
Swing sword up/down: pitch up/down