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

[WIP] Android: Native motion controls #8439

Open
wants to merge 5 commits into
base: master
from

Conversation

@JosJuice
Copy link
Contributor

JosJuice commented Oct 28, 2019

Accelerometer controls seem to work, but I haven't done a lot of testing yet. Left to do:

  • Figure out why the IR pointer is gone now
  • Adjust for phone orientation
  • Enable Sideways Wii Remote when using Horizontal Wii Remote
  • Disable IMU IR automatically when gyroscope or accelerometer is not present?
  • Add a setting for disabling IMU IR? (see PR #8440)
  • Add a setting for disabling motion controls entirely? Could be good for gamepad users
  • Add a setting for disabling screen rotation? Too easy to trigger when using motion controls
@JosJuice JosJuice changed the title Android: Native motion controls [WIP] Android: Native motion controls Oct 28, 2019
@JosJuice

This comment has been minimized.

Copy link
Contributor Author

JosJuice commented Oct 28, 2019

Seems like the buildbots don't run for PRs marked as drafts, so let's undraft this. Still a WIP, though.

@JosJuice JosJuice marked this pull request as ready for review Oct 28, 2019
@JosJuice JosJuice force-pushed the JosJuice:android-native-motion-controls branch from 3421cc1 to 995f73c Oct 28, 2019
@jordan-woyak

This comment has been minimized.

Copy link
Member

jordan-woyak commented Oct 28, 2019

FYI, Sideways/Upright Wii Remote should be already handled. The "IMU" data is transformed appropriately in WiimoteEmu.cpp. You should just have to make sure the Accel and Gyro data is oriented with the screen.

With the current way the IMU data is handled, users will need their phone still and level to use the "pointer". This might be annoying. We might need an option to not use IMU data for producing the transform for IR camera simulation.

@JosJuice

This comment has been minimized.

Copy link
Contributor Author

JosJuice commented Oct 28, 2019

FYI, Sideways/Upright Wii Remote should be already handled.

Yes. What I meant but probably wasn't super clear about was that I need to make it possible to change those settings on Android. They currently aren't accessible in the GUI.

With the current way the IMU data is handled, users will need their phone still and level to use the "pointer". This might be annoying. We might need an option to not use IMU data for producing the transform for IR camera simulation.

Yeah, a setting might be a good idea, so that you can control the IR using the touch screen without motion controls affecting anything. But I'm wondering, how still does it need to be? (Just trying to figure out if my problems with getting the cursor to show up at all could be related to this.) EDIT: This is now solved, and I have been able to test for myself how still it needs to be. It needing to be still isn't too awkward, but other aspects of how IR is handled are very awkward...

@JosJuice JosJuice force-pushed the JosJuice:android-native-motion-controls branch from 995f73c to 02117cb Oct 28, 2019
@rlnilsen

This comment has been minimized.

Copy link
Contributor

rlnilsen commented Oct 29, 2019

PR #8440 adds an "enable" checkbox for motion controlled cursor to Qt. Hope it can be useful to this PR.

@JosJuice JosJuice force-pushed the JosJuice:android-native-motion-controls branch 4 times, most recently from a0e91eb to cef7976 Oct 29, 2019
for (int i = 0; i < orientationValues.length; i++)
{
if (orientationValues[i] == initialChoice)
initialIndex = i;
}
Comment on lines +989 to +900

This comment has been minimized.

Copy link
@BhaaLseN

BhaaLseN Nov 4, 2019

Member

I'm surprised Java has no simple indexOf (or find or whatever) method for such a purpose.

The most concise one I could find (aside from a bazillion libraries) is

int initialIndex = java.util.Arrays.asList(orientationValues).indexOf(initialChoice);

Thoughts on switching to that (potentially with our own, bazillion-th-plus-one utility class)?

This comment has been minimized.

Copy link
@JosJuice

JosJuice Nov 4, 2019

Author Contributor

I was surprised too...

According to this Stack Overflow answer, I can't use your suggestion for arrays of ints, though I don't really understand why (something about int vs Integer?): https://stackoverflow.com/a/4962413

This comment has been minimized.

Copy link
@BhaaLseN

BhaaLseN Nov 4, 2019

Member

Sigh. Java.
But we could just hide that in a util class somewhere, can't we? I'm almost certain we have one of those somewhere already.
Or leave as-is, since I just don't know anymore...

This comment has been minimized.

Copy link
@JosJuice

JosJuice Nov 4, 2019

Author Contributor

We don't have a generic Java util class, just a util namespace that contains more specialized util classes (none of which this would fit into).

@JosJuice

This comment has been minimized.

Copy link
Contributor Author

JosJuice commented Nov 5, 2019

The orientation lock commit is somewhat hacky right now due to an existing hack (see the comments in the commit), but merging PR #8452 would get rid of that existing hack. EDIT: Now merged.

@JosJuice JosJuice force-pushed the JosJuice:android-native-motion-controls branch 3 times, most recently from c6831a8 to 1c53a64 Nov 5, 2019
JosJuice added 5 commits Oct 28, 2019
Not that this has much relation to the rest of the PR, but it's an
easy fix that we might as well throw in while we're already
overwriting everyone's WiimoteNew.ini.
Before, it only flipped the d-pad (and arranged the overlay buttons
differently).
When using motion controls, it's useful to be able to lock the screen
to a certain orientation so that Android won't interpret game motions
as an intent to change the screen orientation. To this end, I've
changed the existing orientation lock setting in the following ways:

- A portrait lock mode has been added in addition to the existing
  landscape lock mode and unlocked mode.
- The landscape lock mode now locks to regular landscape rather than
  letting you change between the two possible landscape orientations.
- The setting is now accessed during emulation rather than outside.
@JosJuice JosJuice force-pushed the JosJuice:android-native-motion-controls branch from 1c53a64 to adfb8d1 Nov 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
4 participants
You can’t perform that action at this time.