Interested in GBP?
When playing “GBA games that display the Game Boy Player logo” on GBP, the color palette automatically switches to the TV premise.
In the case of “GBA games that not display the Game Boy Player logo” or “GBC games”, when played with GBP, the low saturation will be lower and the brightness will be a little darker.
I would like to know the color correction in this case and the LUT that should be applied.
From what I found out from GBP, as well as a strip version of it in Pokemon Box Ruby and Sapphire, when seeing raw screencaps of it, the entire screen is dimmed down, from 255 white to 200. There are no gamma nor colorspace applied in GBP but the luminescence of the picture quality decreased by around 20%. It is the only difference when seeing GBA games on GBP, aside from GBP enhanced games such as SMB3 from Super Mario Advance 4 that has its gamma turn down, to give exact picture as from SNES All Stars version.
Thank you for the reply.
I am a little confused. I’ll clear my head.
GBC -> White only 255 to 200
GBA -> All colors reduced by 20%
GBP enhanced GBA -> Gamma correction is applied to be equivalent to SNES/SFC.
Do you agree with this? If so, I think GBP enhanced GBA is feasible with mGBA core. Is this correct?
My apologies for not replying for a week due to irl stuffs lol.
Well generally, the GBP dims down by 20% reduction in brightness, which leads to 255 white to 200 light grey. It is applied to any game for GBP regardless of which game is GBC, GBA, or GBP enhanced. Despite that, the games would still differ in appearance if its only enhancements are colors, in the case of SMB3 from SMA4. Also even certain games like Legend of Zelda do use regular colors matching from snes, on the game’s option. With Gameboy Interface, it is always using full brightness, and depending on the modes, if using GBP enhancements, then it will look best if color matches to snes
I don’t mind the delay in replying. I wish you success in your research.
OK. ”All Not Enhanced GBC/GBA have the same behavior." I understand that.
It seems that you are currently working on GBM (Gameboy Micro), but is there any possibility that you will also work on GBP?
I’m interested in how it will differ from the NSO color. I have lived with SGB and GBP. However, I am currently playing the actual NSO GB/GBC/GBA, and I feel that the colors are a little different.
I remember that GBP looked more natural than NSO. I don’t know if this memory is correct.
Emulating GBP is very simple. There is no gamma nor colorspace being emulated, and if there were any difference, it’s often the composite output that gives an inferior quality. I remember seeing a video gameplay recorded from GBP, the composite decoding on that one gameplay video, had clipped blacks being noticeable. When seeing the raw output, be it emulation in Dolphin from Pokemon Box Ruby and Sapphire, or raw HDMI Capture from the digital output, seeing the GBP post processing (200 white color instead of 255, and motion blur depending on the smooth settings) is pretty clear. I could use image adjust to decrease luminance to “0.79” on its setting to get the same picture as GBP.
I had finished up the GBM shader, for all targeted colorspaces and now ready to examine the GBC screen, had brought a portable light that has white temperature adjustments
@Pokefan531 Is there any reason why you set both lighten_screen and darken_screen to 0 on the lcd-grid-v2 presets?
EDIT: And is there a reason why gbc-color.slang has lighten_screen's default set to maximum (1.0)?
That default looks extremely bright and de-saturated compared to my GBC screen.
@Pokefan531 Why do you use display_gamma=2.0 in gba-color/sp101-color/nds-color/psp-color? If I understand correctly, display_gamma should always be 2.2 which is the gamma of user’s display.
Here is my interpretation of your algorithm. The color correction has essentially three steps:
Now given that the standard gamma for monitors is 2.2, I think the display_gamma should be 2.2 instead of 2.0.
Another issue: The code of palm-color.slang says it is for PSP lol. I think you just copy-pasted and forgot to change the variable names and comment.
For lcd presets, the v2 one has an option to adjust the gamma in shader so you don’t need another post processing effect to change the gamma. Otherwise, not only the subpixels would get darkened, but also the whole lcd effects as well, and can look darker than needed. It’s best to just go with the lcd shader’s gamma settings.
Yeah I’m considering to change the default setting for lighting screen value to 0.5, as GBC’s average gamma is a lot lighter, even not perfect gamma to the screen’s curves. The best use is to use sameboy’s correct curves on top of the gbc shader with lighting screen to 0.0
It was treated that way when I use linearize shaders within the libretro shader packs, from using two shaders from it, sandwiched with colorimetry shader to have any gamma correction. All it does is it gives out a gamma 2.0 effect when I used those shaders, in which they call linear correction? I wasn’t sure completely myself, but somehow when I get colors from my colorimeter and spectrometer, it gives a bit less saturated on those old LCDs for some reason, and having the linearization method from those shaders gives the better results to the actual screen’s colors. Btw I did buy camera portable flash lighting for those screens and gives out more range of colorspace on GBC/GBA than what a phone flashlight can do. It does show more of the proper color range by the portable light, much the same way as the light bulb and the sun. It does still fall short of less saturation than NDS so there is a difference.
Btw, somehow it happens on those old LCDs when I sample colors from it, but it does give a proper gamma 2.2 when sampling modern displays, like my phones, TVs and monitors. In fact I did sample gbc/gba off from my monitor when doing my insane method of sampling colors from the non-backlit screens, and noticed having gamma 2.0 for gbc/gba looks a little too inaccurate, so I’ll be reverting this on my next update.
It’s just the NDS, GBA-SP 101, PSP, and Micro that looks a bit less saturated when viewed from programs like ColorHCFR and Displaycal, so I wasn’t sure if it was the setting that I use on two color units, and I did try to load many kinds of color correction file for colorimeter and get same results on how far it can reach the color matrix. And when I did look at the colorspace inside colorimeter shader with two linearize shaders, they seem to make the primary colors look identical to the console’s screens, which was why I had it at 2.0 than 2.2. I would like to know how I can get them to look the same except in gamma 2.2 process. You can suggest if I can resample all colors from my monitor, but even my capable calibrated DCI-P3 monitor can’t show the blue color from any of those LCDs so I couldn’t be able to sample them than what I could from the LCDs.
As for Palm color shader, yeah I didn’t change the name, but also I maintain it pretty less as I only found one data from it, but haven’t kept it up to date as other ones here.
I see, I understand now.
But then, shouldn’t the LCD presets have a default gamma that approximates to the GBC and GBA screens? As it stands now, both GBC and GBA LCD presets look practically the same, which I believe is not accurate.
Thank you for the feedback. I’ll go ahead and suggest that change to 0.5 on the libretro repo. As as things stand now, the bare gbc-color.slang shader is looking almost broken.
Looking forward to your updated shader! 
EDIT: This post is WRONG. Please ignore it and see my next post.
I tend to disagree with this. And also from using the color correction after the LCD effect.
I’ve read why you did it this way on one of your previous posts, but I didn’t fully understand the reasoning.
From my experimentation, using the LCD shader gamma controls affects it’s subpixels, which should not be the case if our purpose is just doing color correction.
For example, a full white screen should look exactly the same regardless of gamma value, as gamma does not affect full white. But look at the following test:
Gamma 2.8:
Gamma 1.8:
These 2 pictures should look the exact same, as gamma doesn’t affect white, but they look very different here.
This also happens if we control the gamma with the lighten_screen and darken_screen parameters. The subpixels are being affected, even on full white.
I don’t feel like this is the intended behavior of color and gamma correction. Shouldn’t we be first correcting the color, and then applying the LCD shader on top?
Please disregard my previous post. I was wrong.
It seems the test I was doing was not on full-white pixels. My bad.
I have properly tested on full-white and the picture is not affected when correcting the gamma on the LCD pass, as is expected.
Furthermore, I think I now understand the reasoning for correcting the subpixels, instead of correcting only the original picture.
But, by default, the gamma is still not corrected on the lcd-grid-v2 presets. So I have proposed (on the libretro slang repository) an LCD Gamma value of 1.6 and 2.6 for the GBC and GBA lcd-grid-v2 presets, respectively.
I tried to get a picture as close as possible to the non-LCD color correction shaders with the lighten_screen and darken_screen values set at 0.5 for both. But if you want to suggest more accurate values from your measurements, please shout out, @Pokefan531
Here rise again on another major update to this project! A major update to the shader pack!
https://mega.nz/file/DAwyEZgQ#_er6RRa4m1d5d399upq52xrkAkcMKy9HGr6SNYf_0wI
Also here’s my big page of the project on Tumblr:
https://pokefan531.tumblr.com/post/766008194709454848/handheld-lcd-shader-projects
Changes:
-Gameboy Micro, DS Lite, and GBA SP (AGS-101) shader added.
-Used a bright portable light that makes out the saturation of GBC and GBA, being on par with Nintendo DS and Micro saturation levels. Previously used my phone’s light which isn’t ideal way to get colors without glass rainbowing on screen in the way.
-Added LUTs on shader presets to emulate the greyscales ramps on GBC, GBA, and PSP, plus colder greyscales for all displays that these old LCD screens have, for preservations. PSP uses pure power Gamma 2.2, GBA nearly uses power pure instead of sRGB curve, and GBC has its own bright curve.
-Removed white balance option since most would want full white balance. Was an option to tune in to my handheld’s whitepoint, but can vary between same units while using same colorspace.
-Fixed gamma correction on the shaders, all fixed 2.2 (was 2.0 due to not knowing how ColorHCFR displayed colors correctly, but now knowing how).
-Reshade LUTs uses MultiLUT to change between normal and cold greyscales between two LUT Textures.
-Added External Gamma option on GBA and GBC own shader to tune incase if you don’t have a specific LUT shader preloaded from the preset. Both default at 0 since the gamma for GBA are set by default, and GBC’s special gamma curve is in place from LUT.
Tools, comparisons, development info, and explanation are included on the tumblr link.
@nfp0 Well now, you can set it to default 2.2 because I have the LCD-cgwg presets configured differently to where GBA and GBC LUT shader have their own gamma before loading the LCD shader.
Edit: More update info
@Pokefan531 Fantastic news!! 
I’ll give that page a good read and test the new shaders as soon as I can.
It’s also good news that you have the gamma on the LUT now, so no need to change it on the parameters.
Looking forward to seeing this into the libretro repo!
Oh yes! Although I do have one issue with mGBA Core, that the white color isn’t completely white, like it’s 255,251,255, green being slightly lower, so a change in gamma would affect the white color unless a shader before the LUT (and after motion-blur shader) uppers the green color by 1.016 from something like image-adjustments to have the screen be consistent. Yeah a bug like this isn’t in the standalone mGBA. But yeah, no need to add in extra shader to fix only one emulator white balance. Hopefully one of its maintainers are able to solve it.
But yeah beside that, the shader should work like normal with LCD shaders.
Fun fact, the sameboy lcd shader seems to be more sharper than cgwg, and relying on seeing just the RGB subpixels by having low color at 0 and high color at 1. Can look similar like lcd-shader preset or the newly authentic-gbc shader, but does blend each subpixel a bit which gives a bit more brightness, and friendly for targeted colorspace that had to clip the blue primaries that balances the white color more by decreasing a bit of red to maintain its balance. Although I also would like to ask if BGR subpixels are possible on sameboy or authentic-gbc for something like GBA since it uses BGR aside from Micro. It simply is a 180 degree rotated RGB, even its small tail on each subpixel on a GBA when comparing with GBC.
Yep I’ve been testing different kinds of lcd shaders on the project. CGWG shader is pretty good which does have options for BGR and works constantly with any size starting from 3, but I see more sharpness on Sameboy and authentic-gbc. I also set LCD-shader preset to only use RGB instead of CYM colors for each subpixels to match the real lcd subpixels and looks how authentic-gbc looks. But yeah, they work best when the image is multiples of 3 to give balance each subpixel display, and I like sameboy’s blended subpixels that nearly matches on how it looks when only having the low color at 0. Although I do see errors when having these shader go exactly 3x as I see really bad moire pattern, but not anything higher somehow.
Also, yep I even give Micro lut shader a gamma control in handhelds due to GBA games needing gamma control to look less bright from raw RGB.
And last, a page for GBA database and measurements would come later this month, showing ColorHCFR data and its greyscale, plus my discovery on why GBA gamma looks dark
Hi, i’m the developer of open_agb_firm and i would like to ask for a bit of clarification on the usage of your shaders/LUTs. My goal is to have the most accurate colors and until now i have only been using the shader with the colorspace conversion. Do i understand correctly that for the best results i need a combination of that shader and a LUT? This is what i had implemented so far and an extended version with saturation, contrast and brightness is in the works:
As for 3DS LCDs i can tell you it’s a very deep rabbit hole. There are a bunch of different LCDs used by Nintendo and whenever they are calibrated or well calibrated is a literal lottery. We call it LCD lottery for a reason. Some LCDs look very warm and others very cold. And IPS has issues with the gamma curve near black. It’s an absolute mess. What we found out so far is that Nintendo intended LCDs to have a deviation from standard 2.2 gamma like this (top curves). Sorry can’t post more than 2 links with a new account: ht_tps://github.com/profi200/open_agb_firm/discussions/192#discussioncomment-10171955
Example of the difference: ht_tps://github.com/profi200/open_agb_firm/releases/tag/beta_2024-07-30
I tried to compensate for this by applying the curves at the bottom and that already helps a lot but nothing is perfect with Nintendos LCD lottery. Anyway, if you want to discuss technical details of the 3DS hardware i would recommend you to join the GodMode9 Discord or IRC (your choice, they are bridged).
Thanks for adding more info on the 3DS gamma curves and its graph. Yep I’m very aware of 3DS having different type of LCDs as well as rare IPS lottery, to which I don’t plan to review on due to rarity. But since it’s in Pure Power Gamma 2.2 rather than sRGB curve, you don’t really need the LUT shader that comes bundled from the handheld shader that corrects to near pure power gamma that was made for sRGB curve. And also, I assume the 3DS greyscale with those TN LCDs are often cold, which not even GBA’s cold LUT texture is needed either. So I’d say go with just the shader alone, to which your code of it looks pretty good to match our slang shaders of it. I do suggest adding in more options like GBA, GBA-Micro, NDS, or even VBA, since they have different colorspace on the RGB primaries appearance, along with the gamma for user’s choice.
Btw, what does the 3DS color gamut look like in your community posts?
It depends. I have a New 3DS XL with top IPS panel and bottom TN. The IPS panel is quite neutral in color temperature but the bottom LCD is quite warm. Yep, they literally mix and match everything they could get ahold off. They don’t give a sh*t if the LCDs look totally different. The situation improved a lot with the Switch. https://www.neogaf.com/threads/detailed-review-of-switch-screen-quality-and-compared-to-3ds-by-erica-griffin.1369087/
Good to know that i only need the regular shader. I will update it with the latest values later. That reminds me i always assumed the alpha channel doesn’t matter in your shaders but it looked like it’s also affected in the matrix multiplication by the luminance value. Do you override alpha somewhere to fix that? And another thing i noticed is that reds look very dull with your GBA color shader in comparison to my GBA SP (AGS-001). It has noticeably stronger reds. Is that a result of clamping on the color space?
As for color gamut i don’t have the means of measuring that right now but the LCDs are off in various ways. IPS for example sucks badly at displaying purple. And TN often looks way too washed out (mostly because of the weird gamma curves but it’s not the only factor).
Thanks for your help.
This looks like the new 3DS with IPS colorspace looks much similar to my results to GBA-SP AGS-101 and the DS-Lite, which I’m guessing that colorspace has been very similar across from DS-Lite to New 3DS, until the switch got a major difference. It’s no wonder their purple/magenta matrix has less saturation than actual sRGB colorspace. As for TN panels, yep a lot of them have wild greyscale color temperature that are more inconsistent than an IPS panel.
As for the alpha value, yeah I lowered it because since the blue color is out of gamut, I have to subtract the red color on blue matrix, and to have the white color be completely balanced, I also have to increase the red color value on either the red or green, to see where it fits. The only matrix that clips out if alpha/luminance isn’t lower, is the yellow matrix, since it takes only the red and green colors, and both would have a clipping red color, which would change the hue on the yellow. Because of that, I have to lower the alpha a little bit to show proper yellow color. Well, we do get a slightly darker image overall due to it, but still far brighter than what 3DS GBA default brightness looks.
Also, I do get comments about the red color a lot, due to the red color having a colder tint, making almost pinkish. Although my recent update from two weeks ago tried my best to have the red color be truly accurate, but that’s the exact color you see from the original GBA I used with complete flashed to 6500k and matched my monitor on the white. I thought the colorspace from the first SP models are the same as the GBA, until I thought now, maybe the colorspace changed during GBA’s life when they switched from 40 pin Sharp LCD to 32 pin Panasonic LCD? That’s when I decide to investigate of this was true given a lot of posts I’ve seen relating to GBA’s red matrix when using my color shader. I assume all GBA-SP AGS-001 models use panasonic since they have 32 pins. If you use the screen’s frontlight, or flash with a lightbulb (not flashlight since it causes rainbowing and less saturation), does the red color look like the NDS shader, or Gameboy Micro? If so, maybe it’s the reason some had noted about the pinkish red matrix.
Yeah the GBA I used for the shader is a Sharp 40 pin LCD, as the numbers on the back is 02. Sharp did the entire GBC revisions on the LCD, which explains why both GBC and GBA that I have, very same colorspace. Although I hear 32pin GBAs have darker gamma, but I have yet to see deep details on it. I also tried to see which manufacturer made the LCDs for NDS if it was panasonic or not, if the red color is the same as your GBA SP.