We want to save the currently selected platform tab,
but doing so immediately after switching tabs leads to
unnecessarily much file I/O (on the main thread, no less).
This change makes us defer the saving until later.
In master, the game scanning process looks like this:
1. Scan for games
2. Scan for additional metadata (icon.png and meta.xml)
3. Save the cache if needed
4. Update the game list with the results
This change makes the game scanning process look like this:
1. Scan for games
2. Update the game list with the results
3. Scan for additional metadata (icon.png and meta.xml)
4. Update the game list with the results
5. Save the cache if needed
Updating the game list as soon as possible means the user
has to wait less before their games show up. The new behavior
matches what DolphinWX did before it was removed. (DolphinQt
has an even fancier approach where games get added one by one.)
The main reason why I'm adding this isn't actually to allow
users to swipe down to refresh, it's to add a loading indicator.
Considering that the Storage Access Framework can be slow for
folders with many items (many subfolders?), not showing a
loading indicator might give users the impression that adding
a folder resulted in nothing happening even though Dolphin is
scanning for games in the background. But I suppose letting
users swipe down to refresh is a nice bonus with the change.
EmulationActivity has an instance of Settings. If you go to
SettingsActivity from EmulationActivity and change some settings,
the changes get saved to disk, but EmulationActivity's Settings
instance still contains the old settings in its map of all
settings (assuming the EmulationActivity was not killed by the
system to save memory). Then, once you're done playing your
game and exit EmulationActivity, EmulationActivity calls
Settings.saveSettings. This call to saveSettings first overwrites
the entire INI file with its map of all settings (which is
outdated) in order to save any legacy settings that have changed
(which they haven't, since the GUI doesn't let you change legacy
settings while a game is running). Then, it asks the new config
system to write the most up-to-date values available for non-legacy
settings, which should make all the settings be up-to-date again.
The problem here is that the new config system would skip writing
to disk if no settings changes had been made since the last time
we asked it to write to disk (i.e. since SettingsActivity exited).
NB: Calling Settings.loadSettings in EmulationActivity.onResume
is not a working solution. I assume this is because
SettingsActivity saves its settings in onStop and not onPause.
Added Opacity controls for the user to customize the opacity of their touchscreen controls. Also, placed both Scale and Opacity settings into one window/option called Adjust Controls.
In 8c723d0, I intended to update the main activity, emulation
activity and game properties dialog, but I forgot to actually
update the game properties dialog. This commit fixes that.
The changes outside of GamePropertiesDialog.java are just
to hide the Wii controller settings for GameCube games.
Basically, instead of having one button for config, one button
for graphics settings and so on, we now have just one settings
button which takes you to a screen where you pick between
config/graphics/GameCube controllers/Wii Remotes.
The main reason I want to do this is because people still have
trouble finding Overlay Controls in the "new" in-game menu.
Typically (depending on the screen size and the length of the
game name), the scrollable part of the menu can fit 4 items,
and merging Config and Graphics Settings into one item would
move Overlay Controls from 5th place to 4th place (assuming the
user doesn't have savestates enabled), which makes it findable
even for users who don't realize the menu can be scrolled.
The dialog that's shown when long pressing a game in the game
list is also shortened. While not a pressing matter, I think
it was getting a bit long.
An additional reason to do this is because we probably will
want to make it possible to edit the controller settings
from the in-game menu at some point in the future. With the
old approach, this would require us to dedicate a whopping 4
menu items just for settings (not including Overlay Controls),
which I think is excessive.
I moved it from the main settings screen to the in-game menu
in PR 8439 so that it could be changed while a game is running,
but now that the main settings can be accessed while a game is
running, there's no reason to not put it in the main settings.
https://bugs.dolphin-emu.org/issues/12067
This is already handled by SurfaceDestroyed. In the worst case,
the extra code could even race with SurfaceDestroyed if they
are triggered at the same time, but this is highly improbable.
Time for yet another new iteration of working around the
"surface destruction during boot" problem...
This time, the strategy is to use a mutex in MainAndroid.cpp.
This assumption is false both in portrait mode (where it only
covers the top half of the screen) and when using two apps at once.
Fixes https://bugs.dolphin-emu.org/issues/12307.
This was removed in cc5802b when it should have
been converted to the new setting instead,
and it seems like I didn't notice when reviewing it.
I'm changing the DirectoryInitialization logic a little
so that clearWiimoteNewIniLinkedPreferences also is called
when there was no WiimoteNew.ini previously, in case the
user deleted WiimoteNew.ini but not Dolphin.ini.
We generally have no reason to call these functions on our own, so
there's not much reason to declare them, especially not in the cpp
file where they're defined. In case we ever do get a reason to do
it, we can add declarations for just the functions that need them.
In case someone wants to be very careful with how much bandwidth
they use or with what data GameTDB.com collects on you.
This is already an option in DolphinQt (though in DolphinQt it
will switch entirely from using covers to banners when turned off).
It would be difficult to use the AlertMessage class for
messages that need to be showed outside of emulation,
but showing them as toasts is better than not showing them.
During emulation, when LocalGame has a value but CurrentRun
doesn't, we want to read from LocalGame, not CurrentRun. This
change exposes a LAYER_ACTIVE option that handles this correctly.
This is part of my efforts to add support for scoped storage.
I figured I would start with a relatively simple feature to
make sure that everyone is fine with the approach I'm taking
before I tackle more complicated features like the game list.
The main activity loads settings essentially as soon as it
starts, in order to determine which tab to show. If the process
of stopping emulation has not finished at this point, a race
condition may be triggered where two IOS kernels are created
at once due to the emulation thread loading or saving the
SYSCONF while the GUI thread is loading the SYSCONF. To fix
this, we can wait for emulation to fully end before returning.
Because this race condition is hard to reproduce, I have not
been able to test that this actually fixes the race condition,
or even that the cause of the race condition is exactly what I
believe it is. But I am relatively confident.
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.
Because trying to fit a 3:1 banner into a circle looks very awkward.
Also move the banner below the title/description now that it
takes up more space horizontally.
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.
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.
This will help to disable all inter-instruction dependencies.
So android users can check if only a single instruction is broken without compiling dolphin on their own.
The workaround was added in 0446a58.
The underlying problem is that we must not destroy the surface
while the video backend is initializing, otherwise the video
backend may reference nullptr.
I've also cleaned up the logic for when to destroy the surface.
Note that the comment in EmulationFragment.java about only being
able to destroy the surface when emulation is running is not true
anymore (due to de632fc, it seems like).