I’m using the MBZ_3_STD_GDV, but it actually does it in any other presets I’ve tried. I took 2 screenshots to illustrate, both with overlay and a different value to compare.
It’s still working on 1.16, but 1.17 up to the last version, the value doesn’t seem to apply.
So if you are seeing the resolution text this is because your preset has been saved as a full preset rather than a simple preset.
In this situation you aren’t protected from code / organizational changes between versions because full presets have a copy of all the old passes which may not work with the new shader code, whereas with a simple preset there is only a reference to a base preset and parameter/image path changes and you are protected when moving between versions.
I would suggest creating new simple presets and transplant your parameter values from your old presets into them to work with the new version.
Ah, yeah, that’s not possible, at least, for my RGB settings because I’m using Cyberlab’s Death to Pixels presets as a base, and from there I did massive changes to parameters. Cyber’s presets only work up to 1.14. 1.17 nukes them. (edit: checked the README and see 1.17 is the version I was trying with)
I am having problems even using the base MBZ presets that come with the nightly build:
The smooth adv preset, for example, won’t even load.
“[ERROR] [slang]: Texture name ‘CorePass’ not found in semantic map, Probably the texture name or pass alias is not defined in the preset (Non-semantic textures not supported yet) [ERROR] [slang]: Failed to reflect SPIR-V. Resource usage is inconsistent with expectations. [ERROR] [Vulkan]: Failed to create preset: “C:\Steam\steamapps\common\RetroArch\shaders\shaders_slang\bezel\Mega_Bezel\Presets\MBZ__0__SMOOTH-ADV.slangp”. [ERROR] [Vulkan]: Failed to create filter chain: “C:\Steam\steamapps\common\RetroArch\shaders\shaders_slang\bezel\Mega_Bezel\Presets\MBZ__0__SMOOTH-ADV.slangp”. Falling back to stock.”
While all presets are only guaranteed to look as intended with 1.14, there’s nothing that should prevent my presets from running on higher Mega Bezel versions.
My presets still load fine up to version 1.17.
If the Mega Bezel base presets won’t load, CyberLab presets which reference them won’t load either.
Hmm, then something else must be going on with my MBZ.
Edit: Was a problem with the Steam version of MegaBezel. For whatever reason whatever Steam downloads for the nightly breaks MBZ with presets that apply the bezel border.
I downloaded directly from HyperSpace’s github v. 1.17.1 and the problem went away.
Cyber, you are correct, your presets work now.
So a couple of differences between 1.17.1 image output versus 1.12:
Color hues are drastically off. I would figure this would be preserved, but this is not the case, and will be the most time consuming to adapt.
Afterglow requires a much higher value now.
Surround Luminance (new setting) causing tube to have a greyish glow–this was easy to fix.
Regarding hues, is there one setting I need to tweak that will fix that has changed between versions?
There are more than a couple differences actually. Many things have changed mainly in CRT-Guest-Advanced and also in Grade.
Firstly, what specifically do you see as a benefit in upgrading from 1.14 to 1.17? Are you aiming to achieve a more accurate, realistic or better look? What about the Mega Bezel and CRT- Guest-Advanced has changed that will result in better looking presets?
When I used to try to keep up, I would ask @guest.r or @HyperspaceMadness what had changed between versions and what settings would I have to adjust in order to attain the look of the previous version.
Other than that, you can check out the changelogs of all versions since 1.14 and also do the same for CRT-Guest-Advanced by browsing the changes posted in the thread since 1.14.
Another thing you can do is to compare the Shader Parameters in the old version, maybe take some screenshots/photos, then load up the new version and observe which parameters seem to no longer be active, have changed names or have completely different ranges.
On another note, if you have an HDR display, you can use the following tips as a guide to bring my Mega Bezel presets into the modern era.
I’ll did through the changelogs, ty. Mostly it is the hue that is off - the shade of red, blue and green. Everything else was fixed when I got the proper 1.17.1
I’m upgrading from 1.12 to 1.17 to stay more current. Presently when I share my preset I have to give someone a gigabyte sized file which includes TheNamecs stuff, yours, and 1.12 MegaBezel. For myself, reverting everytime steam updates isn’t a big deal, but for the average user it may be too much of a pain, hence getting my parameters to work on the latest version would go a long way towards making them useful for many others, especially if I attempt to make a overlay to integrate with the bezel that resembles the Tandy CM-5 monitor.
Once you narrow down what you’re looking for, maybe ask a more specific question.
There were lots of changes to taps, sharpness calibration of CRT-Guest-Advanced-NTSC, Chroma/Blending, the way custom and preset settings are enabled via the NTSC Resolution Scale, behaviour of rainbow effects. In general, all of my NTSC presets might look more blurry than intended and possibly less saturated in post 1.14 versions.
Even Mask Stagger has been replaced leading to less fine tunability of Shadow Mask settings while making it simpler for a noob to turn on the Shadow Mask.
In my opinion many of the changes which have come from user feedback might sometimes be a bit premature. I tend to try to milk whatever look I’m going for for quite some time using what is available before asking for things to be hard coded in the shader.
In short newer isn’t always better and updating for updating sake (just to stay up to date) is sometimes counter-productive or futile, especially if the updates break something that was basically at an almost perfect steady state.
Think about it this way, how often do you need to update your CRT?
Anyway, that’s merely my opinion.
For the changes to hue, you can read all about those on Dogway’s Grade thread.
My presets, were never designed with the new Grade in mind.
So in general it’s a big mess trying to keep these presets up to date in lock step with the latest Shader changes and many of the updates are not necessary in the context of the preset pack and many times end up making things look worse than before. Then it’s a fight to try to get things close to back to what they were before when all that’s really needed is to revert to a previous version of the Shader and everything looks great again.
Hmm, this is really weird, because the base preset files and shader files get updated at the same time, so should always match.
You may want to take your own packs and presets out of the shaders folder, then do the ‘update slang shaders’ action in the retroarch menu which will download a new set. I’m not sure if you will get a better result but it might be worth a try.
You could also get a new Mega Bezel package from my GitHub releases. If that doesn’t work, then it seems like something really strange is happening…
It’s more or less compatible with previous settings and definitely not only more “noob” friendly, but definitively and most important tweaker friendly.
Now you can tune the shadowmask with all the other mask settings without the need to adjust the shift amount. If the final mask size is even, you’ll get a “perfect” shadowmask, otherwise a compromise.
It’s impossible to get a perfect shadowmask with odd sized masks and you get basically same results with old and new approach.
I’m only stating that some concerns are to exaggerated, the only major change lately which affects presets is “positive” halation, but it doesn’t break presets. “Positive” and “negative” halation effects were very similar, so “negative” halation is to be used for the old looks. Other changes shouldn’t break presets if they are from prior two years or similar.
Edit: the other “major” change is that now 2-phase and 3-phase “bleeding” settings are separated, but this only benefits general ntsc presets.
Any additional help for the following :
BackgroundImage = "MyImage.jpg"
How can i do it? And where i add the jpg image?
The image can be anywhere on your device, you just have to include the correct path so that the shader can find it.
You can open some shader preset files and you’ll see examples of what to do.
If you look in my MBZ__3__Standard_Full_Reflections_CyberLab_Special_Edition folder, you’ll see some examples of this.
If you load a shader preset, and save a core, game, or content directory preset, you can open the saved file in a text editor.
The file can be found in the config folder of the currently active core. (e.g. E:\RetroArch\config\Beetle PSX HW\Beetle PSX HW.slangp)
If you put the image in that folder you don’t need to use a path. ( i.e. BackgroundImage = "MyImage.jpg" would suffice.)
Edit: If you just save a normal preset, it can be found in the root shaders folder. (e.g. Retroarch\shaders\MyPreset.slangp.)
As above, if you put your image in the root shaders folder, no path would be required.
A more tidy method would be to create an “Images” folder (or My_Backgrounds etc.) within the root shaders folder. (Retroarch\shaders\Images)
Placing your JPG there your path would be. BackgroundImage = "Images\MyImage.jpg"
Sorry if this has been asked before. Tried to search and read but I’m a little confused.
I want to use Retrolust lights out bezels with Mega Bezel Shaders. I have RetroArch handling the overlays. When using mega bezel the frame does not fit in the viewport of the bezel, so I have edited the bezels in photoshop to make the screen/frame fit nicely in the viewport of the bezel. But this method takes some time to do. Then I read about this auto placement, does this work when retroarch handles the overlays? Or must the shader has the bezel as an image? If I use the auto placement, how does it work? Will it scale the screen or just the frame/reflection around to make it fit, so the game maintain the correct aspect.
Instead of using the overlay system, you need to define the overlay as a layer in the shader preset.
If you go to the beginning of this post and download the examples package, there are examples of MrRetrolust overlays being used in a Mega Bezel preset.
Thank you, will have a look!
@HyperspaceMadness Hi! I’d like to request a new feature. I know your amazing shader has a function to automatically crop out black pixels, but the problem is that when the game changes scenes, it can cause some bugs. The black color appears in some transitions, which makes the autocrop try to cut it out, causing the screen to shift. I’d like to suggest a function where the shader detects and crops the game, but after this initial crop, it stops the automatic function. I know you can already do this manually, but what I’d like is an initial automatic crop (when the player chooses) and then lock this specific crop in manual mode. However, when switching to manual, it shouldn’t keep the percentage but only the black pixels that were cropped. I’m not sure if I managed to explain myself clearly.
I’ll try to give an example: Player enters Mario Tennis, the game is full of black bars, player goes into the settings, selects to cut the black bars, the shader detects the pixels that were cut, player activates a manual lock, only those pixels will stay cut from now on.
With all the jumping back and forth into the parameters dialog, I’m not sure it would be any more advantageous than manually setting the crop.
Maybe some kind of averaged crop algorithm combined with crop persistence to survive the scene changes.
I’m sure @HyperspaceMadness has some thoughts.
Edit, I just realized i totally misunderstood the request, or maybe not? I’ll leave the faulty reply just in case…
I tried to implement some sort of dynamic autocropping, no autocentering tho.
It uses some heuristic to detect scene changes and reset the cropping, so it cannot be perfect.
This is an example where it works well, it’s a video from an old implementation, but it is enough to give the idea.
It is available under border/autocrop-koko.slangp and can be prepended.
My idea is to have an initial autocrop at a moment chosen by the user (usually when the game is already in the main gameplay area) controlled by the user within the shader parameters, which will remove all the black pixel areas around with just one button, and another button to lock this crop. Of course, this might result in some other areas of the game having black lines, but most of the game will look normal. The idea is to avoid having to manage the percentages so precisely, especially since my OCD makes me never sure if I cropped it right.