* Apply translations in fr
* Apply translations in ru
* Apply translations in b+zh+Hans
* Apply translations in b+zh+Hant
* Apply translations in de
* Apply translations in el
* Apply translations in ja
* Apply translations in ar
* Apply translations in ta
* Apply translations in pl
* Apply translations in ko
* Apply translations in es
* Apply translations in pl
* Apply translations in in
* Apply translations in it
* Apply translations in b+es+419
* Apply translations in hu
`PreferenceSettings` was removed in favor of:
* `AppSettings`: stores general purpose settings mostly used for UI configuration and state
* `EmulationSettings`: stores emulation-related settings, most of these are passed to native emulation code
This commit reverts PR #2037. Passing `NativeSettings` to emulation code through a member reference, instead of a local variable, caused unpredictable crashes when using custom GPU drivers (v615+) on some Qualcomm SoCs.
The exact cause of the issue remains unknown, my best guess is that it was caused by an incorrect optimization performed on the Kotlin bytecode in release mode, which caused an issue when reading memory that had been forked, because of running emulation in a separate process.
Runtime settings modification will be reimplemented in the future via an alternative method.
Indirect layers are used by the game to render layer on its own, the game allocates a buffer with the size from `GetIndirectLayerImageRequiredMemoryInfo` and uses `GetIndirectLayerImageMap` to draw the applet contents into the buffer.
As we don't LLE applet implementations nor do our HLE implementations draw equivalent applets, we cannot submit this to the guest. As a result, these functions are stubbed with the framebuffer being cleared to red.
Stubbing these functions allows titles such as Dark Souls to not crash while initializing indirect layers.
Accessing the settings class during the execution of the `OnChangedCallback` results in a deadlock, as accesses to values are protected by a mutex. Instead, we now keep a local copy of the relevant settings and update those with the new value.
I missed that addSubpass was only called once-per-subpass, meaning that if a new barrier req was discovered several draws into the RP it wouldn't be applied. Split out barriers into a seperate function to avoid this.
Full pipeline barriers between every RP can be extremely expensive on HW, by analysing the inputs and outputs of a draw it's possible to construct a much more optimal barrier that only syncs what is neccessary.
Sometimes view pointers may change despite the underlying Vulkan image view not actually changing, so use vk::ImageViews for tracking to keep RP breaks to a minimum.
