CDBlue

Another update for the mesen HD pack thread. Looks like mkwong98 released a donkey kong hd pack for mesen. Link can be found in the same thread as mentioned above: https://forums.nesdev.com/viewtopic.php?f=21&t=17110

I don't have a PS4 to test out epsxe with, but I thought I'd point out a better (IMO) choice for PS1 emulation. If you are using retroarch, I would suggest using the beetle psx hw core, and giving that a go for your PS1 games. As I just mentioned, IMO it's a much better PS1 emulator, has more options, better visuals, and since it's a core via retroarch it uses alot of the built in features that comes with retroarch (save states, etc.). Check out Simply Austin's video on the core in question, and how to configure it to look its best: Sorry I couldn't help with the actual question you had, but in case you were not aware of this core for PS1 via retroarch I thought it might be helpful in another way. CDBlue

Anytime

@omlifecrew Make sure you have Save settings on exit (under settings) checked off in puNES. Press alt-enter to go fullscreen then close the emulator by pressing Alt-Q (which is how to close the emulator properly, while letting it save its settings). Now when you launch puNES via launchbox it should remain in fullscreen.

Hmm ok. 2nd thought.... by chance do you have your emulator(s) installed in your program files or program files x86 folders? If so, I would suggest moving them to another location your HD such as C:\Games or something similar. Typically the only time you need to run them as admin is because they're in a location that require admin rights to be able to create/modify files (such as program files). If they're located in a non-admin needing location typically they just work fine. Again, just shooting at the dark here, but those were two obvious things I thought of as I saw what issues you're having. Hope any of this is at least a little bit helpful. Edit: same goes for LB. My suggestion if if it's not needed, it's always best to install it in a location where admin rights is not typically needed to run things (such as C:\Games). And LB does not need to be in the program files (or x86 folder).

Wondering if it's an issue with how your accessing, and more importantly, how LB is accessing the ROMS on your WD Cloud. Do you have the cloud mapped to a local drive on your PC (eg. W: or something) or are you accessing it via the hostname \\WDMYCLOUD\ or the local IP? If it's the hostname or IP, I would suggest mapping the My Cloud to a local drive letter instead, then then getting LB to access it via the local drive letter. That way LB just thinks it's a local drive, even though it's a NAS location. Just a thought, not sure if this will fix both issues or not, but it's worth trying if you're not already accessing it via a local mapped drive

I think this was asked in Cid's unified thread, but I'll ask it here as well since I'm currently using this version of Unified. Is there a quick way to slow down the wheel from fading? I'd like to have it visible for a few more seconds before it fades out.

@Suhrvivor I believe Demul supports CHD file formats since the last couple of releases (at least the changenotes says it does - I don't use those so I can't confirm yes or no). If so, you might want to give the standalone version of Demul a shot and see how it goes. IMO it's a much better emulator than the older Redream core that's in Retroarch that you mentioned you were using. Edit: Also, according to Libretro docs, the Reicast cores in retroarch (I assume both the standard and oit versions that are now available in retroarch) also support chd file formats. https://github.com/libretro/docs/blob/master/docs/library/reicast.md These have also both been growing in leaps and bounds lately as well.

doh... never even saw that. Added the -L "cores\parallel_n64_libretro.dll" to the command line for a game that works only with that core, and it worked like a charm. Thx for the assistance

Hey all, I've been trying to figure out how to do this, and so far have not been able to come up with a way. So, I figured I'd check here to see if anyone knows how, or even if, this is possible to do in Lanuchbox. Here's an example of the scenario in question: - I have two retroarch cores setup in launchbox for Nintendo 64 - One entry using the mupen64plus_libretro.dll core, and one using the parallel_n64_libretro.dll core. Now I can right-click on any N64 game and select launch with... and then select whatever core I want to use and it will launch retroarch using the core I told it to... great, how it's supposed to work However, if I want a game to use a certain core as the default emulator, I can't. All I can do is tell it to use the Retroarch core, and it seems like it just auto-runs the first one on the list (so for the example above, it would always use the mupen64plus core, even if I want it to use the parallel core). I know there are other ways around this, such as renaming the console then putting in the 2nd core for that newly named console and making it the default etc. But I don't want to make custom-named consoles. There are just a handful of games that I find run better, or at all, on the parallel_n64 core instead of the mupen64plus one. For now, I've removed the entry for the mupen core, since I almost never use that one as I have M64P as my primary emulator anyway, so right now I have just the parallel core for the retroarch entry for Nintendo 64. So, when I select Retroarch as the default emulator, it now uses the parallel core. But, I like having multiple cores for consoles that do have multi-core support available. Anyway, tl;dr is there a way to specify which core you want a game to use as a default emulator, when you have 2 or more core entries for a console in Retroarch? Thx for any assistance, CDBlue

Sorry to bring back an older thread, but there have been several new packs released so I thought it would be appropriate to bump this thread back up in case people aren't aware of it and wanted to know https://forums.nesdev.com/viewtopic.php?f=21&t=17110 New/updated Castlevania pack, alternative Super Mario Pack, Ninja Gaiden I and II packs, and I'm not 100% sure but I think the Megaman HD pack was updated since this post as well. It's on version 1.2 now, I don't recall what version it was when this thread was originally posted. Anyway, engoy. -CDBlue

Thx for the suggestion @Lordmonkus I totally forgot about m64p (Mupen64Plus + GLideN64 + GUI) I had tried it a while back when it was new to the scene and was not impressed by its performance. Seeing this post reminded me to revisit it and boy was I not disapointed. It's probably one of the better, if not the best, N64 emulator I've played around with in a while. Also, I was able to convert my .DAT texture packs to .htc format so I could get them to work in m64p is a big plus too Anyway, just wanted to say thx for the suggestion you did and I second the suggestion to the original poster.

I've had this issue in the past as well once in a while. Maybe emumovies is getting alot of traffic, or maybe there's an issue with the API, not sure. You could always just download them from Emumovies directly (https://emumovies.com/files/category/2031-video-themes/). They would go in your videos/platform folders where Launchbox is installed. Just make sure to name them the same names as you have your platforms named in LB. For example, if you download a video for Nintendo 64, and it's called Nintendo_64.mp4 but your platform is names Nintendo 64, you need to rename the video to Nintendo 64.mp4 for LB to pick it up and play it automatically.

Also, if that setting is ok, maybe try using another audio driver other than xaudio to see if you get sound. Wasapi, dsound, etc. .. another might work if xaudio doesn't for some reason.

I remember seeing people post about issues with RetroArch and sound in the past. The one fix that I saw mentioned a few times, that seemed to fix people's issues, was to check to make sure Audio Resampler is set to sinc, CC or nearest in the drivers section in RetroArch. Not sure if this is the fix for you or not, but thought I'd mention it in case as it was a common issue in the past it seems. Hope this helps.

Lol, well this a quick reply to my own thread. I found the issue hehe. I was following BSOD's guide on best settings to use etc. for performance in BOTW. Turns out if I use his recommended timing settings of 1MS and QPC, this bug occurs. If I leave the timings in the debug dropdown to the default Cemu settings, all my games launch fine from within LB/BB. Maybe those timing settings conflict with LB/BB and that's what's causing the emulator to close down, not sure. Anyway, I guess this now a how-to-fix post if anyone else has this same issue as I described above Cheers, CDBlue

Hey guys. Looking to see if anyone else is having this issue, and if anyone knows how to resolve it. I just upgraded to the newest version of Cemu (version 1.12.1) and when I go to load my games from Launchbox, some games open Cemu, go to load the shader files, then Cemu just closed before the game starts up. I can go in Cemu and launch the games just fine, and they are fully playable in Cemu. I checked my launchbox emulator settings, I'm pointing to the correct Cemu.exe file, I've got the correct -f -g command, and some games launch just fine from within launchbox/bigbox. For example, New Super Mario Bros. U and Legend of Zelda Wind Waker HD launch and play just fine when I try to launch them from Launchbox/bigbox, but DuckTales and Shovel Knight don't. They try to, then Cemu just closes with no error message. I was able to run all these just fine with the previous Cemu builds, but not with this one it seems. Anyone else using the newest Cemu getting this same issue, and possibly thought on a fix for it (other than rolling back to the previous Cemu that is)?

Yeah, I figured why not write one. Saw a few people having issues with Dolphin.exe since they made that version use the qt GUI, and moved the old wx gui to the DolphinWx.exe. Eventually, I think the plan is to drop support all together for the old Wx gui and go just with the qt version. Hopefully they will fix the issue of the qt version staying on top of the emulator window when dolphin is launched from launchbox, but in the mean time I figured this might be helpful to some people

Yeah, I couldn't find one either, which is why I wrote that one. You can find the parts needed on that website, just need to know how to put the parts together

Just wrote this script for someone who was having issues in the Emulation thread, with the new Dolphin master file that is having issues with the program windows staying on top of the emulated window. This script will search for the main Dolphin 5.0 window and minimize it, allow just the emulated game/window to be in fullscreen. Figured I'd post it here too since this thread is solely related to AHK script SetTitleMatchMode 1 SetTitleMatchMode Fast WinWait, Dolphin 5.0, , 10 if ErrorLevel { MsgBox, WinWait timed out. return } else WinMinimize ; Minimize the window found by WinWait.

Perfect, thx for the clarification

I haven't installed the beta yet, as I prefer to stick to stable releases on my main retro gaming machine. However I have a question related to the drop down selection for retroarch cores. Is this a set list that you have populated, or can we add cores as needed? I see above you mention that you added a section to add command lines, but that the cores would still be selected from the drop down. My concern would be if it's a set drop down list for the cores, and new cores are added, we will not be able to use them until you add them to the drop down list. Just looking for clarification if possible on the drop-down functionality is all Thx

FYI, just got home and tested the above script and it worked fine for me. I had to put it above any other scripts I had on my autohotkey tab though. Hope it works for you as well Here's my entire autohotkey script for Dolphin emulator in launchbox (the below will also close Dolphin when you press Esc on keyboard, or if you have controller automation setup to close the emulator as well). If you don't want that functionality, just use the code above. SetTitleMatchMode 1 SetTitleMatchMode Fast WinWait, Dolphin 5.0, , 10 if ErrorLevel { MsgBox, WinWait timed out. return } else WinMinimize ; Minimize the window found by WinWait. ; This section closes emulator when pressing Escape $Esc:: { Process, Close, {{{StartupEXE}}} }

I'm at work so I can't test this code, but the following might work. The only part I'm not sure of, is what the title of the game emulation window is. If it also begins with Dolphin 5.0 in its title, as the main program does, then this script may not work. Breakdown of the below is set the winwait command to look for the text at the beginning of the title window. It waits 5 seconds to make sure Dolphin has time to load the main program/window. Once those 5 seconds have elapsed, it will look for the window that has the word "Dolphin 5.0" it it's title name. If it exists it will minimize that window. Again, not being able to test it, I'm not even sure if this will work or not. But, feel free to give it a try. If it doesn't work just don't use it, if it does, then you're welcome FYI, if your computer takes more than 5 seconds to launch the main dolphin program (not talking about loading the game, just launching dolphin), then you can adjust the time delay by changing the last 5 on the WinWait line to longer (eg. WinWait, Dolphin 5.0, , 10) SetTitleMatchMode 1 SetTitleMatchMode Fast WinWait, Dolphin 5.0, , 5 if ErrorLevel { MsgBox, WinWait timed out. return } else WinMinimize ; Minimize the window found by WinWait.

Just an FYI, it looks like if you select the check box next to "Keep Window on Top" in the config/interface in the Dolphin.exe it seems to resolve the issue as well. Not sure what the difference is yet between the Dolphin.exe and DolphinWx.exe (if there are any that is), but in case you wanted to use the recommended Dolphin.exe this work-around seems to work (for me at least it does). Hope this helps.