std::function is allowed to heap allocate if the size of the captures
associated with each lambda exceed a certain threshold. This prevents
potentially unnecessary reallocations from occurring.
This holds the archives which include the SelfNCCH archive which holds the RomFS files. If we don't reset it the LayeredFS class can't get destructed and mods files won't be released.
The original path (file_name.exefsdir) is still supported, but alternatively users can choose to put exefs patches in the same place as LayeredFS files (`load/mods/<Title ID>/exefs`).
Only enabled for NCCHs that do not have an override romfs.
LayeredFS files should be put in the `load` directory in User Directory. The directory structure is similar to yuzu's but currently does not allow named mods yet. Replacement files should be put in `load/mods/<Title ID>/romfs` while patches/stubs should be put in `load/mods/<Title ID>/romfs_ext`.
This implementation is different from Luma3DS's which directly hooks the SDK functions. Instead, we read the RomFS's metadata and figure out the directory and file structure. Then, relocations (i.e. replacements/deletions/patches) are applied. Afterwards, we rebuild the metadata, and assign 'fake' data offsets to the files. When we want to read file data from this rebuilt RomFS, we use binary search to find the last data offset smaller or equal to the given offset and read from that file (either from the original RomFS, or from replacement files, or from buffered data with patches applied) and any later files when length is not enough.
The code that rebuilds the metadata is pretty complex and uses quite a few variables to keep track of necessary information like metadata offsets. According to my tests, it is able to build RomFS-es identical to the original (but without trailing garbage data) when no relocations are applied.
The DIGIT filter was incorrectly implemented as preventing all digits. It actually limits the maximum digit count to max_digits, according to ctrulib and hardware testing.
- We have some important audio settings, makes them more discoverable.
Co-Authored-By: bunnei <bunneidev@gmail.com>
Co-authored-by: bunnei <bunneidev@gmail.com>
Until we get a on screen display or async shader loading, we should at
least have some measure of progress in the meantime. This is 90% a port
from the loading screen I made for yuzu, but with a slightly different
changed detection for when to display the ETA. Now we keep track of a
rolling estimate for shader load ETA and only display a ETA if its going
to take longer than 10 seconds.
Ninja on OSX lately is giving an error where it gets in a cmake
reconfiguration loop. It constantly reruns cmake and detects that the
build file changed, so it reruns it again and again until it times out.
Not going to deal with this right now.
