More gameboy shader presets and modifications

[mattakins]

Here are images of the changes and presets. Please zoom in on screenshots to see the pixel scale properly.

1. Blending Mode default to 0

This variable determines how pixels are blended and affects the appearance of the pixel grid. The original Cg gameboy shader defaulted to Blending Mode 0. While a matter of preference, I find Blending Mode 0 looks better across a wider range of resolutions (especially handheld, lower resolution devices) in both color and grayscale mode. It doesn't wash out the image like Blending Mode 1. Check out the visual difference.

Blending Mode 0

Blending Mode 1

Notice that Blending Mode 0 creates a darker image

2. gameboy-color-white-bg preset

This is an alternative to my previous gameboy-color preset. It features a white background as opposed to the traditional sepia tone used to mimic the original Game Boy panels. This results in truer, brighter colors but a bit harder on the eyes and less nostalgic. Here are both for comparison.

gameboy-color-white-bg.slangp

gameboy-color.slangp

3. gameboy-pocket-high-contrast

Color palette taken from Tatsuya79's Handheld Border Shader project. A great color scheme for Game Boy games that falls in-between gameboy-pocket and gameboy-light-mode. Here are all 3 for comparison.

gameboy-pocket.slangp

gameboy-pocket-high-contrast.slangp (new preset)

gameboy-light-mode.slangp

4. gameboy-advance

Created a preset for the gameboy shader optimized for Game Boy Advance games. This preset creates a cool LCD effect where pixels really pop.

gameboy-advance.slangp

[nfp0]

I find Blending Mode 0 looks better across a wider range of resolutions (especially handheld, lower resolution devices) in both color and grayscale mode. It doesn't wash out the image like Blending Mode 1.

To give some more insight into why both modes exists, the GameBoy (I measured on a GB Pocket but I think the original DMG is very similar) actual pixel to white-space ratio is about 7:1, give or take.

This means up to x7 resolutions, it makes sense to fill the white space with a bit of the adjacent pixel's "color" to get a more accurate look of a real GameBoy screen. For this, we use Blend Mode 0.
The higher the resolution, the less blending is necessary to compensate.
(I'm wondering if I should make this adjustment automatic so that it's automatically compensated when you change resolutions. Otherwise, changing the zoom level will also change the picture.)

But from x8 and above, you're already above the 7 GB pixel to 1 white-space ratio, so the space should not be filled any more. In this case, to get rid of the harshness of the transition, it's best to blend them with Blend Mode 1.
If we instead used Blend Mode 0 on resolutions of x8 or more it would make the pixels look bloated and unrealistic compared to the GB screen. That's why Mode 0 darkens the image.

Also, keep in mind I'm working on seeing if it's feasible to make both blend modes independent parameters so that we can mix and match any amount we want. This might mess with your presets, so maybe it's best to wait a bit before merging this.
Sorry it's taking so long on my side. But I think I can take care of it in the next few days.

[hizzlekizzle]

just give me a ping when it's ready to merge.

[mattakins]

@nfp0 Thanks for the update! I know on the previous PR we had some discussion around the square pipeline (used for the console-border shaders) vs original pipeline (used for presets n the handheld directory). Is your intent to still go to one unified shader pipeline? I don't think this is a good idea as it compromises the look of Game Boy Color games.

I've done a lot of testing of the square pipeline vs the original pipeline, mixing and matching the passes. A few things stand out, namely the gridline and background appearance. All the following screenshots use the following parameters to match the original pipeline:

blending_mode = "0.0"
baseline_alpha = "0.10"
grey_balance = "3.0"
adjacent_texel_alpha_blending = "0.18"
contrast = "0.95"
screen_light = "1.0"
pixel_opacity = "1.0"
shadow_opacity = "0.55"
shadow_offset_x = "1.0"
shadow_offset_y = "1.0"
bg_smoothing = "0.75"

Square pipeline with color

Colors are bit harsh. This remains true even when backing off the contrast. I realized the way the pipeline handles the background is different than the original and impacts the colors, so I decided to pipe in the original gb-pass4 to see what the effect would be.

Square pipeline with color and original pipeline gb-pass4 for background handling

We are closer here, but the original still looks a lot better.

Original pipeline with color

The gridlines are softer and the drop shadow depth effect is more pronounced. I also think the softer pixels give it a more appealing, accurate look.

Square pipeline with original pipeline gb-pass4 background zoom

Original pipeline zoom

Shifting it all over to the new pipeline would compromise a lot of the charm the original gameboy shader has going for it.

[nfp0]

Thanks for the update!

No prob! 🙂

Is your intent to still go to one unified shader pipeline? I don't think this is a good idea as it compromises the look of Game Boy Color games.

I'm not a repository maintainer, so I don't really have a final saying, but my opinion is that it is important we separate what are supposed to be the shaders that replicate the real life console screens from others that are cosmetic variations of it.

Nothing wrong with having variations, and I like the look of your presets, but I think we should keep the originals as simple as possible.
Since you're going a path a bit different than the objective of the originals, I think there's nothing wrong in you maintaining separate shaders files dedicated for this look you're going for. That way you can go wild with the modifications without the fear of breaking the originals. And we can unify the originals if we decide to do so.

Speaking of keeping things separate, I think we should rename the gameboy-color.slangp and gameboy-advance.slangp presets you created to something else. For a new user, these filenames give the feeling these are the "vanilla" shaders trying to replicate the real LCD GB Color and GB Advance screens, which is not the case.
Since they are based on the Dot Matrix screen, why not call it something like DMG-Color and DMG-Advance or DotMatrix-Color. They are more descriptive this way, and will not be confused with the ones replicating the real screens.

On another note, I've always thought the current approach of per-pixel rendering is flawed. But at the time, I lacked the knowledge of how the shader pipeline works on RetroArch to do any further testing.

The current method has a few drawbacks:

• Changing the resolution (e.g. changing the zoom level) changes the amount of blending and the amount of necessary Grey Balance and Contrast. This means we can't have a default preset that looks good for all resolutions.
• It is not suitable for very high resolutions (4K, 8K, etc), because the white-space between pixels becomes too small.

Better than the separation of the Neighbor Blending mode parameters, I think we would benefit from rendering at 8x resolution (7 pixels for the dot and 1 for whitespace, akin to the real screen's 7:1 ratio) and then downscale to the desired size (essentially supersampling). This would perhaps be more expensive but it would defeat those drawbacks and even give you something better looking and more consistent for your colorizations. In case it gives a different look, we can keep the originals for this purpose.

Maybe this was done like this at the time as a processing power saving measure. But I'll try and test it.

PS: There's something wrong on your last screenshot. There are dots darker than the pixels where the white-space columns cross with the lines. Maybe the blending parameter is set too high.

[mattakins]

Naming of presets

I follow your logic on the naming conventions, but I want to push back a bit because I think renaming these new presets is trying to solve a problem that doesn't actually exist for the end user.

A new user is probably looking for a shader that will look good with whatever game they are playing at the time. So if they are playing a Game Boy Color game and see the gameboy-color preset, they will load it up and likely be happy with the result since it looks good. I don't think the user will mind that it is not a faithful recreation of the original display. If they are that type of user, they will be happy to dive into the other existing presets.

I named mine gameboy-color and gameboy-advance because they are variants of the gameboy shader and intuitive names. Convoluting the name may negatively impact the user experience due to discoverability. I don't think there is a current de facto shader for replicating the GBC or GBA display, so this means there is nothing to confuse the new presets with. The closet I found is the lcd-grid-v2 presets.

Shader pipeline duplication

The only part of the gameboy shader pipeline that I modified is gb-pass0 by adding the color toggle and logic which is just a few lines of code. The rest of the pipeline remains unchanged and likely will remain unchanged (except maybe changing the default x y screen offset values to -1 as per #96).

I think the only scenario that would make sense to create separate shader files for the color presets is if you were to replace the original pipeline with the square pipeline. Otherwise it would just be more duplication.

Scaling issues

I am interested to see how this downscaling approach works! I agree that these shaders fall apart at higher resolutions and right now I just use them on handheld devices. Great point about how presets really don't apply across a range of resolutions.

Also here's another issue that seems related to scaling issues. The original pipeline has issues with garbage around the output image when using it in windowed mode on desktop (metal on Mac). It looks like you greatly reduced the garbage with the new square pipeline to just some edge flickering. There's an issue for this (#70) but it seems there was never a clear resolution. I would love to help bring the garbage fixes into the original pipeline.

[nfp0]

Naming of presets

A new user is probably looking for a shader that will look good with whatever game they are playing at the time. So if they are playing a Game Boy Color game and see the gameboy-color preset, they will load it up and likely be happy with the result since it looks good. I don't think the user will mind that it is not a faithful recreation of the original display.

I don't really agree with this. I think the user will, at first, try to find the shader that best replicates his memories of playing on the real console, with correct colors and all. And then yes, he would try variations if he was not happy with the original screen.
At least that was my observation of people first delving into RetroArch shaders, myself included.

The closet I found is the lcd-grid-v2 presets.

Yes, the lcd-grid-v2 presets with GBC and GBA color correction (with colorimeter readings) are indeed the state-of-the-art shaders for simulating those consoles. And the ones for the original GB and GB Pocket are called gameboy.slangp and gameboy-pocket.slangp

So now we would have a sequence of shaders named like this:

gameboy			-> accurate to console
gameboy-pocket		-> accurate to console
gameboy-color		-> completely different

It feels inconsistent. It gives the feeling that the gameboy-color one is the accurate-to-console one for the GameBoy Color, like the other 2. Also, the name transmits no information on what this shader's specialty is.
Why not call it something like gameboy-colorized and gameboy-colorized-advance?

Now that I checked the content of the gameboy-color preset you added, it seems to be an exact copy of the gameboy-pocket one, but with a single parameter toggled. Do we really need a preset for this?
I say this because we've been trying to slim down the handheld folders, as they were quite messy before. I'm not necessarily opposed to having it though. It's just the preset name I'm not too fond of.

@hizzlekizzle What's your take on this?

Shader pipeline duplication

Sure, agree!

We can see how to proceed further down the line if the supersampled version I'm testing turns out as an improvement or not. As things stand now, I see no problem with having things as they are.

Scaling issues

Interesting 🤔
I thought these were solved some time ago on the Nvidia drivers. I did not know it had problems on metal, but I don't have a Mac to test. I only had that problem on old Nvidia cards on Windows. And on Linux I never saw the problem either.

[hizzlekizzle]

Yeah, it's a tough call. We don't really have any hard-and-fast policies about naming things, but if it's really just the gameboy shader (which it is), I think "colorized" or "colorhack" gives users more information about what's going on.

[mattakins]

Thanks for your input @nfp0 and @hizzlekizzle! I can see the point here. How do we all feel about naming the presets in question as follows?

• gameboy-color-dot-matrix
• gameboy-color-dot-matrix-white-bg
• gameboy-advance-dot-matrix

These names are more descriptive and I think they meet everyone's goals.

[mattakins]

Just updated the names accordingly. I think we're ready to merge since we determined the original shader pipeline will remain unchanged for now.

[nfp0]

@mattakins Yes, those names sound good to me! Thank you for your comprehension 🙂

On an unrelated note, I've noticed you're using the gbp-palette.png for your gameboy-color-dot-matrix.slangp. Is this your intention? To tint the colors with the Pocket screen palette?

[mattakins]

@mattakins Yes, those names sound good to me! Thank you for your comprehension 🙂

Excellent, and you're welcome! :)

On an unrelated note, I've noticed you're using the gbp-palette.png for your gameboy-color-dot-matrix.slangp. Is this your intention? To tint the colors with the Pocket screen palette?

Yes, this was a deliberate choice. The gbp-palette creates a nice warm background. In this PR, I have also added an alternative white background version (using the 'b-w-palette.png') which offers truer colors but a harsher image. You can see the first post in this thread for a comparison.

[mattakins]

@hizzlekizzle Good to merge whenever you're ready. Thanks!