Skip to content
RetrogamingFix Published Updated 8 min readViews unavailable

Fixing Overscan and Cropped Edges Without Distorting the Original Image

Separate television zoom, frontend viewport, shader masks, core overscan, and intentional border pixels before changing retro-game geometry.

Consumer CRTs commonly hid part of a video signal behind the cabinet bezel. Game developers sometimes left unstable, blank, or decorative pixels in that area, but occasionally placed useful graphics near the edge. Modern emulation can expose or crop those pixels deliberately. A television’s zoom mode can then crop the already cropped image a second time.

Do not repair missing edges by stretching to 16:9. Aspect ratio changes proportions; overscan changes which source pixels are visible. Establish which layer removes the pixels before saving any override.

Step 1: identify cropping, borders, and distortion separately

Use a scene with a border, HUD, or calibration grid. Capture a screenshot from the emulator and photograph the physical screen. If the saved screenshot contains the missing edge but the display does not, the television, monitor, capture device, or operating-system scaling is cropping after rendering.

If the screenshot itself lacks the pixels, inspect the core, frontend viewport, shader, overlay, and content. If the whole image is visible but objects are wide, narrow, or irregular, follow aspect-ratio troubleshooting instead.

Step 2: disable display-side zoom

Select the manufacturer’s 1:1 pixel or no-overscan mode-often named Just Scan, Screen Fit, Full Pixel, Dot by Dot, or similar. Names vary, so consult the exact display manual. Disable picture zoom and accessibility magnification. On a capture chain, inspect the receiver and capture-card scaling too.

Some televisions remember sizing separately for each HDMI input, resolution, and refresh rate. Verify the mode while the emulator is actually outputting its normal signal, not only on the desktop.

Avoid changing undocumented service-menu geometry. Service menus can affect every input and may expose settings intended for technicians; normal picture-size controls are the safe diagnostic surface.

Step 3: create a plain frontend baseline

Temporarily disable bezels, overlays, custom viewports, video filters, and shader presets. Set RetroArch’s aspect ratio to Core Provided. Test integer scaling both off and on, but understand the result: integer scaling can create unused border space because the source does not divide evenly into the output. That is not cropping.

Settings → Video → Scaling → Aspect Ratio → Core Provided
Settings → Video → Scaling → Integer Scale

Reset custom X/Y/width/height only after recording them. Do not delete the full configuration; per-game and per-core overrides may contain unrelated working settings.

Step 4: inspect the core’s overscan option

Open Quick Menu → Core Options and read the official page for the exact core. Snes9x documents Crop Overscan as removing output that a standard-definition television bezel might hide. Mesen-S exposes separate vertical and horizontal overscan controls and explains that most SNES games use 224 lines while some use 239.

Set crop to off or zero to see the maximum core output, restart content if required, and compare screenshots. Then choose automatic or a measured crop if exposed border noise is undesirable. Do not copy an eight-pixel value from one core into another: option units and source geometry differ.

Step 5: verify region and resolution changes

PAL and NTSC content can use different timings and visible line counts. Some games switch resolution between gameplay, menus, and high-resolution text screens. Test all of those states before defining a custom viewport.

An apparent black border may be generated by the game itself and therefore be part of the emulated frame. Cropping it globally can remove real graphics in another title. Keep a core-wide default conservative and use a per-content override only with evidence.

Step 6: restore shaders and bezels one layer at a time

CRT shaders can include masks, curvature, integer-scale requirements, or explicit viewport assumptions. Bezel presets reserve a window for content; an incorrect preset resolution can cover edges without altering the underlying frame.

Restore the shader alone and compare, then the overlay alone, then the combined preset. Use assets from RetroArch’s supported updater or the shader project’s official repository. Avoid opaque configuration packs that overwrite directories or execute installers.

If a preset crops, inspect its documented parameters rather than expanding the content aspect ratio until it fits. The latter produces a visually full opening at the cost of geometric accuracy.

Step 7: account for MAME’s artwork and aspect options

MAME distinguishes aspect preservation, artwork, integer scaling, and view selection. Its keepaspect option preserves the correct aspect ratio, while disabling it can distort the image to fill an unmatched window. MAME views may intentionally include cabinet artwork or screen masks.

Select a screen-only view for diagnosis and leave aspect preservation enabled. A multi-screen arcade machine can have a layout that is not reducible to one generic 4:3 crop; use the machine’s defined view rather than a console preset.

Step 8: measure and save the narrowest override

After the host display and plain core output are correct, count the actual pixels or lines hidden on each edge. Verify a second game, a menu, gameplay, and any resolution switch. Save a content override for a title-specific exception or a core override only when the hardware family justifies it.

Record display model and picture mode, output resolution/refresh, frontend/core versions, region, crop values, aspect mode, integer scaling, shader, overlay, and viewport. This makes the result reproducible after updates.

The correct outcome may include visible noise at edges or black space around the image. Those are honest source or scaling artifacts. A fully filled panel is not proof of correctness, and stretching is never a substitute for identifying who performed the crop.

Measure the source before choosing how much to hide

Use at least two kinds of evidence: a clean emulator screenshot and an edge-bearing test scene. A screenshot can show the exact frame the core produced, but it does not show what the television later cropped. A photo of the physical panel can reveal display-side zoom, though camera framing and perspective make it a poor pixel ruler. If your core can dump a raw frame, record its dimensions and inspect the first and last rows and columns for game graphics, blank color, or unstable garbage. Keep the untouched capture so later changes can be compared against the same source.

Do not assume overscan has a symmetric number of pixels on all four sides. Some systems expose additional vertical lines in one video mode, some games deliberately place critical UI near an edge, and some capture or scaling pipelines trim only one axis. Measure the left, right, top, and bottom independently. A crop should be described in the units the setting actually uses: source pixels, lines, percentages, or a core-specific preset. “Crop eight” is not portable unless the core documentation defines what the number means.

Separate the visible game frame from console border artifacts. An edge can contain legitimate status indicators, game artwork, timing-sensitive effects, or a color region produced by the video hardware. Conversely, a game may draw a uniform border inside its nominal frame, so the emulator cannot infer that it is disposable television overscan. If the border changes between scenes or carries text, do not hide it with a global crop. Prefer an option that is named and documented by the core over an undocumented viewport adjustment.

Validate the complete output path

The video path can be represented as source frame, core crop/geometry, frontend viewport, shader or overlay, operating-system compositor, display input scaling, and finally the panel’s physical image. Diagnose from the earliest layer at which pixels disappear. If the raw core capture contains the edge but the frontend screenshot does not, investigate viewport or shader behavior. If both software captures preserve it but the panel loses it, check display zoom or the capture chain. This avoids compensating in the emulator for a television setting that will then make every other application too small.

After changing one layer, compare the same saved frame or deterministic scene before and after. Check not just whether the HUD is visible but whether its shape, spacing, and source aspect are unchanged. Restore a bezel or CRT preset only after confirming its window geometry matches the output resolution. A mask may intentionally cover the extreme edge to evoke a CRT, while a crop changes the usable source image; those can look similar on a still image but have different preservation consequences.

Keep overrides narrow and reversible. A title-specific scene with a documented edge case calls for a content override, not a global crop applied to an entire platform. A core-level setting is appropriate only when evidence shows the same behavior across that hardware family and its core option documentation supports it. Save a text record of old and new values, the core and frontend versions, system region, source dimensions, display mode, and test screenshot filenames. After updating the emulator, rerun the test because core defaults and option labels can change.

Acceptance means the important image area is visible without changing the proportions, and that the result survives a restart with the intended per-content or per-core configuration. It does not require eliminating every black border or noisy edge. Preserve a conservative baseline and make any aesthetic crop explicit, so a later researcher can distinguish a historical display approximation from a technical correction.

Related:

Sources:

Comments