C-Beats

Yeah. That would fairly simple to do. I got some dev I got to finish up but if no one reaches out to ya by time I'll done I can write ya up something quick and dirty for ya.

Think you may have misunderstood. You have 2 files that need created for your entire library. The marquee view for your platform list, and the marquee view for the games list. The XAML would be pretty simple/straight forward. If you let us know what you want displayed on both monitors some one could help you make the files. If you just want two images shown it's a 5m job to do.

You'd have to manually create a marquee view file to do this, but yes it's entirely possible to do. I enjoy your cab design quite a bit though the main monitor being 4:3 for pinball I'm not sure I'd enjoy, the overall concept is pretty cool.

The GUID you see on some video filenames is because you have multiple games with the same title in the same platform. We add the game ID to the filename so we know for sure which video goes with which game.

I know my Nvidia cards have the ability to mess with settings like that per app. I'd check and see if you can do any app overrides and just turn it off for LaunchBox/Big Box and leave the global setting to on.

As stated, open up a ticket and we'll see how widespread the issue is. I am locking the thread as it's clear you have no interested in having a civil level-headed conversation about this issue.

Intel drivers are known to have issues with WPF applications (at least for their integrated graphics cards). Do you have the intel graphics software for that card? Or whatever AMD calls theirs? If so look for a setting to force anti-aliasing off or on. Intel drivers by default attempt to "auto-detect" whether they should use it or not and it causing a lot of artifacting. I've never seen it cause the issue you're reporting, but is worth a shot.

CRT is a dying tech, which is why there are adapters being made... to help those refusing to quit it. 640x480 IS low resolution and has been for several decades. 4:3 is an aspect ratio (which is what themes target) not a resolution and IS supported just fine as you've stated. You have several ways of accessing your LB data on another computer or monitor to make it possible to configure your machine. I don't mind discussing the issue with you, but if you are going to be entirely unrealistic about the facts of the matter than it'd be in both of our best interest to just move on.

Yeah, np. I get where you're coming from. Out of curiosity what card are you using, and does your system have an integrated card, a dedicated one, or both? I do know that intel integrated cards have known issues with WPF applications, so curious if something similar may be occurring on your machine.

LaunchBox doesn't have any custom code to handle rendering, it's all done by the WPF framework which is just using Direct X to do everything. A lot of what you're talking about is far too low level for the application to have any idea about it, let alone change behavior because of it.

Most of your performance hit isn't the symlink (per se), it's the fact you've linked to a location on network instead of local. Because of how those links work this WILL cause serious performance degredation.

We don't actively target such a low resolution because frankly a lot of the content just won't fit and be real legible on the majority of machines using that resolution. As many others have stated the amount of users touching resolutions THAT low are extremely small. As a business analyst I would expect you to be able to look at this objectively. We have a team of 3 and only one person actively developing LB/BB. The amount of time we can devote is a set number and any time spent on one item is time that can't be spent on others. To make the highest return on our time investment we have to take into consideration the amount of users affected by an issue as well as if there are feasible work arounds. This particular issue affects very few users, and there are several work arounds since the app is portable. I'd suggest you create a ticket on it so we can get a better understanding of how many users are affected by this issue, then can properly triage the issue from there. That being said you also have to take into consideration you're asking for development time on a hardware that is no longer in production (at least I'm unaware of any company still producing them) and will likely never be again, which alone is a pretty hard pill to swallow.

Remove the controller bindings for the rotations if you don't want them to be. Changelog means there is a setting that can be used to tell the view to use the old way or the new way of showing those views. The old way makes it a static image.

I'd vet if you TV has a "game mode" in it that helps with response times. If the same program works on one TV but not the other it has to be because of the device of the OS settings for that device. The way LB works it really doesn't pay any attention to the monitor it's on other then to determine scaling values.

Unsure if you are using the CTC or raw XAML but essentially all you'd need to do is replace the FlowImage control with a FlowModel one. You can take a look at the Default theme's coverflow views to get an idea as to how to do that

Sounds like a typical issue when using the "Use All Controllers" settings and you have certain controllers hooked up into your machine. Wheels especially are known to do this and Big Box has a setting in it's options to ignore some of those problematic controls.

I read the statement as being closer to the latter image.

We don't have any way to do this in app en masse currently. Does sound like something a plugin dev could whip up fairly quickly if you can con one of them into it.

This was done for backwards compatibility and just folder cleanliness. When we moved from .NET Framework 4.8 to .NET Core 3.1 the file structure applications use changed drastically. We didn't want to clutter the main folder with all the extra crap so we put the main application in the core folder and made a redirect app to sit in the main folder to not break any existing shortcuts. We put the symlinks in the core folder because a lot of the older themes required us to do so to not break pathing. I've never heard of symlinks causing any computer performance hit. Also not real sure why you're already making symlinks yourself in the LB directory.

Interesting. Don't know that I've ever seen a CD case that looked like that.

If you go into Options > Security there are several things you can remove from the system menu. As long as you don't hide it while locked you should be able to

Locking Big Box removes this option

@PaulyC Can you confirm the left/right side of the jewel case looks better for you in beta 6? @spycat we have a clear spine variant, have you tried that?

Yeah if the games are all in \\LaunchBox\Games and your emulators are in that folder (and portable) as well it's just copying the folder from one location to the other.

The answer to your question varies greatly depending on your setup. LaunchBox is an entirely portable app and moving it only requires copy the folder the a new location. If your games aren't in the LaunchBox folder after doing so you will want to select the games by platform and in the Tools menu there is a menu item to change the rom path (believe in the File Management submenu). You can use that to point LB to where the roms are now located.