The source-resolution hunt

We began with a reasonable question: “If a game really renders at 320×240 or 480×270, where is that information in the pipeline?” Some paths exposed a smaller raster and an exact mapping to the screen. Others never stored a complete image at the artwork's logical resolution.

Looking for a source raster

Older games often have a clear logical resolution, with pixels, camera and artwork sharing a recognizable scale. CRT rows and LCD cells need meaningful geometry too. Surely the GPU must know the raster behind that picture, even when the window is much larger?

Several different facts can look like “the resolution”:

Evidence	What it tells us	What remains unproven
Texture or resource size	The storage dimensions of an image	Whether it contains the scene, an auxiliary effect, or a padded region
Viewport	Where a draw maps into its destination	The image's original raster or the meaning of its coordinates
Coordinate system	The units used to position or transform geometry	Whether an image with those dimensions exists
Presented image	The color values supplied for the current presentation	A unique history of how those values were produced
Source-authoritative raster	An actual image with an established contribution and mapping into the presentation	That its storage size equals the artwork's authored grid

A swapchain gives us the presentation surface's dimensions. A small render target might be more useful, but it could just as easily hold lighting or a minimap. Why pixel grids matter introduces these domains.

Following the image backward

Beamline investigated the ancestry of the exact image being presented: render-target production, copies, blits, resolves and sampled fullscreen draws. A plausible chain looks like this:

low-resolution scene target
    -> a draw that samples that target
    -> output-sized backbuffer
    -> presentation

We had to verify every arrow. Was the bound texture actually sampled? Did the triangles cover the fullscreen viewport? Even a three- or four-vertex draw could cover something else. Finding a resource told us little until we could connect its contents to this presentation.

We inspected sampler use, vertex/index geometry, viewport and scissor coverage, coordinate transforms, resource generations and execution order. On programmable paths, we traced constant-buffer and vertex-buffer copies to the values available at the draw. A familiar number was only a clue; we needed a causal connection.

Arrows mark relationships to investigate, not a required rendering order.

Resource domains and coordinate domains

A presentation-causal resource domain is an actual image whose contribution to the presented scene can be traced. A stable low-resolution scene target, with an exact mapping into the output, can provide substantially stronger facts than final-image repetition alone.

A coordinate domain can exist without that image. Sprites might be positioned on a logical grid, transformed into output coordinates and rasterized directly into the backbuffer. An orthographic projection or affine transform may reveal the domain, but only if its meaning and full-scene contribution can be established. A matrix containing a suggestive scale is not enough.

A coordinate grid can help align a treatment pattern. Source reconstruction also needs an image to sample.

Three investigation outcomes

One preserved OpenGL investigation of Gravity Circuit did expose a stable 400×240 composition resource. The observed presentation draw sampled the current color target, and its geometry, transform and sampler use could be connected to the visible scene. Changing between the investigated windowed and letterboxed presentations changed the destination mapping, not the upstream dimensions. This is the case resource tracing is good at.

A preserved D3D9 investigation of Celeste came close. Gameplay exposed a 320×180 render target, bound for a full-frame indexed presentation draw with the expected geometry and texture coordinates. But the prototype's state queries could not prove which sampler the pixel shader consumed. We had a strong candidate with one causal link still missing. Earlier splash/menu observations also used different resource dimensions: even within one launch, “the resolution” was not one timeless number.

An investigation of Enter the Gungeon reached a different limit. It traced a padded 482×272 resource into a final presentation draw, but the draw used generic unit-quad and clip-space coordinates. Those values did not independently encode the hypothesized 480×270 logical domain inside the storage. Knowing the resource and knowing its destination still did not recover the semantic crop or grid.

These are historical investigations of specific modes, versions and backends.

Why a universal answer breaks down

Bloom, lighting and shadow resources are often smaller than the scene. A minimap may have immaculate pixel alignment while occupying only one corner. High-resolution UI may be composited over a low-resolution world. Post-processing can combine several domains; dynamic resolution can change a scene surface for performance without changing the artwork's logical coordinates.

UI and gameplay can use different spaces. A camera transform may describe the world while a menu uses output coordinates. Both can render correctly into one frame without sharing a global grid.

A final render target stores colors without recording how they were made. Different draws and transforms can produce the same result. Coordinates may have been transformed before reaching the graphics API, leaving no identifiable reference resolution in the state we observe.

Scaling, stretching, cropping and post-processing complicate the reverse problem further. Exact mappings sometimes preserve useful relationships. Filtering and mixed composition can obscure or erase them. More inspection can fill gaps in our observations, but it cannot recover meaning that was never represented at that boundary.

Known Grid records

Early Beamline kept Known Grid metadata to spare players the work of researching a resolution and entering Width and Height. Records described particular builds, graphics paths and tested presentation modes.

Even accurate base dimensions could not account for stretching, letterboxing, cropping, mods or high-resolution UI. The artwork’s grid might stay the same while its displayed spacing and alignment changed. Known Grid now serves as regression and reference material; runtime detection measures the live picture independently.

What Beamline measures now

We moved from “What was the developer's original resolution?” to “What geometry does the current frame actually prove?”

Pixel Grid Detection measures repetition and alignment across a short sequence. It can also use spacing with a chosen anchor when the regions disagree about phase.

That geometry sets treatment spacing. Source reconstruction still needs an image and a proven mapping.

Virtual Raster offers another route: Beamline creates synthetic cell colors and samples the raster it made.