Placing the array wholesale into the header places a copy of the whole
array into every translation unit that uses the data, which is wasteful.
Particularly given that this array is referenced from three different
translation units.
This also changes the array to contain pairs of const char*, rather than
QString instances. This way, the string data is able to be fixed into
the read-only segment of the program, as well as eliminate static
constructors/heap allocation immediately on program start.
* Core: pass down Core::System reference to all services
This has to be done at once due to unified interface used by HLE/LLE switcher
* apt: eliminate Core::System::GetInstance
* gpu_gsp: eliminate Core::System::GetInstance in service
* hid: eliminate Core::System::GetInstance
* nwm: eliminate Core::System::GetInstance
* err_f: eliminate Core::System::GetInstance
* Try to manually overwrite
* Update appveyor.yml
* Update appveyor.yml
* what about don't overwrite?
* what if only syyu once?
* still need to syyu twice it seems
* add comment as well as trigger rebuild
what happened to msvc
* it seems that I can just remove the -Syy
Keeps the individual behaviors in their own functions, and cleanly
separate. We can also do a little better by converting the relevant IDs
within the core to a QString only once, instead of converting every
string into a std::string.
Disambiguates what the string represents to help translators more easily
understand what it is that they're translating. While we're at it, we
can move the code to its own function, so that we don't need to specify
the same string twice.
These functions are pretty much identical to BeginImportProgram and EndImportProgram.
We don't need to do anything special in EndImportProgramWithoutCommit and CommitImportPrograms because we don't need to implement the two-phase title installation that the 3DS uses to prevent corruption of the title.db.
FS subfiles are created with File::OpenSubFile, they have a start offset that must be added to all read/write operations.
The implementation in this commit is done using a new FileBackend that wraps the FS::File along with the start offset.
Any SDL invocation can call the even callback on the same thread, which can call GetSDLJoystickBySDLID and eventually cause double lock on joystick_map_mutex. To avoid this, lock guard should be placed as closer as possible to the object accessing code, so that any SDL invocation is with the mutex unlocked