Having fun in doing those, gamegear added using full new phosphorgrid features:
Handhelds/Gamegear-Overlay.slangp
…also, it seems that with the nightification mode enabled, it makes sense to highering the contrast on the zones lightened by leds, this is an upcoming feature, i’m still tuning, the light on the picture is by pure luck already coming from the center, so the effect is nice:
Your work is a marvel, please keep it up and thank you!
Hi Kokoko3k, first of all thank you for your work. I have small display problems with overlays, as you can see I produce artifacts in the image. I use Vulkan as a video driver.
Moreover, surely I’m wrong, I tried to zoom the image, but something goes wrong, it doesn’t stay central and the overlay doesn’t enlarge.
Thanks for your help
Eh, I know about artifacts, it happens on android if one uses jpg, i don’t need alpha, since I simply paint the game over them and I use jpgs that to keep size low (2MB vs 400kb)
Not sure how to deal with it, my intention would be to push those images alongside those presets to the main shader repo in the future, this is why I’m trying to keep them low in size, but by now, you can convert those jpgs back to pngs and everything should be fine.
@hunterk, @HyperspaceMadness : What is your opinion on the issue?
As for the image zoom, use background/foreground section image controls to move/zoom it
Using this option I only increase the zoom of the overlay and then I have to act on the image zoom. It’s absolutely not a problem, but it would be good in the future to include a cumulative zoom option for both levels, as happens with some handled borders I’ve tried in the past. Your result is beautiful, thanks for the support.
Having different zoom levels for overlays/background images and game content is needed to align them to the main content in the first place. Those overlays could be turned into bezels and the global zoom would have an effect on them, but to bezels requires alpha channel which jpgs do not support; so if i want to keep size low and using jpgs as a viable alternative, different zoom levels are needed.
If in the future those overlay will turn into png due to android, then i will use standard bezel format and global zoom will just work.
Making progress on ambient light blend modes…
In the beginning, led lights was dumbly added to the whole image and this produced an halo like effect.
It worked good for tight lights or not extreme night settings, but with the addition of the widen light, it turned out that for extreme nightification settings the result was not good at all:
So the first thing i did was to lower the night effect in the zones lightened by the virtual leds; this was an improvement, but not enough because the image still looked somehow dull:
so i tried to selectively highering the contrast in those zones, it made sense because shadows are more prominent when light is more incident, and indeed the result was better, but still not easy to control via parameters:
My final attempt to address the issue was to study various blend modes avaliable in Gimp and come out with something that works definitely better.
First, the led light is multiplied by the underlying image; that way the contrast of the image is automagically improved because the light will have less effect on dark colors, but zero effect on black, next provide an additional parameter named “foggy” in the ambient light section (kept by default to 1.0, because with 1.0 it acts like the old way to blend lights) that add the selected amount of ambient light to the dark colors (less on the brighter ones to avoid clipping ofc):
Here you can see what happens when the night effect is at maximum and the led power is very very high and wide:
Sun in the game, room looks warm:
Neon lights went off in the game, room feels cold and shrouded into darkness :
Think of the foggy effect like a way to turn the virtual led target from the spectator (halo, foggy=1) to the wall (foggy=0) or to emulate different materials that reflect more or less light back in the darker tones.
So this is a simple jpeg image that you sample for the background? Where does the alpha come from if it has alpha?
I’ve never run into this. Perhaps this is because I haven’t been running the Mega Bezel on android. It would require some testing to see what is going on.
It does not use any alpha, it just uses a jpg lut and draws something over it.
One of the things I was thinking of trying is to multiply the ambient by the background or a grayscale of the background, then add it back on top an unaffected version of the background which may or may not have some blending with the ambient multiplied image. This would help controller contrast and how dark the background can get.
Sounds like my code 
vec3 light_over_image(vec3 light, vec3 image, float black_illumination) {
//Simulates illumination.
//It works by adding the light on the image.
//It will add less light on dark colors
vec3 light_on_black = black_illumination * light;
return image.rgb + ( (light - light_on_black ) * image.rgb ) + light_on_black;
}
vec3 ambi_alpha_masked = ambi.rgb * (1 - image_alpha_adapted);
image.rgb = light_over_image(ambi_alpha_masked, image.rgb, AMBI_ADD_ON_BLACK) ;
Not tried the grayscale variant, i think it looks better by taking color channels into account.
Ah, way ahead of me 
Yeah I think you are probably right 
Have you guys thought about doing the ambient light stuff in yiq/yuv colorspace, where you can separate the luma from the chroma easily?
Actually I use HSV to make the background picture darker and operate on saturation easilly, but YUV never crossed my mind for illumination purposes, you mean touching just Y and see what comes?
I actually had the UV in mind for tweaking, since I think messing with Y would affect your contrast.
Ooohh, yes, it is a great idea, as it would certainly solve some issues i’m having with clipping indeed!
Added another parameter to move the virtual led strip position (Led internalness), that way you will be able to achieve scenic effects by moving the leds far away:
…or why not decorate your virtual display for Christmas!
…it needs more work because some leds seem to burnout, have to understand why.
Hello @kokoko3k, I did an update of my repo to the new ng presets, and they really shine in FinalBurn Neo. However, in MAME (current) the video is turned upside down and mirrored. See screenshot.
Please note: The MAME (current) core has been updated recently n terms of screen rotation, so the rotation is actually fine with your old presets, but not with the ng presets. So it is only a problem with the ng presets in the MAME (current) core.
Cheers!
That’s weird, I don’t think anything in the preset or code has been changed regarding rotation handling, nor i’m doing core specific workarounds, so I cannot explain why koko-aio behaviour could have been changed.
Maybe something on your side? I’ll take a deeper look btw.
What’s the preset in the screenshot?
@HyperspaceMadness: has rotation index passing from RA to the shader landed upstream?
edit - it seems not yet.
It’s apparently 1942 ;-). I tested with identical preset (1942.slangp in the config directories) in latest MAME (current). But let me please double check with another clean repo from GitHub, maybe I did something wrong.
EDIT - FORGET IT, I DID SOMETHING WRONG. I just downloaded your repo, and here the old shader and the ng shader behave the same. So I need to look into my repo for the error. Sorry for the confusion.
