Shaders, presets, and filters

Shaders and filters	Shader presets	Future of CRT simulation	Shaders on real CRTs

"Wait—that's not how I remember this game. Why does it look strange now?"

This reaction, similar to déjà vécu, reflects a conflict between detailed recollection and present perception, and is frequently dismissed as nostalgic positivity bias. However, in many cases, the discomfort does not stem from faulty memory but from a real mismatch between the historical display pipeline and the characteristics of modern output devices.

Key concept: Players never viewed a console's raw framebuffer. Every image passed through an entire chain of signal generation, transmission, display hardware, and human visual perception before becoming the picture remembered today.

The common misconception is that old technology was simply "worse." In reality, developers leveraged the limitations of the hardware to do more with less. This is the "Golden Secret" of the analog era: the display was a collaborative processor working with the human brain. Because a CRT's electron beam bled slightly, it provided a natural, organic blur. This acted as a physical filter that smoothed jagged 16-bit edges and dithered colors into rich gradients. Where a modern 4K OLED shows a "visual mess" of harsh polygons, a CRT provided closure: allowing the brain to fill in the gaps and perceive a cinematic image. The temporal accuracy of CRTs remains unmatched, because a CRT draws with a scanning beam followed by rapid phosphor decay (an impulse display), there is near-zero perceived motion blur. A fast-moving sprite on a 50 Hz CRT can actually appear more "solid" than on a 120 Hz modern flat LCD panel, which instead exhibits sample-and-hold motion smear.

The framebuffer was only one stage of the original display pipeline, not the final image seen by the player.

Traditionally, most emulators have treated the video pipeline as ending at the framebuffer. Once the emulated system's framebuffer is rendered correctly, the remaining stages are delegated to the host operating system and display as presentation details. While this approach produces mathematically correct pixel output, it does not reproduce how the original hardware was actually seen. Real systems never presented raw framebuffer pixels directly to the user. The framebuffer was only one stage in a much longer end-to-end display chain.

From framebuffer to the final image
Stage	What happens
Video hardware	Timing generation, scaling, filtering, color encoding, and digital-to-analog conversion prepare the video signal.
Signal transmission	Cables and connectors introduce bandwidth limitations, impedance mismatches, noise, attenuation, and cross-talk.
Display electronics	The receiving display decodes composite, S-Video, component, RGB, LVDS, or other signal formats, introducing format-specific artifacts, filtering, and loss characteristics before displaying the image.
Display technology	CRTs, handheld panels, and other display technologies each transform the image according to their physical characteristics.

Even the display itself was therefore only one component of the complete pipeline and none of the characteristics were optional or cosmetic. They were inherent to the display technology itself and inseparable from how the image was ultimately perceived.

A mathematically perfect framebuffer can still produce an image that looks noticeably different from original hardware.

As a result, a pixel-perfect, nearest-neighbor, integer-scaled framebuffer (while technically correct) can still look meaningfully different from real hardware. Text, UI elements, dithering patterns, and fine details that appeared stable, blended, and legible on original displays may instead appear overly sharp, aliased, noisy, or visually unstable on modern high-contrast, fast-response panels. This discrepancy persists even when scaling artifacts are eliminated, because the difference lies not in rendering accuracy but in faithfully reproducing the complete signal and display pipeline.

Display simulation reconstructs the historical display—not the game itself.

Modern post-processing shader frameworks try to address this gap by explicitly modeling these characteristics, rather than attempting to enhance or "fix" the framebuffer. These techniques do not add new detail or increase resolution; instead, they reconstruct how the original signal was transformed and displayed by the hardware before reaching the viewer.

Importantly, display simulation is complementary to correct framebuffer output, not a substitute for it. Shaders operate only on the image they receive and cannot recover spatial information that has already been distorted by non-integer scaling, unintended filtering, incorrect aspect ratios, or downstream resampling in the OS, driver, or monitor. Accurate emulation therefore requires a well-defined pipeline:

Establish a correct framebuffer and scaling path.
Apply display modeling as a distinct stage.

Looking forward, the distinction between framebuffer accuracy and display accuracy is becoming a central concept in emulator development.^[1] As depth-aware post-processing and shader frameworks, HDR pipelines, and reusable backends (such as librashader and ReShade integration) mature, emulation is shifting from "rendering the game correctly" toward "reproducing how the hardware was actually experienced". A key parallel advancement driving this shift is signal-level display emulation. Instead of post-processing a finished image, projects like Clock Signal model the original hardware's video output as a time-domain waveform. This approach inherently handles complex timing behaviors (such as dynamic 240p/480i switching, programmatic sync, and composite color artifacts) complementing shader frameworks by moving display simulation earlier into the emulation pipeline. Together, these technologies treat the entire historical display chain not as an afterthought, but as an essential, integrated component of the emulated system.

Quick reference

If you don't have time, here is a quick curated list of recommended setups (recommended presets by system type) for you.
System Type	Preset
240p systems (≤4th generation)	retroarch's slang repo > presets > crt-beam-simulator > CRT beam simulator crtroyale ntsc svideo
240p-480i hybrid systems (5th generation)	Depends on the specific system
480p systems (6th and 7th generation)	SDTV Experience Preset
Early Fixed Pixel Era (7th generation)	Early HD LCD Experience Preset
Arcade cabinets	Koko-aio fork for Arcade Artwork
PC Amiga, Win9x	retroarch's slang repo > bezel > Koko aio > presets-4.1 Win9x Experience Preset (WIP)
Handhelds	Duimon Mega Bezel's handheld presets or retroarch's slang repo > bezel > koko-aio presets
PSP	PSP Experience Preset
Switch	Switch Experience Preset
3DS	3DS Experience Preset
Notes	Guidelines
PPSSPP libretro	The PPSSPP libretro core can suffer from performance issues when using Duimon Mega Bezel's handheld presets. Because of this, using the standalone version of PPSSPP with the PSP Experience Preset is recommended instead. You'll need a reasonably modern GPU; an old office PC from 2010 isn't going to cut it. Both Switch and PSP experience presets are solely focused on 1080p displays. If you use a display other than 1080p, you will need to manually adjust the shader parameters yourself. Make sure to check out the readme.txt first!
Determining resolution	Turn on the statistics overlay or on-screen display (OSD). If in doubt, just check the OSD once.
CRT Beam Simulator	You need a high-refresh-rate display (120 Hz minimum, 240 Hz+ recommended) for this preset; otherwise use one of the other ones mentioned in the CRT presets section for 240p systems. Comes with RetroArch (Slang shaders > Presets > crt-beam-simulator directory). Go to Settings → Video → Synchronization, then enable V-Sync and set "Shader Sub-frames" to match your monitor's refresh rate. Disable "Sync to exact content framerate".
Clock Signal	Consider using the #Clock Signal emulator if it's available for your OS. Its display emulation, particularly the way it models video as a time-based 1D signal and simulates cable and signal characteristics, is a more accurate approach than post-processing shaders. This appproach is especially beneficial for mixed-mode resolution systems (e.g., PlayStation and other 5th-generation consoles) that dynamically switch between 240p gameplay and 480i menus or high-resolution scenes. A signal-level display model automatically reacts to sync timing, interlace cadence, and composite decoding in real time, avoiding the need to manually change shader presets when games switch modes. Note that Clock Signal mostly focuses on signal simulation, which means the advantage applies strictly to signal fidelity, not to CRT mask simulation or other visual effects.

Why Should I Use Shaders/Shader Presets?

While it is tempting to simply increase an emulator's internal rendering resolution (for example, rendering a PlayStation 2 game at 4K), doing so often strips away the visual cohesion of the original presentation. Upscaling older 3D games without additional processing exposes the limitations of their low-resolution textures, low-polygon geometry, and other assets that were designed to be viewed on analog CRT displays rather than modern fixed-pixel LCD and OLED panels. This is not a limitation of the emulator; it is simply the reality of displaying low-resolution assets on an ultra-sharp modern display.

For these reasons, many enthusiasts prefer using texture packs where available, particularly for games with pre-rendered backgrounds or 2D/3D hybrid graphics (such as the original Resident Evil PlayStation titles). To handle the 3D elements without making them look too harsh, they will often couple this with downsampling (also known as supersampling) instead of relying solely on aggressive internal upscaling. With this approach, the emulator renders the game at a higher internal resolution before scaling it back down to the display's native resolution, reducing aliasing and shimmering while preserving a more natural image. When utilizing highly accurate emulator renderers (such as ParaLLEl-RDP or ParaLLEl-GS), this is often achieved by combining native resolution with 2x SSAA (Supersampling Anti-Aliasing) and sharp bilinear filtering. Another viable downsampling alternative is rendering at higher native resolution using area sampling. In either case, combining these methods with shaders that introduce subtle image softening or a light blur is crucial to mimic natural beam bloom, smooth out jagged edges, digitized look and stabilize pixel blending for a result faithful to the original hardware.

CRT shader presets provide another approach though. Rather than increasing rendering resolution, they recreate the optical characteristics of the displays for which these games were originally designed. CRT displays possess inherent physical limitations in image sharpness. Even high-end VGA CRT monitors, considered exceptionally sharp for their time compared to standard-definition televisions (SDTVs), produce a noticeably softer image than a modern fixed-pixel display. This difference becomes readily apparent when comparing the two side-by-side at similar resolutions (for example, a CRT operating at 1920×1440 versus a 1080p LCD at its native resolution). Consumer SDTVs are softer still, owing not only to the characteristics of the display itself, but also to the limitations of analog video signals, inexpensive console DACs, and composite or S-Video connections. Consequently, reproducing the softness introduced by the analog display and signal chain is essential for accurately simulating the original presentation on modern digital displays.

Many games relied on these characteristics to achieve their intended appearance. Low-resolution textures blended together more naturally, dithering patterns created the illusion of additional colors or transparency, and pixel art appeared smoother than it does on modern displays. Simply increasing the rendering resolution cannot reproduce these optical characteristics.

Many emulator enhancements that modify the game's rendering such as texture filtering, widescreen hacks or excessive internal upscaling can introduce graphical glitches, broken user interfaces, lighting inconsistencies, and other rendering bugs. CRT shader presets avoid these issues because they are applied as a post-processing effect over the emulator's native output rather than altering the game's internal rendering pipeline.

General CRT Simulation Considerations

While shaders are highly customizable on a per-system basis, several foundational technical and physical display properties apply universally across all eras when attempting to replicate classic CRT behavior on modern, fixed-pixel digital panels.

Achieving a Convincing Simulation on Modern Displays (Pipeline & Signal Basics, Tube Physics and Glass Simulation)
The Interlacing Dilemma (Deinterlacing vs. Combing) If the emulator provides built-in deinterlacing solutions, always use those native options. Avoid trying to resolve core interlacing or combing problems using post-processing shaders. For interlaced video modes where raw software deinterlacing is already active, you can layer a flickering shader set to a conservative setting (e.g., 5–10% brightness oscillation). But avoid full-screen displacement shaders that constantly shift the entire image 1-pixel up and down to mimic interlaced bobbing. Forcing a global geometric shake on fixed-pixel LCDs causes severe digital judder, induces rapid eye strain, and breaks alignment with layered scanline/mask shader grids. Instead, if you have a high-refresh-rate Variable Refresh Rate (VRR) monitor, leverage native hardware-level integrations like Themaister's ParaLLEl-GS "Scanline Breathing". By utilizing VRR and low-level timing APIs (`EXT_present_timing`), this method schedules native temporal field rendering across perfectly synchronized display cycles. This replicates the true, dynamic "analog buzz" of a live CRT signal flawlessly without introducing judder or forcing synthetic 2D frame geometry shifts.
DAC, Analog Signal and Cable Simulation Prioritize emulator's built-in or core-level emulation solutions where available (e.g., Clock Signal, ParaLLEl-RDP, or ParaLLEl-GS) to accurately handle system-specific internal low-level signal generation, hardware dither, and digital-to-analog converter (DAC) quirks prior to the post-processing stage (such as the Nintendo 64's anti-aliasing and Video Interface/VI horizontal blur, or specialized hardware color blends such as Saturn's VDP2 color gradation effect etc), because the final image was heavily dictated by console hardware before the signal ever reached the video cable. If emulator's solutions do not fully model the entire internal and external analog video chain, complement them with post-processing shaders configured to model cable bandwidth shaping (composite/S-Video chroma and luma limits), horizontal luma bandwidth blur, NTSC/PAL encoding artifacts (including chroma-luma phase offsets, chroma crosstalk, mild chroma delay and color blending) and subtle electrical signal noise. Replicating this complete phase is essential for reproducing the foundational signal degradation and pixel blending inherent to vintage analog connection standards.
Dithering Mitigation Prioritize native emulator-side graphics features (e.g., DuckStation's default graphics options) over post-processing steps. Native fixes preserve original clarity while cleanly resolving hardware-level dither blending.
Color Range Correction Apply a precise levels remap (16–235 → 0–255) prior to signal filters. Omit this step if the emulator already handles limited-to-full range expansion natively (e.g., Dolphin or Theimaster's PCSX2 builds under Enhancements → Color Correction). Legacy content was mastered for limited-range broadcast standards; running it uncorrected on full-range RGB digital displays (0–255) results in washed-out, elevated black floors and severely compressed contrast.
SDR Gamma Adjustment Enable native emulator gamma options (e.g., Dolphin/PCSX2 "Correct SDR Gamma" features). Classic displays targeted an internal gamma curve of ~2.35, whereas modern panels target ~2.2 or piecewise sRGB.
Localized Phosphor Bleed Implement a mathematically tight, high-threshold halation/glow pass rather than a global full-screen bloom filter. Authentic consumer CRT glow was highly localized; extreme electron beam energy hitting a bright area caused light to bleed subtly into immediate neighboring pixels. This preserves the raw brightness and vertical clarity required for SDR panels while convincingly replicating the macro visual illusion of an overdriven analog beam. To mimic this realistically while maintaining text legibility, configure the shader based on your display's hardware capabilities: For 4K+ / HDR Displays (Mask Active): Clamp the bleed threshold high (e.g., triggering only above 80% luminance) and restrict the energy distribution directly to the underlying simulated sub-pixel structures/phosphor triads. For 1080p / SDR Displays (Mask Disabled): To prevent severe Moiré patterns and devastating luminance loss on 480i/480p content, completely disable sub-pixel mask structures. Instead, configure a linear-space halation pass clamped to an ultra-high luminance threshold (triggering only at 90% to 100% brightness). Restrict this pass strictly to a tight, 1-to-2 pixel radius along the horizontal axis only, ensuring that only intense highlights (like explosions or bright UI text) bleed into adjacent pixels while preserving the panel's native contrast.
Glass & Tube Face Simulation Recreating a photorealistic flat-screen CRT faceplate requires a unified, multilayered stack that balances internal electron physics, geometric optics and decades of physical wear. Rather than relying on simplistic, standalone 2D filters, the shader configuration must combine coordinate warping, micro-refractions, subtle lighting tints and surface overlays into a single cohesive pipeline. 1. Volumetric Glass Refraction & Depth Late-era CRTs featured completely flat outer glass faceplates, yet the internal phosphor layer retained a subtle, physical cylindrical or spherical curve. Because the physical glass faceplate becomes progressively thicker as it nears the screen edges, it functions as an asymmetric optical prism. This creates a nuanced, volumetric "magnifying glass" refraction where the game image appears to sit on a deeper 3D plane behind a flat outer window. Realistically mimicking this physical depth on a flat panel requires splitting the coordinate mapping into two independent spatial layers, applied with extreme restraint: The Inner Phosphor Plane: The shader applies a gentle 3D parabolic coordinate warp (barrel distortion) exclusively to the incoming game texture, compressing and curving the image slightly toward the corners to simulate the internal concave tube structure. The Asymmetric Refraction Vector: Instead of warping the entire screen uniformly, the shader scales a microscopic directional offset based on the distance from the center (Offset = Thickness × IoR). This causes the internal game pixels to slide and squeeze at a completely different rate than the flat outer viewport. This organic, sub-pixel spatial parallax tricks the human visual cortex into perceiving a genuine physical gap and volumetric depth between the monitor's surface and the rendered image. 2. Tube Aesthetics, Tint & Vignetting Anti-Glare Tint: Modern displays require a very conservative grey or dark blue-green tint across the entire viewport. Consumer CRTs utilized "dark tint" glass to preserve ambient contrast in lit rooms, ensuring the screen looks like a grounded physical object rather than a digital black void. Coatings: A soft, non-dynamic specular highlight recreates the high-end anti-reflective coatings found on premium sets. Beam Vignetting: A highly feathered, conservative corner vignette replicates the natural fall-off in brightness that occurs as the internal electron beam strikes the underlying phosphor matrix at extreme, oblique angles near the edge bezels. Peripheral Chromatic Aberration: Chromatic aberration passes must remain exceptionally minor, targeting edge convergence rather than distinct red/blue color ghosting. Thick glass and analog electron guns regularly suffered from minor beam misalignment artifacts restricted strictly to the absolute physical corners of the viewport. 3. Outer Glass Surface Overlays Utilize very low-opacity/transparent texture overlays featuring fine, static grain and subtle "dirt" or hairline scratch masks. Physical tube faces naturally accumulated dust due to high-voltage static charges, alongside mild environmental seasoning and surface micro-abrasions over decades of use. These micro-details must remain highly transparent, revealing themselves passively only during bright scenes to establish the outermost physical glass boundary. 4. Overscan and Bezel Masking A critical element of authentic tube face simulation is managing active display boundaries. Vintage CRTs naturally hid 5–10% of the signal's outer perimeter (the overscan area) behind a physical plastic bezel, masking out video blanking artifacts, head-switching noise, and "garbage" edge pixels. By default, many emulators output the full, uncropped internal framebuffer, exposing these unsightly edge artifacts on modern fixed-pixel screens. Prioritize Native Emulator Options: Always utilize native emulator or core-level cropping adjustments first (e.g., RetroArch core options like "Crop Overscan" or "Initial/Last Scanline", DuckStation's crop settings, or PCSX2's zoom/cropping toggles). Avoid using heavy post-processing shaders to forcefully stretch the frame to hide overscan; altering the scaling non-linearly breaks sub-pixel alignment and introduces severe Moiré patterns across layered scanline or phosphor mask shader grids. Complementary Shader-Based Bezel Overlays: If an emulator is configured to leave the overscan area visible (e.g., PCSX2's "Show Overscan" toggle), complement the output with a clean, hardware-aligned shader border mask or overlay. This mask should simulate the soft, slightly curved physical boundary where the glass meets the inner bezel, ensuring that edge pixels vignette naturally into absolute black rather than ending in a harsh, unshaded digital crop. To achieve this illusion convincingly without introducing distracting visual artifacts or muddying corner contrast, the execution sequence follows a strict processing order: Pass 1 (Linearization & Color): Linearizes the raw game texture gamma, applies the base layer, and integrates the conservative anti-glare tint. Pass 2 (Inner Tube Warp): Applies the restrained 3D parabolic barrel distortion to generate the base warped coordinate layer (UV_warped). Pass 3 (Refraction & Convergence): Calculates the dynamic Index of Refraction (IoR) offset vector based on a non-linear coordinate delta (Δ) from the screen center, keeping center distortion at zero and confining micro-displacements and corner chromatic aberration strictly to the screen periphery. Pass 4 (Composite Slicing): Shifts the UV_warped coordinates by the calculated micro-refraction offset vector and samples the results to generate the combined 3D depth view. Pass 5 (Surface Finishing, Vignette and Masking): Compiles the separate spatial layers into a unified viewport, applying the soft beam vignette, the non-dynamic specular highlight coating, the low-opacity dust/scratch overlays, and the overscan bezel mask to lock the underlying 3D depth view directly beneath a flat outer faceplate.
Common Pitfalls to Avoid
Phosphor Ghosting & Decay Trails Avoid activating shader-based temporal phosphor persistence or decay simulation passes. While authentic phosphors have measurable chemical decay times (with green tracks lingering slightly longer), modern flat-panel LCDs already exhibit inherent sample-and-hold motion blur alongside independent pixel response time lag. Stacking software-driven frame accumulation buffers on top of modern digital display panel physics results in an smeared mess that drastically degrades motion clarity far beyond real-world CRT specifications.
Double-Mapping & Black Crushing Do not stack shader-based color/gamma configurations on top of active native emulator color and gamma correction settings. Doing so causes stacked calculations that crush black levels, over-saturate color fields, and permanently destroy shadow details.
Exaggerated Blooms & Halos Avoid aggressive or heavy "Halation/Glow" shader passes that blanket the entire viewport. Standard post-processing bloom filters often exaggerate delicate phosphor behavior into unnatural, blinding, HDR-like halos that crush dark shadow details and create distracting visual artifacts on user interface text. Authentic consumer CRT glow was highly localized, mathematically subtle phosphor bleed; extreme electron beam energy striking a single phosphor cluster only bled light into its immediate, sub-pixel neighbors. If a glow filter is utilized, it must be clamped to a strict, high-luminance threshold to keep structural edges and text completely crisp while allowing only intense, intentional highlights (such as lasers, explosions or bright skyboxes) to bloom authentically.
Fake Beam Blooming Shaders Avoid shader passes that apply dynamic 2D coordinate warping/radial distortion to simulate screen expansion during bright flashes. While hardware CRTs briefly expand their picture due to flyback transformer voltage drops, real blooming causes the electron beam to simultaneously defocus and alter its spot-size structure. Forcing a flat geometric warp on a fixed-pixel LCD simply creates an artificial, distracting "camera lens zoom" effect whenever an explosion occurs, failing to replicate the living physics of an analog chassis.
Horizontal Luma Rise-Time Blur Avoid utilizing asymmetrical horizontal blur filters to simulate electron gun rise-time limits. On a real CRT, this behavior is a fluid physical side-effect of a continuous stream of electrons drawing a line left-to-right across the screen. Forcing a digital blur pass strictly along the horizontal axis on a standard 1080p display conflicts with modern sample-and-hold display physics and lacks the sub-pixel density required to cleanly map that analog ramp-up phase. The result is a cheap, muddy smear dragged slightly to the right that completely ruins the native structural clarity of the underlying artwork.
Aggressive Blur-Filtering Do not attempt to use destructive blur passes or aggressive analog signal shaders to blend dithering patterns. This strips the global image of its native structural clarity and causes extreme edge softening across the entire viewport.
Beam & Rolling Scanline Simulation Avoid activating CRT Beam, BFI or rolling scanline shaders on standard 60Hz refresh rate displays. Attempting to simulate hardware-level beam scanning cuts perceived screen luminance in half and induces severe stroboscopic flicker, leading to rapid eye strain. These motion-clarity techniques should only be utilized on high-refresh-rate panels (120Hz or greater) capable of handling the strobing frequency gracefully.
Mask and Scanline Simulation Avoid applying CRT mask simulations on standard 1080p SDR displays, particularly for higher-density 480i/480p content. A 1080p grid lacks the raw pixel density required to cleanly map complex sub-pixel structures alongside active scanlines, resulting in severe Moiré interference patterns and uneven artifacting. Furthermore, without the massive peak brightness headroom of an HDR display to back-compensate for the heavy mask occlusion, the final image suffers from devastating luminance loss and crushed color dynamics.

Era-Specific Considerations

For a fast setup guide, see #Quick reference.Each console generation requires different considerations, as display technologies and video output standards evolved substantially over time.

For 5th-generation systems onward, avoid CRT mask and heavy scanline shaders unless outputting to a very high pixel-density display (approximately 5K or greater). Most consumer 1080p and 1440p SDR displays lack the pixel density, contrast ratio, and phosphor persistence necessary to convincingly reproduce aperture grille or shadow mask structures, often resulting in distracting moiré patterns or an exaggerated "screen door" appearance. While these shaders work well for 240p content, they generally appear unnatural for later consoles. Additionally, late-era consumer CRTs (particularly flat-screen models from the late 1990s and 2000s) rarely exhibited pronounced scanlines or sharply defined phosphor masks due to increased beam overlap and phosphor bloom.

Instead, prioritize the analog signal characteristics described in the general CRT simulation considerations, as these can be reproduced convincingly even on standard 1080p and 1440p LCD displays.

3rd and 4th Generation (NES, SNES, Genesis)

Late 1980s to Mid-1990s

Pure 240p systems used standard-definition double-strike scanning at a 15 kHz horizontal frequency, causing the electron beam to skip every other scanline. The resulting high-contrast scanline structure is fundamental to the intended appearance of sprites, transparency effects, and ordered dithering.

Unlike later consoles, the NES generates video directly through NTSC color encoding rather than producing conventional RGB output. As a result, emulators require custom palette files to accurately reproduce the way different consumer CRT decoders interpreted the console's video signal.

Monitor refresh rate also affects shader selection. Users with high-refresh-rate displays should consider beam simulation presets such as CRT-beam-simulator-crt-royale-ntsc-svideo, while lower refresh-rate displays generally produce better results with lighter, less refresh-dependent shader presets.

5th Generation (PlayStation, Nintendo 64, Saturn)

Late 1990s

Fifth-generation consoles occupy a transitional period between the purely 240p systems of the 16-bit era and the predominantly progressive 480p systems that followed. Many games switched dynamically between 240p and 480i, while others rendered entirely in interlaced resolutions (for example, Tekken 3 outputs at 384×480i).

Both DuckStation and Ymir include graphics options that accurately reproduce deinterlacing and hardware dithering for modern displays. Combined with the ntsc-adaptive preset (using a reduced ntsc_scale value) or the ntsc-256px-composite preset, these provide an excellent baseline for PlayStation and Sega Saturn emulation.

For Ares, the ParaLLEl-RDP renderer emulates the Nintendo 64's Video Interface (VI), naturally blending framebuffer dithering and softening image transitions. Pairing this with Maister's 320px Composite NTSC or ntsc-adaptive further reproduces the console's distinctive analog video characteristics.

6th and 7th Generation (PS2, GameCube, Xbox, Wii, Xbox 360)

SDTV and scanlines

Late 1990s to Mid-2000s

For sixth- and seventh-generation systems, visual priorities depend largely on the display configuration being emulated.^[1] Although these consoles commonly supported 480p, true progressive output required a 31 kHz display, such as a VGA monitor or certain Enhanced Definition Television (EDTV) sets. In practice, most players continued using standard 15 kHz SDTV CRTs or digital CRT televisions over composite or S-Video connections, meaning 480i remained the dominant viewing mode.

For 480i content, Theimaster's ParaLLEl-GS integration for PCSX2 includes a Scanline Breathing option that effectively recreates the subtle interlace shimmer characteristic of CRT displays. To reproduce the appearance of late consumer CRT televisions, simulation should account not only for analog signal characteristics but also for the digital image processing increasingly integrated into CRT chassis. Unlike earlier analog-only displays, many televisions of this era employed internal frame buffers and dedicated image enhancement hardware that substantially altered the final image.

Edge Enhancement (SVM, LTI, CTI, and Peaking): Many televisions combined Scan Velocity Modulation (where implemented), Luminance Transient Improvement (LTI), Color Transient Improvement (CTI), and peaking filters into a unified sharpness system. These techniques selectively enhanced horizontal edge transitions rather than applying uniform sharpening. When reproducing this behavior, edge enhancement should remain subtle, as conventional sharpening filters (such as CAS or standard unsharp masks) do not accurately replicate the original processing.
Digital Noise Reduction: Spatial and temporal filtering was commonly applied to composite and S-Video inputs to suppress analog noise. Although effective, these filters also softened fine textures and slightly reduced motion detail.
100 Hz Processing Pipelines: Many European and late-generation CRT televisions implemented 100 Hz display modes using internal frame buffers. While primarily intended to reduce flicker, these systems also modified motion cadence, occasionally introduced interpolation artifacts, and altered perceived motion sharpness.
Digital Geometry and Convergence Correction: Flat CRT designs frequently incorporated digital correction for geometry, convergence, and edge focus. These adjustments could produce subtle regional differences in sharpness and image behavior compared to earlier analog chassis.
Picture Enhancement Features: Proprietary image processing, such as shadow coring, black-level expansion, or dynamic white balance ("Blue Stretch"), was often included to increase perceived contrast or showroom brightness. If simulated, these effects should remain conservative, as aggressive settings can crush shadow detail and clip highlights.

For this generation, the SDTV Experience Preset provides a strong baseline for recreating the appearance of consumer composite-video CRT televisions used throughout the early-to-mid 2000s.

Why LCD shaders help even at integer scale

Role of LCD shaders - demonstration

As mentioned in the introduction section in this page, faithfully reproducing a system's framebuffer does not necessarily reproduce the appearance of its original display. This distinction also applies to handheld LCD systems.

Using a 1× internal resolution with nearest-neighbor sampling produces a mathematically correct reconstruction of a handheld's framebuffer. However, that framebuffer must still be mapped to the host display. If this mapping involves non-integer scaling—for example, displaying a 480×272 PSP image on a typical desktop resolution—resampling occurs somewhere in the display pipeline. Depending on the configuration, this may be performed by the emulator, GPU driver, operating system compositor, or monitor. The result can be uneven pixel widths, spatial distortion, and reduced text readability even when the emulator itself is configured for nearest-neighbor sampling.

When the framebuffer is scaled by an exact integer factor (for example, 480×272 scaled 4×, or displayed in a native-resolution guest window), these resampling artifacts are avoided and the framebuffer is reproduced faithfully. Nevertheless, the presentation can still differ substantially from the original handheld because the display itself contributed characteristics that modern LCD and OLED panels do not possess.

Display characteristics

Early handheld systems used low-resolution transmissive or reflective LCD panels with limited contrast, non-linear gamma, partial pixel fill ratios, visible pixel apertures, and relatively slow pixel response. Together these characteristics introduced natural softening, intra-pixel blending, and mild temporal smoothing. Consequently, text, UI elements, and fine graphics that appeared stable and legible on the original hardware may appear excessively sharp, aliased, or visually unstable on modern high-resolution displays, even when the framebuffer itself is reproduced perfectly.

Some handhelds also incorporated scaling as part of their native display pipeline. A notable example is the PlayStation Portable (PSP). Many PSP titles render internally at 320×240 (or 256×224), after which the hardware scales the image to the LCD panel's native 480×272 resolution. Because the LCD panel never receives the original framebuffer directly, reproducing the PSP display accurately requires modeling both the console's internal scaling and the physical characteristics of its LCD.

Role of LCD shaders

Handheld LCD shaders and presets model these display characteristics after a correct framebuffer has already been established. Depending on the implementation, they simulate various aspects of the original display, such as pixel structure, fill ratio, gamma, diffusion, and temporal response. Like CRT shaders, they do not add new image detail or compensate for incorrect rendering. Instead, they reconstruct how the original display transformed the framebuffer before it reached the viewer.

For this reason, LCD shaders complement—but do not replace—correct rendering and scaling. They cannot recover information already lost through non-integer scaling, unintended filtering, incorrect aspect ratios, or downstream resampling. Their purpose is to model the historical display, not to correct rendering errors.

DAR vs. PAR

Main article: ResolutionOne of the most confusing topics in retro game emulation is the relationship between internal game resolutions, pixel geometry, and display shape. Modern LCD and OLED displays are generally designed around fixed square pixels, meaning each pixel typically has a 1:1 aspect ratio. Many classic video game systems, however, were designed for analog CRT displays. Because a CRT is simply a glass vacuum tube, it can technically be manufactured into almost any physical shape. While most consumer televisions were built to a 4:3 standard, the final image was defined primarily by the television's analog scanning characteristics and electron gun timings rather than a fixed grid of physical pixels.

This distinction creates two important concepts:

PAR (Pixel Aspect Ratio): The intended shape of an individual pixel when displayed. A pixel may be square (1:1) or non-square depending on the system and display standard.
DAR (Display Aspect Ratio): The overall shape of the displayed image, such as 4:3.

Throughout the 1980s, 1990s, and early 2000s, most consumer televisions displayed a 4:3 raster image regardless of the console's internal rendering resolution or horizontal pixel count. As a result, many systems generated images using horizontal resolutions that do not naturally map to square pixels. For example, consoles from the early 2D era through the PlayStation 2 generation frequently rendered images at resolutions whose pixels would appear non-square when stretched to fill a standard 4:3 display. The resulting pixel aspect ratio varied depending on the console, video mode, and active image area. A similar situation existed on PC VGA CRT monitors. Unlike modern flat panels, VGA CRTs could display a wide variety of resolutions and timings without relying on a fixed physical pixel grid. The monitor's geometry settings determined how a given raster filled the screen. As a result, resolutions whose pixel dimensions did not match the physical screen shape (such as 1280×1024 displayed on a 4:3 CRT monitor) could still be shown correctly by adjusting the displayed image area. However, PC graphics standards generally assumed square pixels, distinguishing this from many console video modes where non-square pixel presentation was often an expected part of the display pipeline.

Internal Resolution	Approximate PAR for 4:3 Display	Notes
256×224 (common NES/SNES mode)	~8:7	When displayed as 4:3, pixels become slightly wider than they are tall.
320×240 (common PlayStation mode)	~32:35	Pixels become slightly taller than they are wide when mapped to a 4:3 display.
352×240 (common Saturn/PlayStation mode)	~6:7	Pixels become noticeably taller than they are wide when displayed at 4:3.

Values shown are common approximations. Actual pixel aspect ratios varied by video standard, active image area, overscan, and console-specific implementation.

Because these systems were designed around analog displays, there is ongoing debate regarding the most accurate way to present them on modern screens. Different games, development practices, and artistic assumptions can produce different results.

Native/Raw Framebuffer Presentation: Displays the original framebuffer without display-aspect correction. The resulting image preserves the original pixel grid but may appear narrower or wider than it would on a typical CRT display.
Aspect-Corrected Presentation: Adjusts the image so that the overall display matches the intended 4:3 output. This more closely resembles how the game would have appeared on most consumer televisions, but requires resampling or horizontal scaling on modern square-pixel displays.

Some artwork appears more natural with aspect correction, while other graphics were designed with square-pixel workflows or development tools in mind. For example, SNES artwork was almost certainly intended for CRT display and an approximate 8:7 pixel aspect ratio, whereas PlayStation artwork was often created on PCs using square-pixel tools. Historical development practices varied between platforms, studios, and individual projects. Developers frequently previewed their work on CRT displays during development, yet different games (even on the same platform) could assume different display characteristics. As a result, modern emulators often provide multiple aspect-ratio options to accommodate these differing interpretations.

Early Fixed-Pixel Era (7th Generation)

Replicating the visual presentation of HD-capable seventh-generation consoles such as the PlayStation 3 and Xbox 360 on modern fixed-pixel displays can produce a noticeably different image compared to how these systems originally appeared on many contemporary televisions. While these consoles primarily targeted 720p output, with some titles using sub-720p internal rendering or dynamic resolution scaling, modern high-PPI PC monitors (1440p and 4K) present this content with a level of pixel density and clarity that was uncommon in many early HD living-room setups, which frequently used larger 720p or 1366×768 LCD televisions. Running a 720p Xbox 360 game through an emulator using a standard full-screen bilinear stretch introduces a small amount of interpolation blur due to image scaling, as it applies straightforward bilinear filtering without additional sharpening (or alternatively, a sharp bilinear variant). Despite this subtle softening, the resulting image can still appear noticeably cleaner and more structurally defined than the presentation on many original display setups. This difference is not merely subjective or “placebo”, but depends on factors such as display technology, viewing distance, signal processing and individual hardware configurations. On original hardware, television-side scaling, overscan, image enhancement processing and the characteristics of many early fixed-pixel panels could introduce additional softness or minor image distortion beyond the console's framebuffer output. In contrast, modern fixed-pixel displays and GPU or emulator-based scaling typically provide a more consistent digital presentation with less additional processing, resulting in a cleaner overall image even when basic bilinear interpolation is used. Not only that, but some users additionally choose to use integer scaling or increase the emulator's internal rendering resolution beyond the console's original output. While these techniques increase perceived image clarity, they also produce a presentation that departs even further from the visual characteristics of the original hardware and its contemporary display environment. As a result, although such enhancements are often preferred for image quality, they are less accurate of the era-authentic viewing experience.

1. Dedicated Hardware Scaling Pipelines

On a modern PC running emulators like RPCS3 or Xenia Edge, the software typically renders the frame at its native internal resolution and passes a single, mathematically uniform bilinear or bicubic filter directly to the GPU to stretch the frame to the monitor's native fixed-pixel grid. But original hardware utilized heavily processed, multi-stage topologies:

The Xbox 360 "HANA" Pipeline: The Xbox 360 included a hardware display processing stage (ANA, and later the digital HANA chip) capable of scaling and converting framebuffer output to match selected resolutions, essentially a hardware filtering explicitly engineered to blend geometric edges and naturally suppress aliasing. In practice, output quality depended on the chosen display mode and the connected television’s processing pipeline.
The PS3 Display Reset & Television Upscaling: The PS3 often output the game’s native framebuffer directly over HDMI or component. Upscaling to the display resolution was typically handled by the television rather than the console in many configurations. This forced the television's internal scaling engine to process the image, introducing an additional layer of analog-tuned digital interpolation.

2. Transmission Mismatches and Color-Encoding Constraints

Modern emulators usually output a perfectly normalized, Full-Range RGB (0–255) signal directly to your monitor's operating system environment. During the early years of the seventh generation, however, high-definition gaming was split across two highly volatile connection mediums:

Early Digital HDMI & The 16–235 Range Trap: During the mid-2000s transition to digital video, consumer televisions strictly operated on broadcast-centric Limited-Range color standards (16–235). Connecting a console via early HDMI frequently triggered a handshake mismatch. If the console outputted Full Range RGB and the TV expected Limited Range, the television chassis firmware clamped anything below digital value 16 to absolute black and anything above 235 to absolute white. This created a dramatic, hardware-level black crush and highlight clipping effect that altered the contrast depth of the game's assets.
Analog Component YPbPr / YCbCr Bandwidth Splits: Before HDMI became ubiquitous, the premium standard for HD gaming was the 5-cable component connection. While component video possessed ample bandwidth to transmit 720p and 1080p signals at 60Hz, it didn't transmit raw Red, Green, and Blue. Instead, consoles utilized an internal Digital-to-Analog Converter (DAC) to split the image into Luma (Y) and two color-difference channels (CbCr). Because human vision resolves fine contrast edges much better than color edges, early TV chassis processors aggressively sub-sampled and low-pass filtered the chroma channels while leaving the luma sharp. This physical bandwidth limit introduced a distinct horizontal color bleeding effect, causing highly saturated hues (like red UI text or vibrant energy shields) to softly spill horizontally into adjacent pixels while underlying brightness boundaries stayed crisp.

3. Late-2000s TV Processor Electronics

The early flat-panel HDTVs (circa 2005–2010) that players originally paired with these consoles utilized scaling engines that were drastically less precise than modern fixed-pixel PC monitors.

Non-Integer Panel Grids: A significant portion of early consumer LCD televisions featured a native panel resolution of 1366x768. Feeding a 1280x720 signal into a 1366x768 physical matrix forced a complex, fractional interpolation pass that inherently blurred fine lines and softened textures.
Mandatory Image Processing & Overscan: Consumer televisions of this era featured mandatory overscan processing, cropping between 2% and 5% of the outer perimeter of the video signal. This required a second non-linear spatial stretch to expand the cropped image back to the panel boundaries. When combined with the aggressive spatial smoothing filters and baseline noise reduction active on early digital inputs, the final image was fundamentally softened before reaching the viewer. Modern PC monitors bypass these steps entirely, presenting an uncropped, structurally raw pixel stream with clinical precision.

4. Physical Sub-Pixel Density and Optics

The physical construction of late-2000s display panels inherently masked low-resolution rendering artifacts in ways modern high-density screens cannot:

Aperture and Fill Ratio: 720p and 768p LCD and plasma televisions featured large physical sub-pixels with wider gaps between them (a lower pixel fill ratio). This allowed light emitting from adjacent pixels to subtly bleed and blend in the air before reaching the human eye, acting as a physical spatial low-pass filter that naturally smoothed out jagged geometry.
Liquid Crystal Response and Motion Ghosting: Early consumer LCD televisions suffered from notoriously slow liquid crystal response times compared to modern display technology. While modern display marketing frequently claims near-instantaneous "1ms Gray-to-Gray (GtG)" performance, these figures are widely recognized as optimized marketing metrics, often achieved only during cherry-picked, single-shade transitions under extreme hardware overdrive profiles that induce severe visual artifacting (such as inverse ghosting or bright coronas). In real-world usage across the entire color spectrum, modern high-refresh gaming panels typically average a true ~5ms GtG. By contrast, flat panels of the late-2000s operated without the benefit of fast-switching panel chemistry or advanced pixel driving. Their true, unexaggerated baseline response times averaged ~16ms, with deep-black to dark-gray transitions often ballooning past ~30ms. Furthermore, early chassis "overdrive" circuits were incredibly primitive, completely failing to accelerate complex color state transitions cleanly. During rapid camera pans, high-speed gameplay or low-contrast scenes, this genuine physical sluggishness introduced heavy native temporal smearing and faint motion trails: this physical artifact acted as a natural temporal low-pass filter. It smoothed out pixel shimmering, harsh specular specular aliasing, and jagged geometric edges whenever the camera or objects were in motion, a smoothing characteristic that is completely lost on modern ultra-fast displays that expose every raw rendering imperfection with clinical, unforgiving rigidity.
The Modern Grid Contrast Trap: Displaying an unadulterated 720p stream on a modern high-density 27-inch 1440p monitor maps a low-resolution asset directly onto a microscopic, ultra-sharp physical grid. Because the panel features intense pixel contrast and zero intra-pixel blending, the jagged edges of low-polygon models, low-resolution texture steps, and specular aliasing are laid bare with harsh, unnatural contrast.

Mitigation and Emulation Configuration

To recreate the cohesive, blended presentation intended by developers during the early HD era, users should avoid relying solely on basic, uniform bilinear full-screen stretching within core emulator video options. For an authentic, period-accurate presentation, apply dedicated post-processing shaders configured to simulate the engineering constraints and internal firmware logic of mid and late 2000s LCD and plasma television chassis. Rather than mimicking the raw analog cable bandwidth limits of the CRT era, these shaders should replicate the digital video processing pipelines characteristic of early HDTV scalers (such as Faroudja DCDi or Genesis Microchip engines). This includes simulating minor horizontal luma (brightness) bandwidth restrictions, which television firmware deliberately utilized as a low-pass filter to mask early digital compression artifacts, panel overdrive smearing, and high-frequency analog noise from Component (YPbPr) connections. When combined with subtle pixel aperture diffusion and non-linear edge peaking, this simulation perfectly restores the original "soft yet defined" visual cohesion of the 720p era without resorting to destructive global blur filters.

For this generation, you can try the Early HD LCD Experience Preset for recreating the authentic look of seventh-generation HD capable console systems as they appeared on early HD LCD televisions.

The Eighth-Generation

Unlike the transitional nature of the seventh generation, eighth-generation consoles operated almost exclusively within a fully digital HDMI pipeline. This removed many earlier sources of image instability such as analog chroma subsampling artifacts, signal noise and connector-dependent range mismatches. However, limited-range (16–235) versus full-range (0–255) RGB mismatches could still occur when console output settings and display black level configurations were not correctly aligned. These issues were generally less common than in the Xbox 360 / PlayStation 3 era due to improved HDMI standardization and more consistent default auto-detection in modern televisions. Most eighth-generation titles also relied on internal resolution scaling (e.g., 900P -> 1080P) and reconstruction techniques rather than consistently rendering at native 1080p or higher. This included sub-native rendering on base PlayStation 4 and Xbox One systems, followed by upscaling to the display output resolution. On later mid-generation hardware, techniques such as checkerboard rendering and temporal reconstruction became more widespread, improving perceived sharpness but introducing artifacts like temporal instability, shimmer, and reconstruction blur on high-resolution displays. Overall, the eighth generation significantly reduced the need for display-side correction compared to the seventh generation through standardized HDMI output and more consistent 1080p-era display design. However, it introduced a different set of tradeoffs centered around internal resolution scaling, reconstruction methods and the inherent limitations of sample-and-hold motion presentation.

Emulator support

Name	Shader file types	Chain/Preset files	Notes
RetroArch	.cg, .glsl, .slang, .dll/.so	.cgp, .glslp, .slangp	.cgp/.glslp/.slangp files "stack" individual shaders. SoftFilters (.dll/.so) are platform-dependent.
MAME	.vsh, .fsh, .fx, .glsl	.json, .ini	Uses .json for BGFX chains; HLSL and GLSL settings are typically stored in mame.ini or separate custom.fx files.
OpenEmu	.cg	.slangp (Upcoming)	Currently supports .cg; Slang support is planned for the new Metal-based rendering engine.
Snes9x	.cg, .shader	-	Uses basic XML-based .shader files or individual .cg files; does not use a secondary chain format.
Ares	.slang	-	Added full .slang shader support via librashader in version 137 (March 2024), through this pull request. All shaders from libretro/slang-shaders are bundled, though some may have minor compatibility issues due to the recent addition of both librashader support and its integration in Ares.
DuckStation	.glsl, .fx, .slang	.ini	Supports .slang shaders by implementing its own slang parser/runtime to accommodate RetroArch-specific semantics that many shaders rely on. Since RetroArch's slang implementation deviates from standard practices, direct shader sharing across emulators typically requires dedicated support rather than simple file copying. Modern post-processing chains are supported via .ini files and the built-in interface.
PCSX2	.slang (Upcoming)	.slangp (Upcoming)	Supports .slang shaders by implementing librashader, accommodating RetroArch-specific semantics that many shaders rely on. Still work-in-progress. Theimaster's paraLLEl-GS project is also aim to improve the accuracy of native-resolution rendering.[1]
Dolphin	.glsl, .hlsl	-	Shaders are simple and generally single-pass; parameters are handled via the UI rather than external chain files.
Pedro-HDSR's MelonDS build	.slang	.ini?	This custom MelonDS build adds libretro slang shaders support directly in the melonDS UI. Possibly added to the master branch in the future.
86Box	.glsl	?	Librashader support WIP?[2]

References

↑ ^1.0 ^1.1 Theimaster blog: Emulating old junk from yesteryear – or my obsession making native resolution PS2 emulation look good

External links

All things shaders and filters
Cg shader spec.
Vulkan GLSL (Slang) shader spec
Shader preview thumbnail repository
More CRT Shaders (filthypants.blogspot.com) - hunterk's comparison of current CRT shaders.
RetroArch Additions - Shaders
Reshade Shaders Repository Index
thingsiplay's article on sonkun's preset pack
"Integrum Retro" showcasing shader presets and overlays
"Retro Crisis" YouTube channel - Videos about various shader presets and podcasts with creators of those projects.
libretro forum: what crt shaders can do
S4W: Scanlines for Windows — Adjustable real-time CRT/VHS shader tool for PC games, emulators and frontends. No added latency, low CPU usage.

Downloads

This article is a never ending list. It will always need updates, it will likely have new content added to it on a consistent basis, & can never truly be a finished article.

[theimasterps2-1] 1.0 ^1.1 Theimaster blog: Emulating old junk from yesteryear – or my obsession making native resolution PS2 emulation look good

[1]

Shaders, presets, and filters

Contents

Quick reference