Everything that links in core doesn't need to see anything related to bochs, because it's only used internally.
Anything else that relies on bochs should be linking it in explicitly.
Since all queues are FIFO data structures, the name wasn't informative
as to why you'd use it over a normal queue. I originally thought it had
something to do with the hardware graphics FIFO.
This renames it using the common acronym SPSC, which stands for
single-producer single-consumer, and is most commonly used to talk about
lock-free data structures, both of which this is.
I don't know who thought it would be a good idea to put the Wiimote
connect code as part of the Host interface, and have that called
from both the UI code and the core. And then hack around it by having
"force connect" events whenever Host_ConnectWiimote is called
from the core...
Showing the Wii remote connection status leads to inconsistent UX,
because we don't do anything like that for GameCube controllers
or with Bluetooth passthrough.
It's also questionable how useful it is given that:
* it doesn't print the number of connected remotes, just that one
remote is connected, connecting or not connected, so the only info
it provides is actually wrong when using multiple remotes;
* this user-facing feature is actually broken in master and no one has
complained AFAIK, which means people don't really rely on it;
* the status bar isn't visible most of the time unless the user is
using render to main or deliberately keeping the main window's
status bar visible by moving the render window and they're not too
far away from their screen;
* emulated Wii remotes now reconnect on input, which means that there
is less of a need to actually know at all times whether a remote
is connected, since pressing any button will reconnect it and provide
immediate, visible feedback via OSD messages and the Wii remote
pointer appearing.
This one verifies bitmasks where low bits are set to 1 (hence the name).
Any stray 0 among the lower ones or any stray 1 among the higher zeros
renders the mask invalid.
The edge cases of all zeros and all ones are considered valid masks.
It uses an efficient implementation. It's the counterpart of
https://graphics.stanford.edu/~seander/bithacks.html#DetermineIfPowerOf2
- Moves all test code from DSPTool into UnitTests/Core/DSPAssemblyTest.
- Converts test files (which could only be loaded if they were in the
shell's working directory, so basically never) into C++ values.
- Enables most of the commented-out tests.
- Removes non-deterministic random code test.
The current prefixing makes it harder to build test executables directly
from the command line, since the target name breaks CMake convention and
doesn't match the name passed to `add_dolphin_test`. They all have "Test"
somewhere in the name anyways.
This adds unit tests for IOS/ESFormats, and in particular, for the
TMDReader. It is tested using invalid TMDs (to check IsValid()) and
two valid, properly signed TMDs.
Things which are now tested:
* Title type helper functions.
* TMDReader: Validity check.
* TMDReader: General information returned by the Get*() methods.
* TMDReader: Raw TMD and generated TMD view, compared against IOS.
* TMDReader: Game ID generation code (which is Dolphin specific).
* TMDReader: Content information: getting by ID/index, order, metadata.
Lioncash