Last tweak from me:
CONTRAST = “0.050000” TEMPERATURE = “7000.000000” GAMMA_OUT = “0.530000” SATURATION = “1.050000” DO_SHIFT_RGB = “1.000000” OFFSET_STRENGTH = “0.200000” IN_GLOW_H = “5.999996” TATE = “1.000000” PIXELGRID_INTR_FLICK_POWR = “0.150000” HALO_POWER = “0.680000” BEZEL_CON = “5.000020” BEZEL_REFL_STRENGTH = “0.200000” DO_BG_IMAGE = “1.000000” DO_VIGNETTE = “1.000000”
Hi guys, what I’m seeing is amazing, thanks for the work you do, it’s not obvious.
Just added a new parameter in phosphor emulation section, named:
“Sparkling look punch”, it works by exagerating the look of the level 2 vertical mask and compensate that by a gain on the source color, the result is a pinchy image:
pgrid-slotmask-for-1080p-HiNITs-experimental.slangp
This looks good at 1080p, i’ve tuned it after the one I made for oleds, but can run fairly well at 1080p. This carries some slight brightness pushes here and there so that it can be used on displays with a decent black level.
The horizontal mask is doubled in width and follows game pixel size. To keep slotmask offset even/odd not to wide, i used a green/magenta mask, so just 2 phosphors which is capable of displaying RGB, maybe with an halved precision on red and blue channel, but it does not seem an issue.
With a bit of help of IA scaling, I made a new gba overlay, nothing fancy, quite light in size since it’s a jpg meant to go under the main content:
However, while playing with it trying to get a convincing nightify effect with added ambient light, the result was this:
…quite bad, because the nightify function operates on saturation too, and pushing ambient light back over it did not restore the lost colors; it wasn’t noticed in the old presets because basically iy operated on gray bezels and background images only; so i made a change to the nigtify function to take into account ambient lights and modulate its strenght according to it, this is an extreme case where nightify is at its maximum strength, still not perfect, but better:
The following are a more realistic use from GameboyAdvance-Overlay-Night.slangp
While this is without the night effect: GameboyAdvance-Overlay.slangp
Looks great, day mode no problem, night mode gives me error.
Ok, will take a look in a few hours, probably reference path error.
Meanwhile, just push nightify parameter and led power, it is all just that. from day preset.
edit
wops, found it, will fix later, the reference ends in .zlangp in the preset, you can change it to .slangp with a text editor.
edit
should be fixed, done blindly from the phone since i couldn’t test it anyway.
Just added a new parameter in the ambient light section, it is named “widen lights”.
Its purpose is to let the ambient light to cover a bigger part of the screen.
The previous “Light Falloff” parameter did the same thing, but it operates on the single leds, leading to a loss of coloration, because if every led has a wider area, they blends more tending to dull white.
This parameter, instead, is much more dumber, since it stretch the whole visible texture, so that the the look remains the same, just bigger.
Useful in vertical games:
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.