search

flathub / org.libretro.RetroArch

https://flathub.org/apps/details/org.libretro.RetroArch
Creative Commons Zero v1.0 Universal
18 stars 16 forks source link

Ship with some Cores? #243

Open RobLoach opened 1 year ago

RobLoach commented 1 year ago

Have the Flatpak install a small set of cores with the install?

Saroufim commented 1 year ago

i think this will also allow arm64 users to actually have cores.

cantalupo555 commented 1 year ago

i think this will also allow arm64 users to actually have cores.

How can I get the Cores List in ARM64 Flatpak?

RobLoach commented 1 year ago

Load up the Online Updater. Cores are published on the buildbot.

sents commented 1 year ago

The online updater does not work on my raspberrypi 4. It just says 'fetching core list' and does nothing.

matheuswillder commented 1 year ago

Have the Flatpak install a small set of cores with the install?

When a installation is done without the --user option (a system-wide installation) the assets will be in a write-protected directory for a non-sudo user. I think that including cores in a write-protected directory will prevent them from being updated, which could be problematic if some core build has a regression and the user needs/wants to update it. I'm not a developer but I think that the assets shipped cannot be extracted by default in the ~/.var/app folder (the Android build does this, when it is opened the first time it extracts the assets into the correct user folder), so I think it's best to rely the least possible on shipped assets in the Flatpak so that the user can update freely without having to change the default directories. The .deb build in the Debian repository does something like this, if I remember correctly only the /retroarch/assets folder (for UI files) and /retroarch/info (for core info files) are in write-protected directories, everything else needs to be updated manually and will be in ~/.config/retroarch, so the user can freely update whenever want or need.

The online updater does not work on my raspberrypi 4. It just says 'fetching core list' and does nothing.

I was having a issue like this when updating the shaders, I think it's the same problem I was facing (witch I described above), if you want you can change the default directory to ~/.var/app/org.libretro.RetroArch/config/retroarch/info in the RetroArch settings and then try update again. Make sure to use the correct subfolders to avoid mixing the contents. You can do it automatically using a text editor, open retroarch.cfg and use the replace option to replace all /app/share/libretro with ~/.var/app/org.libretro.RetroArch/config/retroarch, after saving and opening RetroArch again it will start without assets, use the Online Update to update Assets to the UI works correctly and then update all other options such as shaders and core info files.

Edit: Sorry just now I paid attention to the comment that this would allow users of ARM64 devices to have cores, I didn't know there was a problem like this, in which case my comment can be ignored entirely. In this case, ship two cores per platform when possible could solve the problem when some core build have regressions. For example, some months ago I had problems with Mesen so I switched to FCEUmm, both for NES. The same can be used for SNES (i.e. ship bsnes and Snes9x), Genesis/Mega Drive (Genesis Plus GX and PicoDrive), and so on. It would increase the total download size a bit, but the current package with all cores for x86_64 for Linux is just over 200MB. And if the user wants still can change the cores directory to one in the home folder and install and update whichever ones want and when need.

RobLoach commented 10 months ago

If anyone could help with putting together some core packages, that would be incredible. Possibly...

  1. Add a modules/libretro/fceumm.json package
  2. Update the retroarch.cfg to have libretro_directory = "@prefix@/lib/retroarch/cores"
  3. Have the package install the core file to /lib/retroarch/cores