dragon57

From your example, it appears you are doing this already, but you are in what Commodore calls "mixed case" mode before entering the load command, right?

I wonder if anyone else is having issues with my usual way of navigating to the forum here. I hit the main URL, then click on the 'Unread Content' link. For the last 2 or 3 days, I get a sorted list of posts like before, but I also usually have a large number of posts in the response that should not be there; old posts with old dates that have already been marked read.

Very sorry for the delay in posting these default MAME bezels for a 21:9 monitor (real life hit me). These are setup to use the default horizontal and vertical settings. Put the ini files into your MAME ini subdirectory and the zip files in your MAME artwork subdirectory. I hope these help some of you. Examples below. genhorizontal.zip genvertical.zip horizont.ini vertical.ini

Yep, existing cfg files will override default settings, so deleting those old ones was the correct procedure. The cfg files not being created might be a bug in the version of LaunchBox you are using, or perhaps a slow server response. Hard to tell, but it sounds like you have a work-around.

I use Fatmatch to do this. Fatmatch uses fuzzy matching to duplicate files against a master directory list you can specify.

While Launchbox creates cfg files under the config directory in a slightly different format than the BP app, the end result should be the same as with the BP app.

I can only tell you what I ended up doing way back when I first started working with The Bezel Project team. I had a huge mixture like you have/had. I just deleted the roms I had and downloaded fresh sets that lined up with the databases the Bezel Project as well as other systems recommended. The ones listed have pretty much become the database standards for the categories listed (1-4). Do not delete any of the artwork files you already have in launchbox. As you import the newly downloaded roms into LaunchBox, it should find the existing artwork and match it up. Launchbox is good about using its own artwork naming as well as No-Intro naming for artwork, for example. I coordinated with the Launchbox team before changing my Windows app to the new method and while no official word was given, I got the impression no change would be made to address the bezel issues that would arise by using cores that supported more than one system. Having said that, I can't speak for the Launchbox coders. Like often mentioned here in the forums, creating a support request is the best way of interacting with any issues you have as a user. As to your last question, and as I have told many other users, if you want to install bezels using the older, default structure, just download the previous version of the app from Github and install it into a different directory than the latest one. I run both here all the time as I need to test against both ways of doing things before I do my releases. Let me know if you have any more questions or concerns.

I suspect the problem of the missing bezels is twofold. 1. The most common issue of a missing bezel is a mismatch in naming of the roms vs the bezel names. The Bezel Project uses the following naming types from their respective databases; No-Intro for consoles, Redump for systems that use optical media, TOSEC for mainly computer type systems, and finally Hyperspin xml data files for systems that may not exist anywhere else. The way to get your naming in sync can be problematic, however we recommand using the Fatmatch utility to rename your roms to match the standard naming used by the various dat files from the naming type mentioned above. 2. The other reason for missing bezels is not specifying which cfg file to use that would have the settings for various bezel related paths/value. Here is an example of a default retroarch installation.

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.