Deinterlacing: Difference between revisions

(21 intermediate revisions by the same user not shown)

Line 1:

Deinterlacing methods are used to process interlaced video signals (480i/576i), common in high-resolution modes for [[Sega Saturn]], [[PlayStation]], and [[PlayStation 2]]. Without deinterlacing, movement causes "combing" or "judder" artifacts on progressive displays. PlayStation 2 Graphics Synthesizer, used unique internal video output modes to handle or disguise interlacing. Emulators must handle these behaviors natively before applying any external deinterlacing method. While there are some attempted [[~~Shaders,_presets,_and_filters~~|shader-based solutions]], emulator's built-in deinterlacing methods provide better results on image quality.

Deinterlacing methods are used to process interlaced video signals (480i/576i), common in high-resolution modes for [[Sega Saturn]], [[PlayStation]], and [[PlayStation 2]]. Without deinterlacing, movement causes "combing" or "judder" artifacts on progressive displays. PlayStation 2 Graphics Synthesizer, used unique internal video output modes to handle or disguise interlacing. Emulators must handle these behaviors natively before applying any external deinterlacing method. While there are some attempted [[Shaders_and_filters#Deinterlacing|shader-based solutions]], emulator's built-in deinterlacing methods provide better results on image quality.

==Before diving in==

Line 41:

=== CRT Simulation===

{{Main|~~Shaders, presets, and filters~~#Full Signal & Cable Emulation}}

==== High Refresh-Rate Insertion ====

==== High Refresh-Rate Beam Insertion (Hardware Deinterlacing) ====

Modern low-latency renderers (such as [[~~PlayStation_2_emulators#Emulation_issues|~~paraLLEl-GS]]) experiment with bypassing traditional software deinterlacing shaders entirely. Instead, they simulate how a CRT monitor naturally ~~displays~~ interlaced fields by utilizing high-refresh-rate displays and ~~Black Frame Insertion (BFI) techniques.~~

Modern low-latency renderers (such as [[paraLLEl-GS]]) experiment with bypassing traditional software deinterlacing shaders (like Bob, Blend, or motion-adaptive deinterlacing) entirely.[https://themaister.net/blog/2026/05/09/emulating-old-junk-from-yesteryear-or-my-obsession-making-native-resolution-ps2-emulation-look-good/] Instead of filtering frames in a buffer, they simulate how a CRT monitor's electron gun naturally draws interlaced fields sequentially by utilizing high-refresh-rate host displays and variable refresh rate (VRR) timing hooks.

* '''How it works:''' The emulator simulates each interlaced field independently with scanlines. By leveraging high-refresh-rate host displays (e.g., 120Hz, 240Hz, or 360Hz), the emulator queries display timings (`EXT_present_timing`) to insert a calculated number of "gentle falloff" or blank frames during a single guest field's duration (~~~60Hz NTSC / 50Hz PAL~~).

* '''Pros:''' Achieves a completely authentic CRT "hardware" deinterlacing appearance; preserves native interlaced motion characteristics without software ghosting or interpolation artifacts; eliminates sample-and-hold motion blur along moving edges because odd and even lines are physically drawn on alternating host refresh cycles.

* '''Pros:''' Achieves a completely authentic CRT "deinterlacing~~" look~~; ~~bypasses the need for soft~~ interpolation ~~filters~~; eliminates sample-and-hold motion blur.

* '''Cons:''' Extremely high display and timing accuracy requirements; can cause minor line-flicker on sharp high-contrast patterns (mirroring original CRT hardware behavior); requires precise synchronization with display presentation timing APIs.

* '''Cons:''' ~~Extreme computational~~ and ~~display~~ requirements; ~~causes a massive drop in screen brightness~~ (~~which~~ requires ~~an HDR~~ display to ~~artificially boost~~ the ~~"proper" frames to compensate);~~ any ~~missed frames or micro~~-~~stutter causes severe, highly visible flickering~~.

* '''How it works:''' The emulator separates the incoming interlaced video into its native, independent odd and even fields. Instead of stacking or combining them digitally, it leverages high host refresh rates and `EXT_present_timing` to instantly scan out each field on alternating screen updates, manually blacking out only the inactive scanline rows for that field. Because the host display updates rapidly enough, human persistence of vision naturally weaves the alternating line passes together, executing native hardware deinterlacing without any artificial full-frame black insertion.

{| class="wikitable" style="margin-left: 20px;"

'''Understanding the Spatial Beam Timing Mechanics:'''

|+~~on a 240Hz monitor, a single~~ 60Hz ~~guest field spans~~ across 4 host refresh cycles. ~~The emulator uses these extra cycles to phase out the image smoothly, accurately mimicking the natural temporal decay of CRT phosphors~~

Unlike software-based "Scanline Overlays" (which simply layer a static 2D grid over a progressive image) or full-frame BFI (which flashes the entire screen on and off), hardware-driven beam insertion utilizes extra host refresh cycles to simulate the fast temporal decay of individual illuminated lines:

*'''Luminance Percentages (%)''' represent the simulated light decay curve of an active scanline row before the alternating field pass occurs. Rather than holding its brightness statically until the next master frame, the shader decays individual lines to mimic analog phosphors.

*'''The Granularity Threshold:''' On a basic 120Hz setup, the emulator can only switch sharply between the odd and even line grids (100% to 0% line state per pass). Higher host refresh rates (240Hz, 360Hz, or higher) allow the shader pipeline to slice a single guest field's duration into multiple micro-steps, letting the active scanline set smoothly phase down its brightness before the next field lines illuminate.

*'''Perceived Image Stability:''' Because the global screen is never blanked out as a solid black block, there is no aggressive stroboscopic flashing. On VRR-enabled high-refresh displays, the fast alternating line-swapping results in an incredibly stable, fluid image where the classic "interlacing flicker" is confined strictly to fine horizontal details, exactly like a high-end CRT presentation monitor.

{| class="wikitable" style="margin-left: 20px; text-align: center;"

|+ Comparative Scanline Field Decay Timelines per 60Hz Guest Field Shows the simulated light decay behavior of an active scanline row across consecutive host refresh cycles before the alternating field takes over.

|-

! Host Cycle !! 120Hz Monitor (2x Container) !! 180Hz Monitor (3x Container) !! 240Hz Monitor (4x Container) !! 360Hz Monitor (6x Container) !! 480Hz Monitor (8x Container) !! 600Hz Monitor (10x Container)

|-

| '''Slice 1 (Beam Strike)'''

| 100% Line Brightness

|-

| '''Slice 2'''

| {{Black}} 0% (Line Blanked)

| 40% Line Glow

| 50% Line Glow

| 70% Line Glow

| 80% Line Glow

| 85% Line Glow

|-

| '''Slice 3'''

| {{Gray}} —

| {{Black}} 0% (Line Blanked)

| 15% Line Glow

| 45% Line Glow

| 60% Line Glow

| 70% Line Glow

|-

| '''Slice 4'''

| {{Gray}} —

| {{Black}} 0% (Black/Blank)

| 20% Line Glow

| 40% Line Glow

| 50% Line Glow

|-

| '''Slice 5'''

| {{Gray}} —

| 5% Line Glow

| 20% Line Glow

| 35% Line Glow

|-

~~! Host Frame !! Display State !! Purpose~~

| '''Slice 6'''

| {{Gray}} —

| {{Black}} 0% (Black/Blank)

| 8% Line Glow

| 20% Line Glow

|-

| '''~~Frame 1~~''' || ~~100~~% ~~Brightness~~ |~~| The initial electron gun strike (Odd or Even lines)~~

| '''Slice 7'''

| {{Gray}} —

| 2% Line Glow

| 10% Line Glow

|-

| '''~~Frame 2~~''' || 50% ~~Luminance~~ |~~| Simulating the natural decay of the CRT phosphor~~

| '''Slice 8'''

| {{Gray}} —

| {{Black}} 0% (Black/Blank)

| 4% Line Glow

|-

| '''~~Frame 3~~''' || ~~15% Luminance~~ || ~~Deepening the fade~~

| '''Slice 9'''

| {{Gray}} —

| 1% Line Glow

|-

| '''~~Frame 4~~''' || 0% (Black ~~Frame~~) || ~~Total blanking before~~ the ~~next field arrives~~

| '''Slice 10'''

| {{Gray}} —

| {{Black}} 0% (Black/Blank)

|-

! style="text-align: left;" | Motion Verdict

| {{Orange}} '''Passable.''' Stutter-free motion, but raw transitions can cause slight raw line-crawling artifacts on fixed patterns.

| {{Yellow}} '''Good.''' Decent transition blending, but line decay timeline is slightly truncated.

| colspan="4" {{Green}} '''Excellent.''' Flawless analog tracking. The high sub-frame refresh ceiling completely masks individual line transitions. When running at 240Hz+ paired with VRR, the spatial interleaving simulates authentic CRT motion clarity without full-screen strobe fatigue.

|}

;[[HDR]] Luminance Compensation & Linear Mastering

To counteract the minor average brightness drop caused by keeping inactive scanline rows unlit, modern implementations render natively inside an HDR10 colorspace. Instead of brute-forcing average luminance via a crude software brightness multiplier (which crushes shadow detail and skews color curves), the emulator performs 3×3 matrix color transformations inside a truly linear mathematical space. By passing precise Maximum Content Light Level (MaxCLL) metadata targets directly to the OS compositor and display engine, the emulator instructs the host monitor to disable its automated internal tone mapping, handing direct control of the hardware backlight headroom to the shader pipeline.

* Because high-refresh environments spread individual line decay characteristics smoothly across multiple sub-frame updates instead of cutting them to black instantly, linear HDR luminance management completely counteracts any perceived dimness penalty. The result is a vibrant, perfectly balanced analog simulation that accurately reconstructs authentic CRT phosphor color profiles and wide-gamut historical profiles (like Japan's legacy NTSC 1953 standard) without crushing fine highlight detail.

* '''Color Primaries:''' Accurate simulation also uses 3×3 matrix transformations to map retro SDTV color spaces (such as BT.601 or historical NTSC 1953 primaries) into modern sRGB (BT.709) or wide-gamut HDR spaces, preventing washed-out or improperly saturated tones.

;Asymmetric Refresh Rates and VRR Automation

When using host displays where the maximum refresh rate is not a perfect mathematical integer multiple of the guest field rate (e.g., 144 / 60 = 2.4, or 280 / 60 = 4.66), traditional synchronous beam techniques break down:

* '''Temporal Judder:''' Because a single 60Hz guest frame cannot be sliced evenly into fractional monitor refreshes, a fixed-refresh display must cycle unevenly between frames (e.g., a 3:2 or 5:4 pulldown pattern). One field stays on screen longer than the next, translating to jarring stutter during camera pans.

* '''Line Alternation Artifacts:''' If timing slices slip out of alignment, the alternating odd/even field order desynchronizes from the panel's physical refresh cadence, resulting in severe combing artifacts and image splitting.

To resolve this, emulators leverage advanced display APIs (`EXT_present_timing`) to handle regional guest variations (~59.94Hz NTSC / 50Hz PAL) automatically via two distinct paths:

;1. Variable Refresh Rate (VRR / G-Sync / FreeSync) Automation

If the host monitor supports VRR, the emulator does not force the display into a rigid, lower desktop refresh rate. Instead, it dynamically constrains the monitor's maximum refresh ceiling to match an exact integer multiple of the incoming guest signal:

* '''NTSC Guest (~59.94Hz):''' The emulator instructs the graphics pipeline to sync the display to exactly '''119.88Hz''' (on a 144Hz panel) or '''239.76Hz''' (on a 280Hz panel). The alternating field scanlines map perfectly into a flawless 2x or 4x container with zero motion judder.

* '''PAL Guest (50.00Hz):''' The monitor dynamically drops its refresh rate down to exactly '''100.00Hz''' or '''200.00Hz'''. This entirely bypasses the asymmetric limitation of the panel's maximum spec, offering automated, stutter-free region switching.

;2. Fixed Refresh Rate Fallbacks

On legacy displays or setups where VRR is disabled, the monitor operates at a rigid, unyielding clock (e.g., a flat 120Hz or 144Hz). The emulator must handle this via software adaptation:

* '''The 0.05% NTSC Speedup:''' To align a standard 59.94Hz NTSC game with a static 120Hz display container (120 / 59.94 = 2.002), the emulator subtly adjusts the internal emulation speed (audio and video) upward by roughly 0.05% to hit a flat 60.00Hz. This aligns the fields perfectly with a 120Hz refresh grid without perceptible distortion.

* '''The PAL Asymmetry Issue:''' Running a 50Hz PAL title on a static 120Hz container results in the same severe 2.4x frame-slicing judder as running NTSC on 144Hz. In this scenario, the emulator must actively call a display mode-switch to alter the hardware's EDID profile to a fixed 100Hz environment, or the user must manually adjust their display control panel.

==== FRAME Mode (The Flicker Filter) ====

Line 68:

Line 172:

==== FIELD Mode ====

Used by titles aiming for a true 60 FPS. These games sacrificed half of their vertical resolution and jittered the rendering pipeline to stay perfectly in sync with the interlaced output fields.

* '''Emulator Handling:''' These titles absolutely require a deinterlacing solution to look acceptable on progressive screens~~. While standard shaders often produce subpar results on these titles, high-refresh-rate CRT simulation has proven to be an effective alternative~~.

* '''Emulator Handling:''' These titles absolutely require a deinterlacing solution to look acceptable on progressive screens.

==== Hardware Masking (SCANMSK) ====

Line 78:

Line 182:

File:Bob_Deinterlace_Example.png|'''Bob Deinterlacing''' Eliminates combing but introduces vertical jitter/shimmer.

File:Yadif_Deinterlace_Example.png|'''Motion-Adaptive (MAD)''' Modern standard that preserves detail on static objects without shimmer.

File:ParaLLEl-GS - 1x + CRT sim with High Refresh-Rate Insertion - WE9.webm|'''High Refresh-Rate Insertion''' 120Hz capture on 144Hz host display.

</gallery>

Line 92:

Line 197:

*[[Resolution]]

*[[Shaders, presets, and filters]]

*[[Black frame insertion]]

*[[High dynamic range]]

[[Category:FAQs]]

@@ Line 1: / Line 1: @@
-Deinterlacing methods are used to process interlaced video signals (480i/576i), common in high-resolution modes for [[Sega Saturn]], [[PlayStation]], and [[PlayStation 2]]. Without deinterlacing, movement causes "combing" or "judder" artifacts on progressive displays. PlayStation 2 Graphics Synthesizer, used unique internal video output modes to handle or disguise interlacing. Emulators must handle these behaviors natively before applying any external deinterlacing method. While there are some attempted [[Shaders,_presets,_and_filters|shader-based solutions]], emulator's built-in deinterlacing methods provide better results on image quality.
+Deinterlacing methods are used to process interlaced video signals (480i/576i), common in high-resolution modes for [[Sega Saturn]], [[PlayStation]], and [[PlayStation 2]]. Without deinterlacing, movement causes "combing" or "judder" artifacts on progressive displays. PlayStation 2 Graphics Synthesizer, used unique internal video output modes to handle or disguise interlacing. Emulators must handle these behaviors natively before applying any external deinterlacing method. While there are some attempted [[Shaders_and_filters#Deinterlacing|shader-based solutions]], emulator's built-in deinterlacing methods provide better results on image quality.
 ==Before diving in==
@@ Line 41: / Line 41: @@
 === CRT Simulation===
-{{Main|Shaders, presets, and filters#Full Signal & Cable Emulation}}
+{{Main|Future of CRT simulation#Full Signal & Cable Emulation}}
-==== High Refresh-Rate Insertion ====
+==== High Refresh-Rate Beam Insertion (Hardware Deinterlacing) ====
-Modern low-latency renderers (such as [[PlayStation_2_emulators#Emulation_issues|paraLLEl-GS]]) experiment with bypassing traditional software deinterlacing shaders entirely. Instead, they simulate how a CRT monitor naturally displays interlaced fields by utilizing high-refresh-rate displays and Black Frame Insertion (BFI) techniques.
+Modern low-latency renderers (such as [[paraLLEl-GS]]) experiment with bypassing traditional software deinterlacing shaders (like Bob, Blend, or motion-adaptive deinterlacing) entirely.[https://themaister.net/blog/2026/05/09/emulating-old-junk-from-yesteryear-or-my-obsession-making-native-resolution-ps2-emulation-look-good/] Instead of filtering frames in a buffer, they simulate how a CRT monitor's electron gun naturally draws interlaced fields sequentially by utilizing high-refresh-rate host displays and variable refresh rate (VRR) timing hooks.
-* '''How it works:''' The emulator simulates each interlaced field independently with scanlines. By leveraging high-refresh-rate host displays (e.g., 120Hz, 240Hz, or 360Hz), the emulator queries display timings (`EXT_present_timing`) to insert a calculated number of "gentle falloff" or blank frames during a single guest field's duration (~60Hz NTSC / 50Hz PAL).
+* '''Pros:''' Achieves a completely authentic CRT "hardware" deinterlacing appearance; preserves native interlaced motion characteristics without software ghosting or interpolation artifacts; eliminates sample-and-hold motion blur along moving edges because odd and even lines are physically drawn on alternating host refresh cycles.
-* '''Pros:''' Achieves a completely authentic CRT "deinterlacing" look; bypasses the need for soft interpolation filters; eliminates sample-and-hold motion blur.
+* '''Cons:''' Extremely high display and timing accuracy requirements; can cause minor line-flicker on sharp high-contrast patterns (mirroring original CRT hardware behavior); requires precise synchronization with display presentation timing APIs.
-* '''Cons:''' Extreme computational and display requirements; causes a massive drop in screen brightness (which requires an HDR display to artificially boost the "proper" frames to compensate); any missed frames or micro-stutter causes severe, highly visible flickering.
+* '''How it works:''' The emulator separates the incoming interlaced video into its native, independent odd and even fields. Instead of stacking or combining them digitally, it leverages high host refresh rates and `EXT_present_timing` to instantly scan out each field on alternating screen updates, manually blacking out only the inactive scanline rows for that field. Because the host display updates rapidly enough, human persistence of vision naturally weaves the alternating line passes together, executing native hardware deinterlacing without any artificial full-frame black insertion.
-{| class="wikitable" style="margin-left: 20px;"
+'''Understanding the Spatial Beam Timing Mechanics:'''
-|+on a 240Hz monitor, a single 60Hz guest field spans across 4 host refresh cycles. The emulator uses these extra cycles to phase out the image smoothly, accurately mimicking the natural temporal decay of CRT phosphors
+Unlike software-based "Scanline Overlays" (which simply layer a static 2D grid over a progressive image) or full-frame BFI (which flashes the entire screen on and off), hardware-driven beam insertion utilizes extra host refresh cycles to simulate the fast temporal decay of individual illuminated lines:
+*'''Luminance Percentages (%)''' represent the simulated light decay curve of an active scanline row before the alternating field pass occurs. Rather than holding its brightness statically until the next master frame, the shader decays individual lines to mimic analog phosphors.
+*'''The Granularity Threshold:''' On a basic 120Hz setup, the emulator can only switch sharply between the odd and even line grids (100% to 0% line state per pass). Higher host refresh rates (240Hz, 360Hz, or higher) allow the shader pipeline to slice a single guest field's duration into multiple micro-steps, letting the active scanline set smoothly phase down its brightness before the next field lines illuminate.
+*'''Perceived Image Stability:''' Because the global screen is never blanked out as a solid black block, there is no aggressive stroboscopic flashing. On VRR-enabled high-refresh displays, the fast alternating line-swapping results in an incredibly stable, fluid image where the classic "interlacing flicker" is confined strictly to fine horizontal details, exactly like a high-end CRT presentation monitor.
+{| class="wikitable" style="margin-left: 20px; text-align: center;"
+|+ Comparative Scanline Field Decay Timelines per 60Hz Guest Field<br><small>Shows the simulated light decay behavior of an active scanline row across consecutive host refresh cycles before the alternating field takes over.</small>
+|-
+! Host Cycle !! 120Hz Monitor<br><small>(2x Container)</small> !! 180Hz Monitor<br><small>(3x Container)</small> !! 240Hz Monitor<br><small>(4x Container)</small> !! 360Hz Monitor<br><small>(6x Container)</small> !! 480Hz Monitor<br><small>(8x Container)</small> !! 600Hz Monitor<br><small>(10x Container)</small>
+|-
+| '''Slice 1 (Beam Strike)'''
+| 100% Line Brightness
+| 100% Line Brightness
+| 100% Line Brightness
+| 100% Line Brightness
+| 100% Line Brightness
+| 100% Line Brightness
+|-
+| '''Slice 2'''
+| {{Black}} 0% (Line Blanked)
+| 40% Line Glow
+| 50% Line Glow
+| 70% Line Glow
+| 80% Line Glow
+| 85% Line Glow
+|-
+| '''Slice 3'''
+| {{Gray}} —
+| {{Black}} 0% (Line Blanked)
+| 15% Line Glow
+| 45% Line Glow
+| 60% Line Glow
+| 70% Line Glow
+|-
+| '''Slice 4'''
+| {{Gray}} —
+| {{Gray}} —
+| {{Black}} 0% (Black/Blank)
+| 20% Line Glow
+| 40% Line Glow
+| 50% Line Glow
+|-
+| '''Slice 5'''
+| {{Gray}} —
+| {{Gray}} —
+| {{Gray}} —
+| 5% Line Glow
+| 20% Line Glow
+| 35% Line Glow
 |-
-! Host Frame !! Display State !! Purpose
+| '''Slice 6'''
+| {{Gray}} —
+| {{Gray}} —
+| {{Gray}} —
+| {{Black}} 0% (Black/Blank)
+| 8% Line Glow
+| 20% Line Glow
 |-
-| '''Frame 1''' || 100% Brightness || The initial electron gun strike (Odd or Even lines)
+| '''Slice 7'''
+| {{Gray}} —
+| {{Gray}} —
+| {{Gray}} —
+| {{Gray}} —
+| 2% Line Glow
+| 10% Line Glow
 |-
-| '''Frame 2''' || 50% Luminance || Simulating the natural decay of the CRT phosphor
+| '''Slice 8'''
+| {{Gray}} —
+| {{Gray}} —
+| {{Gray}} —
+| {{Gray}} —
+| {{Black}} 0% (Black/Blank)
+| 4% Line Glow
 |-
-| '''Frame 3''' || 15% Luminance || Deepening the fade
+| '''Slice 9'''
+| {{Gray}} —
+| {{Gray}} —
+| {{Gray}} —
+| {{Gray}} —
+| {{Gray}} —
+| 1% Line Glow
 |-
-| '''Frame 4''' || 0% (Black Frame) || Total blanking before the next field arrives
+| '''Slice 10'''
+| {{Gray}} —
+| {{Gray}} —
+| {{Gray}} —
+| {{Gray}} —
+| {{Gray}} —
+| {{Black}} 0% (Black/Blank)
+|-
+! style="text-align: left;" | Motion Verdict
+| {{Orange}} '''Passable.''' Stutter-free motion, but raw transitions can cause slight raw line-crawling artifacts on fixed patterns.
+| {{Yellow}} '''Good.''' Decent transition blending, but line decay timeline is slightly truncated.
+| colspan="4" {{Green}} '''Excellent.''' Flawless analog tracking. The high sub-frame refresh ceiling completely masks individual line transitions. When running at 240Hz+ paired with VRR, the spatial interleaving simulates authentic CRT motion clarity without full-screen strobe fatigue.
 |}
+;[[HDR]] Luminance Compensation & Linear Mastering
+To counteract the minor average brightness drop caused by keeping inactive scanline rows unlit, modern implementations render natively inside an HDR10 colorspace. Instead of brute-forcing average luminance via a crude software brightness multiplier (which crushes shadow detail and skews color curves), the emulator performs 3×3 matrix color transformations inside a truly linear mathematical space. By passing precise Maximum Content Light Level (MaxCLL) metadata targets directly to the OS compositor and display engine, the emulator instructs the host monitor to disable its automated internal tone mapping, handing direct control of the hardware backlight headroom to the shader pipeline.
+* Because high-refresh environments spread individual line decay characteristics smoothly across multiple sub-frame updates instead of cutting them to black instantly, linear HDR luminance management completely counteracts any perceived dimness penalty. The result is a vibrant, perfectly balanced analog simulation that accurately reconstructs authentic CRT phosphor color profiles and wide-gamut historical profiles (like Japan's legacy NTSC 1953 standard) without crushing fine highlight detail.
+* '''Color Primaries:''' Accurate simulation also uses 3×3 matrix transformations to map retro SDTV color spaces (such as BT.601 or historical NTSC 1953 primaries) into modern sRGB (BT.709) or wide-gamut HDR spaces, preventing washed-out or improperly saturated tones.
+;Asymmetric Refresh Rates and VRR Automation
+When using host displays where the maximum refresh rate is not a perfect mathematical integer multiple of the guest field rate (e.g., 144 / 60 = 2.4, or 280 / 60 = 4.66), traditional synchronous beam techniques break down:
+* '''Temporal Judder:''' Because a single 60Hz guest frame cannot be sliced evenly into fractional monitor refreshes, a fixed-refresh display must cycle unevenly between frames (e.g., a 3:2 or 5:4 pulldown pattern). One field stays on screen longer than the next, translating to jarring stutter during camera pans.
+* '''Line Alternation Artifacts:''' If timing slices slip out of alignment, the alternating odd/even field order desynchronizes from the panel's physical refresh cadence, resulting in severe combing artifacts and image splitting.
+To resolve this, emulators leverage advanced display APIs (`EXT_present_timing`) to handle regional guest variations (~59.94Hz NTSC / 50Hz PAL) automatically via two distinct paths:
+;1. Variable Refresh Rate (VRR / G-Sync / FreeSync) Automation
+If the host monitor supports VRR, the emulator does not force the display into a rigid, lower desktop refresh rate. Instead, it dynamically constrains the monitor's maximum refresh ceiling to match an exact integer multiple of the incoming guest signal:
+* '''NTSC Guest (~59.94Hz):''' The emulator instructs the graphics pipeline to sync the display to exactly '''119.88Hz''' (on a 144Hz panel) or '''239.76Hz''' (on a 280Hz panel). The alternating field scanlines map perfectly into a flawless 2x or 4x container with zero motion judder.
+* '''PAL Guest (50.00Hz):''' The monitor dynamically drops its refresh rate down to exactly '''100.00Hz''' or '''200.00Hz'''. This entirely bypasses the asymmetric limitation of the panel's maximum spec, offering automated, stutter-free region switching.
+;2. Fixed Refresh Rate Fallbacks
+On legacy displays or setups where VRR is disabled, the monitor operates at a rigid, unyielding clock (e.g., a flat 120Hz or 144Hz). The emulator must handle this via software adaptation:
+* '''The 0.05% NTSC Speedup:''' To align a standard 59.94Hz NTSC game with a static 120Hz display container (120 / 59.94 = 2.002), the emulator subtly adjusts the internal emulation speed (audio and video) upward by roughly 0.05% to hit a flat 60.00Hz. This aligns the fields perfectly with a 120Hz refresh grid without perceptible distortion.
+* '''The PAL Asymmetry Issue:''' Running a 50Hz PAL title on a static 120Hz container results in the same severe 2.4x frame-slicing judder as running NTSC on 144Hz. In this scenario, the emulator must actively call a display mode-switch to alter the hardware's EDID profile to a fixed 100Hz environment, or the user must manually adjust their display control panel.
 ==== FRAME Mode (The Flicker Filter) ====
@@ Line 68: / Line 172: @@
 ==== FIELD Mode ====
 Used by titles aiming for a true 60 FPS. These games sacrificed half of their vertical resolution and jittered the rendering pipeline to stay perfectly in sync with the interlaced output fields.
-* '''Emulator Handling:''' These titles absolutely require a deinterlacing solution to look acceptable on progressive screens. While standard shaders often produce subpar results on these titles, high-refresh-rate CRT simulation has proven to be an effective alternative.
+* '''Emulator Handling:''' These titles absolutely require a deinterlacing solution to look acceptable on progressive screens.
 ==== Hardware Masking (SCANMSK) ====
@@ Line 78: / Line 182: @@
 File:Bob_Deinterlace_Example.png|'''Bob Deinterlacing'''<br>Eliminates combing but introduces vertical jitter/shimmer.
 File:Yadif_Deinterlace_Example.png|'''Motion-Adaptive (MAD)'''<br>Modern standard that preserves detail on static objects without shimmer.
+File:ParaLLEl-GS - 1x + CRT sim with High Refresh-Rate Insertion - WE9.webm|'''High Refresh-Rate Insertion'''<br>120Hz capture on 144Hz host display.
 </gallery>
@@ Line 92: / Line 197: @@
 *[[Resolution]]
 *[[Shaders, presets, and filters]]
+*[[Black frame insertion]]
+*[[High dynamic range]]
 [[Category:FAQs]]