dragon57

Correct in all your statements. Overall, a couple items should be noted. 1. The Bezel Project integration written into the LaunchBox application still uses the old, default behavior for Retroarch installation, so you have to pick which way you want your Retroarch structure to be. 2. This isn't to say you can't mix the behaviors. I have a test virtual machine that uses the older default behavior of Retroarch for cores that only support one system which uses the default config directory and the new way of separate, custom cfg files that point to newly created files and directories for those cores that support multiple systems with known overlay issues. It is funny that this way of using custom cfg files that point to system-specific config directories and overlays causes many Windows users of Retroarch some issues of just unfamiliarity. Retropi and many other front ends on Linux have always used this structure, so those users never saw overlay conflicts when using cores that support many consoles/systems.

It may be helpful for anyone who reads this entire thread to link to the Github release notes for the Windows app that explains the new actions of the app. https://github.com/thebezelproject/BezelProject-Windows/tree/V1.1.14 Below is the text from that release. The cfg files created in the Retroarch main directory reference the custom config directories mentioned above, e.g., config_n64. Added the following text to the application Help page: This utility will created custom cfg files in the Retroarch main directory for any Bezel pack installed for the Retroarch platform. Use the name of the cfg file on the command line when Retroarch is started. Example: retroarch.exe -c "retroarch_mastersystem.cfg" Updated the logic of the application to mimic more closely the Retroarch config directories used on the RetroPie Retroarch installation defaults, e.g. separate config directories for each installed platform. This should resolve the issue where cores that support multiple systems can cause references to games with the same name to overwrite each other, with the last installed bezel set being the only set used for supported systems on that core.

Yes.

I hate to assume, so all I can do at this point is get some history and maybe some screenshots of your Launchbox emulation setup for the systems you are having problems with. How did the config_nes, config_n64 directories, for example, come from? Are you familiar with the Bezel Project Windows app and if so, have you used it to install bezels for certain systems? If not, I would have to assume you used the now built in bezel installation feature of LaunchBox itself? If so, what version of LaunchBox? In LaunchBox, if you use the Tools/Manage/Emulators action, then select Retroarch and click on the Edit button, you should get an Edit Emulator panel. Click on the Associated Platforms in the left column. You should then get a list of the platforms defined in Retroarch along with there command line parameters. Show us a pic of that.

The only thing I can think of that might cause the issue you are seeing is how input_overlay_enable is set in the cfg file you specify on the retroarch command line. Make sure that is set to input_overlay_enable = "true"

Actually, having different config directories for the cores is a feature of Retroarch, not a bug, like config_nes, config_n64, etc. The newest Bezel Project Windows app creates this config_<platformname> structure with information of how to specify these via the command line. This is the only way to address the issue you run into when certain cores are used that support more than one system, like Genesis and Master System. Using the default Retroarch settings, the last installed set of bezels will take priority when games are run and you happen to have identically named roms between different, but supported systems with some of those cores, like in my example of using the Retroarch core that supports more than one system type, e.g. Genesis and Master System. Hope this is clear, if not ask any questions you have and I'll do my best to answer them.

I finally circled back to NeoStation today and noticed the current build has the beginnings of themed support, especially the default theme has some optional looks now whereas before you got the one and done version.

Great stuff! I created my own bezel util using AHK years ago for standalone emulators, so your intentions are very doable without using Reshade and the like. Keep at it!

If you are talking the Retroarch core selection for a console/platform, hit ESC on the keyboard on the main screen. The currently active selection will show the core selection screen after the ESC sequence. If you have a gamepad working, there is a mapping for bringing the core selection screen also.

Since this is an early alpha version for the currently supported platforms, there is no support as of yet. It has basic gamepad support and also since it was originally heavily dependent on Retroarch and its support, I am sure this will come, eventually.

According to their Discord, the existing 'theme', if you will, will not change in the short and medium term. Long term plans are to allow something like that. The author was going for something like the SteamDeck interface initially.

Yep, same here. Looks like it will take their web master to address the configuration issue.

While I know my following comment is not helpful, I will take your request and put it on my to-do list. Since 21:9 monitors still account for a very small percentage of overall monitor sizes in current Steam statistics, I believe having at least a generic MAME bezel for horizontal and vertical games would be better than nothing. Please don't take my comment as an official direction by The Bezel Project. It is not. I will see what I can do about generating a default MAME horiz/vert 21:9 bezel and posting here, hopefully before the end of the year. No promises, however, as this is a busy time.

Correct. The latest Bezel Project Windows app creates MAME lay files according to the correct instructions mentioned above. While LaunchBox uses and installs files from the Github repositories as the BP app, lay files are created by Launchbox itself via the devs here and I have no idea if their lay file logic was changed. You could always use the Report a Bug feature of the forums, which is under the Help & Support header if you find Launchbox's latest beta writes out lay files incorrectly.

As long as the symlink is correct and still accessible to the OS and apps, you should have no problem. That is the purpose of symlinks, to do what you are needing to do.

Another 100% in agreement. Hands off everything gaming related unless the user turns on an option. I can't tell you how many friends have enough trouble keeping retroarch running without another app coming along and shooting both feet and kneecaps off.

A new Windows installer, V1.1.15, has been pushed to Github which should write out MAME lay files in the modified format.

Many thanks for pointing this out. I will create an item in the project to address the lay file format as you stated.

So you are saying you must type a name in that field before selecting Browse? If so, indicating that would be super helpful. Also, if the name is required first, could the browse button be inactive until the field is satisfied?

I also come from an IT related team with a QA background. I made a personal decision to stay with an old build because recent updated releases of Launchbox had a number of issues with my installations. I have been too busy to provide feedback, but after searching the beta threads, the issues I saw were already reported. Your points are quite valid. I hope someone from the core team responds.

Down again. Whoever is responsible for the server might want to check for a root cause, assuming no server admin tasks are going on to cause this.

Seems to be fine now. Thanks for the follow-up.

The DB seems to be down again. This is what I get when I search: An unexpected error occurred while processing your request. I've been trying for nearly an hour. Thanks!