g++: error: dolphin/build/Source/Core/../../Externals/fmt/libfmt.a: No such file or directory

[beaumanvienna]

Happens with sudo pacman -S fmt. Dolphin's cmake run configures libfmt as dynamic library, but it should be the static library shipped with Marley. This is to make Marley more stable.

[beaumanvienna]

Fixed with 455ece9
@rien333

[rien333]

Awesome, thanks!

[beaumanvienna]

It would be nice if you could provide more feedback in general. There is one major feature still missing in Marley, which is a sophisticated emulator core assignment to the detected games. Currently, it's makeshift. It only looks at the file extension and assumes you have sorted your games into folders such as "PS1", "PS2", "Wii". Yeah, but other than that all five cores are online and work pretty stable. If you have the time, it would be much appreciated if you could review Marley some more. Thanks!

[rien333]

It would be nice if you could provide more feedback in general.

I will try compiling it tomorrow.

The idea of an emulator front-end with plugable cores (or emulators-as-libraries) is really nice. However, while I was compiling marley yesterday, I didn't really like how it compiled quite big programs I didn't have a need for (i.e. the full Mednafen suite, Dolphin (which I already have), an a psp emulator). It would be nice if the user could specify the emulators they want at the configuration stage (if not already possible). Alternatively, it might be nice if you could follow OpenEmu (for macOS) or RetroArch, in the way they allow you to manage (delete and add) the emulators you need after you've installed either of these frontends.

[beaumanvienna]

I will try compiling it tomorrow.

If you compiled manually without the makepkg script, I think it's easier to do a get git pull later on if I have to amend something. I would simply follow the compile instructions for Arch in the readme.

The idea of an emulator front-end with pluggable cores (or emulators-as-libraries) is really nice.

I might look into this someday. I tried twice fitting the build process into the 50 minutes of Travis CI, but it still times out on me. In general, Marley tries to be different from RetroArch in so far, that it is highly compact. I figured there is so much friction with plugins, be it on the user side, server side (RetroArch is providing the cores from there), or maintainer side, that I am aiming for one highly-integrated package that has all you need. So basically a take-it-or-leave-it basis. Marley also, for example, doesn't allow pop-up windows. So all five cores render into the same OpenGL context. This is to reduce the dependency on the Window manager when the front-end is fullscreen and an emulator core also wants to go fullscreen and doesn't manage to get on top. Marley is zero-install, so everything is included in one binary application. This includes fonts, entire zip files with assets, and the dynamic libraries for PCSX2. It is using a resource system that generates huge C-tables out of files and provides those to the app during runtime. Regarding your comment that you have the other emulators already, Marley is meant to be a "sofa-application" or for DIY arcade machines. It is entirely controlled by a game controller. There are optional keyboard shortcuts for fullscreen (f), save state (F5), load state (F7), and exit (ESC), however, it has no mouse support. The idea is to resemble a gaming console rather than the GUI programs or terminal-controlled versions you normally use. If you have MAKEFLAGS set to all cores your CPU has you can compile it in 11 minutes on a Ryzen 5, 16 minutes on a Core-i7 from 2014, and 21 minutes on a Xeon processor. Good luck and thank you!