PR https://github.com/dolphin-emu/dolphin/pull/9700 removed spaces from within control names, which some user complained about, and their point of view is kind of understandable:
https://bugs.dolphin-emu.org/issues/12605
with this change, only spaces outside (between) control names are trimmed, which are the ones we wanted to trim in the first place.
This will still retain the major advantages from 9700.
Basically, "`Button 1` + `Button 2`" was showing as "`Button1`+`Button2`", while it will now show as "`Button 1`+`Button 2`".
Originally, 1479 (for example) would disassemble as `lsr $ACC0, #-7`. At some point (likely the conversion to fmt), this regressed to `lsr $ACC0, #4294967289`. Now, it disassembles as `lsr $ACC0, #7`.
The CPU-side AX library enables it by default and uses hardcoded parameters.
CMD_COMPRESSOR_TABLE_ADDR (0x0A) was incorrect. It's always a nop on the
GameCube and was probably confused with the Wii version.
It was believed that this only mattered when the rounding mode was
set to round to infinity, which games generally don't do, but it
can also affect the sign of the output when the inputs are all zero.
So it turns out you have to pass XMM0 as the clobber register
to HandleNaNs, because HandleNaNs uses BLENDVPD and BLENDVPD
implicitly uses XMM0, and nobody noticed when I broke this in
2c38d64 because nobody plays the one game that needs accurate NaNs.
This was added because YAGCD's info on MAXANISO (near TX_SETMODE0 in Section 5.11.1) claims it's the case, but Extrems says it does work. I haven't tested anything myself, and dolphin still does not actually implement anisotropic filtering based on this field.
This reverts commit 66b992cfe4.
A new (additional) correctness issue was revealed in the old
AArch64 code when applying it on top of modern JitArm64:
LSR was being used when LSRV was intended. This commit uses LSRV.
The workaround added in 30f9f31 caused a regression where Dolphin
incorrectly replaced runs of one byte with runs of another byte
when writing WIA and RVZ files. ReuseID::operator< was always
returning false unless the ReuseIDs being compared had different
partition keys, which caused std::map<ReuseID, GroupEntry>
to treat all ReuseIDs with the same partition key as equal.
This actually eliminates any setting pertaining to SD cards from the
NetPlay dialog, as it would effectively just be a duplicate of the
setting in the Wii pane, potentially causing confusion.
This also enables save data writing by default, as this is probably
what most players want, and should avoid them losing hours of progress
because they forgot to tick a checkbox.
This implementation is pretty efficient in my opinion. And "As
long as we aren't falling back to interpreter we're winning a lot"
applies to basically every instruction to some degree anyway.
The dcbz instruction needs to lock W30 so that the slowmem code will
push and pop it when calling into C++. Also, the slowmem code expects
that the address is present in W0, so replace the use of W0 as a scratch
register in the fastmem code with the now locked W30.
We currently have a bug when calling Arm64GPRCache::Flush with
FlushMode::MaintainState, zero free host registers, and at least
one guest register containing an immediate. We end up grabbing
a temporary register from the register cache in order to be
able to write the immediate to memory, but grabbing a temporary
register when there are zero free registers causes the least
recently used register to be flushed in a way which does not
maintain the state of the register cache.
To get around this, require callers to pass in a temporary
register in the GPR MaintainState case. In other cases,
passing in a temporary register is not required but can help
avoid spilling a register (if the caller already had a
temporary register at hand anyway, which in particular will
be the case in my upcoming memcheck pull request).
release-ubu-x64 currently fails with "sorry, unimplemented: non-trivial
designated initializers not supported". pr-ubu-x64 doesn't for some
reason, but we might as well remove the designated initializer.
This fixes various texture offsetting issues with negative texture coordinates (bringing the software renderer in line with the hardware renderers). It also handles the invalid wrap mode accurately (as was done for the hardware renderers in the previous commit). Lastly, it handles wrapping with non-power-of-2 texture sizes in a hardware-accurate way (which is somewhat broken looking, as games aren't supposed to use wrapping with non-power-of-2 sizes); this has not been done for the hardware renderers.
A voice is considered running if and only if `running` equals 1,
not if `running` is not equal to 0.
This fixes https://bugs.dolphin-emu.org/issues/12508 because for some
reason *The Sims 2 - Castaway* sets `running` to 8 when a stream
finishes playing; previously our AX HLE would just loop the voice
and eventually crash after accessing invalid memory addresses.
Thanks to JMC47 and delroth's help, I've verified that this is the
correct check for the following ucodes:
GC:
* 0x3ad3b7ac
* 0x3daf59b9
* 0x4e8a8b21
* 0x07f88145
* 0xe2136399
* 0x3389a79e
Wii:
* 0x347112ba
* 0xfa450138
* 0xadbc06bd
And while I was fixing the running check, I noticed that the is_stream
field was also being handled incorrectly, so I've fixed that as well.
Putting AX functions from AXVoice.h in an anonymous namespace does
successfully prevent compilers from merging those functions and
allows us to avoid ODR violations.
However, tools such as gdb still mix up AX GC and AX Wii functions
and variables because those have the exact same symbol names.
This can be fixed by using inline namespaces which are transparent
at the source code level but forces AX GC and AX Wii symbols to be
different.
The fast path of using CVTSD2SS/FCVTN rounds the significand if it
can't be exactly represented as a single, whereas the accurate path
instead truncates the significand. So we should only use the fast
path if we know that the lower bits of the significand are not set.
This is not known to affect any games.
Passing a width of 64 and registers encoded as double to
DUP resulted in an invalid instruction. The registers should
be encoded as quads in this situation.
Fixes https://bugs.dolphin-emu.org/issues/12575.
Manually encoding and decoding logical immediates is error-prone.
Using ORRI2R and friends lets us avoid doing the work manually,
but in exchange, there is a runtime performance penalty. It's
probably rather small, but still, it would be nice if we could
let the compiler do the work at compile-time. And that's exactly
what this commit does, so now I have no excuse for trying to
manually write logical immediates anymore.
Léo Lam