Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Worth flagging the web export case, because it quietly breaks the assumption underneath the tool and nobody has said it outright yet. I ship a browser game rather than Unity, so take this as the web angle rather than a Unity answer.

In a browser there is no single thing called resolution. There are three numbers, and the bugs live in the gaps between them: the CSS size of the canvas element, the size of its drawing buffer, and devicePixelRatio, which multiplies one into the other. A downloadable game has one resolution. A web build has a CSS size times a DPR that the user can change underneath you. Browser zoom changes it. OS display scaling changes it. So you never get 1280x800, you get 1280x800 at 1, at 1.25, at 1.5, at 2, and at whatever fraction a Windows laptop happens to be set to.

That matters for your matrix specifically. Replaying a flow across a list of resolutions varies the axis that produces layout bugs, and those are the cheap ones, the ones a screenshot diff was always going to catch. The axis that produces the expensive ones is DPR at a fixed resolution. 1280x800 at DPR 1 and 1280x800 at DPR 2 are the same layout and four times the pixels, so what breaks is not the layout at all, it is memory and frame time. In a tab that is not a slowdown either, it is the tab getting killed, because there is no swap to page out to the way a native client has.

Which is why we clamp devicePixelRatio rather than honouring whatever the display reports. Uncapped on a high-DPI screen it is the easiest way there is to quadruple your buffer for no visible gain.

The other failure a same-DPR screenshot diff cannot see is the CSS size and the buffer size disagreeing. Nothing errors, the canvas is just soft, and it reads as an art problem rather than a code one 🔎

So the question I would actually put to you: does the recorder capture devicePixelRatio as part of the recorded environment, or only the pixel dimensions? If DPR is a first class axis sitting alongside resolution, this is useful to anyone shipping a web build. If it is not, it will find the cheap bugs and miss the ones that cost a weekend.

Good catch — DPR/display scaling isn't a first-class axis in what we record today.

Right now, Record captures the in-game screen size/resolution, and Replay tests different pixel resolutions by driving the RenderTexture directly (1280x800, 1920x1080, 1920x1200, 3440x1440, etc.).

What we don't currently capture or replay is Windows display scaling (125%/150%) or a DPR-equivalent value as part of the environment. So while we can compare behavior across different pixel resolutions, a same-resolution/different-scale issue is a real gap today, as you said.

I like your framing of Resolution and Display Scale as two separate test axes rather than grouping everything under "DPI issues." A matrix like 1920x1080 @ 100% / 125% / 150% makes sense as an orthogonal dimension on top of the resolution testing we already do.

Since GameCheck is Unity/native-first, the mechanics are different from the browser case you described, but the core point absolutely carries over: resolution and scale can produce different classes of failures and should probably be tested separately.

Adding this to the roadmap as a gap worth solving, not just a nice-to-have. Appreciate the detailed breakdown — genuinely useful way to think about it.