Sbaby

I've been thoroughly testing the Sudachi emulator over the past few weeks, and I have to say the latest version (currently 1.07) is truly impressive. It works significantly better than its predecessor, Yuzu, and even Ryujinx. I managed to complete The Legend of Zelda: Link's Awakening in 4K at a steady 60 fps, with no performance drops or crashes. It's incredible—it runs smoother than a PC game and even better than the original game on the Switch. Of course you have to apply the right mods for some games, but they are easily found. I can't wait for the new chapter from developer Grezzo, The Legend of Zelda: Echoes of Wisdom, to be released on September 26th! 🥰 You can download the latest version here: https://sudachi.emuplace.app To answer your question, the emulator executable is named sudachi.exe, and the game ROM should be in .xci or .nsp format (although the latter is often used for game updates).

Thank you very much for your response and for your appreciation of the use cases I shared. I would just like to point out that I would not want too much emphasis placed on the password protection case, as the other two cases I mentioned, and the several other cases I did not mention, are equally important and deserve equal attention. Upon further reflection, I realize that, despite the length of my description, I may not have emphasized the main point enough: I believe there is a conceptual error in the handling of additional applications in BigBox. To make it clearer, I have prepared some pictures and considerations that can help you understand the problem and find a quick and easy solution. In summary: In case 1: The additional application should be visible and bootable, so in this case the current behavior is correct and should not be changed In cases 2, 3, and 4, however, it makes no sense for the application to be visible or selectable in BigBox, since it is already started automatically. In fact, it should not be possible to start it separately. It would be useful to develop a clear distinction between manual and automatic modes. In particular, if a user selects an additional application in automatic mode, he or she should not have the option to start it manually. I hope this additional “quick” information will help to better clarify the issue and I am always available to provide further details. I also updated the BitBucket ticket Thanks again for your time and the team's support! 🤗

I've been using Hypseus Singe for quite a while now, and I really like it, especially for its native support for bezels. The only issue I've noticed is that sometimes, randomly, when launching from LaunchBox or BigBox, the game doesn't load on the first try and goes back to the frontend. However, it starts successfully on the second attempt. I'm not sure if it's the same issue others are experiencing. It happens to me about once every 10 times, but otherwise, it works very well

Hi @JoeViking245 😉 I just wanted to clarify that I don't have any issues myself because I've configured all my emulators to use XInput, including PCSX2 and Xenia, exactly as you mentioned. I only stepped in to try and help the user, and if they manage, they could consider switching to XInput by disabling SDL2. Additionally, I wanted to share something I've experienced: when I leave SDL2 enabled, my controllers work fine when launching the emulators directly, but if I launch them through LaunchBox, some conflict arises and the game doesn’t run properly. I hope this information will be useful to others and to the Launchbox team as well, in any case I have no problem with it, at least in this context 😅

I confirm that I had a similar problem with the active configuration of SDL2 on an earlier version of PCSX2, now I have disabled the SDL2 in PCSX2 and I am using with xinput, for me nothing changes and so I don't know if this problem has been solved, however it would be useful to investigate this for a use of the new excellent SDL2 driver for controllers

Hi @AstroBob Thanks for your interest. First of all, it is important to distinguish between LaunchBox and BigBox. In LaunchBox, I think everything is perfect as it is, because it is more of a management system, while BigBox I see as a real gaming station, similar to a console, so controllable mainly by controller or integrated into an arcade cabinet. This means it has to be user-friendly and intuitive, even for those who are not very familiar with the system, such as children or other family members. I cannot always be the one to handle any problems that arise when someone accidentally starts an additional application that should not be selectable in BigBox. In LaunchBox there are no problems, but in BigBox the additional applications could be confusing, as a user might mistake them for alternate versions of a game. This could ruin the gaming experience and, in some cases, cause malfunctions, forcing me to take action. I think this is an important issue that deserves to be reviewed. Therefore, I am referring to specific cases where I would like to hide the application in BigBox, because it does not make sense to make it visible. BigBox has the ability to manage additional applications to start other versions of games, such as versions from other regions or revisions, and that is great. Additional applications also make sense in 80 percent of contexts, and it is fine for them to be visible in BigBox, but in certain special cases they should be neither visible nor selectable, because they could compromise the use of the frontend. In the first case I mentioned to you a while back, unfortunately I don't remember exactly which game were referring to, but it was probably a situation that required an automatic mouse click to start the game in full screen or to get the focus. I don't remember exactly, but the concept can be extended to many other situations, so I'll give you more examples. A classic example: the use of JoyToKey for controller management of some old and rare game that does not support joysticks, with two scripts: one to activate JoyToKey before starting the game and one to deactivate it when closing the game. If a child, seeing JoyToKey as an option in BigBox, started it manually without then starting the game, the controls would be defeated because there would be no way to properly deactivate JoyToKey. This would cause confusion and a negative navigation experience in Bigbox with wrong buttons. You might suggest that I integrate JoyToKey into an AHK script that also includes game launching, and you are right: for example, for DemulShooter games, I do it this way. Game execution for LaunchBox is done through an AHK script, not the EXE of the game, and this script handles everything. However, there are cases when it is preferable to use the additional applications, such as when you want to configure something only for certain games that use a specific emulator in LaunchBox. In these cases, you cannot set up an AHK as an executable, because you have to keep the extension associated with the emulator. So the best solution is to configure an additional pre-game and post-game application, but it does not make sense for these to be visible or selectable/startable via a choice in BigBox. Another reason why it is sometimes not ideal to use AHK as an executable is that BigBox struggles to handle it as a process, especially when it involves multiple processes, as is the case with Steam. This can compromise focus or pause management, but we are getting off the main topic here. Back to us: another example is a pre-game script that synchronizes saves between Switch emulators. This script, too, has no reason to be visible or bootable in BigBox, since its purpose is purely functional and related to starting the game. Another case concerns an additional application that starts for some adult MAME games and requires a password to be entered before startup. It makes no sense for this application to be visible as an option in BigBox, since it is not functional on its own. The password prompt is already handled perfectly via an AHK script set up as a pre-game application, which waits for the script to finish before starting the game. It works perfectly, so I don't see why it should be shown as a separate choice in BigBox, much less bootable on its own. You can watch a video in operation here : I could give many more examples, but the concept would remain the same: there are many situations where additional applications are critical to the gaming experience, but they should not be visible or manually accessible in BigBox, as this could be confusing and detract from the proper use of the system. I hope I have been clear on this point. In conclusion, I think there are two possible solutions: 1) Give the ability to hide specific applications in BigBox. 2) Keep the applications visible as they already are, but without the ability to start them manually.. I hope this information is helpful to better understand my use case and, if possible, to update the ticket on BitBucket.

I have never had these problems, but now it has been happening to me for a few days. Restarting Launchbox the videos are perfect, then randomly it can still happen that they go black, so I restart and ok

Regarding the common problem of having to click on the game for the badge to appear, I would also like to point out that although the auto-populate option is turned on, the game is not automatically added to the 'Games with saves' playlist until you click on the game and the badge appears. Only after you click on the game will the badge appear and then it will be correctly added to the playlist. Otherwise, the playlist will not populate

Thanks for the reply, unfortunately I don't see any audio related entries in the emulator.ini file

As far as I am concerned, it would seem to work but unfortunately for example for ps1 I have very few srm format saves from an old core, now I use the mcd format, in the retroarch folder for example I have both old and new Castlevania saves, the new ones are mcd but launchbox only sees me the old srm, could you please add support for the other extensions of the saves folders managed by retroarch? It would be nice that this way a user could see them well and manage them better. My retroarch\saves folder 👇 the last save I made was from 2024 👇 Launchbox automatically imported me only the old srm and savestate from 2019/2020, but not the new important saves in mcd format from 2024 👇

I didn't make new saves after Launchbox started, the scan at startup doesn't work it's like there are no launchbox saves, but I have thousands of them, to view the badges I have to click on them one by one

Hi, I installed this beta, in the menu I applied the badge display for saves, it works however the badge symbol only appears if I click on the game cover, is this normal?

Hi @AstroBob, thanks for the update! No problem, I'm happy to wait while you take a look, talk to you when you have more information. Thanks again for keeping me informed

Okay. For players this is really bad and boring, but if it can't be fixed patience

I’ve been subscribed to EmuMovies for decades, and although the integration test with LaunchBox is successful, the EmuMovies scraper keeps returning "game not found." To resolve this, I have to use FileZilla to manually download the videos from EmuMovies, which works without issues. Additionally, I’ve added several Nintendo Switch games, but LaunchBox doesn’t find any of them, even though they are actually present. What could be the problem?

I'm not asking out of arrogance, but simply to understand better: could you please clarify why my request has remained in the 'Submitted' status for the past five days? 🙄 Thanks

I understand for the game details screen, and I'm fine with that, but if I start a game from RUN WITH, or from ADDITIONAL APPS, when (after playing) I want to go back to the game detail screen I ask if possible to at least automatically close those additional menu and go back directly to the game detail screen (without also having to close the menu of additional apps or additional versions that reappear when you close the game) I am talking about bigbox only

When starting an alternate version of a game in BigBox, is there an option to exit the game and go directly back to the game wheel, without having to see the panel of additional versions or additional applications left open from before again and being forced to press back?

Thank you very much for the clarification regarding the folders 👍

Unfortunately it is a known and never solved problem that occurs differently on various systems, devices, games or emulators, in short it depends a bit on a million different conditions. For example Duckstation does not give me this problem, while it happens to me for other emulators. To solve the problem safely I usually create an external autohotkey script similar to this: WinWait, ahk_exe duckstation-qt-x64-ReleaseLTCG-MSVC.exe WinWaitClose, ahk_exe duckstation-qt-x64-ReleaseLTCG-MSVC.exe WinMaximize, LaunchBox WinRestore, LaunchBox WinActivate, LaunchBox WinMaximize, BigBox WinRestore, BigBox WinActivate, BigBox replace this "duckstation-qt-x64-ReleaseLTCG-MSVC.exe" with the one for your version of duckstation

Excellent job and congratulations! Long live LaunchBox! ☺️

Unfortunately, I have not received any response and am still looking for a solution. Hiding specific additional applications in BigBox by single game: Is it possible? I have created an official request here, please vote for it as soon as it is confirmed by the staff https://bitbucket.org/jasondavidcarr/launchbox/issues/9185/hiding-specific-additional-applications-in

well then something doesn't make sense to me, why by changing the default windows launcher the additional apps stopped working ? you are telling me that launchbox uses its internal but it's not so . all my apps and and ahk emulators started working again when i brought back the default autohotkey launcher UX

I recently discovered that, due to a mouse movement error, I accidentally set my AutoHotkey scripts to open with a different autohotkey.exe on my system. As a result, I noticed that many of my scripts weren't working as expected. I had never checked which version of AutoHotkey was set as default on my Windows, so I tested various versions and finally found that the correct path I was probably using is \Autohotkey\UX\AutoHotkeyUX.exe. Does this mean that most of the scripts I've shared might not have worked correctly for anyone unless they were using AutoHotkeyUX? 😅 With the UX version, everything seems to be working fine. I'm wondering if it's normal for Windows to default to that specific path and if I should continue using this version to ensure my scripts work correctly. Thanks in advance for your advice!