I would like to duplicate some cores, specifically swanstation, to have a core set up for “full on” upscaling and another one for upscale + downsample to use with crt shaders and to have a different look in general.
Can I duplicate cores? is it just a matter of duplicate and rename the core dll and the info files? or are there any other things that I should know?
If different settings is what you want to do, then you don’t need to duplicate cores. Just copying the core wouldn’t make it act individually, as it is registered as the same core as before too (settings, configuration and so on). Only the version of the core would be different. To achieve your goal, you do not need to copy the core.
You just need alternative configuration files. I do that with some cores/systems, where I have a faithful recreation of the original system and also some HD type of enhanced setups for the same game console. The way I am going is to create settings based on the folder the games are in. Meaning, the configuration is tied to folders with a specific name. In my config folder for NES core “Mesen” in example it looks like this:
Mesen.cfg
Mesen.opt
Mesen.slangp
nes⎇hd.cfg
nes⎇hd.opt
nes⎇hd.slangp
“Mesen.xxx” files are the base Mesen configuration, that is applied to all NES games. The “settings nes⎇hd.xxx” are only applying to games loaded from a folder that is named exactly “nes⎇hd”. At least that is one way to achieve this goal. To avoid duplication of ROM files and CD images, you could just create a symlink of the files to that folder.
Hi, thanks for your answer!
What is a symlink?
I understand how settings per folder works but that would need roms/images duplication. Also sometimes I use load content to try something and in that case if the game is not in the proper folder it wont work.
With duplication I mean duplicate the core (and the info file) but also renaming it: swanstation_libretro.dll, swanstation_libretro.info and swanstation5X_libretro.dll swanstation5X_libretro.info.
so that in the available cores I will have both with the option to choose any of them already with my settings and also make two playlists one with the “normal” core and the other with the duplicated one.
I’m saying this because, I think a long time ago, I think I did that for genesis plus gx.
At the moment I have both swanstation and the “old” duckstation but I would like to have “both” swanstation for keeping things updated (I understand that in case of duplication I would need to manually update the “5X” core but that’s no problem)
Symlinks is short for symbolic links, just like hyperlinks in the web. If you run the application with a symlink, then your operating system will point to the real file. That is to avoid duplication of files and just represent the original file with a different name (or same name) in a different folder in example. Obviously it depends how symlinks are handled and if they are resolved to point to the folder of original file or the symlink and such… From my explanation, it may sound much more complicated than it is. My experience is coming from Linux, so it might work differently in Windows, I just don’t know.
And about the duplication of the core, I know exactly what you mean. You can in example copy a copy, give it a different filename and update the other core. Then you can use both cores to play games (could be useful for Arcade games). But both would still use the same configuration files I showed you. BTW if you want keep both cores, original and copy, in sync, then you could create a symlink. 
Then if you update one core, the link points to the original under a different name and pretend to be an individual core.
I actually don’t know what is all necessary to register a new core in RetroArch. If you want go that route, then maybe there is more to it. I also considered that what you suggest here, before doing it the thing with folders.
Hi @Hari-82.
First of all no, you cannot copy the core and info file, rename them to something else and have different settings. This method would require you to edit the source and recompile the core for it to save settings to a different file.
The good news is that you don’t need to do this. Just keep your games in different folders and save per-directory core configs as @thingsiplay explained.
Ok, so I tried to duplicate the core and modified the info file and indeed it works and shows up
but as @metchebe said that is unfortunately not enough because it still retain directories of configs and shaders of the original. :’(
@metchebe As I said before I know how saving settings per folder works but that’s not my goal, I wanted to have 2 swanstations so that one always launch with crt shaders and downsampled resolution and one with just upscale and few other settings and shader that works well with upscaled res. so that I could launch a game with either “set-up”.
Yes well for that you can use per-directory shaders also…
Regardless, what you want is not implemented, so If you really need that then you should consider learning how to compile your own cores (a useful skill anyway).
Yes well for that you can use per-directory shaders also…
ehm…no. the thing is been able to launch the same game with two different set-ups.
To use per-directories settings (shaders, core options, override) I would have to have two copies of each game.
I guess I’ll keep using swanstation and duckstation to achieve that at the moment and later I’ll look into compiling cores… I was just hoping to have a user-side solution to it, for example having directories settings in the info file itself.
You can use an m3u file to point to the same game but in another path (or with another name).
I think the info files are just for displaying the infos in the GUI, like metadata. The paths and names are all hardcoded to the cores I think. Think of it like MP3 title and album name.
But did you try the symlink version? I usually don’t use that, but it works. I just tested it. For this to work you need to create the setup I suggested with different folders and so on. But instead copying the files to that place, just create a symlink to the entire folder of the roms once.
Give it a try, it will save you from the trouble of editing source code and compiling (unless you want that). The above solution gives me a secondary settings, plus roms and games are not taking extra space due to the symlinking.
I just tried using symlinks and it actually works! I used this:
`mklink /D “path/to/new/forlder/” “original/roms/path/folder”
and saving settings by directory in retroarch works. 
I wonder if there is a way to do it using relative path… Now I’ll try to make a playlist with desktop menu and see how it goes…
Seems you can create relative paths too with symlinks. I tried in Linux and changed the paths which the link points to to “./nes” in example (to stay in sync with my previous examples). And searching the web it should be possible in Windows as well: https://superuser.com/questions/361826/how-do-you-make-a-symbolic-link-with-a-relative-path-using-mklink Edit: I use in Linux starting with “./”, because that means current directory. You might not need that, based on the description found in the link.
Yes I tried before, the symlinked folder is created correctly but it was showing an absolute path (greyed out) in the propreties so I wasn’t sure, but now I renamed the folders around and it works and the path in the propreties tabs changes correctly, I guess windows is a little more cryptic 
Thanks a lot, I didn’t know about this symlink! 
No, the same is true for Linux (at least the software I use). After I changed the path, in my graphical filemanager it still showed a fullpath. But using a terminal command (lsd -ld nes* it shows true relative path after I changed it to relative.
Before changing to relative:
nes test ⇒ /home/tuncay/Emulatoren/games/nes
After changing to relative:
nes test ⇒ ./nes
But you should know that some certain software can “resolve” the link to real path. So if you use this for other things than RetroArch directly, then your results “may” be different. In example I personally wrote a helper program to run RetroArch games (context does not matter now). And that program will always resolve the link before giving it over to RetroArch. Which in turn does not work with symlinks. (I need to figure out a solution for this…). And making backups can be complicated, depending of the program.
So what I mean is, just be careful about this when using these folders and files in a different context. If you use these just in RetroArch, then it works like a charm in RetroArch.
Yes, I asked about the relative path behavior also for backup purpose. The first test I did was to create a symlinked folder to my desktop (different drive) then after moving it it warned me about not having enough disk space… this also true the other way around and with relative path. So, yeah got to remember about this when is time to do some backups I guess…
No no, I programmed a launcher program myself with a specific goal in mind. It is how I handled stuff with it before thinking about symlinks like we talk in our discussion. In fact, that program was the first thing I started doing after learning and installing RetroArch last year (Edit: Wait it’s already two years now since I started with RetroArch?). 
I did not want hijack this thread to talk about, just mentioned it can be problematic with symlinks under certain circumstances or with some applications if it is not taken into account. More of a little warning to be aware of.
There is a way to duplicate a core and make it behave like a completely different one, with a different settings folder, etc.
I asked for this some time ago and someone wrote a little program that allows you to do just that.
Here, download this: https://www.mediafire.com/file/3yz5g2slda3o24l/Core_Splitter.zip/file
This is what i used to duplicate the “Atarti800” core and make a second one named “Atari520” (to have different cores for the computers and the 5200 console).
By studying the .bat file (open it with with a text editor) you should be able to figure out how to duplicate other cores, it’s just a matter of changing the names.
This will also duplicate the .info files so you won’t need to do it manually.
I don’t use this anymore since you can now save everything “by directory”, including the main core options (which wasn’t possible before). But that’s when you want to use different rom folders (i have the Atari 800 and 5200 roms in different folders obviously). If you want to use the same rom folder though, this duplication trick is a better, cleaner solution than duplicating your roms.
This cannot be achieved by simply renaming and duplicating the files. I tried that already. There must be something else done with the core files. And looking at the archive you linked, it includes an executable and a batch file. The batch file is just there to run the gsar.exe program.
Unfortunately the linked webpage or source code does not exist anymore and I have no clue what this program does. If anyone knows the source, I would be glad to have a look at it. I would like to write my own program or script to handle this.
Will this also change config directory of the “new” core?
I mean in your example did you get both:
/config/Atari520/
/config/Atari800/
