RetroArch 1.9.6 has just been released.
Grab it here.
If you’d like to learn more about upcoming releases, please consult our roadmap here. The next version of Lakka (with an updated RetroArch 1.9.6 version) is scheduled to be released a week from today.
Remember that this project exists for the benefit of our users, and that we wouldn’t keep doing this were it not for spreading the love with our users. This project exists because of your support and belief in us to keep going doing great things. If you’d like to show your support, consider donating to us. Check here in order to learn more. In addition to being able to support us on Patreon, there is now also the option to sponsor us on Github Sponsors! You can also help us out by buying some of our merch on our Teespring store!
Be sure to also read our Libretro Cores Progress Report (a link will appear here later).
Windows users (with XAudio2 audio driver): RetroArch would previously hang/lock up if you happened to disconnect your current audio device. For instance, this could happen if you were playing with headphones on and you decided to suddenly disconnect your headphones. This has now been fixed. Instead of it locking up the program, instead the sound is just lost instead.
Security concerns over the AI Service on Windows have been addressed.
Improvements to the Windows installer have been made. This should hopefully prevent potentially disasterous situations from happening again. This could happen for instance when the user pointed the installer to install to a directory he should not be pointing to (like C:\Program Files for instance or the desktop), and did not heed the warning.
Linux users should hopefully no longer experience crashes when toggling between normal and threaded video mode with OpenGL thanks to a patch by grant2258.
The Direct3D 11 driver has been improved for Windows users thanks to Stenzek (DuckStation author). Several fixes: tear control support is queried. If not supported, flip mode presentation will not be used and Direct3D will resort back to the legacy blit model instead (less optimal and worse windowed mode). DXGI Alt+Enter handling has been disabled since it would conflict with RetroArch’s fullscreen mode switch. Non-vsynced output without the flip model should also be properly fixed now, when tear support is enabled and flip model is used, it should be possible to fastforward.
When scanning content, the amount of time required to push each new entry to the resultant playlist increases exponentially with playlist size. For small romsets this is typically unnoticeable, but when dealing with very large data sets (e.g. arcade romsets) scanning quickly becomes impractical. A full arcade romset can take several hours to scan – or days on Linux (where certain file operations that are a NOOP on Windows, etc. are very slow).
This happens because the ‘push entry to playlist’ routine is highly inefficient. It has to check whether the entry being added already exists in the playlist, which requires a content path comparison – which in turn involves several expensive operations to resolve ‘real’ file paths and deal with any inconsistencies in archive path notation. The problem is that these expensive operations happen every time: push an entry to the playlist, and it will process and compare every existing content path until it finds (or does not find) a match; push another entry and it will process every path again. Once a playlist hits a couple of thousand entries, this constant reprocessing grinds the scanning process to an effective halt.
1.9.6 solves the issue by caching all parameters derived from content paths on first use, so when pushing multiple entries to playlists the expensive path operations are only carried out once per existing entry. In addition, hash keys are used to minimise lengthy string comparisons. This greatly improves the efficiency of content scanning – and also of playlist management features (since these require nested playlist searches, which now also use the cached content path values/hashes).
For example, before with 1.9.5 and earlier, it was effectively impossible to scan 100k files. Now with 1.9.6, on a low spec development machine running Linux:
* A manual scan of 100k files takes 20 minutes
* Performing a Clean Playlist operation on the resultant playlist takes 5 minutes
1.9.6 adds support for the remapping of individual controllers to arbitrary core input devices. This allows multiple controllers to be assigned to one input. To configure this, a new Mapped Port option has been added to the Quick Menu > Controls > Port N Controls menu:
Here, the Port 2 Controls refers to the physical controller; Mapped Port refers to the core port that will receive input from this controller.
For example, to map physical controllers 1 and 2 to the player 1 input of a core, set the following:
* Port 1 Controls > Mapped Port > 1
* Port 2 Controls > Mapped Port > 1
There are various use cases for this remapping:
* It allows multiple controllers to be used when playing hotseat multiplayer games that normally support only a single controller
* It allows hybrid-type controllers (e.g. two joysticks mounted in a cabinet) to be used as a single device
* It allows easy swapping of player 1/player 2 (etc.) inputs – for example, when the PSX version of Metal Gear Solid asks the player to plug their controller into port 2
Note that these configuration settings are independent from the main RetroArch config file. To make any changes persistent, a Core, Content Directory or Game remap file must be saved.
1.9.6 also cleans up a long standing issue when configuring remaps: before, changes to Device Type and Analog to Digital Type via the Quick Menu while a core is running will ‘bleed through’ to the main config file. This is harmful and unintuitive behaviour. With 1.9.6, the global settings for these values are cached when initialising a core, and restored when the core is unloaded. (This essentially became a necessity for using the port remapping functionality, since it is rather easy to create complex configs that should in no way touch the main config file…)
RetroArch is able to map the left or right analog stick of a gamepad to D-Pad input via the per-port Analog to Digital Type menu setting. Unfortunately, this is a ‘trap’ for new users: mapping a stick in this fashion disables its analog input, which creates confusion when using cores that have native analog support. Many users enable Analog to Digital Type by default, then complain on reddit/discord that analog controls do not work for PSX/N64/etc. games.
1.9.6 modifies the Analog to Digital Type functionality such that it can be disabled automatically for cores that have native analog support. The setting now has the following values:
* None: No mapping
* Left Analog: Map left stick to D-Pad, but disable mapping if core attempts to read analog input
* Right Analog: Map right stick to D-Pad, but disable mapping if core attempts to read analog input
* Left Analog (Forced): Always map left stick to D-Pad, disabling left stick analog input
* Right Analog (Forced): Always map right stick to D-Pad, disabling right stick analog input
In addition, a sublabel has been added to the Analog to Digital Type menu entries, which should help to explain what they actually do.
Finally, this PR required some modification of input overlay-related code, during which the following bugs were fixed:
* There is no longer contention between analog stick inputs when an input overlay and physical controller are attached to the same port
* Input overlays no longer generate analog stick input in addition to D-Pad input when Analog to Digital Type is set to the left or right stick
Several security-related improvements have been made to the AI Service functionality for Windows in an attempt to address concerns that this could be abused. Speech input is no longer sent as a commandline argument to PowerShell, and both the language and speed parameters are properly sanitized and only allow for a few hardcoded safe values to be passed now. This should mitigate most of the attacks that could be thought of with regards to injection.
Several safeguards have been put in place to prevent people from making a severe mistake during the installation process on Windows. With the installer program, it is no longer possible to install RetroArch to a directory that has existing files or subdirectories. Instead, it has to be written in a new directory. We have to insist on this because the uninstallation process involves wiping RetroArch’s entire directory and everything in it. In the past, people could have made the mistake of pointing it to “C:\Program Files” without putting it in a separate subdir, with disastrous results on deinstallation. While the installer program did warn about this and asked you with a dialog prompt if you were sure, nevertheless we cannot take this risk to begin with. This has been resolved by simply deallowing this to happen by forcing you to install RetroArch to a new empty dir.
1.9.6
RetroArch is now available on the Amazon App Store! Note: Will work best with a gamepad. Link 