Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect assets_directory, and libretro_info_path #7

Open
davidhedlund opened this issue Jan 18, 2024 · 7 comments
Open

Incorrect assets_directory, and libretro_info_path #7

davidhedlund opened this issue Jan 18, 2024 · 7 comments

Comments

@davidhedlund
Copy link

davidhedlund commented Jan 18, 2024

In Trisquel 11 but not in some other distros, Appimage version 1.16.0 generates a retroarch.cfg file with:

  • assets_directory = "/usr/share/libretro/assets/" instead of assets_directory = "~/.config/retroarch/assets/"
  • libretro_info_path = "/usr/share/libretro/info/" instead of libretro_info_path = "~/.config/retroarch/cores"

Note: "~" is correct and can be verified by running ./RetroArch-Linux-x86_64.AppImage? from the command line, which says `Setting $HOME to [the directory that you extracted the appimage in]/RetroArch-Linux-x86_64/RetroArch-Linux-x86_64.AppImage.home

Why do we want to fix this?

  • It makes the Appimage dependent of the retroarch-assets package, which is ok since the core packages will install it. But:
  • Even if the retroarch-assets package is installed, it may not be used correctly. For example, sometimes I had font and icon issues with both XMB and Ozone with the retroarch-assets package (version 1.4.1+git20170209+dfsg1-1).

Appimage 1.16.0 in a distro without the retroarch-assets package installed:

image

retroarch.cfg configured with assets_directory = "~/.config/retroarch/assets/"

image

@hizzlekizzle
Copy link
Owner

Hmm, are you sure that's not left over from an old config used with distro packages? Assets are working fine here and I don't have any distro assets packages installed.

@davidhedlund
Copy link
Author

davidhedlund commented Jan 19, 2024

Hmm, are you sure that's not left over from an old config used with distro packages? Assets are working fine here and I don't have any distro assets packages installed.

Here's what I did:

  • Extract RetroArch.7z -- version 1.16.0
  • Open RetroArch-Linux-x86_64/RetroArch-Linux-x86_64.AppImage, and then close RetroArch, just to generate a default retroarch.cfg file.
  • Execute the cat command:
$ cat RetroArch-Linux-x86_64/RetroArch-Linux-x86_64.AppImage.home/.config/retroarch/retroarch.cfg | grep ^assets_directory
assets_directory = "/usr/share/libretro/assets/"

@hizzlekizzle
Copy link
Owner

Dunno man, I just did your exact steps and got:

assets_directory = "~/.config/retroarch/assets"

@davidhedlund
Copy link
Author

Dunno man, I just did your exact steps and got:

assets_directory = "~/.config/retroarch/assets"

Thank you for confirming. That was unexpected. Count potentially be a distro issue?

I'm running Trisquel (based on Ubuntu). I'll evaluate this issue for Ubuntu distros later.

@davidhedlund
Copy link
Author

Dunno man, I just did your exact steps and got:

assets_directory = "~/.config/retroarch/assets"

While we're on the subject, this is my default core info

  • Extract RetroArch.7z -- version 1.16.0
  • Open RetroArch-Linux-x86_64/RetroArch-Linux-x86_64.AppImage, and then close RetroArch, just to generate a default retroarch.cfg file.
  • Execute the cat command:
$ cat RetroArch-Linux-x86_64/RetroArch-Linux-x86_64.AppImage.home/.config/retroarch/retroarch.cfg | grep ^libretro_info_path
libretro_info_path = "/usr/share/libretro/info/"

What is your default value for libretro_info_path?

@hizzlekizzle
Copy link
Owner

libretro_info_path = "~/.config/retroarch/cores"

the one on your system is the default for most distro packages.

@davidhedlund davidhedlund changed the title Incorrect assets_directory Incorrect assets_directory, and libretro_info_path Jan 20, 2024
@davidhedlund
Copy link
Author

libretro_info_path = "~/.config/retroarch/cores"

Thank you for the info again.

the one on your system is the default for most distro packages.

Yes, of course.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants