This can fix a lot of performance issues, like audio crackling and frame
time spikes. This requires the GameMode package to be installed. See:
https://github.com/FeralInteractive/gamemode
This commit adds a "Game Mode" bool option to the "Power
Management" and "Latency" settings sections, and it can be toggled
on/off without restarting RA.
The actual toggling of game mode happens in a new frontend platform
interface function. Perhaps this will become useful for other platforms
that provide some equivalent of Linux GameMode.
Since the GameMode ABI is fixed, and the API comes as a single,
header-only file with no actual deps, we simply bundle the header
(deps/feralgamemode/gamemode_client.h.) That way, all Linux builds will
have support for GameMode regardless of whether the GameMode development
package is installed or not.
* Added setting to allow/disallow players other than the host from pausing the game.
* Added a sublabel for netplay max connections.
* Fixed port override macro from not being set immediately after the port setting.
* Fixed memory leaks.
* Move ui_companion_driver code out of retroarch.c
* Buildfix
* Fix error - was reading the array out of (preinitialized) bounds
* Remove unused variable
Adds new entry (where the entry for dumping CD is) to eject the disc -
in case the CD drive has no physical button to eject the disc / the
button does not work. Useless for most, but quality of life improvement
for some.
Upstream of patch used by Lakka at build time
1943ad296e/packages/libretro/retroarch/patches/retroarch-99-eject_disc.patch
Pressing the START button removes the device pairing. Useful in case
the device (e.g. gamepad) was paired with a different adapter/computer
and needs to be paired again with current adapter/computer.
To pair again, RetroArch needs to be restarted, so the device list is
populated again.
Upstream of patch used by Lakka at build time
1943ad296e/packages/libretro/retroarch/patches/retroarch-98-remove_bluetooth_pairing.patch
* Any pad can control the menu
== DETAILS
I am not sure I've quite got it so that any pad can *open* the
menu, but I do have it so any pad can control it.
- split out the input processing into a separate method
- track down and squish some hairy bugs that boiled down to
bad pointer math
- it looks like `menu_driver.c` has a mix of line endings, so I
ran it through `dos2unix` so it has consistent line endings
again.
- verified that this change did not impact actual cores
* optimize out cumulative_bits
* Incorporate PR feedback
Many thanks to @jdgleaver for providing these optimizations.
* apply one more optimization
