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.
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
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.
Deduplicates code, and gets rid of some problems the old code had
(such as: bad performance when calling native functions, only one
disc showing up for multi-disc games, Wii banners being low-res,
unnecessarily much effort being needed for adding more metadata).
Skip ubershader mode works the same as hybrid ubershaders in that the
shaders are compiled asynchronously. However, instead of using the
ubershader to draw the object, it skips it entirely until the
specialized shader is made available.
This mode will likely result in broken effects where a game creates an
EFB copy, and does not redraw it every frame. Therefore, it is not a
recommended option, however, it may result in better performance on
low-end systems.
Android is allowed to pick any path for the external storage media and
that's why we should always use Environment.getExternalStorageDirectory()
to get the external storage path
1. Allow users to pick games dircetory from external storage.
2. Better UX experince to distinguish between selecting a directory or
a game. The later is needed when we implement change disk for android.
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 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.
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.
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.
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.
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)
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.)
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.
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!
This is the only way to get Wiimotes working under Android now.
This, just like the Wii U Gamecube Controller Adapter, completely goes around Android's limitations and talks with the device directly through USBManager.
Couple notes.
Continuous scanning must be enabled otherwise the Wiimotes won't be seen.
The UI doesn't expose support for this yet. One must change the Wiimote source and continuous scanning settings manually.
Testing up to two wiimotes in Taiko No Tatsujin, no reason to believe all four won't work.
Lets the user set the following in intervals of 10 between 10 and 100;
- Stick/Radius (default 100,000000)
- Triggers/Threshold (default 90,000000)
- Tilt/Modifier/Range (default 50,000000) + mapped Tilt/Modifier button
to the configurations for wiimotes & nunchuks
Main Stick is changed to Control Stick and C-Stick is changed to C Stick.
A new ui_name variable is added to ControlGroup so that the UI strings
in DolphinWX can be updated without breaking backwards compatibility
with config INIs and other things that use names as IDs.
