This unit test compares ApprovedInis.json with the contents of the GameSettings folder to verify that every patch marked allowed for use with RetroAchievements has a hash in ApprovedInis.json. If not, that hash is reported in the test logs so that the hash may be updated more easily.
We currently have 32 different binaries containing unit tests. At least
when I build for Android, each one takes up over 200 MiB, and linking
them all increases my incremental build times by over a minute. I'd
like to change this for the sake of my productivity and disk space.
For reference, MSBuild is already putting all tests in a single binary.
Enable emulator hotkeys and controller input (when that option is
enabled) when a TAS Input window has focus, as if it was the render
window instead. This allows TASers to use frame advance and the like
without having to switch the focused window or disabling Hotkeys Require
Window Focus which also picks up keypresses while other apps are active.
Cursor updates are disabled when the TAS Input window has focus, as
otherwise the Wii IR widget (and anything else controlled by the mouse)
becomes unusable. The cursor continues to work normally when the render
window has focus.
Also make the `Decrypt` method private.
As far as I can tell, the only motivation for exposing the `SetBytes`
and `Reset` methods is to allow `CBoot::SetupWiiMemory` to use the same
`SettingsHandler` instance to read settings data and then write it back.
It seems cleaner to just use two separate instances, and require a given
`SettingsHandler` instance to be used for either writing data to a
buffer or reading data from a buffer, but not both.
A natural next step is to split the `SettingsHandler` class into two
classes, one for writing data and one for reading data. I've deferred
that change for a future PR.
On all platforms, this would result in out of bounds accesses when getting the component sizes (which uses stuff from VertexLoader_Position.h/VertexLoader_TextCoord.h/VertexLoader_Normal.h). On platforms other than x64 and ARM64, this would also be out of bounds accesses when getting function pointers for the non-JIT vertex loader (in VertexLoader_Position.cpp etc.). Usually both of these would get data from other entries in the same multi-dimensional array, but the last few entries would be truly out of bounds. This does mean that an out of bounds function pointer can be called on platforms that don't have a JIT vertex loader, but it is limited to invalid component formats with values 5/6/7 due to the size of the bitfield the formats come from, so it seems unlikely that this could be exploited in practice.
This issue affects a few games; Def Jam: Fight for New York (https://bugs.dolphin-emu.org/issues/12719) and Fifa Street are known to be affected.
I have not done any hardware testing for this PR specifically, though I *think* I previously determined that at least a value of 5 behaves the same as float (4). That's what I implemented in any case. I did previously determine that both Def Jam: Fight for New York and Fifa Street use an invalid normal format, but don't actually have lighting enabled when that normal vector is used, so it doesn't change rendering in practice.
The color component format also has two invalid values, but VertexLoader_Color.h/.cpp do check for those invalid ones and return a default value instead of doing an out of bounds access.
There were three distinct mechanisms for signaling symbol changes in DolphinQt: `Host::NotifyMapLoaded`, `MenuBar::NotifySymbolsUpdated`, and `CodeViewWidget::SymbolsChanged`. The behavior of these signals has been consolidated into the new `Host::PPCSymbolsUpdated` signal, which can be emitted from anywhere in DolphinQt to properly update symbols everywhere in DolphinQt.
Use 1 of the same type as the stored value when shifting left. This
prevents undefined behavior caused by shifting an int more than 31 bits.
Previously iterator incrementation could either hang or prematurely
report it had reached the end of the bitset.
Jimmie Johnson's Anything with an Engine is known to use texture coordinate 7 (and only texture coordinate 7) in some cases. There are a lot of possible edge-cases, so this test brute-forces all combinations with coordinates 0, 1, and 2.
This test fails with the non-JIT vertex loader due to an issue fixed in a later commit in this PR. (Note that the non-JIT vertex loader is only used on machines where no JIT is available or if COMPARE_VERTEXLOADERS is enabled in VertexLoaderBase.cpp.)
This is a little trick I came up with that lets us restructure our float
classification code so we can exit earlier when the float is normal,
which is the case more often than not.
First we shift left by 1 to get rid of the sign bit, and then we count
the number of leading sign bits. If the result is less than 10 (for
doubles) or 7 (for floats), the float is normal. This is because, if the
float isn't normal, the exponent is either all zeroes or all ones.
With this, situations where multiple arguments need to be moved
from multiple registers become easy to handle, and we also get
compile-time checking that the number of arguments is correct.
Using GTEST_SKIP instead of just returning from the function shows that
a test was skipped in the test summary. If GTEST_SKIP is called the rest
of the function won't be run, just like with the return.
GTEST_SKIP wasn't available until gtest 1.10, and we updated to 1.12 in
597f8f1b87.
Check bytes directly to avoid ambiguity in the disassembly between short
and near jumps, which could hypothetically cause the test to pass when
it shouldn't.
Replace the bool parameter force5bytes in J, JMP, and J_CC with an enum
class Jump::Short/Near. Many callers set that parameter to the literal
'true', which was unclear if you didn't already know what it did.
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.
DataReader is generally jank - it has a start and end pointer, but the end pointer is generally not used, and all of the vertex loaders mostly bypassed it anyways.
Wrapper code (the vertex loaer test, as well as Fifo.cpp and OpcodeDecoding.cpp) still uses it, as does the software vertex loader (which is not a subclass of VertexLoader). These can probably be eliminated later.
This currently fails for direct with NormalIndex3 enabled (see https://bugs.dolphin-emu.org/issues/12952). The goal of this test is to be able to confidently say that that bug has been fixed.
We have one that does a similar thing, but only to measure speed and uses indices. This one verifies accuracy (and uses the largest possible input size by using direct components).
* moves dolphin-specific settings out of Base.props
* creates exports.props for externals, allowing to easily import
individual Externals
* corrects some cruft that accumulated and probably contributed
to msbuild overbuilding
Most of these correspond to changes made in devkitPro/libogc@b1b8ecab3a.
The numeric vlaues of ACC0 and ACC1 in Dolphin are different (see b06d38389b, though I'm not sure when this difference first appeared). Technically it's not even necessary to list the registers at the start like this anymore, but old programs do it, so it seems useful to have a test that covers it.
The binary itself does not need to be changed; the warnings were simply stating that "although you wrote $ACL0, the generated binary instead is using $ACC0" or similar; by changing the code to use $ACC0 directly the warnings are resolved.
I don't know what happened here, unfortunately. The version of dsp_mixer.s added to libogc on Nov 14, 2008 in c76d8b851f uses andcf and jlz here, and the version we have matches the one from Feb 5, 2009 in ae5c3a5fb5 exactly (prior to the fixes in my previous commit). I can't see any reason why wait_for_dsp_mail would be changed like this.
ANDCF and ANDF were previously swapped and JNE/JEQ/JZR/JNZ became JNZ/JZ/JLNZ/JLZ on Apr 3, 2009 in 7c4e654253, corresponding to a change Hermes made on Nov 10, 2008 in 2cea6d99ad. But these predate the test being added.
The only other information I can find is that ASNDLIB 1.0 released on November 11, 2008, at https://web.archive.org/web/20120326145022/http://www.entuwii.net/foro/viewtopic.php?f=6&t=87 (but there aren't any surviving links from there).
This change makes assembling DSPTestText match DSPTestBinary, though HermesText doesn't yet match HermesBinary.
The test data was originally added on April 18, 2009 in e7e4ef4481. Then, set16 and set40 were swapped on April 22, 2009 89178f411c, which updated the DSPSpy version of dsp_code, but not the version in DSPTool used for testing. So, when the test was made, the assembled data matched the text, but a few days after it no longer did.
Similarly, on Jul 7, 2009 in 1654c582ab the conditional instructions were adjusted, and 0x1706 was changed from JRL to JRNC and 0x0297 was changed from JGE to JC.
For what it's worth, devkitPro made the same changes on May 31, 2010 in 8a65c85c9b and updated their version of the asnd ucode (which is this ucode) on June 11, 2011 in b1b8ecab3a (though this update also includes other feature changes). Note that at the time, they didn't reassemble the ucode unless they made changes to it; the assembled was stored in the repo until bfb705fe16~...d20f9bdcfb43260c6c759f4fb98d724931443f93.
This fixes the following failures with Hermes:
!! 0015 : 8e00 vs 8f00 - set16 vs set40
!! 016f : 8e00 vs 8f00 - set16 vs set40
and with Hermes:
!! 0014 : 8e00 vs 8f00 - set16 vs set40
!! 0063 : 8e00 vs 8f00 - set16 vs set40
!! 019b : 1706 vs 1701 - jrnc $AR0 vs jrl $AR0
!! 01bf : 0297 vs 0290 - jc 0x01dc vs jge 0x01dc
!! 01d2 : 0297 vs 0290 - jc 0x01dc vs jge 0x01dc
Hermes has the remaining failures:
!! 027b : 03c0 vs 03a0 - andcf $AC1.M, #0x8000 vs andf $AC1.M, #0x8000
!! 027d : 029d vs 0294 - jlz 0x027a vs jnz 0x027a
Page faults should only occur on architectures that support exception
handlers, so skip the test on other architectures to avoid spurious test
failures.
Dr. Dystopia