I do! I’ll give that a shot!
1 Like
Let me know how it goes, I’ll work on setting that up here too. It would be good if we can come up with a common directory structure for all these overlays so it doesn’t clutter things up on people’s machines. We had been doing that with a vertical-overlay parent directory name in the past. Maybe we can do the same for the megabezels?
A vertical folder would be a good idea. I think Mega_Bezel_Vertical_Packs would be a good option.
2 Likes
So, it does capture it correctly as a .jxr file. And if I open it in Windows Photo it looks correct. But if I export the jxr file as a jpg or png, or open the jxr file in Chrome the luminance is off again. Do you do anything to tone map the files before you share them?
EDIT: Nevermind, I found a little utility that can do it automatically, it can be set up to watch the capture folder and convert them all as they come through too, which is nice: https://github.com/brion/hdrfix
3 Likes
Thanks for sharing the GitHub link. I’ll try that one out.
Both of those overlays turned out nice! I’m on board with a singular folder structure for future and updated overlays.
3 Likes
The .jxr file consists of both an hdr file in jpg format and a properly tonemapped sdr file in jpg format.
The SDR/HDR file is used according to whether or not HDR is switched on in Windows.
I think the Windows Game Bar HDR capture generates an actual tonemapped .jpg .png file as well.
I can share another app which is supposed to assist with the tonemapping and viewing of those files.
If you could extract the SDR image from the .jxr file captured using the nVIDIA Shadow Play method, that might look pretty decent.
1 Like
Yes, the Game Bar seems to be the easiest method. It’s actually producing a tone mapped png alongside the jxr, which is nice as it’s also lossless. I’ll just use Game Bar to take the screenshots going forward. Thanks so much for all your help @Cyber!
1 Like
I don’t have a really long history in the community like many of you but when I look at the “traditional” method of putting an overlay together vs wrapping it all up into just the shader config itself, I think it should be the preferred method going forward. Of course this is just my own opinion and it also plays a factor with me being relatively new in this scene (year or so) I’m not “set in my ways” like I bet many of you have become over the years getting use to a method.
Getting the image brought into the config via the shader itself is less moving parts to work with and simplifies the install for others who download your work to use in their setups. It also opens the door to have a set “standard config” in the eyes of the original person who releases something to others. It locks that config in place but it also allows for an easy method for others to further tweak any game they want beyond what the original person put together. @HyperspaceMadness really simplified this. Once I dove in on this and saw it first hand, it was a no brainer in my eyes to use this method to package up all of @Orionsangel art in this format. It was a shit ton of work but that was mostly because I was “playing catchup” with his project to get all of the 165+ games in this format. But once you get caught up, doing additional future ones is easy.
4 Likes
Well said, and I agree.
That being said, there is still a need for overlays on SBC’s and under-powered computers.
Having custom aspect parameters in the overlay *.cfg file (Like MAME *.lay files) would greatly simplify overlay distribution for Retroarch. It is odd that MAME, Rocketlauncher, and EmulationStation all use coordinates in the *.cfg (Or *.bezel) but RA does not.
2 Likes
A quick note on “…automatic placement of the bezel (image)”. That was my original plan as well with Orions work. The problem is, once I tested that out I discovered the placement isn’t 100% perfect on many of the games. It’s not HSM fault it’s just the nature of the beast with the actual image being used and where the calculations come in based on the video area of the image. Many games looked just fine with the auto fit but many were also bugging me seeing one side with a thicker bezel then the other. I ended up just accepting the fact that I was going to customize the fit for every single one if I wanted it more how I wanted the bezels. But I was OK with that because you still have that option available if you went that direction while also doing individual customized ones. Plus that great feature that auto loads the generic cabinet for any game that hasn’t been customized yet. It’s a great system HSM put together!
2 Likes
True. I got caught up in the mindset of “MEGA Bezel is the standard” so much that I forget there might be hardware out there that isn’t the smoothest once you bring that into the config. But for any modern hardware out there MEGA seems to be #1 to get into your config if you can. And if your someone working on a project with your eyes on using the MEGA bezel, then this type of config becomes pretty attractive in my eyes vs the old overlays method looking forward. The hard part is playing the catch up game on old work!
1 Like
Yeah, I use low powered computers myself sometimes and I can’t use the MegaBezel at all on those. I do wonder if @HyperspaceMadness could add an option based on some of the less demanding shaders and without the reflections etc, so we could still use the megabezel as a more universal distribution mechanism?
I think RetroArch did support .lay files as well at one point, but I think it was removed? I don’t know where it stands now.
It would be nice to have something in RetroArch that is as simple as lay files for the consumer, and the megabezel is one option to get there.
It would also be nice if the megabezel could support alternate image files, and have a way for the user to switch between them easily, perhaps as a shader parameter? For instance, we have coin door, CPO, alternative art, small screen, large screen variations in many cases. MAME lay files let you bundle the variations together and the user can just flip between them in the Tab menu.
1 Like
There are actually 8 image layers available in the Mega Bezel. (Background, Device, Device LED, LED, Glass, Decal, and Top.)
They all share the same parameters and the intent defines the layer order.
For a single image overlay you could have up to 8 different images and adjust visibility (Opacity) as you wish.
The Potato have no reflections and only one image layer. It is essentially just a border shader with the Mega Bezel scaling and CRT shader features. I don’t think they will load on a Pi4, but I have had them running on a GTX 750 with 2GB of VRAM. Probably work well on a legacy Intel iGPU.
I assume @HyperspaceMadness could put some kind of scale only shader together that could be prepended with a CRT shader. (Given enough interest and incentive. 
) But I think adding the aspect coordinates to the overlay CFG would be a more universally accessible feature.
1 Like
That is actually a side effect of many of those bezels not having a 4x3 aspect. The automatic placement cannot account for that. It also may work better to create a B & W mask from the overlay and use that as the placement image.
1 Like
I didn’t realize those layers were as simple as that. I’ll definitely take advantage of that to enable the overlay variations.
I will give the potato option a try on my potatoes too when I have some free time 
Agree on the cfg coordinate point too. It seems like an odd omission for the RA overlay framework given all the other capabilities it has.
1 Like
You will have to take care. Many of the layers inherit different scaling. (Background, tube, screen, Device etc.) You will have to change that parameter to be “Background” or “Full”.
2 Likes
Check out my section “— Per Game Art Variations —” in my thread. I account for this as well. It’s a simple adjustment in the main game.params file to change to another variation image.
2 Likes
Yeah, I saw that, we always had that option in the cfg based overlays too, but it required the user to edit the file themselves. I was hoping for a way to do it in the UI without the user having to edit files, as it is in MAME.
1 Like
For switching on the fly I think the “Next Shader” and “Previous Shader” hotkeys are best suited. ATM the system doesn’t “remember” the folder of an automatically loaded preset (Game, Core, or Content Directory.) but if/when that changes, separate variation presets may be cycled through with the keys.
Currently, if you manually load a preset, you can cycle through the variations before saving a preset.
I don’t know about the overlay CFG enhancement, but @HyperspaceMadness is the most likely candidate for changing the “Remembering” of auto loaded presets.
1 Like