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).
This feature was originally exclusive to the previous iteration of
DolphinQt (the one that was the reason for the current iteration
being named DolphinQt2 initially).
https://bugs.dolphin-emu.org/issues/8949
Much of our native code assumes that UICommon::Init has been called
(for reasons such as wanting to access the user's settings),
so not calling it until emulation start heavily limits what native
code we can use in the Android GUI (except during emulation).
This new setting is like Override Language on NTSC Games, except
instead of only applying to the GameCube language setting,
it also applies to the Wii language setting.
Fixes https://bugs.dolphin-emu.org/issues/11299
This isn't as serious as copying global INIs into user game INIs,
but still not good. We want to be able to remove settings from
default game INIs and have those removals apply.
We can use std::array and const char* to make these capable of fully
being stored in the read-only segment, and get rid of a few static
constructors (144 of them).
Avoids dragging in IniFile, EXI device and SI device headers in this header which is
quite widely used throughout the codebase.
This also uncovered a few cases where indirect inclusions were being
relied upon, which this also fixes.
This allows us to update the rich presence description if a channel
is launched from the Wii Menu. It also handles other PPC title
launches, e.g. Smash Bros. Masterpieces.
Host.h: Added Host_TitleChanged().
DolphinNoGUI/MainNoGUI.cpp: Implemented Host_TitleChanged().
DolphinQt/Host.cpp: Implemented Host_TitleChanged().
Android/jni/MainAndroid.cpp: Stubbed Host_TitleChanged().
DSPTool/StubHost.cpp: Stubbed Host_TitleChanged().
UnitTests/StubHost.cpp: Stubbed Host_TitleChanged().
The difference between Dolphin's game IDs and GameTDB's game IDs
is that GameTDB uses four characters for non-disc titles, whereas
Dolphin uses six characters for all titles.
This fixes:
- TitleDatabase considering Datel discs to be NHL Hitz 2002
- Gecko code downloading not working for discs with IDs starting with P
- Cover downloading mixing up discs with channels (e.g. Mario Kart Wii
and Mario Kart Channel) and making extra HTTP requests. (Android was
actually doing a better job at this than DolphinQt!)
People in the Google Play reviews still seem to be confused about
games not showing up in the directory picker, so let's show them
even though they can't be selected. (Either that or they haven't
realized that they need to extract their pirated games.)
This sets the IR/Width, IR/Height, and IR/Center per game, so a controller profile is used
to save the value, then enable the profile in the game ini, then reload the
control configs.
Some of the recent reviews on Google Play express trouble finding the
emulation activity menu. One of them thought you were supposed to go
to the settings accessible through the main activity to configure the
virtual controller buttons.
This commit changes the text so that the user now explicitly is told to
swipe down from the top of the screen to access the menu. In exchange,
I removed the exact selections to make in the menu so that the text
wouldn't get too long, but I think it shouldn't be too hard to
understand once you know how to open the menu.
Delay the creation of the emulation fragment if: the device is a phone, if
emulation should be locked to landscape, and the current orientation is
portrait.
Forcing landscape at emulation start revealed a bug where if the activity was
recreated before emulation started then it would get stuck in a paused state
If emulation started in landscape then it wouldn't lock to landscape, thus
allowing a rotation to portrait then immediately back to landscape. Also
locking to landscape didn't need to be called from another thread, so that
was removed as well
Picasso is using an old version of the support lib which creates a conflict
for the exifinterface support librar, this will make sure to use the
version Dolphin is using which is 27.1.1
Previously would take several seconds to save, sometimes causing ANRs, which
was made worse when adding all the controller values. Now we only load/save
each section instead of doing it for each setting. Also added a method
to save an individual setting.
Android can be funky with controller vibration. Of the three controlers I have that contain a
vibrator(PS3, Xbox360, 2017 Shield controller), only the Xbox360 controller registered as having
a vibrator. So YYMV depending on the driver support of the device.
With the nature of android updates invalidating save states, it's best to hide
these options unless enabled by the user. The option to use savestates can now
be enabled via the General settings menu.
Two reasons for this change. First, it appears that some android launchers do some sort of call into
the application when long pressing the app icon, which in turn calls the DirectoryInit service. This
was ok to do prior to Oreo but will cause crashes with the new restrictions on services running
in the background. Which leads to the second reason that DirectoryInit doesn't need to be a service
at all since these actions are required for dolphin to function and shouldn't be a scheduled action.
So we instead just kick this off in a new thread and send the broadcast when done.
This global belongs in the JitOptions structure, as it's a conditional
setting (A.K.A. option) that changes the behavior of what the JIT does.
Plus it keeps the scope of the variable constrained to the general area
it's intended to be used and nothing further.
This requires buildbot changes: the path to the Android Studio
installation must be supplied in an environment variable.
Modified files are copied out to a temporary directory, Android Studio
is asked to format the files, and a git diff is performed.
There isn't an official Java style, but this seems to be consistent with
everything else. Also it's weird to see one one liners without braces in
Java.
I think the intention might have been to switch styles based on what
platform was selected, but that never happened. Instead, everything just
used the GC styles.
All the platform-specific styles did was add an accent color (which
tints the checkbox and text area elements). This adds a specific color for
that instead of abusing a platform color.
There should be no visual changes for this commit.
Added an option in General config to enable/disable usage statistics. Added a popup on first open if
the user would like to engage in reporting. Clicking cancel or out of the box opts out. Only
clicking 'Ok' will enable reporting. Also added a new android specific values to report.
If a user changes any config options before starting emulation then all SIDevices are set to 0.
This was added in PR 6267(commit 58ee9d2a78) to fix a bug.
This sets up default positions for touch buttons so they are not just bunched in the corner on a fresh install. Also added a toast when emulation starts on how to edit button layout
Per-Game settings now load the settings in this order
1. Emulator Settings
2. Default Settings of the Game that we ship with Dolphin
3. Custom game settings the user have
where the later always overides the former in case of collision, then
we show that on the UI to make it clear to the user which settings being
used.
Some of the write checks do an & on the result, returning 0 will allow these fails to be caught.
Updated the default WiimoteNew to set wiimotes 2-4 to be disabled on new install. No reason to have these
enabled unless there is actually a 2+ players
Apparently there was a different section names used by the custom game
settings that caused Android to have those settings broken for
some sections like the graphics one. This adds the map between the generic
settings <> custom settings.
1. Create Settings class the encaupslate the loading/saving of all settings
2. Decouple the logic of saving the settings into 3 different config files
from the UI code.
A little background: Android has 8 controller setup, 4 gamecube pads and 4 wiimote pads. When the static GCPadNew.ini and wiimotenew.ini is created, pads 0-3 are gc 1-4, and 4-7 are wii 1-4. Problem was the settings set wii controllers as pads 1-4, instead of 4-7. So any setting for wiimote1, was set for gc2(padID 1). Which is why the only wiimote to work was 4, since it mapped to padID 4, which is actually wiimote1.
Some controllers have axes that are stuck to values like 0.5 or 1.
Starting with PR #6123, when you press a control to map, Dolphin will
immediately think that such an axis is the axis that you want to map.
This commit fixes that issue (https://bugs.dolphin-emu.org/issues/10909)
Since we don't have proper confuguration file of what to include/exclude
in the backup, this better be disabled because it will lead to unexpected
state. This will solve any issue that was keep hapenning even after fresh
install of the emulator until you manually clear the app data.
Before we used different way of identifying which settings menu to
show, someotimes we used the section name, other times we used the
settings file name. This one replaces all those different ways by just
one way based on a menu tag which is more clear and easy to follow.
Makes the enum values strongly-typed and prevents the identifiers from
polluting the PowerPC namespace. This also cleans up the parameters of
some functions where we were accepting an ambiguous int type and
expecting the correct values to be passed in.
Now those parameters accept a PowerPC::CPUCore type only, making it
immediately obvious which values should be passed in. It also turns out
we were storing these core types into other structures as plain ints,
which have also been corrected.
As this type is used directly with the configuration code, we need to
provide our own overloaded insertion (<<) and extraction (>>) operators
in order to make it compatible with it. These are fairly trivial to
implement, so there's no issue here.
A minor adjustment to TryParse() was required, as our generic function
was doing the following:
N tmp = 0;
which is problematic, as custom types may not be able to have that
assignment performed (e.g. strongly-typed enums), so we change this to:
N tmp;
which is sufficient, as the value is attempted to be initialized
immediately under that statement.
Ryan Meredith