This fixes a memory leak that would occur when the Android frontend
calls LogManager::Init more than once in order to reload settings.
Note that the log window listener is now owned by LogManager instead of
by the frontend, making it consistent with the other log listeners.
Old cruft from when the Android code was loading INI files manually.
We don't have any handling for failing to load settings anymore.
This change also updates related comments to reflect how things actually
work nowadays.
Add a method to detect console ID from an input file and instruct rcheevos to load as Gamecube or Wii accordingly. Also, hash .wads upon loading, to support achievements on WiiWare titles.
Probably a copy-paste error from layout-ldrtl/list_item_setting.xml.
This error made it so a long setting name could overlap with the
checkbox next to it if Dolphin was running with right-to-left layout.
The incorrect ID was apparently also causing the app:lintVitalRelease
build task to fail. I guess we're not running that build task, because I
only heard of this from someone building Dolphin locally.
There's no guarantee that directory initialization has completed by this
point, so we can't safely use NativeLibrary.
I'm making this change because of a crash being reported in Google Play
Console. The exact way it's crashing is mysterious to me, so I'm not
sure if this commit fixes the crash, but I think this commit is
a reasonable change to make even if it doesn't fix the crash. Backtrace
from Google Play Console:
#00 pc 0x0000000000469074 /data/app/~~m0kqybFNfeqnDenQFc53XQ==/org.dolphinemu.dolphinemu-Mtaw0lU8DVUQbte2ZjBp3w==/lib/arm64/libmain.so (std::__ndk1::pair<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>> const, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>>::pair[abi:nn180000]<char const* const&, char const* const&, 0>(char const* const&, char const* const&)) (BuildId: 64cfebf5b574b6729ebc51799aa94ccc3238cbcc)
#01 pc 0x0000000000468e9c /data/app/~~m0kqybFNfeqnDenQFc53XQ==/org.dolphinemu.dolphinemu-Mtaw0lU8DVUQbte2ZjBp3w==/lib/arm64/libmain.so (std::__ndk1::pair<std::__ndk1::__tree_iterator<std::__ndk1::__value_type<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>>, std::__ndk1::__tree_node<std::__ndk1::__value_type<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>>, void*>*, long>, bool> std::__ndk1::__tree<std::__ndk1::__value_type<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>>, std::__ndk1::__map_value_compare<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>, std::__ndk1::__value_type<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>>, std::__ndk1::less<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>>, true>, std::__ndk1::allocator<std::__ndk1::__value_type<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>>>>::__emplace_unique_impl<char const* const&, char const* const&>(char const* const&, char const* const&)) (BuildId: 64cfebf5b574b6729ebc51799aa94ccc3238cbcc)
#02 pc 0x0000000000462f08 /data/app/~~m0kqybFNfeqnDenQFc53XQ==/org.dolphinemu.dolphinemu-Mtaw0lU8DVUQbte2ZjBp3w==/lib/arm64/libmain.so (Common::Log::LogManager::GetLogTypes()) (BuildId: 64cfebf5b574b6729ebc51799aa94ccc3238cbcc)
#03 pc 0x000000000044339c /data/app/~~m0kqybFNfeqnDenQFc53XQ==/org.dolphinemu.dolphinemu-Mtaw0lU8DVUQbte2ZjBp3w==/lib/arm64/libmain.so (Java_org_dolphinemu_dolphinemu_NativeLibrary_GetLogTypeNames+56) (BuildId: 64cfebf5b574b6729ebc51799aa94ccc3238cbcc)
#04 pc 0x000000000031456c /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (art_jni_trampoline+108)
#05 pc 0x0000000000781508 /apex/com.android.art/lib64/libart.so (nterp_helper+152)
#06 pc 0x00000000002d94d4 /data/app/~~m0kqybFNfeqnDenQFc53XQ==/org.dolphinemu.dolphinemu-Mtaw0lU8DVUQbte2ZjBp3w==/base.apk (org.dolphinemu.dolphinemu.features.settings.ui.SettingsFragmentPresenter.<clinit>+16)
[...]
Previously, PerformanceTracker registered a callback to be updated on
emulation state changes. PerformanceTrackers live in a global variable
(g_perf_metrics) within libvideocommon. The callback was stored in a
global variable in libcore. This created a race condition at shutdown
between these libraries, when the PerfTracker's destructor tried to
unregister the callback.
Notify the PerfTracker directly from libcore, without callbacks, since
Core.cpp already references g_perf_metrics explicitly. Also rename
Core::CallOnStateChangedCallbacks to NotifyStateChanged to better
reflect what it's doing.
Extracted games contain a boot.bin file that contains the disc header.
These boot.bin files are considered valid volumes by Dolphin, since
Dolphin only checks the disc header to determine if something is a valid
GC/Wii disc. Running them doesn't make any sense, though.
boot.bin files used to not be scanned by Dolphin due to their file
extension, but .bin was added to the list of file extensions to scan for
in 494e2c0. To stop them from showing up in the game list, let's update
the ShouldHideFromGameList mechanism.
Different threads are adding and calling callbacks, so this should have
some locking. This is both to ensure thread safety when accessing
`s_callbacks` and to ensure that there won't be situations where a
callback gets called after it's removed.
`s_callback_guards` is also accessed from multiple threads and has
therefore been made atomic.
a1691a4 made it so analytics start events can only be generated when
starting the main activity. However, some users launch Dolphin's
emulation activity from a separate frontend application, bypassing
Dolphin's main activity. This change adjusts the logic so that start
events can be generated if any activity is started after 6 hours of
inactivity. This more closely matches the behavior we had before
a1691a4, while still ensuring duplicate start events aren't generated.
I've also fixed the inconsistent indentation in ActivityTracker.kt.
Require callers of Config::AddConfigChangedCallback and
CPUThreadConfigCallback::AddConfigChangedCallback to handle the returned
ConfigChangedCallbackIDs to hopefully prevent future issues with
callbacks getting called after their associated objects have been
destroyed.
Use a single lambda as a callback which calls InitCustomPaths and
RefreshConfig instead of having separate callbacks for each of them.
This fixes the callback for InitCustomPaths not being removed on
shutdown; the callback for the lambda (previously for RefreshConfig) is
already removed in Shutdown().
Prevent SetHardcoreMode from being called after m_client is set to
nullptr. rc_client_set_hardcore_enabled() checks for nullptr so this
didn't cause any problems, but better not to rely on that.
Also prevents multiple SetHardcoreMode callbacks from piling up when
repeatedly toggling Config::RA_ENABLED.
Remove ConfigChangedCallback in MainWindow's destructor to prevent the
callback from accessing the destroyed MainWindow afterward.
After MainWindow is destroyed UICommon::Shutdown calls
LogManager::Shutdown which ultimately triggers any remaining callbacks.
This resulted in calling MainWindow::OnHardcoreChanged, which crashed in
debug builds and didn't have any obvious effect in release builds.
Fixing an oversight: this was causing the debugger to be disabled if achievements were disabled but hardcore mode was still enabled in the .ini. This fix properly checks for hardcore state via AchievementManager which takes both settings into account.
I've been playing Rock Band 3 recently and have experienced a bug where
sometimes if you disconnect and reconnect a USB microphone, the game
won't pick up on it connecting, not even it you disconnect and reconnect
it again. An investigation into what's going on inside Dolphin shows
that when the game triggers a call to OH0::DeviceOpen after the device
has been reinserted, Dolphin doesn't open the device because it's
already present in m_opened_devices.
Removing the device from m_opened_devices after calling OH0::TriggerHook
in OH0::OnDeviceChange resolves this specific issue in my testing. Doing
this matches us removing the device from m_opened_devices after calling
OH0::TriggerHook in OH0::DeviceClose, but I haven't looked at exactly
what real IOS does.
I have been able to reproduce a much rarer issue that has the same
symptoms on the surface but where OH0::DeviceOpen gets past its
m_opened_devices check. I'm currently not sure what the cause of this
remaining issue is.
71f654c added a new platform in the middle of the C++ platform enum
without updating the corresponding Android code, making the Android code
incorrectly treat Wii discs as WAD files, WAD files as DOL/ELF files,
and so on. This commit fixes the problem.
To be able to add the new Triforce entry into the Platform enum without
it leading to the UI getting an additional tab, I'm splitting the enum
into Platform and PlatformTab. Platform now exactly matches the C++
enum (previously it excluded ELFOrDOL), and PlatformTab has the same
content as the old Platform.
RetroAchievements disables pausing too frequently when running but there's no sense of doing this if RetroAchievements does not currently have a game running.
Some games open two USB interfaces, e.g. /dev/usb/oh0 and /dev/usb/hid.
This was causing us to run two scanning threads at once, using up more
CPU time for scanning than we need to.
We have identified that a failed RetroAchievements game load (most easily done when closing a game before the server can finish responding) can leave data behind that causes problems. As such, refactored CloseGame to always delete data even if there wasn't a game loaded when it was called, and call it on the failure paths of LoadGameCallback.
Instead of having USBScanner create "hooks" as it scans for devices,
let's have USBScanner present a list of devices to USBHost and have
USBHost diff the new device list with its old device list to create the
hook calls instead. This gets rid of some complex edge cases that the
next commit otherwise would have to deal with, in particular regarding
toggling determinism and adding new USBHosts to a USBScanner.
Note: After adding the missing locking of m_devices_mutex, I had to move
the locking of m_hooks_mutex to avoid a random deadlock between the CPU
thread and USB scanning thread. (Either that or I would have to lock
m_devices_mutex before m_hooks_mutex.)
This gets rid of the ugly direct access to USBScanner::m_devices that
was introduced by the previous commit.
This also fixes a potential thread safety issue.
USB_HIDv4::TriggerDeviceChangeReply loops through m_devices and calls
GetDeviceEntry for each device. If USB_HIDv4::TriggerDeviceChangeReply
is called after a new device is added to m_devices but before hooks are
dispatched, GetDeviceEntry crashes, because the hook that's supposed to
update m_device_ids hasn't run yet. With this commit, this issue can no
longer happen, because USBHost::m_devices_mutex doesn't get unlocked in
between updating m_devices and dispatching the hooks.
dolphin-start event was being generated twice for the normal
end-user case, as can be seen in analytics data for some years.
The problem occured when:
* Android reaped the process hosting the dolphin activity
(e.g. for power/memory saving).
and
* Dolphin activity was in "stopped" state for > 6 hours before
being switched back to.
Under above conditions, both calls to ReportStartToAnalytics
would be performed, as dolphin thought it was being launched anew,
and also thought it had been asleep for > 6 hours.
fixes https://bugs.dolphin-emu.org/issues/13675
Due to requests from RA Devs, updating the AchievementManager LoadGameCallback to still set MemoryPeeker (and set m_system) if the load game response is NO_GAME_LOADED, so that the memory inspector et al continue function properly on unidentified hashes. Without this, no memory is loaded and the memory inspector will show all zeroes.
If the development system is started for a game with an unrecognized hash, RA_Integration opens a dialog for connecting the hash with a title. That dialog is prepopulated by the results of GameTitleEstimateHandler.
Displays an additional message when an achievement unlocks that isn't on the site yet (either hasn't yet been uploaded or modified from remote) i.e. achievements the "player" is actively developing.
When you use TimePlayed, you have to provide a game ID either when
creating the object or when calling GetTimePlayed on it. If you don't
provide a game ID when creating the object, function calls that don't
take a game ID will silently fail, except for Reload. This isn't very
obvious, and there's no strong benefit to storing the game ID inside
TimePlayed anyway (it just lets TimePlayed skip calling EscapeFileName),
so this commit removes the TimePlayed constructor that takes a game ID
and instead makes the functions that need game IDs always take a game ID
argument.
It was being done manually, which a TODO comment advised against.
Using generic_string() from std::filesystem::path solves this.
Fix encoding issue using generic_wstring instead.
Fix overlays stacking on top of each other or not moving to the edge of
the screen when enabling or disabling overlays while emulation is
active.
This change only applies when Config::GFX_MOVABLE_PERFORMANCE_METRICS is
False.
This lets you use PS3 Rock Band controllers with Wii Rock Band and
Guitar Hero games.
A normal user will probably never have any reason to disable this
behavior, but I figured maybe there's some person out there who would
like to disable it. (For instance, I know there's a mod for RB3 that's
trying to implement the same kind of cross-console controller
compatibility, and that can only be tested if the behavior I'm adding is
disabled.) So the behavior is controlled by an INI-only setting.
Removed VolumeChanged signal, as ConfigChanged will trigger what is needed.
Only applies UpdateSoundStream to things that can change during emulation.
Settings::SetVolume might no longer be used, but left it in.
Gecko codes in Dolphin feature a dedicated field for the creator of the
cheat code. When saved into the INI file, the code name and the creator
name are concatenated, and then inserted in the `[Gecko]` section:
```ini
[Gecko]
$<cheat code name> [<creator>]
<code line 1>
<code line 2>
<code line 3>
<...>
$<other cheat code name> [<creator>]
<code line 1>
<code line 2>
<code line 3>
<...>
```
On the other hand, enabled codes are listed under the `[Gecko_Enabled]`
section, but in this case the creator name is omitted from the line:
```ini
[Gecko_Enabled]
$<cheat code name>
$<other cheat code name>
```
Having the creator name in the `[Gecko]` section but not in the
`[Gecko_Enabled]` section is arguably not ideal, but this is legacy
behavior in Dolphin.
The **Cheat Code Editor** dialog is not acknowledging this subtle
behavior in Dolphin: the cheat code name and the creator name *can* be
both inserted in the name field. This issue manifests as an inconsistent
state where a Gecko code that *appears* to be enabled has no effect when
the game is launched.
As part of this fix, the creator name (if present) is now moved into the
dedicated creator field before the code is stored internally.
Test plan:
- Right-click on any game and open the **Properties** dialog.
- Switch to the **Gecko Codes** tab.
- Press the **Add New Code...** button.
- In the **Cheat Code Editor** dialog:
- Enter `This is a test [Jane Doe]` in the **Name:** field.
- Enter `01234567 00000000` in the **Code:** field.
- Press **Save**.
- Observe that the newly added code is now in the list, and *appears* to
be enabled.
- Close the **Properties** dialog.
- Right-click on the same game and open the **Properties** dialog again.
**Without** the fix, the newly added code, while still on the list, has
been inadvertently disabled (it was never really enabled!).
**With** the fix, the newly added code is the list and remains enabled.
This fixes https://bugs.dolphin-emu.org/issues/13695.
Fix the following bug:
* Have a moveable ImGui overlay enabled, such as the Statistics window.
* Pause the game.
* Click and hold on the overlay's title bar as if you were going to move
it. Because the screen isn't updating while the game is paused, you
won't be able to actually move the overlay.
* Press the Frame Advance hotkey several times until it stops
responding.
At this point emulation hotkeys are no longer responsive. This can be
resolved by selecting Play from the toolbar or menu, or selecting Frame
Advance from the menu a couple times, but it's annoying and not obvious
what's gone wrong or how to fix it.
Why the bug is happening:
* Doing a framestep while clicking on the overlay title bar causes ImGui
to set IO.WantCaptureKeyboard to true, indicating that ImGui is
requesting Dolphin ignore any keyboard events while the overlay is
being interacted with.
* Dolphin complies with this request, causing
Host_UIBlocksControllerState to return true and thus setting the input
gate to ignore input.
* IO.WantCaptureKeyboard is only updated when ImGui::NewFrame() is
called, which only happens at the end of each present. It thus remains
true indefinitely since the game paused after the last framestep, and
so Dolphin ignores any hotkeys such as the framestep or play keys.
The fix:
Ignore IO.WantCaptureKeyboard when the game is paused. ImGui can't
meaningfully capture input anyway when the game is paused, so this
shouldn't cause any problems elsewhere.
Once async presentation is implemented we'll want to revert this change,
both because it'll become unnecessary and because ImGui will be able to
do stuff while paused and so suppressing emulation hotkeys will actually
be useful.
This is an Android continuation of bc95c00. We now call
InputDetector::Update immediately after receiving an input event from
Android instead of periodically calling it in a sleep loop. This
improves detection of very short inputs, which are especially likely to
occur for volume buttons on phones (or at least on my phone) if you
don't intentionally keep them held down.
JosJuice