You will see an empty gc pad settings screen until you open any other
settings screen and change something, at that moment the Dolphin.ini will
be created and the gc pad settings will be loaded successfully the next
time you open the screen.
This fixes the bug by putting the default gc pad settings section even if
the Dolphin.ini file doesn't exist
This solves the following issues:
1. If user uninstall Dolphin and install it again the resources will
not be copied unless the user manually clear the app cache because we
are enabling the allowBackup flag in the manifest which will make the app
restore the settings saved in the shared prefernces including the flag
assetsCopied. This PR always copy the files everytime you open Dolphin.
2. If the AssetCopyService took long time and you tried to open the settings
screen or start a game the behaviour was not expected or the emulator will
crash, this PR make sure that whatever we add to the DirectoryInitializationService
or how long it will take will still work as expected by blocking both
the settings screen and the emulaion screen to wait untill all resources
needed are copied.
3. Better communication between the DirectoryInitializationService and the
UI screens using brocast messages.
This only works if GCPadNew.ini and Dolphin.ini files are not already in the dolphin config folder. Any advice would be helpful. I'd really like to tackle the UI and wiring for deadzones, radius, etc.
This has no effect now, as we've never bumped the database version.
Instead, it adds future proofing, and makes moving between a future
version with a bump and master clean.
Now that all inputs are corrected to zero-centered, we can use getFlat()
to ignore movements that are just noise.
This eliminates a lot of drift when the controller is at rest, notably
on the character select screen in Melee.
Android reports the same physical axis multiple times for analog
triggers, and this handles this case.
There are also some controllers with broken mappings (eg the analog
triggers on a PS4 DualShock 4). These axis don't center correctly.
There are also some controllers (again, the PS4) that send both a button
press and an axis movement. This ignores the buttons so we can use the
analog axis. Otherwise, since the button comes before the axis moves
far we would always take the button.
This reverts commit 1fc910b3ea,
replacing the old INI setting EFBScale with a new INI setting
called InternalResolution, which has a simpler mapping:
| EFBScale | InternalResolution
----------------- | -------------------- | --------------------
Auto (fractional) | 0 |
Auto (integral) | 1 | 0
1x | 2 | 1
1.5x | 3 |
2x | 4 | 2
2.5x | 5 |
3x | 6 | 3
4x | 7 | 4
5x | 8 | 5
6x | 9 | 6
All the fractional IRs were removed in f090a943.
Emulation needs to be running when the surface is destroyed, but we want
to pause in onStop. So call the surfaceDestroyed callback, as this
accomplished both.
The source Views don't need the transition name. We could get the name
from the sharedView via getTransitionName, but since the TV
ImageCardView isn't inflated in XML it would be to be manually set.
I'm not sure if that would be any cleaner than this.
called.
The user will get a brief system popup tutorial the first time it's
used, so we don't need to show them the menu every time. Once they
enable it by pulling down, hide again after 3s.
Move the parameter extraction earlier on in onCreate. Mostly this moves
setting sIsGameCubeGame to before setContentView, which means
EmulationFragment will always see it in a consistent state. Previously,
there was a race, which mean the controller overlay would randomly be
Wii controls for a GameCube game (since the default is false).
Use the correct support version of things, ActivityOptionsCompat and
transitions
Rename static var mIsGameCubeGame to sIsGameCubeGame. s is static, m is
member.
Make the MenuFragment added and removed by fragment transactions only,
instead of being initially present in the XML. This fixes a glitch where
it doesn't animate correctly the first time it's used.
The Activity is responsible for just its views and menus and such. It
signals the Fragment via setGamePath, StartEmulation and StopEmulation.
The Fragment manages the actual emulation lifecycle. It is solely
responsible for calling the NativeLibrary lifecycle methods.
With this lifecycle simplification, the NativeLibrary no longer needs to
kill the Activity. It happens normally now.
This simplifies a lot of things, live handling rotation.
Without this View, the emulation SurfaceView acts like it has the
highest Z-value, blocking any other View. This includes the menu
fragments and the screenshot ImageView.
This makes it clear that the Activity is being cleared and removes null as
a valid param. This improves readability (and logging slightly).
Fix spacing between [Tag] and message. This matches the rest of the log
messages.
In the support lib, the code comes from the SDK, not the device like the
framework version. This means we're shipping a more recent and less buggy
version.
It's also a good idea to keep the entire project on one version. We have a bit
of a mix now. I think some of the Fragment animation issues were because of
this mixing.
For the leanback activities, AppCompatActivity requires AppCompat themes, which
they don't ship for Theme.Leanback. So use FragmentActivity instead (that's the
parent of AppCompatActivity, but still in the support library). For passed
around Activities, use FragmentActivity to work with both.
Bump the support lib version to 26. This allows for using property
animators (R.animator) in FragmentTransaction.setCustomAnimations.
Add the google maven repo, as from support lib 26 onwards, they're only
publishing it in there.
Bump the gradle version while we're at it, keep Android Studio quiet.
Other than what action they send back to
EmulationActivity.handleMenuAction(), they are the same.
Change the menu-handling logic in EmulationActivity to keep track of a
boolean for whether the submenu is visible, rather than keeping the
fragment tag. There's only one fragment visible, so this makes more
sense.
Prefixing everything with a constant packagename is not needed for
internal keys, and just adds complexity.
Rename ARGUMENT_ prefix to ARG_ to match (most) of the rest of the
codebase.
Restrict visiblity of above as much as possible.
FRAGMENT_ID wasn't actually the fragment's ID (that's misleading, and
sounds like the tag). It's actually the layout resource ID. There's no point in making that a static constant.
Ideally Common.h wouldn't be a header in the Common library, and instead be renamed to something else, like PlatformCompatibility.h or something, but even then, there's still some things in the header that don't really fall under that label
This moves the version strings out to their own version header that doesn't dump a bunch of other unrelated things into scope, like what Common.h was doing.
This also places them into the Common namespace, as opposed to letting them sit in the global namespace.
If a SettingsFile had at least one section, it was assumed all sections
were correctly filled out. This caused crashes when opening the settings
menus if that was not the case - for example the GFX.ini settings empty
sections are removed by the main dolphin app, putting the .ini file in a
state that would crash the settings window if at least one setting was
changed in it from the default, some sections were left as default.
This adds a subclass of HashMap<String, SettingSection> that constructs a
new SettingSection instead of returning 'null' if the key isn't found,
so the mSettings.get(FILE).get(SECTION).get(SETTING) pattern can be
safely used.
It would fail on lines line "Value =" - IE a value set to emptystring.
This would cause the app to crash when trying to open the corresponding
settings window.
I don't know who thought it would be a good idea to put the Wiimote
connect code as part of the Host interface, and have that called
from both the UI code and the core. And then hack around it by having
"force connect" events whenever Host_ConnectWiimote is called
from the core...
Showing the Wii remote connection status leads to inconsistent UX,
because we don't do anything like that for GameCube controllers
or with Bluetooth passthrough.
It's also questionable how useful it is given that:
* it doesn't print the number of connected remotes, just that one
remote is connected, connecting or not connected, so the only info
it provides is actually wrong when using multiple remotes;
* this user-facing feature is actually broken in master and no one has
complained AFAIK, which means people don't really rely on it;
* the status bar isn't visible most of the time unless the user is
using render to main or deliberately keeping the main window's
status bar visible by moving the render window and they're not too
far away from their screen;
* emulated Wii remotes now reconnect on input, which means that there
is less of a need to actually know at all times whether a remote
is connected, since pressing any button will reconnect it and provide
immediate, visible feedback via OSD messages and the Wii remote
pointer appearing.
* Move out boot parameters to a separate struct, which is not part
of SConfig/ConfigManager because there is no reason for it to
be there.
* Move out file name parsing and constructing the appropriate params
from paths to a separate function that does that, and only that.
* For every different boot type we support, add a proper struct with
only the required parameters, with descriptive names and use
std::variant to only store what we need.
* Clean up the bHLE_BS2 stuff which made no sense sometimes. Now
instead of using bHLE_BS2 for two different things, both for storing
the user config setting and as a runtime boot parameter,
we simply replace the Disc boot params with BootParameters::IPL.
* Const correctness so it's clear what can or cannot update the config.
* Drop unused parameters and unneeded checks.
* Make a few checks a lot more concise. (Looking at you, extension
checks for disc images.)
* Remove a mildly terrible workaround where we needed to pass an empty
string in order to boot the GC IPL without any game inserted.
(Not required anymore thanks to std::variant and std::optional.)
The motivation for this are multiple: cleaning up and being able to add
support for booting an installed NAND title. Without this change, it'd
be pretty much impossible to implement that.
Also, using std::visit with std::variant makes the compiler do
additional type checks: now we're guaranteed that the boot code will
handle all boot types and no invalid boot type will be possible.
This file is pretty small now that it doesn't handle Wii
partitions anymore, so let's move its contents to Volume.cpp.
This is also more consistent with how blob creation works.
Since these button names are printed on all real controllers,
we should show them in the same way as they are printed on
the controllers, regardless of the user's language. It seems
like this was intended all along (except for "Start"), but the
_ markers in TASInputDlg.cpp (accidentally?) led to the button
names in the controller configs also becoming translatable.
I'm making exceptions for "L" and "R" because translators
may want to mark them in some way (for instance "L-Digital")
to clarify the difference from "L-Analog" and "R-Analog".
I'm also making an exception for START/PAUSE because it's
referred to as スタート in Japanese games.
I'm changing "Home" and "Start" to uppercase for consistency
with how Nintendo refers to those buttons, and because someone
who isn't familiar with the Latin script might not know the
connection between the lowercase and uppercase letters (most
users likely do know the connection, but we shouldn't assume it),
and because leaving "Start" as "Start" makes it "collide" with
unrelated strings, such as the string for the button that starts
a netplay session.
To rename "Start" and "Home" without breaking INI
compatibility, I added a ui_name variable like in f5c82ad.
Whenever the EmulationActivity crashes and the app gets back to the
TvMainActivity, dolphin will crash tring to restor the mBrowseFragment
since we don't save the adapter data in the bundle.
This is quick hack to avoid the crash. The proper fix would be to save the
adapter data in the bundle and restore it before restoring the fragment
when the activity gets recreated.
Crash Stacktrace:
Process: org.dolphinemu.dolphinemu.debug, PID: 30353
java.lang.RuntimeException: Unable to start activity ComponentInfo{org.dolphinemu.dolphinemu.debug/org.dolphinemu.dolphinemu.ui.main.TvMainActivity}: java.lang.IllegalArgumentException: Invalid position 1 requested
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2691)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2752)
at android.app.ActivityThread.-wrap12(ActivityThread.java)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1461)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6120)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)
Caused by: java.lang.IllegalArgumentException: Invalid position 1 requested
at android.support.v17.leanback.app.BrowseFragment.createMainFragment(BrowseFragment.java:509)
at android.support.v17.leanback.app.BrowseFragment.replaceMainFragment(BrowseFragment.java:1454)
at android.support.v17.leanback.app.BrowseFragment.setAdapter(BrowseFragment.java:764)
at org.dolphinemu.dolphinemu.ui.main.TvMainActivity.buildRowsAdapter(TvMainActivity.java:183)
at org.dolphinemu.dolphinemu.ui.main.TvMainActivity.onCreate(TvMainActivity.java:59)
at android.app.Activity.performCreate(Activity.java:6664)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1118)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2644)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2752)
at android.app.ActivityThread.-wrap12(ActivityThread.java)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1461)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6120)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)
Use Bitmap.setPixels() instead of Bitmap.copyPixelsFromBuffer() the former
use non pre-multiplied values of the colors which is what we expect to
come from the native code.
We can do this now that the x86-64 JIT supports PIE.
JITIL is deliberately excluded from the GUI because it
doesn't support PIE yet. (JITIL will be used if it's
set in the INI, though.)
Apparently the path was changed from using "/thump.png" to using
"/gameId-#.png". We will always use the first screenshot for the game
broswer wich will be "/gameId-1.png"
Saving screenshot was not working due to 2 problems. The first one is that
the view id of the save screenshot in the Android TV fragment doesnt match
the one declared inside the menu_emulation. Second Problem will be fixed
in another commit.
This commit chnage the code to not depend on reusing the ids of the menu
everywhere in the emulator inorder for the onMenuItemClicked to work.
Instead you need to call EmulationActivity.handleMenuAction passing
the action to handle regardless of the ids you are using in the view.
Compilers are very picky and don't use PCH when they have been compiled
with different flags. I even got some ICE in MSVC, so removing them for now.
Modules are the solution.
Load all the inis at once, choose which one to write to, and save them all
at the same time. This allows us to modify settings from different files
on the same settings page.
The usage of "Wii Remote" and "Wiimote" in the interface is inconsistent. "Wiimote" is also not a real word nor is it an official product name. Therefore I have changed instances of "Wiimote" in the UI to instead say "Wii Remote". I also made a couple of minor grammatical changes as well.
This is mostly a resubmission of #4338 but there are some minor other changes as well.
It's now possible to switch between a horizontal or vertical Wiimote
with no extension, a Wiimote with a Nunchuk, a Classic Controller,
or a GameCube Controller when running a Wii game.
This is needed because for some reason the WSI for NV Vulkan drivers
doesn't return VK_ERROR_OUT_OF_DATE_KHR, so there is no other way to know
that a resize has occured apart from polling, which is a poor solution for
X11 (since it is blocking).
These were made when the button images were first remade many months ago, but they were never committed since there was no use for them at the time (and laziness :P). BUT now there is a PR that finally has use for these images, so it's time to get this into Dolphin and available for use!
At first there weren't many enums in Volume.h, but the number has been
growing, and I'm planning to add one more for regions. To not make
Volume.h too large, and to avoid needing to include Volume.h in code
that doesn't use volume objects, I'm moving the enums to a new file.
I'm also turning them into enum classes while I'm at it.
EndPlayInput runs on the CPU thread so it can't directly call
UpdateWantDeterminism. PlayController also tries to ChangeDisc
from the CPU Thread which is also invalid. It now just pauses
execution and posts a request to the Host to fix it instead.
The Core itself also did dodgy things like PauseAndLock-ing
from the CPU Thread and SetState from EmuThread which have been
removed.
Fix Frame Advance and FifoPlayer pause/unpause/stop.
CPU::EnableStepping is not atomic but is called from multiple threads
which races and leaves the system in a random state; also instruction
stepping was unstable, m_StepEvent had an almost random value because
of the dual purpose it served which could cause races where CPU::Run
would SingleStep when it was supposed to be sleeping.
FifoPlayer never FinishStateMove()d which was causing it to deadlock.
Rather than partially reimplementing CPU::Run, just use CPUCoreBase
and then call CPU::Run(). More DRY and less likely to have weird bugs
specific to the player (i.e the previous freezing on pause/stop).
Refactor PowerPC::state into CPU since it manages the state of the
CPU Thread which is controlled by CPU, not PowerPC. This simplifies
the architecture somewhat and eliminates races that can be caused by
calling PowerPC state functions directly instead of using CPU's
(because they bypassed the EnableStepping lock).
