Real GBA and DS-Phat colors

The github one is correct as the most recent update. So to answer your questions.

  1. If you want to manually set it up, load shader 0 with gamma control for desired handheld (gbc, gba, or others) and set to nearest 1x. shader 1 would be the LCD shader, correct. Must match to whichever integer scaling retroarch sets to, along with using nearest filter. After that, shader 2 will use the color correction shader at nearest 1x. So yeah, that order is correct.

  2. Accurate ones would be ones that uses subpixels. LCD-Grid-V2 would fit the usage, as long as you leave the lcd gamma at 2.2 as the gamma correction shader does its job. The V2 supports BGR subpixels that GBA uses. Although on Android with Vulkan, the subpixels are misaligned only on LCD-Grid-V2 for whatever reason, but not sure about on ios. May behave better under metal. More accurate ones would be either Authentic-GBC shader due to its more accurate subpixel rendering (minus the lack of BGR layout), or load the first two shaders from LCD-Shaders. For best results, Authentic-GBC (fast or single pass) works best when image is scaled by 3x due to three subpixels clearly emulating the look from GBC that looks the best at 3x, 6x, 9x, and so on. For sharp results, I leave bloating at 0 and brightness at 0.08 as there is no blend between subpixels that way. As for the LCD-Shader method, I used it in my way, but yeah it requires integer scaling by 3x as there is no scaling on its shaders. Just load the first two pass, its first one set to 3x or 6x. Second pass is left at 1x. Cell should be at 2 if scaled by 6x, and make R, G, and B’s subpixels to only use respective colors. BGR’s layout is done the same, but swap Red and Blue’s subpixels settings. Then load up the color correction shader on top of it. The last two lcd-shader passes aren’t needed as it makes parts of the subpixels a bit fuzzy or something, lack of better words lol.

Yeah sounds a bit complicated, but if you want a bit more easy way for accurate representation of LCD look, the Authentic-GBC is the best way to go with a bit less work. LCD-Grid-V2, while less sharp than the other two shaders, works good enough without worrying about integer scaling by 3x as subpixels are always blended together. The LCD-Shader method seems to produce it slightly more sharp than Authentic-GBC, performs faster on a phone, and was easy for me to set RGB or BGR subpixel layouts as Authentic-GBC doesn’t have BGR yet. How it works as BGR is it’s complete 180 rotation from RGB as I can see the tail be on the top for BGR layout instead of the bottom that RGB layout shows.

  1. Yeah, quite often the shader repository constantly changes the location on where the shaders are stored in which folder. Whenever I come back into doing GBA or GBC shaders here, I always see either the shaders or the presets move to a different location, including my presets. But for your situation, it should work fine if you put everything inside from “Handheld-Colorspace-Shaders-main” to “shaders_slang” folder where the folders are identical that you would accept “write into” when pasting folders.

  2. I don’t know how it works on IOS, but I assume it has an option that changes colorspaces from its option. On both my LG-V60 and Samsung S23 Ultra android phones, all I had to do is use the “Vivid” colorspace mode to use the screen’s full gamma for Retroarch to take advantage of wider colors for the blue color to look more accurate. At least Retroarch on Android isn’t color-managed that happens on other apps on my V60, so I was able to use full gamut on it. As for IOS, I don’t know if the IOS version is color-managed to where it automatically applies as sRGB app, or if it’s allowed if the phone supports a type of vivid mode that forces wide colors on all apps. The whole thing can be tedious for me if I’m not familiar with how it works on IOS or other phones with different ways of representing color management.

iOS is color managed. There isn’t a way to force a colorspace. If the RA app supports HDR then you could use one of the HDR shaders to output HDR10 and set up the shader to output BT.2020 color space.

I see. I’ll eventually get to the HDR side of things later on. I also got plans to redo the GLSL shaders since I know a lot of linux ARM based handhelds may only use OpenGL.

This would be fantastic! :slight_smile:

1 Like

It’s easy if the data is already in BT.2020: you just use #pragma format to set a 10-bit output texture, apply a linearization function (if needed), multiply the value by a target brightness (can be 100, 203, or a user brightness setting), and encode with the PQ function which compresses the range from 0 to 10 000 to 0 to 1.

You can append one of the HDR presets which does this. They include an inverse tonemapper, but that step is entirely optional. But I encourage you to do it yourself.

Of course, I don’t know if HDR is supported on iOS. I would confirm that. And the HDR system is being worked on, there are some backwards incompatible changes, so best to wait until the next stable release.

2 Likes

Thank you! this was really helpful! I also had a question about GB micro. You said this in your original post:

Does this mean that the GBMicro shader would be preferred to use compared to the GBA shader? With my own testing it seems that the micro shader gives slightly more saturation but otherwise is very similar to GBA-color

1 Like

Comparing GBA and Micro, Micro has red a bit warmer and slightly more saturated, and the green is even more saturated. I know a couple have problems with GBA’s red color being a bit colder, and had suggestions to use Micro before. Tho, when I scanned the GBA one a couple months ago, the red color doesn’t look as cold as I thought it would, but still a bit, and the SP-001 one is a bit more colder. So yeah, now it’s moreso your preference. Somehow GBA’s screen has a bit more saturation than both GBC and SP-001 screens. The hue of the red color from GBC is almost similar to Micro but different saturation level