Note
This guide is an independent technical project, not an authoritative reference. Despite the research and experimental work behind it, some interpretations or conclusions may be incomplete or incorrect. Corrections supported by measurements, primary sources, or reproducible tests are welcome.
This project aims to accurately reproduce the original color output of handheld console screens on modern displays.
All data is based on instrumented colorimetric measurements of real hardware. Subjective, visual, or “by eye” adjustments are explicitly excluded.
Each display measurement is translated into a dedicated RetroArch shader, designed using color science principles and high-precision mathematical modeling.
Note
Physically accurate simulation of ambient illuminant effects through measured screen reflectance data, enabling the modeling of the display's reflective behavior instead of relying on chromatic adaptation.
Warning
The GBC shaders are based on "-45°" screen reflectance measurements (45°/0° geometry + 180° orientation), which produce a washed-out image due to the reflective properties of the original display. The screenshots shown here were generated using the "45° Simulation" parameter (45°/0° geometry + 0° orientation), a rough approximation that better represents the display's intended appearance.
| GBC no shader | GBC Illuminant A (WIP) | GBC Illuminant D50 (WIP) | GBC Illuminant D65 (WIP) |
|---|---|---|---|
![]() |
![]() |
![]() |
![]() |
| GBA no shader | GBA SP AGS-101 | GB Micro |
|---|---|---|
![]() |
![]() |
![]() |
| DS no shader | DS Phat | DS Lite |
|---|---|---|
![]() |
![]() |
![]() |
| 3DS no shader | 3DS | New 3DS XL (IPS) |
|---|---|---|
![]() |
![]() |
![]() |
Detailed notes about individual consoles and their screen measurements are available in handhelds/README.md.
| Status | Nintendo Handheld | Console code(s) | Display Category | Bit Depth | Known Panel Manufacturers |
|---|---|---|---|---|---|
| 🔴 | Game Boy |
DMG-01 |
Reflective | 2-bit/pixel | ? |
| 🔴 | Game Boy Pocket |
MGB-001 |
Reflective | 2-bit/pixel | ? |
| 🔴 | Game Boy Light |
MGB-001 |
Reflective | 2-bit/pixel | ? |
| 🔴 | Transmissive | ||||
| 🟡🕐 | Game Boy Color |
CGB-001 |
Reflective | 5-bit | Sharp (link) |
| 🟡 | Game Boy Advance |
AGB-001 |
Reflective | 5-bit | ? |
| 🟡 | Game Boy Advance SP |
AGS-001 |
Reflective | 5-bit | ? |
| 🔵 | AGS-101 |
Transmissive | 5-bit | ? | |
| 🔵 | Game Boy Micro |
OXY-001 |
Transmissive | 5-bit | ? |
| 🔴 | DS Phat |
NTR-001 |
Reflective (link) | 6-bit | ? |
| 🔵 | Transmissive | ||||
| 🔵 | DS Lite |
USG-001 |
Transmissive | 6-bit | Hitachi, Sharp (link) |
| 🔴 | DSi |
TWL-001 |
Transmissive | 6-bit | ? |
| 🔴 | DSi XL |
UTL-001 |
Transmissive | 6-bit | ? |
| 🔵 | 3DS |
CTR-001 |
Transmissive | 8-bit | ? |
| 🔴 | 3DS XL |
SPR-001 |
Transmissive | 8-bit | ? |
| 🔴 | New 3DS |
KTR-001 |
Transmissive | 8-bit | ? |
| 🔴 | New 3DS XL |
RED-001 |
Transmissive TN | 8-bit | ? |
| 🔵 | Transmissive IPS | ||||
| 🔴 | 2DS |
FTR-001 |
Transmissive | 8-bit | ? |
| 🔴 | New 2DS XL |
JAN-001 |
Transmissive | 8-bit | ? |
| 🔴 | Wii U GamePad |
WUP-010 |
Transmissive | 8-bit | ? |
| 🕐 | Switch |
HAC-001HAC-001(-01) |
Transmissive | 8-bit | Innolux |
| 🔴 | Switch Lite |
HDH-001 |
Transmissive | 8-bit | ? |
| 🔴 | Switch OLED |
HEG-001 |
Emissive | 8-bit | ? |
| 🔴 | Switch 2 |
BEE-001 |
Transmissive | ? | ? |
| Status | Sony Handheld | Console code(s) | Display Type | Bit Depth | Known Panel Manufacturers |
|---|---|---|---|---|---|
| 🔵 | PSP Phat |
PSP-1000 |
Transmissive | 8-bit | ? |
| 🔴 | PSP Slim |
PSP-2000 |
Transmissive | 8-bit | ? |
| 🔴 | PSP Brite |
PSP-3000 |
Transmissive | 8-bit | ? |
| 🔴 | PSP Go |
PSP-N1000 |
Transmissive | 8-bit | ? |
| 🔴 | PSP Street |
PSP-E1000 |
Transmissive | 8-bit | ? |
| 🔴 | PlayStation Vita |
PCH-1000PCH-1100 |
Emissive OLED | 8-bit | ? |
| 🔴 | PlayStation Vita Slim |
PCH-2000 |
Transmissive | 8-bit | ? |
Note
For transflective panels, measurements are divided into the individual reflective and transmissive components.
Note
Known manufacturers are grouped for now; each will eventually have its own row and status once measurements identify the manufacturer of each panel.
Note
Bit depth notation: Values refer to the bit depth of each RGB channel, except for Game Boy models, where they refer to bits per pixel.
Screen data status legend:
- 🔴: No screen data available
- 🟡: Measurement data incomplete or potentially unreliable
- 🔵: Screen data available
- 🟢: Screen data available and verified by two or more screen reports from different consoles
- 🕐: Screen measurement data validation in progress
Note
The 🟡 status means that either the measurement was not performed correctly and may not be representative of the display, or it was performed correctly but did not capture enough information to reproduce the display faithfully. Shaders based on such measurements may therefore be inaccurate.
Even when a measurement is correct, the information extracted from it may be limited by the mathematical procedures currently used in this project and may therefore be inaccurate. In general, mathematical inference should be avoided whenever possible, since it can introduce unnecessary errors that could be avoided by measuring all the required data, as described in CONTRIBUTING.md.
In the handheld folder, you’ll find the measured consoles and their corresponding RetroArch shaders.
Note
Currently, only the sRGB color space is supported. I haven’t found a way to instruct RetroArch or the operating system (at least on macOS) to interpret the shader’s output framebuffer as a non‑sRGB color space (such as Display P3, Rec. 2020, etc.). Given this limitation, there’s little benefit in supporting other color spaces, since you wouldn’t get the expected colors. If you know of any way (even a partial workaround) to overcome this limitation, I’d appreciate your support.
Note
Future improvement: The current implementation applies full chromatic adaptation to D65, but does not model how the human visual system adapts to different viewing conditions. A future version could introduce partial chromatic adaptation through a color appearance model such as CIECAM16, using the required viewing-condition parameters to better approximate how chromatic adaptation is perceived by the human eye.
No chromatic adaptation is applied. This preserves the original display behavior, including differences between screens of the same console model, often referred to as “screen lottery”.
This option applies full chromatic adaptation to a D65 white point — typically used on modern displays — to achieve a more neutral color temperature and reduce screen tinting.
The trade-off is a loss of color accuracy compared with the original display reproduction. Choosing between OFF and ON is therefore ultimately a matter of personal preference.
Note
Because of the “screen lottery”, this option can be understood, in a broad and conceptual sense, as moving the output toward a common reference that resembles an average across measurements from multiple screens. It is not a literal average, however, and its relevance depends heavily on the console model, panel manufacturer, panel age, and panel wear.
In this Game Boy Micro example, chromatic adaptation is OFF in the bottom-left image, producing a blue-tinted, cool-temperature greyscale, and ON in the top-right image, producing a neutral greyscale.
This diagnostic option highlights in red colors that must be approximated because they fall outside the sRGB gamut.
- Pokéfan531 for almost all the consoles’ screen measurements and feedback
- Pica200 for the 3DS and New 3DS consoles’ measurements
- Anikom15 for helping me fix some issues with the shader code and and OS/program-specific color space management.
- Libretro Forum
Note
AI was used as a supporting tool during the development of this guide. All technical content, decisions, and AI-assisted output were carefully reviewed before inclusion.












