Site icon Libretro

RetroArch 1.9.4 released!

Libretro Team

EDIT/UPDATE 31/5/2021: We have pushed a new 1.9.4 version. Specifically this fixes a bunch of regressions in the Vita port which unfortunately snuck into the initial 1.9.4 version. If you are using RetroArch on a PS Vita, we highly recommend you redownload the stable again. There are no real changes for other platforms.


RetroArch 1.9.4 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.4 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!

Release notes

Be sure to also read our Libretro Cores Progress Report – lots of work has gone into all of the various cores that are maintained (either by us or elsewhere), and it’d be a shame if the work goes unnoticed. Read it here.

There were some issues with RetroArch on PlayStation TV devices which should now be resolved. Additionally, it’s possible to run RetroArch at 720p now on a PSTV if you use the Sharpscale plugin.

Just like in version 1.9.3, we have been going back and improving code in RetroArch to improve file I/O performance, something that is very important for systems suffering from slow disk storage. Most game consoles would fall in this boat because all file I/O tends to be typically unbuffered on homebrew SDKs. In the process, we have discovered some parts where RetroArch was being inefficient when loading files from compressed files (such as .zip or .7z files). In the past, it would extract this file first to a temporary directory on the disk, and then it would read from this file and load it into the RAM buffer. Now we load it into the RAM buffer directly from the compressed file without first extracting it to disk. As if that wasn’t bad enough, on any platform that supports runahead, we would have to create another copy – even when runahead is disabled. And if cheevos are enabled, that’s another copy. All things combined, it would take 128MB of RAM to load one 32MB GBA ROM. As of 1.9.4, this RAM usage is severely cut down for cores that set ‘need_fullpath’ to false.

PlayStation2 users get a new core, prboom (a Doom 1/2 game engine). Thanks to a new and improved toolchain for PS2, this runs at a very impressive framerate, targeting 60 frames per second with stock settings. There might be some minor dips to the 50s in the busier scenes but nothing too serious, and disabling settings like ‘Wiggle Geometry Fix’ might help alleviate that.

Highlights

Prevent unnecessary extraction (to disk) of compressed content files

In previous versions, when loading content from compressed files, RetroArch always extracts the archive to a temporary file – even when cores specify need_fullpath = false. This is incorrect behaviour. If a core does not explicitly need to load a file from disk via some internal mechanism, the frontend should merely provide it with a data buffer. RetroArch was doing this, but in absurd fashion, i.e.:

1.9.4 fixes the issue. Now if compressed content is loaded into a core that sets need_fullpath = false, the file will be loaded directly into memory – no disk writes will occur.

Additional notes:

Previously, it was in fact impossible to load content inside zip files directly into RAM. This has now also been resolved.

The end result? Less read/write on disk storage, which will make a big difference in terms of game content loading time on systems with slow file I/O (typically game consoles).

Option to select between ‘touched’ elements and physical controller inputs when showing inputs on overlays

The ‘Show Inputs on Overlay’ option was previously ‘broken’ when using remaps: the mapped button is highlighted rather than the pressed button, which is confusing for users and at odds with every other application (in existence) that has on-screen touch controls.

1.9.4 remedies the situation by changing the ‘Show Inputs on Overla’y option from a bool to an enum, with the following settings:

When Show Inputs on Overlay is set to Physical (Controller), the index of the ‘physical’ device to be monitored can be set via a new Show Inputs From Port option (this option did in fact exist already, but was hidden/disabled by a long standing bug)

Changelog

1.9.4

Exit mobile version