Override shader settings per-platform

Is it possible to save shader settings on a per-platform basis, rather than per-core ?

Why?

  1. Some cores support several platforms where shaders should look different (Game Gear / Master System).
  2. Different cores can be used on a given platform.

In these cases, saving a shader configuration for a given platform is more convenient.

Nope, RetroArch doesn’t have any concept of platforms/systems, only cores and content. You can use different cores for different systems or modify the core’s internal name to make “split” cores (really just the same core with a different name and different list of supported file extensions).

1 Like

This should fix that issue when implemented. So long as you organise your roms by system.

Nope, overrides don’t handle shader presets correctly, anyway I’m on it

5 Likes

:grin::grin::grin::grin::grin::grin::grin::grin::grin::grin: and to hit 20 characters

This feature would fill the gap for the time being, but I don’t feel like it would be the right solution in the long term because it imposes a certain directory structure.

Isn’t the database divided into systems? If a content belongs to a certain database, then some setting specific to that database could be applied.

We can’t leverage the database for this. Not everyone uses databases.

It won’t save the preset in the content dir anyhow, it just uses it as an indication of the folder name you want to use.

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.

2 Likes

@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!

@radius thanks!

@SkyHighGam3r I was saying that most people do divide their games by system using playlists, as an argument for per-playlist settings overrides. :slight_smile:

1 Like

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.

1 Like

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.

2 Likes

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.