The Config::AddLoadLayer functions call Load on the layer
explicitly, but Load is already called in the constructor,
so they'd cause the loader's Load function to be called twice,
which is potentially expensive considering we have to read an INI
from the host filesystem.
This commit removes the Config::AddLoadLayer functions because
they don't appear to be necessary.
This was mainly included for debugging, but could end up being confusing
for users, as well as polluting the GL program cache with a mix of uber
and specialized shaders if the option was changed.
On Windows, File::GetTempFilenameForAtomicWrite returns a path
somewhere in C:\Users\XXX\AppData\Local\Temp\{UUID here}\
in which all writes just fail.
Just use the SYSCONF path + ".tmp" for the temporary file name.
These vertex formats enable all attributes. Inactive attributes are set
to offset=0, and the smallest type possible. This "optimization" stops
the NV compiler from generating variants of vertex shaders.
This add support for SD protocol 2 while staying compatible with protocol 1.01.
Most of this is quite hacky, but it seems to be working well.
The original implementation was quite confusing, so I didn't touch most of the stuff I did not understand.
This makes the EGL interface select OpenGL|ES contexts over "desktop"
OpenGL ones.
Possibly not useful for anyone outside my own debugging, but you never
know
It's not particularily useful to list the platform here,
and these kinds of messages that use words as parameters
are more likely to be mistranslated than the average string.
Same as the previous commit, except I'm copying strings
in the other direction because the DolphinWX variants
of these strings could use some improvement.
The spec says it should have an EXT not OES suffix, as it's enabled as
an interaction with GL_EXT_multi_draw_arrays.
On some drivers GetProcAddress() returns NULL, which causes the
GLExtensions init to fail
This 'happened' to work if GetProcAddress() doesn't return NULL on missing
functions (as allowed in EGL) - as the function appears to never be called so
this would not have been noticed.
Mesa also (incorrectly?) exports the EXT version, so this would all
happen to work there, but appears to be contrary to the spec.
This invalid prefix even ended up in the upstream khronos registry, the
issue was reported here:
https://github.com/KhronosGroup/OpenGL-Registry/issues/81
The section is 0x461 bytes long, not 0x460. The config data is also now
initialised to zero to avoid garbage being written to the SYSCONF.
Because our handling has been wrong forever, we discard older BT.DINF
section backups as using them would result in the section being the
wrong size / incomplete again.
It turns out that the last byte of array entries isn't unused (as we
thought); instead, it looks like it's actually part of the main data,
and the length stored next to the name is in fact the length minus one.
Getting it wrong and always storing a null byte in there won't affect
most entries (since the last byte is zeroed most of the time), except:
- IPL.NIK: the length is stored in the last byte, and it must be kept.
- BT.DINF: u8 unknown[0x45] should be another Bluetooth device entry.
- Possibly other unknown affected entries.
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...
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.
Rather than returning 0 / not creating an expected SI interrupt. You can
test this by running VBA-M in a debugger and stopping it while it's
connected to Dolphin: on current master, Dolphin will freeze-up until it
gets a response. With this PR, Dolphin will gracefully disconnect the device, and reconnect if it starts responding again.
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.
The actual problem was combining the values from the date and time
pickers incorrectly. The uninteresting parts of the returned wxDateTime
need to be ignored and the WX documentation says so for the time picker.
I also cleaned up the handling of both widgets a bit, removing redundant
member variables in the process, in order to not risk correctness.
It's a bit confusing to get a yes/no dialogue box without any indication
of what yes or no will do in this situation, so add a short explanatory
sentence.
Only remaining issue is that clicking on the titlebar of the window, to give it focus, is already interpreted as input. But clicking on the window in the task bar, or using alt tab works to get back, without causing an input event.
Changes:
- `ShowDevelopmentWarning` is now under the '[Interface]' group in
Dolphin.ini, with other interface-related settings. So, whoever uses
DolphinQt will have to edit that manually again. Sorry!
- Game search paths and the last file are now shared properly with
DolphinWX
- Qt-only preferences like "Preferred View: list/table" are now
stored using the platform's native settings storage, rather than in
UI.ini
struct GekkoOPTemplate was implemented differently in different
compilation units, which breaks the ODR and could end up causing issues
as symbols exported from one compilation unit could end up being used by
another even if they have different implementations.
This puts them in an anonymous namespace, restricting any generated
symbols to the single compilation unit.
Some code was calling more than one of these functions in a row
(in particular, FileUtil.cpp itself did it a lot...), which is
a waste since it's possible to call stat a single time and then
read all three values from the stat struct. This commit adds a
File::FileInfo class that calls stat once on construction and
then lets Exists/IsDirectory/GetSize be executed very quickly.
The performance improvement mostly matters for functions that
can be handling a lot of files, such as File::ScanDirectoryTree.
I've also done some cleanup in code that uses these functions.
For instance, some code had checks like !Exists() || !IsDirectory(),
which is functionally equivalent to !IsDirectory(), and some
code was using File::GetSize even though there was an IOFile
object that the code could call GetSize on.
The MonoSpaceFont of the LogWindow was using a Windows native way to
specify a font name.
Now it's using wxFONTFAMILY_TELETYPE.
On Win32 it will additionally request the specific font name "Consolas",
so it doesn't use ugly "Courier New". I pilfered that specialization
from Source/Core/DolphinWX/Cheats/ARCodeAddEdit.cpp.
Before, if you extracted a directory like /map/Final/Release/,
Dolphin would create the nested folders map, Final and Release
in the output directory and put the files in Release instead of
just putting the files directly in the output directory.
While setting up a proper NAND for Wii emulation has become much easier
now that disc and online system updates work, they still require users
to have a recent disc game, certificates extracted from IOS or a NAND
dump for online updates to work and to really get all system titles.
This commit adds the ability to do an online update right from
Dolphin itself, which solves that usability issue.
Allows reusing the WAD import logic more easily, whereas UICommon
code can only be used from UICommon and UI.
And managing what's on the NAND is the Core's responsability, not UI.
It didn't work when there were non-ASCII characters
in the directories argument, but it worked fine with
non-ASCII characters in names of found files and folders.
* IOS: WiiRoot shutdown was moved to HW.
* Movie: Don't call UpdateWantDeterminism() if we're not running yet,
because this will automatically be done during the boot process.
Not doing this will result in two NANDs being created.
This is larger than I thought I would be, but unfortunately it's quite
hard to split fixes like this when the handling is wrong in tons of
different places.
The content table is limited in size. It can only hold 16 entries.
Three consequences:
* Since the table cannot grow indefinitely, instead of using a std::map
we use a std::array as we should.
* Remove a hack where the CFD was cleared back to 0 on IPC close (wtf?)
* The CFD now doesn't keep increasing to infinity. It's unknown if this
would fix anything at all, but some issues in the past were caused
by CFDs being excessively large.
Other minor changes:
* Simplify save state logic.
* Keep track of the UID like ES does. Not sure how useful this is, but
we can do this very easily so why not.
* Remove the guesswork and use the actual error codes.
* Add more error checking to make Dolphin less likely to crash.
Something that should be done in the future: deduplicate the filesystem
logic. Something that takes one line in the actual ES code takes
10+ lines in our implementation... while duplicating the FS logic...
This will likely harder to fix though, so I'm leaving that
for another time.
It seems to make no difference besides allowing lower latencies and more
stability on hardware OpenAL cards. Maybe the Wait() call waits for too
long, causing buffers underruns.
Before these changes each value of latency were actually 5ms, with a
minimum latency of ~10 ms. If it was set to 4 ms on the UI, the actual
latency was 10 + 5 * 4 = 30 ms.
Now 30 ms on the UI means 30 ms on the backend.
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.
This seems like an oversight in the old code, because
what's the point of loading user files if the titles
in them are going to be ignored for nearly all games?
This commit fixes the issue by making the first LoadMap
variant not overwrite entries and making the constructor
do everything in the opposite order. An alternative solution
would be to make the second LoadMap variant overwrite entries.
This fixes the global-static fifo object causing infinite hangs in some
cases. Notably, failure to initialize a graphics backend would result in
BlockingLoop::Prepare being called but never executing Run(), leaving the
object in a bad state.
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.
The GameCube IPL sounds the same when using the free ROM as it does when
using the official ROM (and in Audacity, I couldn't visually distinguish
between the waveforms). It has a reference to an unimplemented function
at 0x8644 which seems to only be used in an inlined version of the CARD
ucode.
This allows the user to go through the Wii Menu first boot setup
screen when they launch the System Menu for the first time.
Most useful on a clean profile, after doing a full system update,
to configure settings like the console country.
This rewrites the SysConf code for several reasons:
* Modernising the SysConf class. The naming was entirely cleaned up.
constexpr for constants.
* Exposing less stuff in the header.
* Probably less efficient parsing and writing logic, but much simpler
to understand and use in my opinion. No more hardcoded offsets.
No more duplicated code for the initial SYSCONF generation.
* More flexibility. It is now possible to add and remove entries,
since we rebuild the file. This allows us to stop spamming
"section not found" panic alerts; we can now use and insert
default entries.
On a real Wii, the title list is not in any particular order. However,
because of how the flash filesystem works, titles such as 1-2 are
*never* in the first position. We must keep this behaviour, or some
versions of the System Menu may break.
Will be used from several functions to verify the signatures for
different containers (TMDs, tickets, device signed blobs).
An option was added to disable signature checks, because that could be
useful for people trying to import unsigned stuff.
stat() returns an error code in errno on both POSIX compliant
platforms and Windows.
This means we should always use errno instead of GetLastErrorMsg
which uses GetLastError() (Win32) on Windows.
POSIX allows one or more trailing slashes for directories.
From POSIX.1-2008, section 3.271 (Base Definitions / Pathname):
> A pathname can optionally contain one or more trailing <slash>
> characters. Multiple successive <slash> characters are considered to
> be the same as one <slash>, except for the case of exactly two
> leading <slash> characters.
On Windows, the extra trailing slashes are ignored for directories too.
This makes it possible to catch errors earlier so that file systems
simply fail to load instead of behaving oddly. It also makes it possible
to check for errors that weren't checkable before, like the end of a
directory being after the end of the parent directory.
Instead of expecting callers to know how the size of directory file infos
relates to which files are in which directories, filesystems now offer a
GetRoot() method, and file infos offer a way to get their children. As
a bonus, m_FileInfoVector no longer has to be created and kept around
in RAM. Only the file info objects that actually are used are created.
Not initializing until the filesystem is used is good when
a filesystem is constructed and then never used, but nobody does that.
This simplifies the code a little and lets all methods be const.
Instead of using lots of small scattered reads to read the FST,
only one big read is used, which is more efficient.
This also means that the FST only allocates memory once and stores all
strings close to each other - good for the CPU cache. The file info
objects use pointers to this FST memory of containing data themselves.
Keeping around the big m_FileInfoVector containing objects with only
pointers is a bit unnecessary, but that will be fixed soon.
Instead of calling GetPathFromFSTOffset for every file info, FindFileInfo
now only looks at names in directories that are included in the path.
For the common case of searching for "opening.bnr", this means that
only root-level files and directories have to be searched through.
Some callers already have the file info, making the relatively slow
FindFileInfo calls unnecessary. Callers that didn't have the file info
will now need to call FindFileInfo on their own.
Some callers (i.e. ISOProperties) don't want the full path, so giving them
it is unnecessary. Those that do want it can use GetPathFromFSTOffset.
Not storing full paths everywhere also saves a small bit of RAM and is
necessary for a later commit. The code isn't especially pretty right now
(callers need to use FST offsets...) but it'll become better later.
GC/Wii filesystem internals shouldn't be exposed to other classes.
This change isn't especially useful by itself, but it opens up the
way for some neat stuff in the following commits.
Too much boilerplate that is duplicated if we use curl directly.
Let's add a simple wrapper class that hides the implementation details
and just allows to simply make HTTP requests and get responses.
Makes it slightly less likely to forget a check and end up doing an
out-of-bounds access. Also makes it obvious that we *are* indeed
checking whether the handle is valid, instead of hiding it in
HasOwnership (which won't handle the root key handle case properly).
This code hadn't been touched since 2010. Nowadays, the panic alert
setting is loaded by ConfigManager and applied in UICommon.
VideoConfig has no business messing with it.
I don't see why we need to call ShutdownWiiRoot on InitializeWiiRoot.
Also, atexit? Really? Not only is this unnecessary, it will also cause
ShutdownWiiRoot to be called twice in rapid succession for no reason.
The config must only be restored after the HW has shut down, not while
it is still running, because the HW can still query the config, which
can lead to inconsistent states.
This fixes WiiRoot not being able to copy back saves on shutdown.
This ioctlv is used to get an IOSC decrypt handle for a title.
It is known to be used internally by the WFS modules, but it can also
be used from the PPC under some conditions.
Brings us down to 2 essentially unimplementable ioctlvs (syscalls which
seem to return kernel thread priorities...), and 1 known but
unimplemented ioctlv (VerifySign).
In the future, NAND filesystem access will be limited to one IOS
instance, for safety reasons and to make it possible to consider
supporting NAND images. This means that any code accessing the NAND
filesystem must go through the FS device, both for code that is
external to IOS and internal.
Because we don't want to introduce any singleton, this requires
internal IOS code that needs NAND access to be part of an IOS device
class, so they can access the FS device easily.
Making some of the internal ES implementation functions member
functions also prevents them from being (mis)used outside of IOS,
since they cannot be called everywhere anymore.
OpenALStream was querying the backend for AL_EXT_float32 support (which
suceeds), but AL_FORMAT_STEREO_FLOAT32 was defined incorrectly.
Also changes OpenALStream to query for AL_EXT_MCFORMATS (multichannel
support) rather than hard-coding that it doesn't work on macOS.
They have been broken since 2 years and no one has noticed,
which shows that no one really cares.
And it's arguable whether showing the CPU info is really useful.
I don't see any reason to disable loading the IPL if bHLE_BS2 is
disabled. bHLE_BS2 should only cause us not to run the IPL, but not
skip loading it in the first place. More importantly, without always
loading it, this causes issues when trying to launch only the GC IPL
while having bHLE_BS2 = false.
They're essentially the same. To achieve this, this commit unifies
DolReader and ElfReader into a common interface for boot executable
readers, so the only remaining difference between ELF and DOL is
how which volume is inserted.
* Move out boot parameters to a separate struct, which is not part
of SConfig/ConfigManager because there is no reason for it to
be there.
* Move out file name parsing and constructing the appropriate params
from paths to a separate function that does that, and only that.
* For every different boot type we support, add a proper struct with
only the required parameters, with descriptive names and use
std::variant to only store what we need.
* Clean up the bHLE_BS2 stuff which made no sense sometimes. Now
instead of using bHLE_BS2 for two different things, both for storing
the user config setting and as a runtime boot parameter,
we simply replace the Disc boot params with BootParameters::IPL.
* Const correctness so it's clear what can or cannot update the config.
* Drop unused parameters and unneeded checks.
* Make a few checks a lot more concise. (Looking at you, extension
checks for disc images.)
* Remove a mildly terrible workaround where we needed to pass an empty
string in order to boot the GC IPL without any game inserted.
(Not required anymore thanks to std::variant and std::optional.)
The motivation for this are multiple: cleaning up and being able to add
support for booting an installed NAND title. Without this change, it'd
be pretty much impossible to implement that.
Also, using std::visit with std::variant makes the compiler do
additional type checks: now we're guaranteed that the boot code will
handle all boot types and no invalid boot type will be possible.
I didn't know better back then, but the boot type is only supposed to
be used for the actual boot params. It shouldn't be used or changed
after booting.
- 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.
Disassemble code without the additional text for humans, like the
current PC and opcode hex values, so that it can be reassembled.
I'm not updating any commented-out tests here.
You may want to read the PR #2047 comments before reading this.
Dolphin attempts to support an unencrypted type of Wii discs
that apparently is identified by a 4-byte integer at 0x60
being non-zero. I don't know what discs (if any) would be
using that format, so I haven't been able to test Dolphin's
support for it, but it has probably been broken for a while.
The old implementation is very short but also strange.
In CreateVolumeFromFilename, we read a 4-byte integer from
0x60, and if it's non-zero, we create a CVolumeGC object
instead of a CVolumeWiiCrypted object. This might seem like
it makes no sense, but it presumably worked in the past
because IsVolumeWiiDisc used to check the volume type by
reading the magic word for Wii straight from the disc,
meaning that CVolumeGC objects representing unencrypted Wii
discs would be treated as Wii discs by pretty much all of
Dolphin's code except for the volume implementation code.
(It wasn't possible to simply use CVolumeWiiCrypted, because
that class only handled encrypted discs, like the name says.)
However, that stopped working as intended because of ace0607.
And furthermore, bb93336 made it even more broken by making
parts of Dolphin expect that data read from Wii discs needed
to be decrypted (rather than the volume implementation
implicitly deciding whether to decrypt when Read was called).
Disclaimer: Like I said before, I haven't been able to test
any of this because I don't have any discs that use this
unencrypted Wii disc format, so this is all theoretical.
Later, PR #2047 tried to remove Dolphin's support for
the unencrypted Wii disc format because seemingly no
discs used it, but the PR got closed without being merged.
At the end of that PR, I said that I would make a new PR
with a better implementation for the format after PR #2353
was merged. Now that PR #2353 is merged (two years later...)
and PR #5521 is merged, the new implementation was easy to
make, and here it is!
Untested.
Normal users don't care about it. In fact, people care so
little about it that the Wii implementation of it was broken
starting from when it was implemented (eb65601) to 7 years
later (e0a47c1), apparently without anyone reporting it.
Léo Lam