Retroarch: Include retroarch-assets in RetroArch

[loganmc10]

Now that XMB is the default menu system, it would be nice if retroarch-assets was included in the main RetroArch repo, so that when you "make install" RetroArch, the assets get installed as well.

XMB needs retroarch-assets to be useable, everything is just a black box without it, and it's nice to be able to just "make install" RetroArch without having to pull in another repo just to use it.

[twinaphex]

It's not a good idea to mix images into the main repository.

Instead, I recommend using libretro-super, doing ./libretro-fetch.sh retroarch, that should already pre-fetch all the necessary repos inside the retroarch directory instead. That will be what you are looking for.

If git submodules sucked less, that might have been an option, but the experience I have had along with other devs has been overwhelmingly negative, so we cannot use that.

[loganmc10]

Fair enough, I guess i'll just need to change how I build it, the documentation could be improved, the readme.md file for this repo still makes it seem like you can do a simple "make install".

Also the line Instructions for compiling on PC can be found in the wiki. in README.md points to Themaister's repo for the wiki link.

[loganmc10]

Even if you use ./libretro-fetch.sh retroarch, "make install" still does not install the items that were put in the "media" folder like assets, so you still get black boxes by default do you not?

[RobLoach]

If git submodules sucked less

git submodules are great, when done right. May be worth reconsidering.

[twinaphex]

I agree that with Linux there is the need to set up these assets dirs manually since Linux is just not very well setup for providing sane defaults for assets like this, on Windows and OSX we can just sanely distribute nightly builds so this is less of an issue.

I guess things like FlatPak or whatever are all the rage now which provides something similar to that, we could look into that.

I am not going to introduce either a submodule or a copy of the retroarch-assets repo into this repo though. It would severely bloat the git history as well, not a good thing to do.

[twinaphex]

Also, 'installing' assets to a read-only directory would be pretty limiting since then you can no longer update assets from online updater. I think it's up to repo package maintainers to provide sane default dirs for this stuff until we can get a FlatPak build going or something similar.

[RobLoach]

I am not going to introduce either a submodule or a copy of the retroarch-assets

Agreed... retroarch-assets is not a hard dependency for the RetroArch source.

[loganmc10]

@RobLoach The biggest issue for me with git submodules for me is that you cannot use --depth 1, I think they are fixing that with the next version of git but a lot of people won't use that for a while.

@twinaphex I agree that putting the assets in this repo probably isn't a great idea, but you need a way to install the assets.

They should be installed to $(DESTDIR)$(PREFIX)/share/..., and the online updater should put them in the user's home directory if they update them, overriding the installed versions.

Having to manually copy stuff into your home directory after you "make install" an application for it to work is pretty clunky.

[Alcaro]

The biggest issue I see with submodules is that git clone and git pull ignores them by default, you need some weird incantations like git clone --recursive and git submodule foreach --sacrifice-virgins=72 git pull and whatever. git already has enough ways to screw up, we don't need even more.

[loganmc10]

Also, does ./libretro-fetch.sh have a way to pick the version? like -b v1.3.6 would with git?

[loganmc10]

@RobLoach I would call retro-assets a hard dependency when you default to XMB and it all looks like garbage by default.

RetroArch has never been great in the whole UI/UX arena, but you've got to do all little better than black boxes everywhere...

[orbea]

This is a problem that should probably be solved by package maintainers so it is now possible to hide the assets update option in the menu with --disable-update_assets for distros that wish to install the assets into a non writable system directory.

For anyone compiling retroarch on their own using the online updater should be fine as should using libretro-super.

It would probably be a good idea to package the retroarch-assets repo with github once every RetrorAch release so that a known working assets package can be provided with the stable RetroArch source. There should be no reason to do this until 1.3.7.

[loganmc10]

I don't see what the problem with having the assets in a read only directory is. Literally every Linux application does something like that. Think of retroarch.cfg, it gets placed in /etc and then saved in the home directory when modified.

I don't think using the online updater for the first time is a good solution. You still get a piece of software with black boxes everywhere the first time you open it.

[loganmc10]

You guys really need to start thinking about the user experience. There are so many things. Why is Remote Retropad now the first option when you launch RetroArch? I don't even know what that is.

Just look at the reviews on the Android app, almost every comment is "this is too complicated to use", and if there is a response it is usually "if you can't figure it out you're an idiot, use a different emulator".

Anyway I guess I'm just frustrated... It'd be nice if this was an application that could be installed and used by regular people

[twinaphex]

We lack contributors who can take the initiative there. If you want to be that guy, by all means.

[orbea]

I moved Start Remote RetroPad to where it was with rgui. Is this better?

https://github.com/libretro/RetroArch/pull/3444

[orbea]

The problem is not so much that the assets are in a read only directory, but more so that as twinaphex has already pointed out that neither including them in the RetroArch repo or using a git submodule are good ideas. Just as using retroarch to download them to a system directory should not work. If there are specific build scripts or packages for distros that also provide the assets, then there should be no reason to download them with the online updater.

So installing the assets should be left up to whoever is packaging libretro as different distros will want to handle it differently. RetroArch should at most just make it easier for package maintainers to do this.

[loganmc10]

Fair enough, how about this though:

Pretend I'm a package maintainer, or just someone that likes to install things from source. Where are the instructions on how I should install version 1.3.6 of RetroArch? And will those instructions still wok in 6 months? Couldn't someone change something with tje assets that break it with 1.3.6?

Also pretend I'm a package maintainer, how do I provide a RetroArch install that includes the assets, and also one that allows the user to update the assets? Is it possible?

[twinaphex]

Linux packaging is complicated, it's not our fault that Linux is a huge disastrous mess in this area and that they are currently resorting to some latest 'gee-whiz' constricted thing like FlatPak in order to do application development the same way that MacOS and Windows have been doing it since the '90s. I consider that a huge failure on Linux' part to make applications easily usable, distributable and updatable since the start. They could have nailed this since the '90s, instead they thought that dependency hell and endlessly relinking against glibc whenever an update is pushed would be preferable. Obviously it wasn't.

You can blast our application and ecosystem all you want and deride it for whatever nitpicky 'convenience' reason you can think of but at least unlike the entire Linux scene, we are not such huge morons where we think breaking ABI for super-important stuff that every application in Linux userland depends on would be a _great_ idea or even desirable to do. In libretro's case, that ABI has never broken even once in about six years.

That is what installing and maintaining Linux applications should have been like instead of this clusterfuck of upgrade-itis that puts responsibility back in the hands of some package maintainers for every Linux distro out there under the sun. And this in turn makes it IMPOSSIBLE to put any kind of generic binary Linux version out there lest you want to prepackage it with a bunch of shared libraries/shims to get rid of all the potential breakage that could arise on random distro X.

And now you want to throw this failure of coming up with a decent standard for packaging for decades back in our face? In the absence of any standard, what do you expect us to do? Where there is a decent standard for this, like on Windows/OSX, we can provide a default version of RetroArch on our buildbot (nightlies and stables) that are already preconfigured out of the box. That is way harder to do on Linux, I do hope you understand that at least. In the absence of that, we left it up to package maintainers to do their thing.

We simply don't know how to do it nicely for this platform. If you do know how, by all means, step up to the plate and start leading in this area. i have said plenty of times I am open to any and all contributions to make RetroArch easier to use and friendlier to use. What does get on my nerves though is incessant whining, bickering and complaining with no real suggestions or proposals for how it SHOULD be done then. That is not productive and all it does is demotivate us and drain our passion. We have said multiple times we are looking for people to help us with this. We are taking on a huge enormous workload here. We very much need every hand on deck and we absolutely believe in improving RetroArch, but a lot more can be done with more people taking the initiative. I am not making things deliberately obtuse or hard to do, I simply lack enough manpower and dedicated devs that want to help me make things easier. It's perfectly possible for a main dev to lose the forest for the trees and to need people with an outside perspective to make the necessary changes so we start seeing the forest again. But just whining, complaining and being passive aggressive about things and lambasting us for not doing this or that is not helping, it is being destructive instead and it causes more harm than good.

Preferably, the assets directory is writable, since assets can be directly updatable through the application's online updater. On systems where this isn't possible or distros where we have setup assets to be read-only (for whatever reason, because they put assets in some non-user writable dir like /usr/share/retroarch/assets or whatever), we might have to hide it but that would be less than ideal.

[twinaphex]

That being said, I can understand that to a lay person, starting up XMB and having none of the assets work from the get go is a bad first impression.

How would you have us deal with this issue though? We cannot include image assets in this repo since it would bloat the repo and we already have a retroarch-assets repo, best we could do is maybe a submodule but there are known problems with submodules, so it kinda limits our options from the get-go.

[loganmc10]

Here I what I would do:

Pin retro-assets to a version. When you release 1.3.6, tag the assets repo so you can install assets you know work with that version.

Update the documentation to explain how to install RetroArch along with the assets. Being able to do it for a specific version is important too, I should be able to install v1.3.5 or 1.3.6 with libretro-super.

Put the assets in /use/share, and have them installed when you do a "make install" for RetroArch (have the Makefile do it if they exist, which they should if the person used libretro-super.

When someone updates the assets, put that where they go now (.config/retroarch)

[twinaphex]

I don't know where you get the idea though that assets will suddenly stop working 6 months down the line. This is simply not going to happen. So tagging the assets would not be necessary at least.

Regarding installing the assets in /usr/share, I can do that.

When someone updates the assets, put that where they go now (.config/retroarch)

That's more complicated. In order for the assets to be read, we'd have to set the default assets dir to to the /usr/share location. Then that would become the assets dir from that point on. We can't then also have some 'override' directory that will be used when we update assets. This is the entire problem with putting assets in a read-only location to begin with.

[orbea]

As far as Slackware is concerned all that would help is for releases 1.3.7 and newer any RetroArch-$VERSION.tar.gz also has a corresponding retroarch-assets-$VERSION.tar.gz. This will allow the assets to be installed easily with:

sed -i "s|# assets_directory =|assets_directory = /usr/share/games/retroarch|" retroarch.cfg

mkdir -p $PKG/usr/share/games/retroarch
cp -a retroarch-assets/* $PKG/usr/share/games/retroarch

@ loganmc10, if you are a package maintainer, install the assets during the build process. Individual persons can just use either libretro-super, the online updater or figure out their own method.

RetroArch build system is pretty stable, something along the lines of ./configure && make && make install should be enough. Looking at the build scripts in the AUR or slackbuilds.org usually helps with understanding how to build a program.

[fr500]

We could have a cli switch I guess.
So users could do
sudo retroarch --update-assets

That would make it download and exit.

Assets might not be forward compatible but the latest assets are most
likely to work 99% of the time.

Another alternative would be not to package them at all and just check for
their presence and otherwise default to rgui.

On Sat, Aug 27, 2016, 8:53 PM orbea [email protected] wrote:

As far as Slackware is concerned all that would help is for releases 1.3.7
and newer any RetroArch-$VERSION.tar.gz also has a corresponding
retroarch-assets-$VERSION.tar.gz. This will allow the assets to be
installed easily with:

sed -i "s|# assets_directory =|assets_directory = /usr/share/games/retroarch|" retroarch.cfg

mkdir -p $PKG/usr/share/games/retroarch
cp -a retroarch-assets/* $PKG/usr/share/games/retroarch
find $PKG/usr/share/games/retroarch -name ".git*" | xargs rm -rf

@ loganmc10, if you are a package maintainer, install the assets during
the build process. Individual persons can just use either libretro-super,
the online updater or figure out their own method.

RetroArch build system is pretty stable, something along the lines of ./configure
&& make && make install should be enough. Looking at the build scripts in
the AUR or slackbuilds.org usually helps with understanding how to build
a program.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/libretro/RetroArch/issues/3433#issuecomment-242951257,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABpC0IdXpfUO7NybqvLjGsFmHkqg6D5bks5qkOosgaJpZM4JuHzC
.

[loganmc10]

The assets should be pinned to a version. A person that installs 1.3.6 today shoukd have the same program as someone that installs 1.3.6 6 months from now. The assets are part of the application.

I don't know why have an "override" dir isn't an option. The other option would be to copy the assets from /use/share to the home directory if they aren't there. Similar to how RetroArch.cfg is handled. That is probably the best way.

[orbea]

Letting RetroArch create or overwrite files in system directories is a really bad idea and will cause issues with Slackware's pkgtools (Since the files have changed). It should download them to ~/ or not at all.

[loganmc10]

I don't mean change the files in /use/share. I mean copy them from there to the home directory on first launch

[orbea]

What would the point of an override be? I can get that for cores and core info files, but with assets they should be either provided by the distro's package management or through libretro-super / online updater.

[orbea]

Sorry, I was replying to fr500 with that concerning "sudo retroarch --update-assets".

[twinaphex]

This is what I came up with so far -

https://github.com/libretro/RetroArch/commit/63e1afc1cba902b6c6501980cf39e0818eea5e70

[orbea]

That is good, but why /usr/share/applications? In Slackware that is for desktop files, /usr/local/share should be a good default location.

So I came up with this. https://github.com/libretro/RetroArch/pull/3449

[sergiobenrocha2]

I second orbea question. It should be /usr/local/share/retroarch/ if you install it from make install.

Debian/Ubuntu uses /usr/share/libretro/assets/ (should I change to /usr/share/retroarch/assets/ to have some consistency?)

[orbea]

I think /usr/share/retroarch/assets is better because the assets are for retroarch, not libretro. In slackware I am setting --with-assets_dir=/usr/share/games now so they will end up in /usr/share/games/retroarch/assets and RA will look for assets in these four locations before deciding on using ~/.config/retroarch/assets.

/usr/local/share/retroarch/assets
/usr/local/share/games/retroarch/assets
/usr/share/retroarch/assets
/usr/share/games/retroarch/assets

[fr500]

Related: https://github.com/libretro/RetroArch/issues/3466

[probonopd]

@twinaphex

We simply don't know how to do it nicely for this platform. If you do know how, by all means, step up to the plate and start leading in this area.

I get the feeling that you might like AppImage. A no-nonsense bundling format for Linux similar to macOS .app. bundles on .dmg disk images. And yes, Linus Torvalds endorses it, because he hates breaking the userspace and app packaging nightmares, too.

[probonopd]

I have started writing a recipe script that generates a RetroArch AppImage. RetroArch launches (on Ubuntu 16.04), but I can't seem to select menu entries with enter, and running in verbose mode I get

RetroArch [INFO] :: [DBus]: Suspended screensaver via DBus.
RetroArch [INFO] :: ALSA: Using signed 16-bit format.
RetroArch [INFO] :: ALSA: Period size: 1024 frames
RetroArch [INFO] :: ALSA: Buffer size: 3072 frames
RetroArch [INFO] :: ALSA: Can pause: no.
RetroArch [INFO] :: Found menu display driver: "menu_display_gl".
RetroArch [ERROR] :: Failed to create rendering backend: freetype.
Failed to open /home/me/.config/retroarch/assets/xmb/monochrome/font.ttf: No such file or directory
RetroArch [ERROR] :: Failed to create rendering backend: stb.
RetroArch [INFO] :: Using font rendering backend: bitmap.
RetroArch [ERROR] :: Failed to create rendering backend: freetype.
Failed to open /home/me/.config/retroarch/assets/xmb/monochrome/font.ttf: No such file or directory
RetroArch [ERROR] :: Failed to create rendering backend: stb.
RetroArch [INFO] :: Using font rendering backend: bitmap.
RetroArch [INFO] :: SRAM will not be saved.
RetroArch [INFO] :: Loading history file: [/home/me/.config/retroarch/content_history.lpl].
RetroArch [INFO] :: Loading history file: [/home/me/.config/retroarch/content_image_history.lpl].

So some more fine-tuning by someone who actually understands RetroArch would be required; unfortunately I am not this person (though totally willing to help on all things AppImage).

[RobLoach]

I can't seem to select menu entries with enter

Default controls are to use x to select menu entries, z to go back.

[probonopd]

Default controls are to use x to select menu entries, z to go back.

What the!? Would not have guessed that in 100 years.

In fact I can say my AppImage seems to work :-)
More testers are definitely needed though, and someone who knows about the software would have to do some polishing.

[twinaphex]

It's really meant to be used with a gamepad instead of a keyboard primarily. RetroArch is entirely designed around a gamepad abstraction called the 'RetroPad', the 'keyboard' just maps superficially to that for menu operation.

You can still use the keyboard for manual operation but yeah it might not have the most straightforward keybinds because most of the keys already are used for hotkey operations.

[probonopd]

Discussion on the RetroArch AppImage at http://libretro.com/forums/showthread.php?t=6005&page=2; thanks @gouchi for your help

[probonopd]

Binary delta updates are practically instant, despite the file being 240 MB.

For example, when I download RetroArch-1.3.6+r444.glibc2.17-x86_64.AppImage and then run AppImageUpdate, select the r444 AppImage, it will download only the 0.7% that have changed between r444 and r445 as of today. People with slow Internet will love this :)

If we want, we can include AppImageUpdate inside the RetroArch AppImage and make it update itself without any external tools needed.

[probonopd]

@twinaphex what do you think about this form of packaging and updating? Do you like it? If not, what would you like to see improved?

[RobLoach]

@probonopd Nice work on the AppImage. Don't think RetroArch would adopt that as an official/only means of package distribution, but it is good to have alternatives. We could put recipes together for:

• AppImage
• Flatpak
• Snap

Once they are solid and working, we could likely advertise them on the new RetroArch.com .

[twinaphex]

Yeah, I'd very much like to see AppImage/Flatpak/Snap versions of RetroArch for Linux.

[probonopd]

Moved AppImage discussion to its own ticket, https://github.com/libretro/RetroArch/issues/5069

[loganmc10]

Closing since the discussion moved to a new ticket