This commit renames the "Services" tab to "Network" and adds a combobox that allows the user to select the network interface that yuzu should use. This new setting is now used to get the local IP address in Network::GetHostIPv4Address. This prevents yuzu from selecting the wrong network interface and thus using the wrong IP address. The return type of Network::GetHostIPv4Adress has also been changed.
Service::NIFM::IGeneralService::GetCurrentIpConfigInfo currently hardcodes 192.168.1.100 as the IP address, which prevents LAN play from working correctly.
This was mainly used to keep track of mapped buffers for later unmapping. Since unmap is no longer implemented, this no longer seves a valuable purpose.
Skip unmapping nvdec buffers to avoid breaking the continuity of the VP9 reference frame addresses, and the risk of invalidating data before the async GPU thread is done with it.
This setting is best referred to as a speed limit, as it involves the limits of all timing based aspects of the emulator, not only framerate.
This allows us to differentiate it from the fps unlocker setting.
We were including the first 2 default miis which are not meant to be shown in games. With this change, we properly retrieve the 6 default miis shown in games, with 3 of each gender.
bcat: Fix settings access
telemetry_session: Fix settings accesses
So this is what I get for testing with the web service disabled.
touch_from_button: Fix settings access for clang
Creates a new BasicSettings class in common/settings, and forces setting
a default and label for each setting that uses it in common/settings.
Moves defaults and labels from both frontends into common settings.
Creates a helper function in each frontend to facillitate reading the
settings now with the new default and label properties.
Settings::Setting is also now a subclass of Settings::BasicSetting. Also
adds documentation for both Setting and BasicSetting.
If someone else wants to support other mod formats in the SDMC
directory, that can be added later. For now, just allow RomFS modding
here and force people to do other types of mods the old way.
Addresses review comments.
Co-authored-by: LC <mathew1800@gmail.com>
Currently, processing of audio samples is called from AudioRenderer's Update method, using a fixed 4 buffers to process the given samples. Games call Update at variable rates, depending on framerate and/or sample count, which causes inconsistency in audio processing. From what I've seen, 60 FPS games update every ~0.004s, but 30 FPS/160 sample games update somewhere between 0.02 and 0.04, 5-10x slower. Not enough samples get fed to the backend, leading to a lot of audio skipping.
This PR seeks to address this by de-coupling the audio consumption and the audio update. Update remains the same without calling for buffer queuing, and the consume now schedules itself to run based on the sample rate and count.
bunnei