RetroArch File Structure Improvement Suggestions

Description

I like the fact that RetroArch, despite all the nuances and complexities in game emulation, remains true to the Plug and Play principle.

It seems to me that it would be great to separate directories more strictly for files that a user, in fact, should not touch, and files that, on the contrary, a user may interact regularly. By "more strictly" I mean leave users the freedom they have now to change directories, but change some of the default directories.

I will give an example for macOS.

RetroArch uses two main directories by default: ~/Library/Application Support/RetroArch for assets, configs, cores, etc., and ~/Documents/RetroArch — for saves, states, BIOS images, etc. By default, Library folder (~/Library) is hidden for macOS users and a user's freedom of action within it is very limited, since changes to files in it can cause irreversible damage to the system. In fact, casual users do not even know that this folder exists and can be accessed.

I am confused by the following points in the current RetroArch file structure:

Screenshots are located in ~/Library/Application Support/RetroArch/screenshots directory. I believe that screenshots, like all other files that are inherently related to the game and curated by a user, such as saves, states, BIOS images, should be in their directories located in ~/Documents/RetroArch by default
I believe that when a user uses the Save New Configuration option, the new config file should not be saved to ~/Library/Application Support/RetroArch/config, but to ~/Documents/RetroArch/config by default. This will make it easier for a causal user to transfer their configuration files, if necessary. At the same time, the main configuration file remains in its place and all changes are written to it from custom configs using Load Configuration
RetroArch does not have a default folder for ROMs. It is great that users can store their games anywhere. Moreover, someone can use standalone emulators, as in the case of PSX2, without which it is impossible to get achievements for PS2 games at the moment. However, it would be nice to make ~/Documents/RetroArch/roms the default directory for ROMs, as well as the default directory for File Browser
By default, there are several unspecified directories in the settings: records, playlists (favourites, history, images, etc.), dynamic backgrounds, and so on. I believe that all these directories should be children of ~/Documents/RetroArch directory by default
Options Sort Saves/States into Folders by Core Name, Sort Saves/States into Folders by Content Directory and Sort Screenshots into Folders by Content Directory are turned off by default. This options should be turned on, otherwise it all turns into a mess, especially when you try to run a game using different cores
The user can create any directory structure for storing ROMs, however, for example, storing PlayStation BIOS images in a manually created directory ~/Documents/RetroArch/system/Sony — PlayStation results in an error. RetroArch only finds images if they are located in ~/Documents/RetroArch/system directory
I believe it would be great if RetroArch automatically sorted games into folders by game system name and game title, because all this information is already in the RA game database
The start directory of File Browser in all cases, except for using the Import Content option, is the root of the hard drive (even if File Browser directory is set in the settings). Instead, the start directory should be macOS current user's User Folder. The user should not be able to see anything outside of this directory in RA File Browser

Also a couple of things that are not directly related to the file structure issues:

14555
I may be wrong, but notifications about the release of a new version of RetroArch are missing in the standalone version of the application. It would be great to add to the application the ability to show a notification to a user at startup if a new version of RetroArch is available with a direct link to download, for example, the DMG file (if using macOS)
Achievements are disabled by default. I think it would be nice to have them enabled (including achievement screenshots), as achievements are enabled by default on all modern gaming systems as far as I know

Suggested File Structure for the User File Directory

I have not used Windows for a long, long time, so I will give an example for RA macOS default directory ~/Documents/RetroArch.

Since users tend to use user-friendly file naming in Documents folder, I suggest that all directory names should be capitalized and should include spaces instead of underscores.

Suggested File Structure: ~/Documents/RetroArch/Assets/Dynamic Backgrounds

~/Documents/RetroArch/Configs — saved custom configuration files ~/Documents/RetroArch/Configs/Recording — recording configuration file/files

~/Documents/RetroArch/Logs — RetroArch general logs ~/Documents/RetroArch/Logs/Runtime Logs — runtime logs

~/Documents/RetroArch/Playlists ~/Documents/RetroArch/Playlists/Favorites ~/Documents/RetroArch/Playlists/History ~/Documents/RetroArch/Playlists/Images ~/Documents/RetroArch/Playlists/Music ~/Documents/RetroArch/Playlists/Videos

~/Documents/RetroArch/Records

~/Documents/RetroArch/ROMs

~/Documents/RetroArch/Saves

~/Documents/RetroArch/Screenshots

~/Documents/RetroArch/States

~/Documents/RetroArch/System

Version/Commit

RetroArch: 1.12.0 / 1.11.1 / 1.11.0

Environment Information

OS: macOS Ventura 13.0 / macOS Monterey 12.6
Hardware: MacBook Pro (15-inch, 2018), Intel Core i7 (6-core, 2,6 GHz), 16 GB 2400 MHz DDR4, Radeon Pro 560X 4 ГБ

I think these are good suggestions. AFAIK, the biggest blocker on any of this stuff is just unfamiliarity with Apple development conventions. Are you able to make any of these changes? If so, we would welcome a PR :)

Are you able to make any of these changes? If so, we would welcome a PR :)

I think that I am able to make all the necessary improvements, however, I am currently working on a very time-consuming project and I am not sure when I will have the time to get everything done. At best, I will have free time only after two months.

I decided right now to pay attention to the issues with the file structure of RetroArch because this project has reached such a level of development that it has become, in fact, the only and best emulator of game systems (more precisely, an emulation frontend). In my practice, there have been many cases where seemingly minor flaws in the file structure resulted in serious problems that could not or still cannot be solved for years due to the fact that applications have acquired with a lot off new features.

In addition, modern gaming systems are striving for unification and game backward compatibility. There is no need for emulators for more modern gaming systems. In this regard, I believe that RetroArch already has all the necessary system cores and main features, like Netplay. It remains only to "do a nice haircut" and continue to support this application for all major operating systems.

I really fell in love with this project 😄

I think these are good suggestions. AFAIK, the biggest blocker on any of this stuff is just unfamiliarity with Apple development conventions.

Perhaps, however, although I have not had the opportunity to check how things are for other operating systems, separating the areas of responsibility for a user and an application is always a good thing. Therefore, I think that at least some of my suggestions are relevant for all supported operating systems. Maybe I am wrong.

In any case, as soon as I have the opportunity, I will dive deeper into this issue, if no one else has already paid attention to it.

Reading through your suggestions, I want to add: Spreading files across the operating systems user or system folders is a concept which failed for me and many others. I do not share my phone or computer with others, so I don't need configs to be placed "somehwere" outside of my application or RetroArch folder.

Moving applications from one OS installation to the next, is a nightmare if files are spread around. I also don't know anybody using an Android TV box, windows, smartphone with multiple accounts for Mum, Dad, Kids, Grandpa, it does not happen in the real world (I think o)?

So I welcome any folder structure cleanup, but please keep the "portable" people in mind, let's have an option at least to always force "portable" mode. Moving RetroArch from one Android, Windows, Linux installation to the next should be possible with a simple folder copy.

I would welcome a RetroArch user profile handling though, that would give best of both worlds (user profiles and portable), since I don't see people log out and back in of their linux session to use RA, so just switch users in RA directly if needed.

Sorry for the delay in reply, @tbone2k-git. I rammed a car with my head a few days ago 😅

I think that you misunderstood me. I wholeheartedly support portability. It would be strange if this were not so.

Spreading files across the operating systems user or system folders is a concept which failed for me and many others. I do not share my phone or computer with others, so I don't need configs to be placed "somehwere" outside of my application or RetroArch folder.

Separation is not necessary so that several users of the same OS can work with RA. Separation is necessary in order to leave casual users the ability to work only with those files that are part of their area of responsibility: game ROMs, saves, states, BIOS images and boot ROMs, screenshots, recordings, playlists, saved configs (general and cores), logs, dynamic backgrounds. RA has many other resources over which users have no broad control (and should not have): UI assets, audio filters, auto-configs for input devices, video filters, shaders, cores and others. These are the resources that exist separately and are not the product of a user's activity. A user is not directly related to them. A user can only update them and, in the case of cores, download them. These are the resources that come with RA and should not be modified by a user.
This approach is aimed precisely at portability, security and ease of understanding: users transfer between devices with different operating systems only a folder with resources that they created, modified or downloaded themselves, and which are not provided with RA. The contents of such a folder are easy to understand. Users will never lose everything they have achieved, will not lose their configs and will not disrupt the application's performance by deleting something important for its operation. All other resources are installed and updated along with RA. Does it make sense to transfer them to another device?
I think that this misunderstanding arose because you mixed up /Library/Application Support and ~/Library/Application Support directories (if we are talking about macOS). I was referring to ~/Library/Application Support directory, which is contained in a user folder and is not system-wide.

I also don't know anybody using an Android TV box, windows, smartphone with multiple accounts for Mum, Dad, Kids, Grandpa, it does not happen in the real world (I think o)?

This is true! 😂 Except in some very rare cases.

So I welcome any folder structure cleanup, but please keep the "portable" people in mind, let's have an option at least to always force "portable" mode. Moving RetroArch from one Android, Windows, Linux installation to the next should be possible with a simple folder copy.

I would welcome a RetroArch user profile handling though, that would give best of both worlds (user profiles and portable), since I don't see people log out and back in of their linux session to use RA, so just switch users in RA directly if needed.

User profiles are not directly related to the file structure. It seems to me that this is a more labor-intensive feature and it can only become popular for shared devices, like Android TVs.

The only alternative to my suggestions regarding the file structure that I see is to add the ability to enable Portable Mode for the application, which would organise the file structure so that absolutely all RA files would be stored within a single directory. It may be useful for arcade halls and some advanced users. Also it is the best choice for gaming-only devices, probably (to be honest, I have not yet looked at how the RetroArch file structure for game consoles is arranged and how new game ROMs are loaded there).

However, I believe that in most cases it will be enough for an advanced user to change the directory where the cores of the game systems are stored to the RetroArch directory, which is located within the user's folder (~/Documents/RetroArch/Assets for macOS, as an example). Thus, there will be no optional files left in the RetroArch system folder.

Nothing against your launcher but there is no purpose for it to be posted here.

libretro / RetroArch