The only place where initTouchPointer was called automatically
was Host_RequestRenderWindowSize, which is called at least once
after emulation start, but not after activity recreation.
I was hoping we would be able to pull in the default values
from C++, but it seems like more trouble than it's worth,
partially because of different settings having default values
of different types and partially because we don't have any
convenient way to get a list of all C++ settings.
Except controller settings, because those would be annoying
to fit into the same system, and I only need the non-controller
settings to be brought over for the next commits to work.
...instead of waiting for it after launching EmulationActivity.
We need this because there is code that runs very early in
EmulationActivity that accesses the settings.
Android TV devices aren't the only devices without touchscreens.
Regarding MotionAlertDialog, I could've replaced the leanback
check with a touchscreen check instead of just removing it,
but I thought there was no reason to prevent people with
touchscreens from doing a long back press if they want to.
https://bugs.dolphin-emu.org/issues/12029
We currently have one way of opening the menu on touch screen
devices (swiping down from the top of the screen to bring up the
action bar and selecting the menu in the action bar), and another
way of opening the menu on Android TV (pressing Back). However,
some devices that claim to support touch (or don't support
leanback? Dolphin currently conflates the two) don't actually let
you swipe down from the top of the screen in the way that Dolphin
expects, notably Chromebooks. There are also some phones where you
can swipe down from the top of the screen but this for some reason
doesn't lead to the action bar becoming visible, though we are
getting less reports about this nowadays than in the past.
This change makes us use the Back method on all devices,
since it should work on all devices with no significant drawbacks.
Unfortunately, we not only have two different ways of triggering
the menu but actually two entirely different menus, with the
non-touch menu not implementing options that only are revelant
when using a touch screen. A later commit will add the missing
features to the menu that we now use on all devices.
The reason why the finish() call was added no longer exists.
(Also, there was never a duplicate SettingsActivity as far as
I can tell, only a duplicate SettingsFragment.)
Just for maintainability. This is a shorter and more standard
solution compared to our current one where the Fragment
persists the Settings and passes it to the Activity.
That a device doesn't have a touchscreen doesn't necessarily mean
that it doesn't support rumble (though it is usually the case).
setPhoneVibrator already contains a check for whether the device
supports rumble, so we can simply remove the touchscreen check.
Since updating to 28 took us so long that Google Play started
requiring updates to target 28 before we actually merged the PR that
made us target 28, I'm trying to get the update to 29 done early.
Setting targetSdkVersion to 28 would normally force scoped storage
on us, which we do not support yet. However, we can easily
avoid this by setting android:requestLegacyExternalStorage="true".
There will be no such luxury with targetSdkVersion 30, however...
The functions with "UTF" in the name use "modified UTF-8" rather
than the standard UTF-8 which Dolphin uses, at least according
to Oracle's documentation, so it is incorrect for us to use them.
This change fixes the problem by converting between UTF-8 and
UTF-16 manually instead of letting JNI do it for us.
This essentially reverts d9c78d5. Thanks to the previous commit,
the touch controls issue which was fixed by d9c78d5 is still fixed.
The behavior for gamepads is reverted, bringing back the ability
to run diagonally in games that had trouble with it after d9c78d5.
Currently, the touch controller overlay uses a square gate for
sticks. This commit changes that so that it instead uses the
stick gate configured in the INI, which ensures that the values
sent to the core are appropriately scaled regardless of what
is configured in the INI and makes the overlay look nicer
if the INI is set to a stick gate that matches the graphics.
While having motion control emulation of IR enabled by default
makes sense in situations like using a DualShock 4 on a PC,
Android has the additional option of touch emulation of IR
which seems to be better liked, and the default value which
was chosen with PC in mind was carried over to Android
without any particular consideration. This change disables
motion control emulation of IR by default on Android only.
Also fixes the same crash when accessing the game details
(which only can be accessed after long pressing a game).
The problem was that we were not using a theme that had
an AppCompat theme as a parent.
Unfortunately, the game details dialog uses white on white on
Android TV, and I don't know how to fix this in a clean way.
This fixes a crash on ATV devices, because the the AlertDialog is
from the appcompat class, but the theme derived from the parent
view on ATV devices isn't from AppCompat.
This changes channel syncing to happen when the operating system is
Android TV rather than when TvMainActivity is launched. (You can run
TvMainActivity on a phone by specifying a launch activity manually
in Android Studio, which I do sometimes for testing purposes. Without
this change, you get an exception when channel syncing runs.)
Currently, we do not display every second frame in 25fps/30fps games
which run to vsync. This improves performance as there's less rendering
for the GPU to perform, but when combined with vsync, could cause frame
pacing issues.
This commit adds an option to force every frame generated by the console
to be displayed to the host, which may improve pacing for these games.
Fixes https://bugs.dolphin-emu.org/issues/11911 and makes the range of
values when using touch controls correct. Also affects the range of
values for physical controllers in a way that may or may not be
desirable, depending on the controller model. (If there are
undesirable effects, they would be that the range of inputs is too
small, especially diagonally.) Such is our messy Android input system.
Should be an improvement on the whole for physical controllers, though.
We must set Java_GCAdapter.manager before the GC adapter thread (C++)
starts. We used to set it at emulation start, which was fine until
9f3f45a made the GC adapter thread start much earlier.
JosJuice