Cull Unused Retroarch Cores from Install

[WingofaGriffin]

There are a good number of cores that are pretty redundant aside from some niche usecases that should be culled from the install process, such as Desmume2015. We should review which cores are being installed by default and cull ones that are redunant/superceded by other installed cores. Users can manually install them if they really miss them.

For reference: https://github.com/dragoonDorise/EmuDeck/blob/main/functions/EmuScripts/emuDeckRetroArch.sh#L1813:L1829

[Godsbane]

Tyki can you go through and list out the cores that are trash, that you know of?

[WingofaGriffin]

Initial Evaluation from the STABLE release install script:

Delete	Superseded By	Notes
a5200_libretro.so	atari800_libretro.so	Abandoned by upstream
bsnes_hd_beta_libretro.so	bsnes_libretro.so	Looks to be abandoned by both dev and libretro
citra2018_libretro.so	Standalone
citra_libretro.so	Standalone
desmume2015_libretro.so	desmume_libretro.so
crocods_libretro.so	cap32_libretro.so	Croco is more designed for ARM devices
dolphin_libretro.so	Standalone
dosbox_svn_libretro.so	dosbox_pure_libretro.so	Abandoned by upstream
fbalpha2012_cps1_libretro.so	fbneo_libretro.so
fbalpha2012_cps2_libretro.so	fbneo_libretro.so
fbalpha2012_cps3_libretro.so	fbneo_libretro.so
fbalpha2012_libretro.so	fbneo_libretro.so
fbalpha2012_neogeo_libretro.so	fbneo_libretro.so
fceumm_libretro.so	mesen_libretro.so
fmsx_libretro.so	bluemsx_libretro.so
frodo_libretro.so	vice_x64sc_libretro.so
gambatte_libretro.so	sameboy_libretro.so	Opinion here, core itself is fine and default for many users
gearsystem_libretro.so	genesis_plus_gx_libretro.so
gpsp_libretro.so	mgba_libretro.so
handy_libretro.so	mednafen_lynx_libretro.so
nekop2_libretro.so	np2kai_libretro.so
parallel_n64_libretro.so	mupen64plus_next_libretro.so
pcsx2_libretro.so	Standalone
pcsx_rearmed_libretro.so	Duck, Swan, Beetle
ppsspp_libretro.so	Standalone
quicknes_libretro.so	mesen_libretro.so
race_libretro.so	mednafen_ngp_libretro.so
smsplus_libretro.so	genesis_plus_gx_libretro.so
snes9x2010_libretro.so	snes9x_libretro.so	Deck is far powerful enough for current
stella2014_libretro.so	stella_libretro.so
tgbdual_libretro.so	sameboy_libretro.so
vba_next_libretro.so	vbam_libretro.so	Good to have a mgba backup I guess
yabasanshiro_libretro.so	kronos_libretro.so	Yaba is ARM focused
yabause_libretro.so	kronos_libretro.so

Some question marks I had were:

• same_cdi_libretro.so - Just a fork of MAME only focusing on CDI
• puae_libretro.so - there's a fs-uae beta that we don't have installed, but puae should work fine for must
• neocd_libretro.so - MAME and FBNeo cover this, but this is dedicated?
• mednafen_supafaust_libretro.so - superseded by snes9x and bsnes tbh, but part of mednafen
• mesen-s_libretro.so same as above, but also fine?
• genesis_plus_gx_wide_libretro.so - is this actually used?
• bsnes_mercury_accuracy_libretro.so - ditto
• I don't know enough about the vice ones to make a call
• Similar with mednafen_pce_fast_libretro.so
• Old mame versions
• Beetle-psx non hw seems useless

There may be some missing, but that's for a different issue. All are open to debate.

The good thing is people are able to download any extra cores they want at will. I think deleting cores for existing users is a no go (or an optional tool), but for new users it doesn't make sense to add all of these.

[leonstyhre]

I disagree with this proposal. You would remove a number of default ES-DE cores which will make those systems unusable unless the user either installs the cores manually or changes the default emulator. Or you'd need to make a number of custom system configuration entries which you need to manually keep synchronized with the bundled configuration whenever I add more emulators or file extension etc. in future releases.

Then there's the questions around personal preferences and existing savestates etc. I just don't understand why you would want to do such a radical thing and remove valid options for people. Many of the alternative emulators supported by ES-DE have been requested by someone (or by multiple persons), it's not like everyone has the same opinion of which cores and emulators to use. Some hate RetroArch and only want to use standalone emulators, some have the opposite opinion and love RetroArch and want to use it for everything even if it's not objectively the "best" option. And so on.

[WingofaGriffin]

Hey @leonstyhre, thanks for the feedback.

The first thing I'll note is that nearly all of the proposed cores I have for removal from the initial install have zero configuration done by EmuDeck right now, meaning that they can all be easily downloaded from the RetroArch Online Updater GUI if a user wants to use a core not provided in the initial install. This makes me less cautious about culling "bloat", as they aren't something that would be difficult to add back if desired.

Regarding your concern with defaults in ES-DE, I think there is merit, but also cause for further discussion. Taking a quick look crossreferencing your list of defaults with my list of proposed culls the following seem to be of issue:

• a5200_libretro - Not super familiar with atari5200 emulation personally so I am happy to keep it in. My quick research showed that atari800 was more active
• Citra, PCSX2, Dolphin and arguably PPSSPP should, in my opinion, not be used with RetroArch at all. We do not configure for them, and they have noticeably worse performance. I know you keep compatibility with in on ES-DE for valid reasons, though making them default should be heavily reconsidered.
• PUAE and SameCDI should probably be kept from what little I know
• FBAlpha can be manually downloaded easily IMO. Neo has superseded it for people who aren't holding onto old ROMsets
• Gambatte will probably be kept, but again I urge the community to consider migrating defaults due to its cease in activity
• I admit I have never heard of the Othello Multivision. If Gearsystem is the only emulator it works it should stay

That said, I still think that some of these being culled is more than obvious. Like why does DesMuMe 2015 need to stay?

[Godsbane]

I also think it needs to be clear that we would not delete things for existing users.

The idea is to reduce the initial set of cores downloaded.

On Thu, Mar 30, 2023, 6:18 PM Griffin @.***> wrote:

Hey @leonstyhre https://github.com/leonstyhre, thanks for the feedback.

The first thing I'll note is that nearly all of the proposed cores I have for removal from the initial install have zero configuration done by EmuDeck right now, meaning that they can all be easily downloaded from the RetroArch Online Updater GUI if a user wants to use a core not provided in the initial install. This makes me less cautious about culling "bloat", as they aren't something that would be difficult to add back if desired.

Regarding your concern with defaults in ES-DE, I think there is merit, but also cause for further discussion. Taking a quick look crossreferencing your list of defaults with my list of proposed culls the following seem to be of issue:

• a5200_libretro - Not super familiar with atari5200 emulation personally so I am happy to keep it in. My quick research showed that atari800 was more active
• Citra, PCSX2, Dolphin and arguably PPSSPP should, in my opinion, not be used with RetroArch at all. We do not configure for them, and they have noticeably worse performance. I know you keep compatibility with in on ES-DE for valid reasons, though making them default should be heavily reconsidered.
• PUAE and SameCDI should probably be kept from what little I know
• FBAlpha can be manually downloaded easily IMO. Neo has superseded it for people who aren't holding onto old ROMsets
• Gambatte will probably be kept, but again I urge the community to consider migrating defaults due to its cease in activity
• I admit I have never heard of the Othello Multivision. If Gearsystem is the only emulator it works it should stay

That said, I still think that some of these being culled is more than obvious. Like why does DesMuMe 2015 need to stay?

— Reply to this email directly, view it on GitHub https://github.com/dragoonDorise/EmuDeck/issues/561#issuecomment-1491040630, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAM3AOL7L5FCLT7DJU6XDGTW6YBEBANCNFSM6AAAAAATED3LAA . You are receiving this because you commented.Message ID: @.***>

[leonstyhre]

Ultimately it doesn't matter for ES-DE as it will still support everything, I just think it's sad if you remove user options and reduce diversity for no good reason, it's not like it 's an overwhelming amount of work for you to install alternatives for people that want to use those. And while yes they can install cores manually that's true for the entire emulator setup and I guess that defeats the purpose of using an installer like EmuDeck in the first place.

[WingofaGriffin]

Found a few more defaults I deleted and have since restored. I think there's a slippery slope. At what point do we install every single RA core? Seems a bit extra and bloated.

[Godsbane]

I agree.

I think anything we configure in emudeck -> defaults for es-de that we didn't switch es-de away from (dolphin, pcsx2, citra) -> unique cores which do something special or specific that es-de supports.

Everything else is user installable from RA?