CDBlue

Hi all, Not sure what's changed, but in the past I used to be able to edit my retroarch emulator settings and assign multiple cores for different platforms. For example, for Super Nintendo Entertainment System I used to be able to add two entries, both named Super Nintendo Entertainment System, and one uses the bsnes core, and the other uses the snes9x core. This would then allow me to select one as the primary core, and one to use as an alternative. Today when I went to edit something in my retroarch settings, it would not allow me to exit/save settings until I deleted all those duplicate/different core entries. How do we do we setup alternative cores for retroarch now?... or is this a bug I've discovered? See pics for what I get as an error when I try to add a 2nd entry for Super Nintendo Entertainment System using the snes9x core. EDIT: I'm on version 12.1 and using Windows 11 64-bit... FYI

Have you followed the instructions on the libretro Mesen core page? Making sure to pay special attention as to where to put the HD packs, what to name the main folder (HdPacks), and what to name the folders where the actual packs are located. I assume you have the folder names correct for the actual packs, as you mentioned you have them working on the stand alone version of Mesen. I'm not sure if it's case sensitive or not but make sure you have the folder in your System folder labelled "HdPacks" and not "HDPacks" or anything else... they have it in quotes on the instructions page with that case, so perhaps the core is case sensitive for that.... just a thought anyway https://docs.libretro.com/library/mesen/

@ferretlegs I noticed the same thing. It seems to automatically start giving errors when it gets to the portion of the import of the actual media download from emumovie, if you do a large import of roms where the metadata portion of the import takes a long time to process. I don't think the speed of the internet is much related to this, as I have a 350 Mbps down/15 Mbps up connection on my line and I get the same issues when doing a big import. I think, as mentioned previously, if you do a large import I think the emumovies connection times out before it actually gets to the portion of the import process where it actually starts trying to download the media from emumovies. I guess a fix, if possible, would be to re-establish a connection to emumovies right before that portion of the download starts, rather than earlier in the import process, but not sure if that's doable or not. Either way, I'm sure the devs figure something out

K, just got home and tested. I forgot to test with version 1.23.0 though, as it prompted me to update to the latest version and I did... so I tested with version 1.23.1b. For me, with all the settings set to Cemu default for custom timer and MM timer accuracy, and with Cemuhook enabled, all my games launched fine from LB/BB. So, if you do upgrade to 1.23.1b and you still have issues, it might be a setting in Cemu you have custom selected that's causing an issue. Hopefully though, it was just an issue with 1.23.0 and when you do upgrade to the latest version that just came out, maybe it'll fix your issue. Good luck, CDBlue

I'll test when I get home tonight. Do you have all the other settings set to Cemu default or have you custom selected any other setting in there? If so, try setting them all back to Cemu default and see if the issue goes away. Another thing I've found sometimes is that if you're using Cemuhook, after an upgrade you need to deselect it, then re-select it for it to work properly (it can cause games to close on startup otherwise ... sometimes). Just a thought in the mean time, but like I said I'll test when I get home and see if I am also having this issue or not.

Not sure if this was reported or not. But, on the latest beta when you do a rom import and select folder, as you go through the wizard, you get presented with the arcade/mame portion of the wizard even for non-arcade platforms. It shows for about 5 seconds, then automatically closed and proceeds to the last step of the wizard/import process. In my case I was doing an import of Nintendo Entertainment System roms and I got the Arcade portion everytime I went through.

FYI, I got this same issue while updating meta data/media for my Mame/Arcade roms. While it displayed clearing image cache my processor went up to 100% usage on all cores... my CPU cooler went crazy lol

I've run into this issue, but mostly just when I'm doing some editing of files. Sometimes, when you exit out of the editor for a game, the video seems to get "stuck" looping, and like you said the only way to stop it is to close LB and open it up again. Lately, if I'm planning one doing alot of editing I just mute my speakers and ignore it because I know it's going to happen 100% of the time at some point during editing multiple things in the same session. Unfortunately, I don't think there's any fix or work-around for this issue at this time, I think it's been reported and attempted to be fixed, but it obviously hasn't been fixed yet, as I can reproduce it on each version of LB. Like I said though, I don't let it bother me, I just turn of the speakers and do all my editing in one session if I can.

This might be a question better asked/answered on the retroarch discord. Mapping buttons in general in retroarch is easy though. If you open retroarch (not via a game, etc., just retroarch directly) then go into the drivers/input section. From there you can map your global control/buttons. However, the problem is, retroarch also allows per core and per game mapping of inputs. So, it really depends how this person setup retroarch as to if they've set it up via per game and/or per core input overrides. Generally though, with retroarch, there is an order of loading controls/buttons, 1st is per game (if it exists), 2nd is per core (if it exists), lastly it's the global settings. So, in theory, if you can map your general/global mappings to have all teh buttons do what you want, then (again in theory) if you go through the retroarch folders and delete any core or game overides, then those global settings should then be used for all emulators/cores/games. I know this is not a great answer, but I'm not sure there is a one answer for this question because of all the possible ways retroarch can be setup. Also, some cores do require per-core settings as some cores have extra options that you can map buttons to that might not show up in the global settings (arcade/mame for example I believe offer extra buttons that you can assign). For me, I would recommend setting up the emulators and mapping for each platform you want to play on your own, so you can learn how each emulator/mappings work, rather than trying to use a pre-built package.

Not sure if this will work for you or not, but you could try disabling the option that allows for pressing twice to exit Retroarch. This way a single press of ESC will close any emulator/core (including the Mame cores). You can still press F1 to get to the retroarch menu if needed, not sure what you the key press is to get to the Mame UI interface though (if you do need to get to that I'm sure there's a way to get to it via the F1 retroarch menu).

FYI, Legend of Zelda HD Pack now available .... https://www.romhacking.net/forum/index.php?topic=31559.0 Note: You need to use the latest core version of Mesen in retroarch, or the latest dev build of the stand-alone Mesen for this pack to work (it will not work with the stable release of stand-alone Mesen)

FYI, the stand-alone Citra emulator is being developed/updated pretty regularly. The Citra RA core, however, has not been updated since Dec. 2019 if I recall correctly (the dates on the libretro core file on the buildbot server is not correct due to them having to restore the files from their backups after their servers were hacked/deleted)... pretty sure that's still the case anyway. At least I haven't seen my RA core of Citra update in many many months so I assume that's still valid. Therefore, I would suggest trying to use the stand-alone as your primary emulator for 3DS since it's being more actively developed/updated, and the RA core as a secondary (if needed/wanting to see if a game plays better, etc.).

Excellent, glad to head that resolved the issue.

FYI, I ran the same scenario you mentioned above on my system, to see if I could reproduce it with the steps you mentioned, but it exited fine for me. In my case, I have an nVidia 1060 GTX video card, with the latest nVidia drivers, and PPSSPP is using Vulkan as a backend.... if that helps at all. Cheers, CDBlue

hmm not sure then. But, if you can reproduce it everytime in the emulator itself, then as you said it's an issue on the emulator-side. I'd suggest maybe going to the PPSSP discord and reporting the issue on there maybe. EDIT: Also, make sure you video card drivers are up-to-date, and that you're using an appropriate driver in PPSSPP. For example, for an nVidia card, you can use OpenGL or Vulkan. For AMD, use Vulkan, for built-in/onboard intel test to see which one works best, but likely OpenGL will be your likely best bet on those cards (or d3d if it supports it, I don't recall if PPSSPP supports d3d or not.. if it does then for an intel card use that)

hmm, working fine for me. Can you reproduce the issue by launching and exiting the game directly from the emulator rather than launching it via launchbox? Is it happening to all PSP games, or just a certain one? That might help pinpoint if it's a setting in PPSSPP or in LB/BB.

I don't use the angrylion pluggins/options as I prefer to upscale and make the n64 games look more modern (rather than going for the original n64 experience), so I'm using the latest release of m64p as my primary emulator for n64. As for the retroarch cores it looks like they might have just put up the buildbot repository again, so it should be safe. They might not be totally up-to-date until the core devs push their latest versions though (so you might have a release or two behind right now for the cores since they only uploaded what they had on backups I believe). In a few days though I'm sure if you update again you'll be sure to be on the latest versions of the cores that are being actively developpped.

There are many good options for decent N64 emulation these days. But, I would say yes, m64p is likely still the better out of the box solution to get up and running quickly with decent compatibility and features ... IMO. There are some good cores available in Retroarch as well, but I won't bother suggesting any of those at the moment since retroarch is in repair mode since they were recently hacked, and getting cores downloaded/installed is not as easy until they get things back up and running again.

FYI, I have this issue occasionally as well. Only one monitor/device, 1080p, 100% scaling. Happens with different themes too, not just the default theme. It's very random, but most times I've noticed it it's either when I just open launchbox, or when I get back into LB after playing/closing a game/emulator.

You shouldn't need to use the core commands anymore, as you can simply go into the Retroarch emulator settings in LB, go into the Associated Platforms tab, and the select the core for the platform in question from the drop down. For your example, for Super Nintendo Entertainment System (or whatever platform you have it called) click the drop down and select snes9x_libretro.dll from the list. If the core is not in the drop down, or it says missing core, then you need to download the core first via retroarch's core installer section. If you do need to use that command line parameter, for example for a game-specific situations, it should still work fine, but you need to make sure you have the correct syntax in the command line. In your example above you have spaces between the cores and the \ and the dll file name. I'm not sure if this is just a typo or if this is actually what you're trying to use. If this is what you actually have, then this is not the proper syntax and will not work. You should be using the following if you have to use that older format: -L "cores\snes9x_libretro.dll" Notice no spaces between the cores and the \ and the snes9x_libretro.dll. Again though, this will only work if you actually that that core downloaded and installed in retroarch's cores folder.... which if it worked for you before, it should be Hope this helps, CDBlue

Ok, I tried Mesen stand-alone and the lastest Mesen on on the latest nightly of Retroarch, and had no issues with the HD Packs I have installed. On both, the packs worked, and the controls worked without issues. Not sure what the issue might be for you now, as I can't reproduce it. I'm out of ideas as to why it wouldn't work for you, because if the buttons mapped correctly, then your controls should work with or without the HD packs

Just re-read your original post. I guess you can ignore the above because you said you mapped it in the emulator lol. I'll test my HD Packs when I get home to see if maybe they're broken in the latest versions.

Hmm, ok. next thoughts then :). In the stand-alone Mesen, did you go through the input mapping section in the options? And, if so, did it recognize/map properly there? By default, the Mesen stand-alone won't likely work with a controller until you map the inputs to your actual controller, as opposed to Retroarch which usually just works with most controllers without having to map the inputs. Open Mesen, select Options/Input. On the window that pops up, select setup next to player on, then go through and assign mappings to all the buttons/d-pad inputs, etc.

I haven't played with the HD packs in a while, but it sounds like maybe a corrupted HD Pack. If it doesn't allow you to play in the stand-alone, or the retroarch core, it might be related to that. But, just because you didn't specify, you should also make sure you're running the latest version of the stand-alone, and the latest version of Retroarch and the Mesen core. As of the time of this post: Mesen standalone - latest version is 0.99 (https://www.mesen.ca/#Downloads) Retroarch - latest version is 1.8.9 (https://www.retroarch.com/?page=platforms) Mesen core - You can download it via the Core Installer option in retroarch, or update via the core updater option in retroarch (or if you do cores manually, you can grab the latest version from the nightly buildbot - https://buildbot.libretro.com/nightly/windows/x86_64/latest/mesen_libretro.dll.zip) It's especially important to keep retroarch updated, because sometimes they introduce new features that the cores use. So, if you're using an updated core on an older version of retroarch, it might be glitchy and/or not work at all. Not sure if that's the case with Mesen, but it's good to keep them both updated either way to ensure smooth functionality in general. Hope this helps, CDBlue

1) Yes. You can delete those files, but I would recommend to not delete the most recent version... in case you ever need to re-install you can just run that file again instead of having to download from the website. 2) Yes, I believe so. As long as in your image settings for priorities, you have box front reconstructed listed below box front, then it should only pull the reconstructed one if the box front image is not found.