QORPOUnreal performance comparisons: record the render resolution
Before comparing two Unreal performance captures, record both the output resolution and the render resolution. A dynamic-resolution system can change the amount of work behind the same display size. Match the conditions for a controlled comparison, then review the intended adaptive behaviour separately. Otherwise, a faster frame may also be a different image.
The display size is only one part of the picture
Two captures can both be presented at the same output size while their internal rendering conditions differ. That matters when a team is deciding whether a material, effect or scene change actually reduced cost. A visible image and a frame-time number need enough context to be interpreted together.
Epic's documentation describes dynamic resolution as adjusting primary screen percentage in response to recent GPU workload. Its purpose is adaptive performance, so a change in rendering resolution can be expected behaviour. The review problem is treating an adaptive result as if every condition had stayed fixed.
This is a proposed development workflow rather than a measured result for a QORPO game. Our studio live page shows ongoing work; a specific performance claim still needs evidence from the relevant build and hardware.
Decide which question you are answering
There are two useful questions. First: how do two versions compare under matching rendering conditions? Second: how does the intended adaptive configuration behave during play? Both deserve attention, but they should have separate records.
For the controlled question, choose a repeatable location and action. Record output dimensions, camera, relevant render settings, build, hardware and whether dynamic resolution is active. Decide what you will hold steady before capturing the comparison. Avoid changing the scene and several quality settings at once.
For the adaptive question, use the configuration players are meant to receive. Observe the transition into a demanding moment and the return from it. The purpose is to understand how the experience changes over time, including image stability and responsiveness, rather than merely finding a pleasing still frame.
An original comparison exercise
Consider an invented scene with an island path, a camp and a burst of particles near a doorway. A team wants to review a revised particle effect. Both recordings use the same output size, but the adaptive system lowers the internal resolution during one of them.
The team should not immediately credit the particle revision for the entire timing difference. First it needs a comparison under matched conditions. It should also keep the adaptive recording, because that recording may reveal an important player-visible transition. The two captures answer related questions without becoming interchangeable evidence.
Write the observation plainly: which version, which action, which rendering state and which time window? If the available capture does not expose the effective render state, mark that gap. A precise limitation is better than a confident percentage drawn from an uncontrolled comparison.
Inspect the transition, not just the endpoint
An adaptive result may look acceptable when the camera stops. The important visual issue might occur as an effect enters the frame or the camera turns. Include those moments in the review and use the same route when comparing versions.
Choose a few visible features to watch: thin silhouettes, a sign at a distance, foliage edges or a moving character against the sky. This is an editorial checklist, not a claim that those features will fail. It gives the reviewer something specific to observe while the render state changes.
If the team is also judging lighting, keep that question distinct. Our exposure comparison guide covers matching exposure before judging light. Adding uncontrolled exposure changes to uncontrolled resolution changes makes the result harder to explain.
Record effective state alongside timing
Epic's dynamic-resolution guide identifies Stat Unit and its DynRes information as tools for inspecting the active state, with graph views for timing and screen-percentage changes. Availability and useful output depend on the build and platform, so use the tools your actual configuration exposes.
Do not infer an active setting from a menu label alone. Record what the capture establishes and keep a screenshot or trace that connects the rendering state with the reviewed interval. If a shipping build does not expose development tools, collect the evidence from an appropriate authorised development build rather than claiming an unavailable check passed.
Our existing effective-settings guide considers a broader settings problem. The narrow concern here is whether a render workload changed behind an apparently unchanged output image.
What belongs in a useful result?
A useful comparison identifies the two builds, the repeated action, the fixed conditions and the adaptive conditions. It states which observation concerns cost and which concerns image behaviour. It also records anything that changed between captures, including a different scene state or a different target configuration.
Avoid turning one result into a general promise for every PC. A controlled local comparison can support a local conclusion. A player-facing performance statement needs the hardware, settings and workload that make its scope understandable.
If the result remains unclear, choose the next check from the missing evidence. You may need a repeat at a known render state or a longer adaptive capture. Repeating everything without a question creates more files rather than a clearer answer.
Keep the review connected to play
The point of profiling is to improve the experience during actual actions. After a controlled comparison, return to the intended configuration and repeat the path as a player would. Check whether the improvement remains useful when the game is moving, not only when the scene is arranged for inspection.
Explore QORPO's games for the product context and the studio for ongoing development. This method offers a way to make a performance discussion more precise; it does not announce a new engine feature or a tested optimisation in a particular game.
Primary source: Epic Games, Dynamic Resolution, checked 5 November 2026. The particle scene and review plan are original editorial examples; no benchmark was run for this article.