The Libretro Team
patreon
RetroArch 1.9.3 released!
🕑 Added 2021-05-16 22:49:43 +0000 UTC
RetroArch 1.9.3 has just been released.
Read the full article here.
Grab it here.
Release notes
We have a roadmap now (see here), and you can expect more frequent releases from this point on. We are aiming for a new version every two weeks. We were initially aiming to have the Lakka version ready to be released concurrently with this version, but had to postpone it. We are definitely aiming to have a new Lakka version ready with future releases of RetroArch though.
We have implemented core info file caching and enabled this by default for the console platforms. This should lead to significantly reduced startup times and content loading after the first initial startup. The first time RetroArch starts up (and/or new core info files are added), it will need to build/rebuild the cache. After that though, it only has one cached file it has to load at startup instead of having to sequentially read every single core info file. This used to take a very long time on platforms with slow disk I/O (such as game consoles). PSP/Vita and 3DS users in particular will definitely notice these improvements.
WiiU users get a couple of new cores, such as bk (the Oberon RISC emu), xRick (the Rick Dangerous game engine reimplementation), and REminiscence (the Flashback game engine reimplementation).
Highlights
Core info file caching
It seems that on platforms with slow disk I/O (mostly all game consoles), it takes the same amount of time to load a file no matter how large it is (within reason) – so ~300 ms to load one info file, and the same ~300 ms to load everything stored in one cache file. Loading ~80 info files takes forever – and basically constitutes almost all the startup time on these systems. This reality is what has led to a new feature called ‘core info file cache’. An anecdotal report from the person who implemented this – previously without core info file caching t took 29 seconds just to boot XMB. With the core info file cache, it only takes 12 seconds. On RGUI, it boots in 3 seconds or less. Significant reductions to be sure.
Things you should know about the core info file caching
- Core info cache can now be enabled/disabled on all platforms via a new Settings > Core > Cache Core Info Files option
- Core info cache file are stored as core_info.cache
- The core info cache file is compressed (rzip) to further reduce disk I/O
- The presence of a core_info.refresh file in the core info directory will force a one-time refresh of the info cache. This file is generated automatically when toggling on the Cache Core Info Files option, and we will also add it to core info file packaging such that updating info files (either manually or via the online updater) will force a refresh
- The core info cache no longer contains ‘core is locked’ and ‘firmware missing’ data fields; these are ‘dynamic’ properties that must be determined at runtime
- The ‘core is locked’ status is now determined on core info initialisation by parsing the core directory listing, rather than by performing individual ‘lock file exists’ checks. This minimises file I/O, and greatly improves performance on devices with slow storage
- While parsing the core info cache file, we now avoid unnecessary strdup()s when adding entries to the resultant cache list
(Static Platforms) Add option to not restart RetroArch when launching content with the currently loaded core
Before, whenever content was loaded using a static build of RetroArch (i.e. most of the console ports), a new process is forked. This basically means that RetroArch in it’s entirety is reloaded, which can be quite slow.
This kind of ‘reload’ is required when changing cores (since each is a stand-alone application) – but if the core we want to launch is already loaded, then it’s wasted effort.
1.9.3 adds a new Always Reload Core on Run Content option under Settings > Cores on statically built platforms. When enabled (by default on consoles), the current existing behaviour is maintained. When disabled, launching content with a core that is already loaded will skip the process fork/reinitialisation and just load the content directly.
On an o3DS testing setup, this reduces content load times by 60%-70%, depending upon the core.
Important caveats:
- There is a significant annoyance in the way that static builds work. If you run the ‘top level’ RetroArch app, then everything works as you would expect – but if you run a core directly (e.g. a specific core cia on 3DS), RetroArch doesn’t actually have any way of knowing which core is currently loaded. It ‘assumes’ you are running the last loaded core – which may not be the case. If it isn’t, the first ‘run content’ operation with Always Reload Core on Run Content disabled will cause an unnecessary fork (but the next ‘run content’ will behave correctly). Unfortunately there is nothing we can do about this…
Changelog
1.9.3
- 3DS: Disable menu screensaver animations in XMB/GLUI
- COMMAND: Initialize netcmd->cmd_source_len before recvfrom()
- CONTENT LOADING/STATICALLY LINKED: Ensure ‘Always Reload Core on Run Content’ setting is applied when loading content via the file browser
- CONTENT LOADING/EMSCRIPTEN: Fix content loading via file browser on platforms with ‘broken’ core handling (i.e. emscripten)
- CORE INFO: Skip whitespace when writing compressed core info cache files
- CORE INFO/FILE IO: Core Info cache; significant file I/O performance improvements on systems with slow disk file I/O
- CORE INFO/FILE IO: Enable core info cache by default on all ‘console’ platforms
- FREEBSD: FreeBSD build fix
- LAKKA: Support for tweaking CPU governors/scaling policies
- LAKKA: This adds managed policies and settings to store them and reload them at startup
- LIBRETRO API: Add API extension for cores to override frontend fast-forward state
- MENU/RGUI: Fix saving of config files/overrides when ‘Lock Menu Aspect Ratio’ is enabled
- SHADERS: Fix ‘Auto-Shader Delay’ functionality
- UWP/D3D11: Disable mipmap generation
- UWP/XBOX: Add ‘Force 4K resolution’ option (Force the resolution to the fullscreen size on Xbox, if set to 0, a fixed value of 3840 x 2160 will be used)
