Build a game settings test plan that produces useful answers
Compare graphics settings through repeated A/B captures instead of copying an unexplained optimisation list.
Choose a target and a repeatable scene, record the original configuration, then compare one setting at a time. Retain both performance evidence and image-quality observations. Restore the baseline between experiments to check whether an apparent improvement survives repetition.
Open the related tools →Choose a useful target
Decide what you are trying to improve: steadier frame delivery, a particular frame-rate target, clearer visibility, lower measured PC latency or quieter operation. These goals can conflict, so do not hide the trade-off behind a single best-settings label. Describe the scene that currently fails your goal. A busy competitive encounter and a quiet cinematic area are different workloads. Select a practical test route that represents your problem and can be repeated without relying on a lucky online match.
Save the original configuration
Record the game version, driver version, hardware, resolution and render scale. Capture the relevant settings pages and note frame caps, synchronisation, upscaling and frame-generation modes. Save an in-game profile if supported. Do not edit undocumented configuration files just to make the experiment look more advanced. The purpose of this record is to return to a known state and let someone else understand the comparison. If a patch changes the menus or renderer, treat the previous plan as a reference to recheck.
Make a small experiment matrix
Choose one setting with a plausible relationship to the symptom. Label the original configuration A and the alternative B. Keep every other condition as similar as practical. Run several A captures, several B captures and then another A capture. This final return helps reveal whether time or background conditions changed the outcome. Record exceptions, such as a new loading event or an accidentally different route, before looking at the result. Exclude a run only for a stated reason that would apply to either configuration.
- Define the scene and capture duration.
- Change one setting and label the configuration.
- Repeat both configurations and return to the baseline.
Record performance and the visual cost
Use a trusted measurement tool and retain its capture files. Average FPS alone cannot describe every interruption, so inspect frame delivery as well. Add a short visual note about aliasing, fine detail, motion clarity or visibility at the tested setting. Do not claim a latency improvement from FPS arithmetic alone. When a metric is unavailable, say so. Vendor features and measurement tools can have hardware or game support requirements, and their reported quantities should be interpreted using the relevant documentation.
Keep only conclusions the evidence supports
If repeated runs overlap heavily, mark the experiment inconclusive rather than rounding it into a dramatic win. If B consistently achieves your target with an acceptable visual trade-off, keep the profile and its restoration notes. Test stability during ordinary play before calling the setup finished. A successful result belongs to the documented game build, scene and system; it is not proof of the best configuration for everyone. Revisit the plan after major game, driver or hardware changes and preserve the earlier results for comparison.
Common questions
Should I change every setting at once?
That can compare two complete presets, but it cannot tell you which individual setting caused a difference. Use one-variable tests when you want an explanation.
Can I publish my results?
Yes, with the exact workload, versions, settings, metric definitions, repeated runs and limitations. Do not present them as independent lab certification.
How often should I retest?
Retest after a meaningful change to the game, driver, hardware or symptom. Do not update a tested date without doing the corresponding work.
Verify with the official sources
NVIDIA FrameView benchmark capture ↗
AMD: per-game performance tuning and configuration differences ↗
Educational workflows, not a claim of hands-on testing across every device. Retest after a game, browser, driver or network change. Editorial policy →