Hi @Cyber , I’d like to adapt some of your preset packs for my handheld emulators. What would be your recommendation for Game Boy (greenish dot matrix), Game Boy Color, Nintendo DS, and Nintendo 3DS presets?
This is what I use and recommend for handheld systems:
It’s an interesting project and serves as a complement to CyberLab; however, my goal is to find a shader set that meets these criteria:
a) A set or package created by a single artist. b) A set or package that covers tabletop, handheld, and other systems. c) A border design focused on minimalism and maximizing screen frame.
Currently, the only artist I’ve seen that covers a wide range of systems is @Duimon , which I’ve been using for some time now. But I must admit that I’m more of a fan of CyberLab’s @Cyber aesthetic. My ideal scenario would be to bring CyberLab’s shader aesthetic to @Duimon handheld presets, or achieve a blend of both. Even better, I’d like to encourage @Cyber to update their set and ask them to expand the number of supported systems. In any case, I appreciate the work done by both artists, and I’ll be on the lookout if either of them decides to release an update this year.
HSM is the shader artist behind my presets. He is a shader framework master that has managed something on a different level from previous shaders.
That being said, he isn’t a traditional shader author, and borrowed existing shaders like Guest advanced and LCD-Grid.
If and when he dives back in we can hope that he updates the existing integrated shaders, and possibly borrows from new LCD ventures (Such as Koko’s brilliant shaders.)
While some of the advanced features of the Mega Bezel are missing, you might find some handheld luck in my koko-aio presets.
Thanks for the clarification, Duimon. I forgot to differentiate between shaders and presets when I wrote my previous response. Of course, I was referring to presets in my earlier reply. In any case, thanks for the great work; both Duimon MB and CyberLab are excellent. I’m already looking forward to seeing what crazy things you’ll create in the future.
@Guest.R, @kokoko3k, @hunterk, @Duimon, @soqueroeu
This is a little project I’ve been working on over the past several weeks. I’m feeling like it’s ready for you guys to take it for a spin. I still have to make some more presets for it but there’s no reason why folks like yourself can’t begin to have fun making presets of your own.
CyberLab Golden Bezel
Click the link below to download
CyberLab_Golden_Bezel_v1 - 01-09-2026
Installation instructions and usage tips can be found in the included readme.txt file.
For those who want to experience Legendary CRT Shader Software Technology!
This pack is built on a comprehensive, deeply-tuned CRT-Guest-Advanced-NTSC shader stack - mask and scanline simulation, deconvergence, phosphor persistence, NTSC signal simulation, adaptive strobing, and HDR output, all working together. In the right hands it produces some of the most accurate and best-looking CRT simulation available. Golden Bezel (see below) builds a reflective bezel and automatic background-fitting system on top of that same stack, rather than replacing any of it.
Installation:
To install these presets copy the “Shaders” folder into your “…\Retroarch” folder (or whatever your Retroarch Root Folder is called).
These presets REQUIRE CRT-Guest-Advanced-NTSC version 2026-07-12-release1 in order to look as intended.
(It’s already included so you don’t have to do anything else beyond copying the “Shaders” folder in the previous step in order to install it.
If you need to install it manually for whatever reason, it can be downloaded at the following location.
After downloading, extract the “crt-guest-advanced-2026-07-12-release1” folder to “…\Retroarch\shaders_slang”)
These presets were developed and tested using RetroArch v1.22.2. It is therefore strongly recommended to use that version of RetroArch or newer (stable or nightly) in order to take full advantage of the features of the new HDR Pipeline which was recently overhauled by MajorPainTheCactus.
While HDR is not required for these presets to work, they were developed and tested in an HDR environment using a relatively bright, modern display. A bright display is definitely essential to enjoying these presets as intended.
Usage:
Quick Menu–>Shaders–>Load–>.slangp
Quick Menu–>Shaders–>Shader Parameters–>Mask Layout
================================================================ CYBERLAB GOLDEN BEZEL
Golden Bezel is a reflective bezel/frame system that sits on top of this pack’s CRT simulation. It adds a procedurally generated bezel with real-time reflections of what’s on screen, a background/border image behind and around the game content, and an automatic system that fits your game content into that background correctly without you having to manually size and position anything.
New capabilities:
- A procedural reflective bezel with adjustable lighting (shine, ambient glow, reflection strength and distance) that reflects the actual game content and CRT effects in real time.
- Automatic content fitting: point it at a background image with a transparent cutout, and it detects that cutout and sizes/positions your game content to match automatically.
- 5 independently selectable background images per preset, switchable live via a shader parameter - no need to load a different preset to change your background/bezel artwork.
- 5 matching LAYER2 slots, one paired to each background - see below.
- The HDR pipeline is built directly into the bezel compositing pass itself, so HDR output applies to the whole final image (game content, bezel, and reflection together), not just the game screen.
Naming and storing your background images
Background images live in the “backgrounds” folder, next to “base_presets”. There’s also a “BG Vault” subfolder inside “backgrounds” - that’s just a holding area for reference/master copies; the shader only ever reads directly from “backgrounds” itself.
The 2 Golden Bezel presets (in base_presets) expect your background images named exactly:
BG_1.png BG_2.png BG_3.png BG_4.png BG_5.png
Copy or rename your own artwork to match. All 5 files need to actually exist for the preset to load - if you don’t have 5 different backgrounds yet, point the extra slots at a copy of one you do have (or the default background) rather than leaving any of them missing. A background slot pointing at a real file that just happens to be a duplicate is safe; a slot pointing at a file that doesn’t exist on disk may stop the whole preset from loading, not just that one slot.
Switch between them live with the “CBL: Background Image [1-5]” shader parameter, no preset reload needed.
LAYER2 - independent LED/lighting decals
LAYER2 is a second image layer on top of each background, meant for LEDs, power/status lights, control panel highlights, ambient lighting accents, or any decal you want to be able to control separately from the background artwork itself (brightness/dimming, or just keeping it as a separate layer so you can update one without touching the other).
Named the same way as the backgrounds, and paired 1-to-1 with them:
L2_1.png L2_2.png L2_3.png L2_4.png L2_5.png
L2_1.png goes with BG_1.png, L2_2.png with BG_2.png, and so on - switching “CBL: Background Image [1-5]” switches both together. If you don’t have decal art for a given slot, use a plain transparent PNG rather than leaving the file out - the same file-must-exist rule described above for backgrounds applies here too. A transparent PNG in that slot will correctly show nothing on top of the background.
Preparing a background image for automatic fitting
The auto-fit system works by reading your background PNG’s own alpha (transparency) channel. To use it:
- Your background image needs to be a PNG with a real alpha channel
- not a JPEG, and not a PNG that’s been flattened to solid color everywhere.
- In your image editor, select the area where the game screen should show through (the TV/monitor cutout in your bezel artwork) and clear/delete it to fully transparent. Keep this area a clean, simple shape - close to a rectangle is best. The shader detects the bounding box of the transparent region, not its exact outline, so an oddly-shaped or irregular cutout will still just produce a rectangular fit.
- Keep the edge between transparent and opaque reasonably clean. Very fine, intricate detail right at that boundary can be missed by the detection scan at its default settings.
- Save as PNG (this preserves the alpha channel - most other common formats don’t).
- In the shader parameters, set “CBL: Auto-Fit Mode” to the mode you want (Border/Content/Contain - see that parameter’s own description for the difference) so the shader actually uses what it detects.
Once that’s done, loading a different background with a different cutout size or position will refit automatically - no manual adjustment needed.
Bringing your own CRT tuning into Golden Bezel with .params files
If you already have a favorite plain CRT-Guest-Advanced preset (from this pack or your own) with mask, scanline, deconvergence, and color tuning dialed in exactly how you like it, you don’t have to redo that work by hand inside Golden Bezel. This pack uses RetroArch’s own #reference mechanism to combine your original preset’s tuning with Golden Bezel’s shader chain into one preset file that just works when loaded - no manual Quick Menu steps needed once it’s set up.
To convert one of your own presets:
-
Make a copy of your original preset and rename it, keeping the same name but adding “_BZL” to the end. This will become the combined preset you actually load.
-
Make a second copy of the original. Open it in a text editor and delete every line that defines the shader chain itself - all the shaderN=, aliasN=, wrap_modeN=, filter_linearN=, float_framebufferN=, srgb_framebufferN=, scale_type_xN=, scaleN=, mipmap_inputN= lines, and the "shaders = " count line at the top. Keep everything else - feedback_pass and every remaining parameter line (the actual mask/scanline/color/deconvergence values). Save this file with the same name as the original, but with a .params extension instead of .slangp, into the “Reflective_Bezel_Params” folder.
-
Open the “_BZL.slangp” file from step 1 and replace its entire contents with just two lines:
#reference “base_presets/.slangp” #reference “Reflective_Bezel_Params/<your preset’s name>.params”
The first #reference supplies the shader chain (Golden Bezel’s bezel, reflection, and auto-fit passes). The second supplies your original preset’s parameter tuning on top of it. Match the base preset to your system (NES_Chain, TurboDuoDC_Chain, etc.).
Load the resulting “_BZL.slangp” file like any other preset - RetroArch resolves both #reference lines automatically. The result: your original preset’s exact CRT look, with Golden Bezel’s reflective bezel and auto-fitting background wrapped around it, and nothing to retune by hand.
There’s a blank placeholder file in the “Reflective_Bezel_Params” folder named “Convert your existing shader presets to params files and place them here” - its filename is the reminder, the file itself is empty. Same idea for the placeholder files you’ll find in the “backgrounds” folder and its subfolders.
================================================================
Recommended:
Settings–>Video–>HDR
HDR - HDR10
Brightness - 340...540...600...630...720...880...1000 (or whatever looks best on your display. 340/540 looks great for Arcade Cores on my display depending on the preset or game)
Colour Boost - Expanded
Scanlines - On
Subpixel Layout - BGR (or whatever matches your display's subpixel layout)
Additional notes on setting the Brightness:
If colours look washed out or whites look very harsh, this is too high. If still too dark after fine tuning, your display might just not not be bright enough. Consider alternative presets for example CyberLab CRT Royale or 4K HDR Ready Presets in my Mega Bezel Preset Pack or PVM Edition presets in my Megatron Epic Preset Pack)
Settings–>Video–>Scaling
If you’re using a Golden Bezel preset (anything from base_presets, or a “_BZL” combined preset), use these settings instead of everything below - Golden Bezel and reflective bezel shaders in general need the entire display canvas to render into, since the bezel/background fills the whole output and the game content is scaled and positioned inside it by the shader itself, not by RetroArch’s own scaling:
Integer Scale - Off
Aspect Ratio - Full
Everything below this point (Common Settings through the per-core Custom Aspect Ratio settings) is for the plain, non-bezel presets.
Common Settings:
Integer Scale - On
Integer Scale Axis - Y + X (Or Y)
Integer Scale Scaling - Smart (Or Overscale or Underscale)
Aspect Ratio - Custom (Or Core Provided)
Bilinear Filtering - Off
Crop Overscan (Restart Required) - On
Why Integer Scale matters here: this pack’s CRT masks and scanlines are fine, intricate patterns. Scaling by a non-whole number stretches that pattern unevenly across output pixels, which shows up as moire, uneven gaps, or a mask that looks “swimmy” instead of crisp. Integer scaling keeps every source pixel mapping to the same whole number of output pixels, so the mask/scanline pattern stays uniform and sharp. This is worth prioritizing first, before other scaling/fit tweaks.
This same principle is why Golden Bezel has its own “CBL: Integer Scale Mode” shader parameter (Off/Y/X+Y) - since RA’s own Integer Scale is set to Off for Golden Bezel (see above), this in-shader parameter is what actually controls it there instead. Set it the same way you’d otherwise set RA’s own Integer Scale Axis.
Tip for Shadow Mask presets specifically: you may need to nudge Integer Scale one stop up or down on the Y axis for the mask to align properly - shadow masks are more position-sensitive than slot masks in this regard. Be aware this can sometimes make it harder to fit the image within a specific TV/bezel cutout size, since it changes the overall output height in whole-pixel steps rather than smoothly.
For PC-Engine cores:
Custom Aspect Ratio (Width) - (9x)
Custom Aspect Ratio (Height) - (8X)
or
Custom Aspect Ratio (Width) - (8x)
Custom Aspect Ratio (Height) - (7X)
For NES Cores:
Custom Aspect Ratio (Width) - (9x)
Custom Aspect Ratio (Height) - (8X)
or
Custom Aspect Ratio (Width) - (8x)
Custom Aspect Ratio (Height) - (7X)
For SNES Cores:
Custom Aspect Ratio (Width) - (10x)
Custom Aspect Ratio (Height) - (9X)
or
Custom Aspect Ratio (Width) - (9x)
Custom Aspect Ratio (Height) - (8X)
For Genesis Cores:
Custom Aspect Ratio (Width) - (9x)
Custom Aspect Ratio (Height) - (9X)
or
Custom Aspect Ratio (Width) - (8x)
Custom Aspect Ratio (Height) - (8X)
For PSX Cores:
Custom Aspect Ratio (Width) - (9x)
Custom Aspect Ratio (Height) - (9X)
or
Custom Aspect Ratio (Width) - (8x)
Custom Aspect Ratio (Height) - (8X)
For N64 Cores:
Custom Aspect Ratio (Width) - (4x)
Custom Aspect Ratio (Height) - (4X)
For Saturn Cores:
Custom Aspect Ratio (Width) - (8x)
Custom Aspect Ratio (Height) - (9X)
or
Custom Aspect Ratio (Width) - (7x)
Custom Aspect Ratio (Height) - (8X)
For Arcade Cores:
Custom Aspect Ratio (Width) - (8x)
Custom Aspect Ratio (Height) - (9X)
By the way Arcade Presets and Video Settings work equally well for Sharp X68000 Cores.
Of course you’re free to experiment with different Custom Aspect Ratios and scale factors as you see fit. On many displays smaller window sizes lead to higher brightness output. These Custom Aspect Ratio settings are aimed more at power users - if that’s not you, setting Integer Scale Axis to Y, Integer Scale Scaling to Smart and Aspect Ratio - Core Provided should be sufficient.
Smooth Advanced presets have access to Anti-Aliasing/Smoothing. This can be enabled or disabled by toggling the No Blend/AA Shader Parameter.
If you see HSR in the filename of a preset it means that the preset has Higher System Requirements relative to the other presets.
For vertical games rotate your display.
If you’re on 1080p, change the following Shader Parameters:
CRT Mask Size - 1
For Slot Mask Presets, you might also have to tweak the Slot Mask Height.
If you’re on 1440p, change the following Shader Parameters:
Shadow Mask Type - 10
CRT Mask Size - 1
For Slot Mask Presets, you might also have to tweak the Slot Mask Height.
Although it is highly recommended to set your GPU to output RGB 4:4:4 Full 8-bit or higher colour, 4K 120Hz 10-bit YCbCr422 is viable with Mask 6 Size 2 aka RRGGBB Mask.
For information on setting up your system for Adaptive-Strobe 120Hz+ presets, see the following post:
For information on low latency settings, see the following post:
Optional but recommended:
Quick Menu–>Shaders–>Save–>Save Core Preset
Optional:
Quick Menu–>Overrides–>Save Core Override
CyberLab Golden Bezel - Acknowledgements and Third-Party Licenses
CyberLab Golden Bezel - Acknowledgements and Third-Party Licenses
This project’s license is in License.txt, in this same folder. This document covers the third-party work this project is built on.
All third-party code referenced below remains governed entirely by its own respective license or terms, regardless of any modification made to it for use in this project. Nothing in this document or in License.txt alters, supersedes, or restricts those terms.
Inspiration - HyperSpaceMadness and the Mega Bezel Team
This project would not exist without HyperSpaceMadness’s HSM Mega Bezel Reflection Shader. My deepest gratitude and respect go to HyperSpaceMadness for that work, and to the rest of the Mega Bezel Team, of which I was a member in its heyday. Many of the concepts and features in this project will show unmistakable similarity to Mega Bezel’s, because Mega Bezel is where I was first exposed to them.
CRT-Guest-Advanced-NTSC (Guest.R)
Bundled at: shaders_slang/crt-guest-advanced-2026-07-12-release1/
Licensed GPLv2-or-later. Copyright notice, reproduced from the source:
CRT - Guest - Advanced - NTSC
Copyright (C) 2018-2026 guest(r)
Incorporates many good ideas and suggestions from Dr. Venom.
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
Full GPLv2 text: https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
Guest.R has approved this project’s use and modification of his work. Dr. Venom is credited by Guest.R in the notice above as a contributor of ideas and suggestions incorporated into the shader.
uBorder (Hyllian)
The bezel/reflection UV framework, the rounded-rect cutout math, and the overall Frame/Bezel/Border layer structure this project builds on originates from Hyllian’s uBorder project.
rotation.inc (uborder_bezel_reflections folder) credits its rotation helper functions to fishku.
Adaptive-Strobe / koko-aio-slang (kokoko3k)
Referenced by the base presets (adaptive_strobe-koko.slang) - ships as part of RetroArch’s own bundled shader library, not included in this package.
kokoko3k has approved this project’s use of his work, on the condition that modifications to his code are documented for users. Every modification is documented in THIRD_PARTY_MODIFICATIONS.txt, in the RetroArch folder this shaders/ folder sits in.
Phosphor Persistence (cgwg, Themaister, DOLLS)
The phosphor decay/persistence effect (phosphor-apply_CBL_Mod.slang, phosphor-update_CBL_Mod.slang) is copied from crt-geom-deluxe. Header, reproduced from the source:
Phosphor Persistence - code copied from crt-geom-deluxe
Copyright (C) 2010-2016 cgwg, Themaister and DOLLS
Licensed GPLv2-or-later. Full text: https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
Modular Image Adjustment / img_mod (hunterk)
Bundled at: shaders_slang/misc/shaders/img_mod_CyberLab-No_Grain.slang
Public domain. Header, verbatim:
Modular Image Adjustment
Author: hunterk
License: Public domain
This customized variant was created by hunterk himself, at CyberLab’s request - not a modification made by CyberLab to his file.
HDR10 / Sony Megatron Colour Video Monitor (MajorPainTheCactus)
The HDR10/scRGB output pipeline (PQ/ST.2084 encoding, Rec.2020 gamut mapping) used in this project originates from MajorPainTheCactus’s work on the Sony Megatron Colour Video Monitor shader.
Everything else the presets reference
The presets reference additional stock RetroArch/libretro shaders (xbr-lv2-standalone, NTSC decode passes, LUTs, and others) that ship with RetroArch itself and are not included in this package. These are part of the standard libretro slang-shaders library, governed by libretro’s own per-file license terms.
A note on completeness
This document reflects what’s been directly verified so far. It is not represented as a final or complete account of every third-party influence on this project.
Thank you
To everyone who made this project possible - named and unnamed, known and unknown, whether your contribution was direct or came through influence and inspiration passed down some other way - my sincere and utmost thanks and gratitude.
Special thanks also to Guest.R, Dogway, MajorPainTheCactus, Hyllian, kokoko3k, HunterK, cgwg, Themaister, DOLLS, fishku and all the other software developers, testers and contributers who made this all possible.
For the full list of third-party work this pack is built on, and what’s known about each one’s license terms, see shaders/ACKNOWLEDGEMENTS_AND_LICENSES.txt. Modifications made to any third-party code are documented in RetroArch/THIRD_PARTY_MODIFICATIONS.txt.
Enjoy!
Very nice! Doing that the dumb way would be an heavy operation, how do you achieve that? Maybe it scans the overlay in a low resolution pass and/or it caches its findings for later frames?
It crossed my mind several times, but I never did that to avoid overengineering, but it’s definitely cool.
I suggest you to setup a repo with documentation so it does not get buried in the thread.
Thanks @kokoko3k, both of your guesses are exactly right:
-
Low-resolution pass — confirmed. The detection pass doesn’t scan the background at full resolution; it samples a specific mip level chosen so the scan grid lands around a target size (default 48×48, user-adjustable 16–128), via
textureLod(), not the base texture. - Caching — also confirmed, and this one has a specific mechanism worth mentioning since it’s the more interesting half: it uses RetroArch’s per-pass feedback texture support (reading a pass’s own output from the previous frame) to only re-run the actual scan once every N frames (default 20) rather than every frame. Every frame in between just re-outputs the previous frame’s cached result. So it’s genuinely both of the things you guessed, working together — coarse resolution and infrequent recomputation, not one or the other.
This specifically had to be added partway through — the pass originally re-scanned every single frame with no caching at all, which was caught and fixed once it stood out as measurable, wasted GPU work rather than being part of the original design. So it wasn’t “not overengineering,” it was initially under-engineered and got fixed later.
Thanks for the suggestion. For now my current workflow is simple, fast and easier for me to manage and I don’t like the automatic sense of entitlement that some devs and members of the public seem to assume to have when it comes to anything they find on public repos. My core experiences are from the music industry and I’ve gotten burned by not dotting my i’s and crossing my t’s before.
I function most efficiently in my own little bubble.
I’ve even had the recent experience of getting banned soon after my first post on the LocalLLaMA subreddit due to simply being a beginner.
All I did was shared my current setup and was immediately accused of being a bot and a liar without any sense of understanding or willingess to hear me out, discuss things civilly or to teach and guide.
Rest assured that this latest project won’t be lost in this thread because it’s most likely going to be featured much more prominently. I just wanted to let it out before the complete redesign of the first post.
This whole caching idea came about because I had previously embarked on optimizing the performance of my existing shader stack without degrading image quality and kept that ethos throughout.
Depending on the implementation, scanning via an high lod could lead to imprecise alignments; the right way to do it that way would be to implement a binary search (/divide et impera); not sure if it already works that way tho.
Also, In Retroarch external textures are loaded with the presets,so the shader knows what they are since trhe beginning with no possible change in between frames; this voids the need to repeat the calculation every 20 frames.
Doing so could lead to periodic spikes if the whole operation is not light enough to be processed within a frame time; so my advice would be to make that computation at full resolution just in the very first frame.
As a final warning, i suggest you to learn what the LLM is telling you, because i smell trouble when users will ask you for more (and they’ll do) or deeper support.
That way at least you will be able to guide it better.
Okay, it works exactly as intended currently though. Is there a performance and / or quality benefit to the alternative method? Please elaborate on what scenarios you are picturing where this might of occur.
Have you tested it to see if there are any alignment issues or cause for concern?
It feels like you haven’t yet, fully tested the shader. The calculation needs to be repeated at intervals in case there is an event that triggers a cache miss, for example, the user switching to a different background and lighting/decal texture mid-game.
Also, due to the adjustability and optimization of the cutout box scanning area / this occasional performance hit can be very minor.
I don’t see what is the issue here. The new features and structure you see were not conceptualized or suggested by any LLM. They are my ideas (some novel, some influenced by prior art) to put them in this shader, I tested, found, fixed bugs and more. The primary function, I might have used an LLM or LLMs for was to help modify, organize and implement the code that reflected my vision and intentions, so I guess time will tell.
It isn’t any different from when I had ideas for new shaders or to improve or customize existing shaders to my liking and HunterK might have responded with some source code which I might have tried unsuccessfully to compile myself, then he might have responded with the brilliance you’re seeing at the top of all of my “Advanced” shader stacks. He even provided a rudimentary strobing beam shader, which I had conceptualized which works virtually identically in principle to the current CRT beam simulator.
At the time when testing that shader, there was no subframe processing and I only had a 60Hz screen so visually, I couldn’t really see any improvement. Now that the supporting technologies have caught up, we can see that the original concept was solid.
If only I could find that little piece of coding history.
I will close with this. It has been a remarkable journey to arrive at this juncture and it is truly a remarkable time we’re living in where so many more people can be empowered to bring their ideas to life. Rome wasn’t built in a day but I had to start somewhere, this was true with my CRT-Shader presets and it was also true with my music journey (I’m a music producer in another realm) and I don’t see it being any different with my Golden Bezel project.
One does not need to be a Master of All Trades in order to make an impactful and meaningful contribution to many different areas of life. So I hope that I would be able to rise to any occasion and challenge that my latest endeavour would lead me to encounter.
So thanks for looking out.
When you sample a low resolution mipmap, you have an average of colors of a bunch of pixels, so you cannot say exactly where exactly the overlay ends, so the method should be more complex; and when you find a possible “area”, you’ve to inspect what’s inside increasing the detail (lowering the lod).
I’ve not tested, because I’ve really no time left lately, sorry, just asking for curiosity; but if it works fine, then it has to do something similar to what i just described.
Indeed I did not (sorry! family), but that won’t change the fact that if there is an event that triggers the cache miss, then that event is definitely known to the shader (and it has to, due to the fact that external textures are loaded just once at the shader loading stage), which in turn should react just to that event, rather than blindly compute the same thing over time “just in case”, if there is no need to; in other word, that event should trigger the calculation too, just when needed.
The only events that would trigger this are events which change the positioning or composition of the background texture. Currently the shader is checking to see if there is coherency every N Frames, which is user adjustable for a performance / responsiveness tradeoff.
So if the user changes the Background image, that would certainly invalidate the data in the Cache requiring a refresh. Are you saying that there is an actual useable method of providing feedback to the shader when a user requests the texture to be changed mid game and post shader load?
That’s why there is a safe and recommended range if you push outside of that, what you described will occur.
It is fine that way but it is different from the previous answer.
I assumed that “scan” was the process of finding overlay boundaries, ofc.
All of that needs to be recalculated if the user changes the background mid-game.
What is different?
Also, my previous question wasn’t rhetorical. Is there a way that you might be aware of that the shader can understand and know when the user has changed the background other than periodically checking for the purpose of revalidating cached data?
Nope, checking every n frames if something changed and then do the heavy code is a great way to achieve the goal.
Blindly do that calculation every n frames despite something changed or not is dumb, that’s it.
Explained above; that is what i got from previous answers, different approaches.
But if the way it is done is the former, I repeat, it’s totally fine.
That makes sense. I’ll check and see if the current implementation does this and if necessary and possible integrate this optimization if you don’t mind, thank you.
This looks fantastic!
Question: I am running Mega Bezel 1.12, due to my presets being tuned for that version, and not later ones(can’t figure out how to port easily). If I apply your pack and all of the files (82 overwrites), will this break my 1.12 shaders? Does this require the latest version of MBZ?
Edit: Answered my own question.
So far, I overwrote, every 1.12 preset is working fine, so far.
edit: However, these presets from the pack, are not. They error out, installed as directed.
You really need to read all of the included documentation. Then read it twice before proceeding. This shader project has nothing to do with Mega Bezel or any of my old Mega Bezel presets or Preset Packs.
This is a Reflective Bezel Shader that was built to work with existing CRT-Guest-Advanced-NTSC CRT shader presets, primarily my CyberLab Guest Legendary Death To Pixels 4K HDR Preset Pack but not limited to those presets at all. Theoretically, you could take RetroCrisis’ or any other presets designed for CRT-Guest-Advanced-NTSC and just use this to “slap a reflective bezel” on top of them.
There’s a method to the madness of integrating existing presets which is described in the readme and in the post above with the download link.
Feel free to ask if you have further questions.
I was able to implement this via a parameter change detection pass. Was this what you had in mind or was your idea more of a “visual” check to see if there was a change in the pixels in a certain area of the screen before triggering a full bezel cutout and repositioning scan?
Yeah, this is ok.
Make sure the LLM model made that pass as low resolution as possible, possibly with an absolute scaling method to be not dependant on the input core resolution.
Btw, I’ll step back from this, as it apparently is already working fine and I really don’t feel comfortable interacting with LLMs, even in an indirect way, for personal reasons and opinions; I hope you understand.
