This reverts commit e140516130. This assert triggers for AX and AXWii uCode games (including the Wii System Menu) for various addresses that seem to be 4-byte aligned. Worse still, if the DSP thread is in use (i.e. for DSP LLE recompiler, but not for DSP LLE interpreter), Dolphin completely hangs after the panic alert. Perhaps the data DMA has fewer restrictions compared to the instruction DMA?
The change to DSPTool (e391a28102) has not been reverted, as it still fixes broken behavior for DSPSpy at -O0 on real hardware.
Gives two members without explicit initialization default values to be
consistent with the rest of the class and also ensuring deterministic
values on construction.
Though less important compared to #11470, save states also show the full path in the OSD message and could potentially dox a streamer who is playing in Dolphin. This is a simple fix - it removes the path from the message and only displays the file name.
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
I haven't tested this extensively on real hardware, but I do know that bad things happen if the address isn't properly aligned, and libogc says it should be 32-byte aligned.
Turns out all OSD messages, every single one, are written to the titlebar. We've just never seen them because the FPS is in the title bar and it replaces it in a fraction of a second. This was only visible when saving savestates because it halts emulation for a moment while writing.
This is dumb, let's not do that anymore.
A few weeks ago, a vtuber tweeted that they had to remove a vod of their stream because Dolphin Emulator showed some personal information during the steam, and left a warning to everyone else that Dolphin shows the account name of the computer. And yea, we do, we show the full directory of the memory card every time a memory card is written, and due to mandatory Microsoft account nonsense, that is very likely to contain someone’s real name.
Fortunately this is very easy for us to solve. This change simply removes the filename from wrote memory card contents string. That’s it. All functionality of the wrote memory card OSD message remains the same, it just doesn’t say where the memory card is anymore.
There are lots of other potential solutions to this but after talking on IRC it seems the simplest one is the best.
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!
See the comment added by this commit. We were previously guarding against
overshooting in address calculations, but not against undershooting.
Perhaps someone assumed that the displacement of an x86 loadstore was
treated as unsigned?
Note: While the comment says we can undershoot by up to 2 GiB, in
practice Jit64 as it currently behaves won't actually undershoot by more
than 0x8000 if my analysis is correct. But address space is cheap, so
let's guard the full 2 GiB.
This is the behavior in the x64 and ARM64 vertex loaders. I don't know if it makes sense (the whole skipped vertex system seems jank, but several games behave incorrectly without it).
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.
Before, it was also compiled on ARM builds, but since it was unused it wasn't linked (and thus its dependency on the nonexistent x64Emitter didn't cause any link issues).
Fixes incorrect logspam when the buffer needed to be reset on flushes (which we already were doing, but 52feed04db moved it to after the check was made). This is https://bugs.dolphin-emu.org/issues/10312.
I also converted it to an assert, as if this does happen, things are going to render incorrectly, so we want to make it obvious.
This was added in #10394 for both the hardware and software backends to work around an issue with Mario Kart Wii, Fortune Street, and Baten Kaitos. However, it seems like the software renderer handles blending well enough that we don't need this (and in any case, it's easy to change blending in the software renderer).
Some experimentation with #11387 (not pushed) showed that the software renderer's logic would also produce correct results on the hardware backends with this hack removed, but would require fbfetch (currently); if a better solution is found the hack can also be removed from the hardware backends.
Otherwise, texelFetch() will use an out-of-bounds layer for game textures (that have 1 layer; EFB copies have 2 layers in stereoscopic 3D mode), which is undefined behavior (often resulting in a black image). The fast texture sampling path uses texture(), which always clamps (see https://www.khronos.org/opengl/wiki/Array_Texture#Access_in_shaders), so it was unaffected by this difference.
The former is deprecated and pretty much all modern drivers
support VK_EXT_debug_utils.
Android drivers dont support it. On those drivers,
we use the implementation provided by the validation layers.
Plus two miscellaneous debugger features that I found along the way when
reading Jit64's code for comparison: bJITNoBlockLinking and tracing.
Fixes https://bugs.dolphin-emu.org/issues/13127.
Small optimization. By not calling WriteExit, the block linking system
never finds out about the exit we're doing, saving us from having to
disable block linking.
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.
Previously, if a user on Windows launched Dolphin from the command line
and specified a path to an M3U file and included backslashes in this path,
Dolphin would fail to resolve relative paths in the M3U file.
The calculation of each address in lmw/stmw currently has a dependency
on the calculation of the previous address. By removing this dependency,
the host CPU should be able to pipeline the loads/stores better. The cost
we pay for this is up to one extra register and one extra MOV instruction
per guest instruction, but often nothing.
Making EmitBackpatchRoutine support using any register as the address
register would let us get rid of the MOV, but I consider that to be too
big of a task to do in one go at the same time as this.
Now that we've flipped the C++20 switch, let's start making use of
the nice new <bit> header.
I'm planning on handling this move away from BitUtils.h incrementally
in a series of PRs. There may be a few functions remaining in
BitUtils.h by the end that C++20 doesn't have any equivalents for.
This reverts commit 351d095fff.
In hindsight, my attempted optimization messes with the return
predictor, unlike real tail calls. So I think it does more bad than
good.
The "vector shift by immediate" category encodes the shift amount for
right shifts as `size - amount`, whereas left shifts use `amount`.
We're not actually using SHRN/SHRN2 anywhere, which is why this has gone
undetected.
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.
For quite some time now, we've had a setting on x86-64 that makes Dolphin
handle NaNs in a more accurate but slower way. There's only one game that
cares about this, Dragon Ball: Revenge of King Piccolo, and what that game
cares about more specifically is that the default NaN (or "generated NaN"
as I believe it's called in PowerPC documentation) is the same as on
PowerPC. On ARM, the default NaN is the same as on PowerPC, so for the
longest time we didn't need to do anything special to get Dragon Ball:
Revenge of King Piccolo working. However, in 93e636a I changed how we
handle FMA instructions in a way that resulted in the sign of NaNs
becoming inverted for nmadd/nmsub instructions, breaking the game.
To fix this, let's implement the AccurateNaNs setting, like on x86-64.
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).
Operations that have two operands and can't generate a default NaN,
i.e. addition and subtraction, already have the desired NaN handling
on x86. We just need to make sure to not reverse the operands.
This fixes ps_sum0/ps_sum1 outputting NaNs in cases where they shouldn't.
(HandleNaNs assumes that a NaN in a ps0 input always results in a NaN in
the ps0 output, and correspondingly for ps1.)
1. In some cases, ps_merge01 can be implemented using one instruction.
2. When we need two instructions for ps_merge01, it's best to start with
a MOV to avoid false dependencies on the destination register.
3. ps_merge10 can be implemented using a single EXT instruction.
Pokechu22