BluetoothEmu had its own bdaddr_t type which is a old style C struct
and typedef, which makes comparisons and copies a bit ugly.
On the other hand, BTReal had its own btaddr_t type using std::array.
To make things very slightly nicer, this commit changes the Bluetooth
code to use a single type (std::array<u8, 6>) for all BT addresses.
Imports/exports don't always use the title key. Exporting a title and
importing it back uses the PRNG key (aka backup key handle or key #5),
not the title key (at all).
To make things even more fun, some versions of IOS have a bug that
causes it to use a zeroed key instead of the PRNG key. When Nintendo
decided to fix it, they added checks to keep using the zeroed key only
in affected titles to avoid making existing exports useless.
(Thanks to tueidj for drawing my attention to this.
I missed this edge case during the initial implementation.)
This commit implements these checks so we are using the correct key
in all of these cases.
We now also use IOSC for decryption/encryption since built-in key
handles are used. And we now reject any invalid common key index,
just like ES.
Core::PauseAndLock requires all calls to it to be balanced, like this:
const bool was_unpaused = Core::PauseAndLock(true);
// do stuff on the CPU thread
Core::PauseAndLock(false, was_unpaused);
Aside from being a bit cumbersome, it turns out all callers really
don't need to know about was_unpaused at all. They just need to do
something on the CPU thread safely, including locking/unlocking.
So this commit replaces Core::PauseAndLock with a function that
makes both the purpose and the scope of what is being run on the
CPU thread visually clear. This makes it harder to accidentally run
something on the wrong thread, or forget the second call to
PauseAndLock to unpause, or forget that it needs to be passed
was_unpaused at the end.
We also don't need comments to indicate code X is being run on the
CPU thread anymore, as the function name makes it obvious.
The region mismatch check that we used can give false positives.
Skipping the check won't lead to any harm - games will ignore
save files that have a non-matching fourth game ID character.
According to http://scanlines16.com/en/blog-3/retro-gaming/game-cube/gamecube-korean-master-list/,
Korean GC releases use the following country codes:
- E or W for games in English
- K for games in Korean
- Unknown value for games in Japanese (my guess is that they might
have made the discs bit-for-bit identical to Japanese releases
because the regions of these games are already set to NTSC-J)
As far as I know, the GC has no Taiwanese releases, which is what
the W country code is used for on the Wii. But I could be wrong.
A small note: The country_byte == 'K' check in the code isn't
actually necessary as long as RegionSwitchGC returns NTSC_J
for 'K', but I thought it would be better to not rely on that.
The county code isn't 100% reliable for detecting the region.
For instance, some games released in Korea have the country
code E even though they're region-locked to NTSC-J consoles.
This commit makes the GC disc region detection match the Wii
disc region detection (apart from the region value being in
a different place on the disc).
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.
Tracking a buffer's size manually and storing it under a name that
does not make it obvious it is related to the buffer is really... meh.
Also gets rid of the need to manually manage its capacity and
new/delete an array.
This commit merges the import and export contexts into a single context
because this is what IOS does, which means we can only reproduce its
behaviour correctly if we use a single context for both operations.
The other reason is that having two separate and very similar structs
is not really a good idea.
While working on this commit, I was notified that our handling of
ImportTmd/ExportTitleInit is not correct. In particular, we always use
the title key for both importing and exporting, which is wrong. To make
this easier to fix in a follow-up PR, the context now also has a title
key field, just like ES. This also lets us avoid computing it every
single time in ImportContentDone.
Allows them to be reused easily. Still a bit too much duplicated code
in my opinion (OpenContent/SeekContent/ReadContent should just call
FS code), but this is a start.
I think I do not need to explain why hardcoding space usage for two
random directories when we can calculate it and when IOS doesn't
actually do that is wrong.
There are some cases where overriding the opening.bnr names
isn't desirable, such as when someone has several modded
versions of a game that differ in names but not game IDs.
This was causing Dolphin to always save "WriteToWindow = False". Instead
of disabling logging to the window (a config value), tell LogManager
that there's no window to log to (a runtime state).
This is a remake of https://github.com/dolphin-emu/dolphin/pull/3749
Full credit goes to phire.
Old message:
"If none of the texture registers have changed and TMEM hasn't been invalidated or changed in other ways, we can blindly reuse the old texture cache entries without rehashing.
Not only does this fix the bloom effect in Spyro: A Hero's Tail (The game abused texture cache) but it will also provide speedups for other games which use the same texture over multiple draw calls, especially when safe texture cache is in use."
Changed the pr per phire's instructions to only return the current texture(s) if none of the texture registers were changed. If any texture register was changed, fall back to the default hashing and rebuilding textures from memory.
Leo Lam