Will manually controlling both an accelerometer and a gyroscope at the
same time be reasonable to do? No idea. Was this easy to implement
thanks to the input override system? Yes.
Fixes https://bugs.dolphin-emu.org/issues/12443.
This gets rid of a blocking operation, improving performance and fixing
https://bugs.dolphin-emu.org/issues/12893.
This also makes us no longer directly access the state of certain UI
elements from the CPU thread, which probably wasn't thread-safe but
doesn't seem to have caused any observable issues so far.
This resulted in the labels being solid black even when audio stretching is disabled the first time the settings are opened, but then properly being greyed out after changing a setting (even the audio backend or DSP emulation engine, not just whether audio stretching is enabled).
Before these changes you could tell Dolphin to convert a game file into the same format it is already in, leading to the FileDialog using the input path as the default destination path
An unsuspecting user could then click Save and Dolphin would try to convert the input file by writing the destination file on top of it... leading to an I/O error and the input file being entirely removed
This avoids a pseudo infinite loop where CodeWidget::UpdateCallstack
would lock the CPU in order to read the call stack, causing the CPU to
call Host_UpdateDisasmDialog because it's transitioning from running to
pausing, causing Host::UpdateDisasmDialog to be emitted, causing
CodeWidget::Update to be called, once again causing
CodeWidget::UpdateCallstack to be called, repeating the cycle.
Dolphin didn't go completely unresponsive during this, because
Host_UpdateDisasmDialog schedules the emitting of Host::UpdateDisasmDialog
to happen on another thread without blocking, but it was stopping certain
operations like exiting emulation from working.
This fixes a problem I was having where using frame advance with the
debugger open would frequently cause panic alerts about invalid addresses
due to the CPU thread changing MSR.DR while the host thread was trying
to access memory.
To aid in tracking down all the places where we weren't properly locking
the CPU, I've created a new type (in Core.h) that you have to pass as a
reference or pointer to functions that require running as the CPU thread.
- Cancel doesn't shut down anymore.
Allowing it to be used multiple times thoughout the life of
the WorkQueue
- Remove Clear, so we only have Cancel semantics
- Add IsCancelling so work items can abort early if cancelling
- Replace m_cancelled and m_thread.joinable() guars with m_shutdown.
- Rename Flush to WaitForCompletion (As it's ambiguous if a function
called flush should be blocking or not)
- Add documentation
CMakeSettings.json is a Visual Studio only extention to cmake that isn't
supported anywhere else. Not even Visual Studio Code.
So we set CMAKE_PREFIX_PATH inside DolphinQt's CMakeLists.txt instead.
Almost all the virtual functions in Renderer are part of dolphin's
"graphics api abstraction layer", which has slowly formed over the
last decade or two.
Most of the work was done previously with the introduction of the
various "AbstractX" classes, associated with texture cache cleanups
and implementation of newer graphics APIs (Direct3D 12, Vulkan, Metal).
We are simply taking the last step and yeeting these functions out
of Renderer.
This "AbstractGfx" class is now completely agnostic of any details
from the flipper/hollywood GPU we are emulating, though somewhat
specialized.
(Will not build, this commit only contains changes outside VideoBackends)
Capitalize Skylander in tr strings
Lint and validation method fixes
Proper Attach and Change Interface method
Re-jig code to exit early and read easier
Skylander code tidy ups
Convert c array to std::array and fix comments
Formatting fixes/review changes
Variable comment
Migrate portal to System Impl and code tidy ups
Use struct
Restore review changes
Minor fix to schedule transfer method
Change descriptors to hex and fix comments
Ported the code from RPCS3, with improvements made to the handling of control messages and audio transfers, Co-Authored with @mandar1jn
Missing new line chars
Co-Authored-By: mandar1jn <49076509+mandar1jn@users.noreply.github.com>
We've decided this track will never be used in the future. Releases will
continue using the "beta" branch internally, though we'll have the
user-visible strings use a different name instead.
(Note: Dolphin provided builds have always defaulted to 'beta' as the
auto-update track, so anyone who set 'stable' did so manually.)
This should be a fairly easy merge, assuming I didn’t mess anything up. TL:DR no one uses it and it’s not great.
Boot from DVD Backup is an ancient feature with origins in the Megacommit. Back then, GameCube and Wii games were quite large relative to drives of the time. For example, in 2008, the most common hard drive sizes were 320GB and 512GB. On the 320GB drive I personally had at the time, as little as 42 Wii ISOs could have filled it entirely! And that’s ignoring any other files one might want to put onto a drive. Backup DVDs allowed users to burn relatively cheap DVD media and store their GameCube and Wii dumps in a Dolphin accessible way that didn’t eat into their precious HDD space. It had compromises, even then, but in 2008… I mean honestly users probably wouldn’t even notice those compromises with how Dolphin barely even worked at all back then.
Obviously, today the storage space concerns are not as big of an issue. According to seagate the average hard drive it sells today is 8TB. For typical laptops purchased now, the -minimum- selection for storage is usually 1TB. You can even buy a name brand 4TB external hard drive for $100. GC and Wii ISOs are not as big as they once were, relatively anyway. Plus flash drives and SD cards are super cheap and way faster than disc drives ever were. For anyone that has limited drive space, removable flash media can fulfill this offloading role far better than backup DVD media ever could.
Also no one has DVD drives anymore. That’s kind of an important detail.
But to see if Booting from DVD Backup even still worked, I decided to give it a try. I have an ASUS BW-16D1HT, a badass Bluray XL reading and burning drive, connected to my Windows 11 Threadripper 5975WX machine. A super fast drive on a super fast machine is as good as it possibly can get for this feature. So I bought a spindle of DVD-Rs, burned a couple of discs and gave it a try. Surprisingly, it does still work. However, as expected, it introduces a lot of stuttering. Testing Prime 1 and Prime 3, in both games stuttering was introduced whenever the DVD Drive had to suddenly seek. Spikes of 50ms occurred constantly, but I observed 150ms and even over 1000ms stutters! The worst was a three second stutter, when loading Elysia in Prime 3. I could even hear the stutters - any time the drive suddenly made a harsh seeking noise, the game would have a hard stutter. It worked but, it has some serious compromises.
Boot from DVD Backup isn’t great, using removable flash media or external hard drives is a FAR better option for anyone with limited storage space today, and no one can even use this feature anymore because their computers don’t even have disc drives. It’s time for Boot from DVD Backup to go!
So I did my best on the cleanup but I’m bound to have left some bits. Especially in translation - I didn’t get any warnings or anything there that could help point me to where to clean that up. Please review!
This generated a warning on GCC about the operation being potentially undefined (-Wsequence-point). I'm not sure if that was actually the case, but either way it is a mistake.
We should expose Enable Controller Input and the turbo settings for
GBA just like we do for GameCube controllers and Wii Remotes.
I just forgot about it when implementing the GBA TAS input window.
Use: callstack(0x80000000).
!callstack(value) works as a 'does not contain'.
Add strings to expr.h conditionals.
Use quotations: callstack("anim") to check symbols/name.
This affected the memory and registers widgets (and possibly others). I'm pretty sure it regressed in 5f629abd8b.
The SetCodeVisible line is a new fix, but the equivalent already existed in the memory widget.
The call to analyzer.Analyze breaks when it attempts to read an instruction, as it eventually tries to read memory when Memory::m_pRAM is nullptr. Trying to read when execution is not paused in general seems like a bad idea (especially as analyzer.Analyze uses PowerPC::TryReadInstruction which can update icache - this is probably still a problem).
When emulated GBAs were added to Dolphin, it was possible to control them
using the GC TAS input window. (Z was mapped to Select.) Unaware of this,
I broke the functionality in b296248.
To make it possible to control emulated GBAs using TAS input again,
I'm adding a proper TAS input window for GBAs, with a real Select button
and no analog controls.
`ImGui::GetIO` performs an assertion that a context exists, and if one doesn't then things will likely crash. Unfortunately this crash is hard to consistently reproduce.
This lets the TAS input code use a higher-level interface for
overriding inputs instead of having to fiddle with raw bits.
WiiTASInputWindow in particular was messy with how much
controller code it had to re-implement.
Before, only the symbols box would update. However, if you edit the symbol of a function in the call stack (which seems like something that would happen reasonably often while debugging), the call stack would be out of date until it was updated by clicking on it. Callers and calls were more of an edge case; for them to be out of date, you would need to right-click on an instruction in a function other than the one containing the currently-selected instruction (though it would also affect recursive functions).
Texture dumping can already be done using VideoCommon's system (and in fact the same setting already enabled *both* of these). Dumping objects/TEV stages/texture fetches doesn't currently have an equivalent, but could be added to the FIFO player instead.
Because of the previous commit, this is needed to stop DolphinQt from
forgetting that the user pressed ignore whenever any part of the config
is changed.
This commit also changes the behavior a bit on DolphinQt: "Ignore for
this session" now applies to the current emulation session instead of
the current Dolphin launch. This matches how it already worked on
Android, and is in my opinion better because it means the user won't
lose out on important panic alerts in a game becase they played another
game first that had repeated panic alerts that they wanted to ignore.
For Android, this commit isn't necessary, but it makes the code cleaner.
