Scaling: Difference between revisions
From latest Wayback Machine snapshot |
No edit summary |
||
| Line 11: | Line 11: | ||
==CRT monitor== | ==CRT monitor== | ||
Because not all systems use the same resolution, if you want them to be native resolution on your CRT Monitor you either have to make a different custom resolution for each game, or you can make one resolution that has a really high horizontal res, scale games to fit that resolution, and send that to your CRT which gets squished to 4:3. The latter is the better option since you don't have to change resolutions for every game you play, and bonus points if the horizontal res is an integer scale of several common console resolutions (3840 is a common multiple of 240, 256, and 384). | Because not all systems use the same resolution, if you want them to be native resolution on your CRT Monitor you either have to make a different custom resolution for each game, or you can make one resolution that has a really high horizontal res, scale games to fit that resolution, and send that to your CRT which gets squished to 4:3. The latter is the better option since you don't have to change resolutions for every game you play, and bonus points if the horizontal res is an integer scale of several common console resolutions (3840 is a common multiple of 240, 256, and 384). | ||
=Framebuffer Scaling & Output Methods= | |||
While [[Texture filtering|Texture Filtering]] happens inside the 3D engine and [[#Smoothing Shaders|Smoothing Shaders]] are stylistic choices used to "redraw" the art, Framebuffer Scaling refers to the final step of displaying the game on your monitor.This is the process of taking the emulator's rendered frame (e.g., a 240p or 720p image) and stretching it to fit your 1080p or 4K host display screen. Unlike artistic shaders (like xBRZ), these methods aim for mathematical accuracy or shimmer reduction rather than changing the art style. While many of these methods are implemented via Post-Processing Shaders for better control, they are not always "shaders" in the traditional sense; they can be built-in functions of the emulator or the hardware's display scaler. | |||
*Shader-based Scaling: Uses the GPU to perform complex math (like Spline36 or Lanczos) to ensure the image stays sharp and artifact-free. | |||
*Driver/Hardware Scaling: The "basic" scaling performed by your GPU driver or monitor. Usually defaults to a simple Bilinear or Nearest Neighbor stretch, which can result in blur or "pixel shimmer" if not configured correctly. | |||
*Software-Level Scaling: Built-in options provided by emulators (e.g., PCSX2's "Sharp Bilinear" or "Smooth Bilinear" toggles). These are hardcoded into the emulator's video output code to provide a better result than the raw GPU driver without requiring the user to manually load external shader files. | |||
{| class="wikitable" style="text-align:center;" | |||
! scope="col"|Filtering type | |||
! scope="col"|What it does | |||
! scope="col"|Pros | |||
! scope="col"|Cons | |||
|- | |||
|'''Nearest neighbor''' | |||
|This scaling method assigns each output pixel the color of the single closest pixel in the original image (no averaging or blending). When enlarging an image, each source pixel is effectively “copied” into a block of identical pixels (e.g., 2× scaling turns 1 pixel into a 2×2 block). This preserves hard edges and a crisp, blocky appearance. | |||
| | |||
* Fastest and computationally cheapest (minimal GPU cost). | |||
* Preserves sharp pixel-art style with practically no blur or smoothing when using with integer scaling. | |||
| | |||
* If the output is not a perfect multiple (e.g., integer scaling 240p to 1080p), and instead using non-integer scaling: it causes uneven pixel sizes, leading to distortion, shimmer, or wobble artifacts during movement. | |||
* Text and fine details can look distorted or "warped" on modern displays if the scaling isn't perfectly aligned. | |||
* To avoid distortion, users often must use "Integer Scaling", which usually results in black bars on the top/bottom or sides of the screen on modern displays. | |||
|- | |||
|'''Bilinear''' (Smooth) | |||
|This linear filtering method uses color data from the pixels in a nearest-neighbor texture, and combines multiple bits of color data in order to replace some of the pixels with an averaged-out version of the colors, so that the colors gradually switch rather than jump to a new color. | |||
| | |||
*Looks better than nearest neighbor for 3D games. | |||
*Fast and computationally cheap form of scaling. | |||
| | |||
*At low resolutions, 2D games tend to become very blurry. This is especially noticeable in 2D games, and low res 3D games. | |||
*If you have the hardware to do so, look into more complex filtering methods to preserve clarity. | |||
|- | |||
|'''Bilinear''' (Sharp)<br />(Bilinear with Prescale) | |||
|A technique that first scales the image using Nearest Neighbor to the largest possible integer size, then uses Bilinear filtering for the final "small" stretch to fill the screen. | |||
| | |||
*Eliminated "pixel shimmer" or "wobble" during scrolling. | |||
*Keeps pixels looking sharp and square while filling the entire screen (even at non-integer scales). | |||
| | |||
*Requires a shader or specific support from emulator (like RetroArch or PCSX2). | |||
*Technically a tiny bit of blur on the very edges of pixels compared to pure Nearest Neighbor. | |||
|- | |||
|'''Spline36''' | |||
|A high-order mathematical interpolation method used primarily in video playback (like mpv) and advanced shader packs. Unlike Bilinear, which only looks at the immediate surrounding pixels, Spline36 uses a larger 6x6 grid of pixels to calculate new color values. | |||
| | |||
*Sharper than Bilinear. | |||
*Computationally efficient on modern hardware. | |||
| | |||
*Rarely a built-in option[https://github.com/hrydgard/ppsspp/pull/21527]; usually requires loading a specific .slang or .glsl shader. | |||
*Can occasionally produce "ringing" artifacts (faint halos around high-contrast edges). | |||
|} | |||
[[Category:FAQs]] | [[Category:FAQs]] | ||