c5fa470 made the extension check discard directories, but
only in the new code that currently only is used on Windows.
Let's add an equivalent check in the old code so that the
behavior is consistent across platforms.
The sanity check runs *before* finalising the import, so at that time
the whole title directory is still in /import and not in /title.
This means we should check for contents there, not in /title. Whoops.
The efficient function (that is nearly the same as
https://graphics.stanford.edu/~seander/bithacks.html#DetermineIfPowerOf2)
replaces one loop based instance (which also reused the xx variable
afterwards, whereas it should have used htabmask instead) and one
instance using the population count a.k.a. Hamming weigth.
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
Simpler, and puts the call to CheckIntegrity right where it should be,
instead of being hidden somewhere in a thread class.
This also makes it more obvious what we're getting from the async task.
Oh, and coincidentally, this fixes a random crash that could occur
during the check. I'm not sure why.
This adds a check to ImportTitleDone to make sure all required contents
that are listed in the TMD have been imported before allowing to finish
the import. Not checking for this could allow titles to be left in an
inconsistent state.
There seems to be a race condition between a peripheral device
connecting to the bluetooth controller and it being ready to use.
It's very short and it depends upon the controller, some appear to
connect synchronously and block until the device is ready, others
report the device upon discovery but do not allow communication straight
away. I don't know which is the correct behaviour, or whether it depends
on the peripheral, controller or both. Anyway, Dolphin waits for a
remote to appear and immediately attempts to open the communication
channels, this can fail because the device isn't ready yet, delay, try
again, and it works.
There are other (unlikely) chances the device is busy at random
moments after this initial race condition so it loops around try to
reconnect.
This was inspired by an earlier patch, see here:
https://bugs.dolphin-emu.org/issues/5997#note-20
I can confirm that it works perfectly for me on a bluetooth
controller where otherwise it's impossible to connect (Dell 380
Bluetooth 4.0).
So, a FifoRecorder instance is instantiated as a file-local variable and
used as a singleton (ugh). Most users likely don't regularly use the
FIFO player/FIFO recorder, so this is kind of a substantial waste of
memory.
FifoRecorder's internal RAM and ExRAM vectors are 33554432 and 67108864
bytes respectively, which is around 100.66MB in total.
Just on the game list view on a clean build with nothing loaded, this
knocks debug build memory usage down from ~232.4MB to ~137.5MB, and
release build memory usage down from ~101MB to ~5.7MB.
JosJuice