People organize their folders differently. To have features depend on folder structure makes things less flexible ultimately. And folder structure isn’t immediately apparent in Retroarch. It could make setting overriding seem unpredictable. Playlists, however, are apparent and most people sort content by system with them. IMHO it would be more elegant to override settings on playlists rather than on folders.
The playlist and/or database name aren’t reliable either. For now this will have to do. I also made provisions so this can be used in the future by playlist name or db name.
@radius - I, for one, am VERY excited about this feature as it solves something I’ve dealt with for a while. - I continue to appreciate the work you do. Thank you
@Cutter - “most people sort content by system this way” I’d have to argue the opposite. Most people I’ve talked to that use RetroArch, at least on Windows, are running a frontend. Personally, I’ve never once used the playlist, database, or favorites features. I was very pleased in a recent update when I was able to remove them from the F1 menu.
I’m not saying either way is ‘better’ by any means, just that this is going to be pretty helpful for a lot of users who do things the other way. Plus it’s not like this negates the possibility for other solutions down the line.
Although, I’ve got to ask, if your games are not organized by system in your library… how are they organized? I can’t think of another way to do it. I’m just curious.
This is so awesome！Thank you!
@SkyHighGam3r I was saying that most people do divide their games by system using playlists, as an argument for per-playlist settings overrides.
Thanks a lot for implementing this feature. However the way it works is it applies to content of the same folder AND for the same core. It doesn’t apply for two games of the same platform (folder) when a different core is used. The folder-specific preset is created in a subfolder named as the core. Is this expected ?
Yes. this is for having different shaders for different systems using the same core.
For instance, i use Gambatte for both Game Boy classic and Color. But the two consoles need different shaders so this is where the save as dir comes in handy.
This was a long standing issue with GenesisPlusGX which supports a bunch of Sega systems. You couldn’t have different shaders on those systems using the same core. But now you can easily do this by saving the shaders per dir.
Is there any solution for when a given system uses different cores?
You could just save the same shader for each core (save core profile).
If one of those cores is used for another system and you want a different shader for that, you can save a directory profile for that system and when you use it it will read that over the core profile…
Or you can just use the same shader and save per directory for both cores, it will work as well.
The priority goes like this (from lower to higher)
Global - Core - Dir - Game
“Dir” is basically “system” if you have your roms stored per system. I assume you don’t have SNES and Mega Drive roms in the same folder.
The way this feature works is unnecessarily complicated in my opinion. It can lead to unexpected behavior from the user’s point of view: folder should mean folder, not folder/core association.
Why would someone need to have the folder-specific preset simultaneously specific to a core ?
Yeah that’s how I understood it at first, but it is in fact “dir is system plus core”.
Each core has it’s own cfg/remap/shader preset folder where they read the overrides from. When you load SNES9X and save any override, this override is saved in the SNES9X folder.
Sure, there could be a “SNES” folder and all SNES cores could save there. But what if a core is used for more systems like Genesis Plus GX? I don’t think RetroArch can understand systems, only cores. I assume it’s much harder to make it understand systems, especially when games have multiple ports on different systems. So you would need to specify a core along with the dir. Which is the same thing again.
It could have both a core and system cfg folder but that would probably create an even bigger confusion because the cores would have to read overrides from multiple different folders.
The only way i can think of that will work is if all the multisystem cores are splitted and there isn’t a single core that can be used for more than one system. And all gameboy cores would have a color and classic version. This way there would be no reason for RetroArch to mix things up, just hard code every core to it’s specified system and you are done.
Anyway, as is, i can’t think of any scenario where the user is confused, or where any conflicts can occur. assuming the user understands the override priorities.
Sorry but I still don’t understand why it is needed to associate folder-specific shader presets to a core.
This wouldn’t a problem as long as the roms are stored in their respective system’s folder. RA would load the appropriate shader based only on the content’s folder, whatever the core. No need for RA to understand systems.
Ok here’s a scenario.
Let’s say you want to use both SNES9X and BSNES to play SNES games. You like to use crt-Royale on SNES9X but it will slow down your PC if you use it with BSNES. So you need choose a different SNES shader for that.
The answer is use save core profile right? This way each core gets it’s own shader. Ok but what if i want to use BSNES to play, say, Super Game Boy games? Will i use save directory profile for that?
Sure but wait, this profile is going to be used with Gambatte as well, my main Game Boy core. Maybe i don’t want to use the same shader with BSNES as there could be a difference in resolution, the way it renders the games, etc. So what do i do? I can’t use save core profile for Gambatte because the directory profile has higher priority than the core so it will use the same shader as BSNES for game boy games regardless.
So what if we change priorities and core profile goes first? Then it will mess the initial setup i did with BSNES for Super Game Boy games. Remember, i needed to save a directory profile for that.
I don’t know if you followed that but my point is that the current system solves issues like this. Because the dir profile also takes the core into account it means you can have multiple dir profiles per system and different core profiles per core at the same time without conflicts. Maybe it’s not as convenient but it’s safer and you can have more control over what you want to use in any situation/combination.
This is an edge-case scenario. The general case is that different cores render a given system in a similar-enough way for the same preset to be applied to both. For this general case, RA provides no easy solution at the moment.
Retroarch is all about edge cases and the current system provides that, removing functionality doesnt seem like a good idea.
If you are well versed enough to use different cores for different games of the same system, picking the shader and saving an extra per content directory override is not a major problem.
Adding this information to the documentation would suffice imo. I understand using overrides is not self explanatory for a new user
I don’t agree that it is removing functionality. It is providing functionality in the more general case where different cores of a system require the same shader for consistency. It is extremely specific that two cores would render the same system so differently that one shader couldn’t reasonably be applied to both. I don’t see a rational reason to address edge cases to the detriment of general cases.
But there is no detriment of general cases. You can easily save a directory profile for all the cores you use for a specific system. At worst you will have to do this for 3 or 4 cores.
As an advanced user I prefer stability and full control over “one for everything” type of convenience, that can lead to conflicts, any day.
I understand but disagree. I think the developers have done a great job catering for all eventualities. These extra features have been added because users asked for them and were needed.
I dont see an easy way to cater for simple and advanced. Im sure they would look at and github PR’s if they got any.
There’s a core splitter that works like a charm!
If you’re on Linux, you can do this quite easily by symlinking the core preset files to a single file. For example, if you create a file
nes.slangp and then symlink it as both
Mesen/Mesen.slangp, both Cores will use the same shader settings and store them in
Note that when you change shader settings and do “save core preset”, it’s
nes.slangp that will get updated. So changes in shader settings in one core will also apply to all the other cores as well.
This is of course not helpful with cores that support multiple systems. But it works well for single-system cores.