Just wanted to say thanks for these awesome quality of life innovations and improvements!
This is a welcome improvement and something that I had just started implementing manually in my Sega Genesis presets. Is this active already?
Anyway, Keep up the great work!
Sorry for hijacking the thread, but this is something I always wondered.
What is it and why is it needed?
…to return in topic, how do you enable it automatically? Maybe you check the core resolution?
Great work as usual!
I think Sega Luma fix looks better to me than the Sega brightness fix. Wouldn’t be better to remove the Brightness one instead the Luma? Sorry for the stupid question…
I recently did some testing and I found one of them to be more neutral colour temperature wise, while the other seems to add a bit of warmth (red).
I prefer the more neutral one.
Do you mean that Sega Brightness fix is the more neutral one?
I just checked it and it’s the Sega Luma Fix in the [BRIGHTNESS & CONTRAST] Section that I found to be more neutral.
So you agree with me that looks better… So I wasn’t wrong then…
Yes and no.
You asked this, but this is exactly what @HyperspaceMadness did. Remove the Sega Brightness Fix and leave the Sega Luma Fix.
This is the corresponding parameter in the slangp file that remains active:
g_lum_fix
This is for Sega Luma Fix.
Hmm, Sorry, but I’m not sure why this would be happening, it’s kind of strange…
Yup this is active already, it covers the Genesis cores in online updater, let me know if you see it not applying to any particular emulators
Basically Sega hardware has white not at the top value of 255 like everything else, instead white on Sega consoles was like 248 or something, so when playing through an emulator the brightest white will not appear as white as it should. The luma fix stretches the brightness of all values so that 248 lands at 255.
Enabling it automatically is done by using the $CORE$ wildcard for the known Sega cores, so this will not automatically apply to Sega arcade games. If you wanted to use these you could copy the ones in here Mega_Bezel/resource/param_values/core-defaults/core
Hmm I’ll see if I should swap these around because in general something is neutral is usually better. If I do I would need to have the afterglow passes on the potato presets, because that’s where this color correction is.
The way you have it now already uses the more neutral Sega Luma Fix. So it should be good to go.
Ok great, thanks for clarifying that 
Sounds like I can keep it as is.
How do we get our shader presets included in a pack? I really love TheNamec’s monitor bezels and have worked really hard on my VGA and RGB monitor presets that go along nicely with one of his and would love to be able to share so other users can game with such nuanced and tailored displays, once I feel satisfied enough with the results.
I would recommend sharing your presets as a standalone pack, and let @TheNamec detail how to add them to his presets.
I have both local and global overrides in my reference chain, but I am not sure what he has made available in his presets. Although we started with the same boilerplate, we moved in independent directions.
The alternative would be for @HyperspaceMadness to include them as base preset variations, but even so it would still depend on @TheNamec’s reference chain.
Keep in mind that although my pack is pretty neutral (As far as CRT settings go.) I believe he has developed some CRT parameters of his own. Your settings could conflict with his.
You could always contact him via PM.
HSM_Mega_Bezel_Examples is updated to V1.5.0_2023-04-19
Changes:
Go to the first post here for links to the package and install instructions. Please make sure to read the install & setup instructions
The following were done all with the same preset. The shader scales and places the crt image without any user input. The following have no adjustments on top of the default placement of the preset.
If there is no image for the specific game name it falls back to the default image
You can make adjustments per game with only your adjustments saved and no duplication. The following were done this way, see the readme for instructions
To run any of these you only load the top preset, all graphics and specialized presets are chosen automatically based on the name of the game.
Here is the structure for these examples, to add additional games all you need to do is add new images to the folder and name them to match your game.
Awesome work here fella! This is what I’ve needed!! 
Thanks @HyperspaceMadness for all the support over the years and letting me use your shaders with my bezels. It was your idea to begin with and it was a great one. It’s an honor to be used in your example showcase 
Thank you for this advanced setup option. I’ve been playing around with this method the last two nights to see the results on some games with orionsangel bezels. I know you and I have had a side convo on this but I figured it’s good to move it to your main thread now that you have it in here as well.
#1 - In each of the horizontal and vertical _base.params files, are these options below more or less tied together based on the values you go with?
HSM_NON_INTEGER_SCALE_OFFSET = “93”
HSM_BZL_WIDTH = “200.000000” HSM_BZL_HEIGHT = “200.000000”
For example, if you wanted to decrease the bezel width and height to say 125 for each, do we need to try out different values for that HSM_NON_INTEGER_SCALE_OFFSET?
I’m thinking that fatter 200 bezel might have been done on purpose to account for different overlay scenarios?
I’m currently testing out what exact shader parameters while in the game are the ones we want to start off tweaking when we do additional changes to fine tune each game.
#2 Is the point of the move of the additional .slangp file out of the /retroarch/config directory and into the \RetroArch\shaders\Mega_Bezel_Packs\OrionsAngel_Arcade\CORE-ASPECT-ORIENT-HORZ (and the rename plus reference edit inside) just for cleanliness to keep all config files in one central location (shaders)? The reason I ask is because the individual game .slangp file that is saved in retroarch/config appears to work just fine in there from my testing as long as it references the Multigame.slangp thats in the shaders location. Just curious.
Thanks!
Yeah, it’s whatever you like, if you want a bigger or smaller tube you can adjust it. But these are the base settings, so you’ll need to see if it still fits the holes.
So any presets that you are setting up for use in the future for possible distribution or use by other people these presets should not be in the config folder. In my opinion the config folder is about an individual’s retroarch setup. These should really be ones the user has created. And if you put per game presets in there the user can accidentally overwrite them.
In an optimal situation the user ends up with a low number of content directory presets in their config folders, and have additional per game presets for adjustments that the user has decided to make.
Hopefully that helps explain it
Really cool example pushing the boundaries of trying to show reflections in different places. This is leveraging the reflection mask. I’ll be working on more in this area soon to make it easier and avoid the reversing of the reflection on the sides in the bottom.
Thanks @p3st for your awesome work, and inspiring me
Hooray! What a time to be alive 
