A useful test starts with a problem you can repeat
“My game feels rough” is a real complaint, but it is too broad to choose a replacement part. A repeatable test turns it into something you can investigate: a particular game, scene, settings and pattern of interruptions.
Start with a game you already own. Choose a built-in benchmark if it represents the problem, or a short route you can follow again. Record the settings and capture several runs before changing anything.
Those original runs are your baseline, meaning the reference you compare later changes against. You are looking for a difference that repeats, rather than one unusually good or bad run.
These results describe the game tested. They are not GTA VI benchmarks. The PC compatibility guide explains why another game’s results cannot establish a GTA VI FPS figure.
FPS and frame time tell you different parts of the story
FPS means frames per second. It describes how many frames are produced or displayed over a period, depending on the metric. Frame time describes an interval associated with individual frames, usually in milliseconds.
If frames arrive evenly at 60 per second, the interval is about 16.7 ms. At 120 per second it is about 8.3 ms. These are simple mathematical examples, not measurements of a particular game.
| Even rate | Approximate interval |
|---|---|
| 30 frames per second | 33.3 ms |
| 60 frames per second | 16.7 ms |
| 120 frames per second | 8.3 ms |
An average can hide brief delays. Imagine two runs with a similar average FPS. One delivers frames quite steadily; the other repeatedly pauses for much longer intervals and then catches up. They can feel different despite the similar average.
That is why a frame-time graph helps. It shows where the interruptions occur and whether they form a repeatable pattern.
Choose a scene that answers your question
A built-in benchmark is convenient because it repeats a defined workload. But it may not include the scene that causes your complaint. A repeatable in-game route can be more relevant if you keep it consistent.
For example, you might walk from one saved location to another for a fixed minute. Keep the same camera direction and actions as closely as practical. Avoid comparing a quiet indoor scene before the change with a busy street afterwards.
Online sessions can be harder to repeat because players, network conditions and events change. If the game provides a more controlled scene that reproduces the symptom, start there. If not, document the variation rather than pretending the sessions are identical.
Include the workload that matters. If you normally record while playing, keep recording active for the initial test. A separate run without it can then investigate its effect.
Write down the conditions before capturing
Record the game version, graphics driver, Windows version and exact PC parts. The PC specs tutorial helps with the component list.
For settings, note output resolution, quality preset, individual changes, upscaling, frame generation, frame cap and synchronisation. Include the background applications central to the complaint.
A cap can stop the GPU working at full load because it has already reached the requested rate. Upscaling changes the rendering work. Frame generation changes what some frame counters include. Those settings need to stay visible in the comparison.
If a driver or game update arrives between tests, write it down. A changed version can affect the result, so do not attribute every difference to the component you replaced.
Warm up and capture several runs
Run the scene once before the planned captures. Then record repeated runs using the same route and duration. Three runs are a practical starting point for seeing ordinary variation, not a universal statistical guarantee.
The warm-up matters because first-launch work, loading and the system’s thermal state may differ from later play. If your complaint specifically concerns the first launch, test that separately rather than removing it from the question.
Use a longer relevant session when the problem appears only after time has passed. A smooth one-minute test cannot settle a complaint that starts after an hour.
Keep every reasonable run. Do not compare the old setup’s worst result with the new setup’s best one. If unchanged runs vary widely, investigate that variation before using a small improvement to justify a purchase.
Capture with a documented tool
PresentMon is an open-source Windows performance tool with a graphical capture application and a console recorder. Obtain it from the official project releases and use the documentation for the version you install.
In a graphical recorder, choose the intended game process, set a known capture duration or start-and-stop control, and record the same scene. Save the output with names that identify the configuration and run number.
The tool can produce CSV files, which are tables you can open in a spreadsheet. Confirm the file contains the actual game rather than a launcher or unrelated process before interpreting it.
Capture support and available metrics depend on the tool version, graphics path and system. Missing fields are not zero values. If the recorder reports a limitation, keep it with the result.
Optional console example for PresentMon 2.3.1
This example uses the options documented for PresentMon 2.3.1. It is a version-specific example, not a claim that 2.3.1 is the newest release. If you install another version, check its own option and metric names.
Open PowerShell in the folder containing the downloaded recorder. Replace Game.exe with the actual game’s process name. The example assumes the release executable has the filename shown:
New-Item -ItemType Directory -Force C:\PC-tests | Out-Null
.\PresentMon-2.3.1-x64.exe --process_name Game.exe --output_file C:\PC-tests\baseline-01.csv --v1_metrics --delay 5 --timed 60 --terminate_after_timedThe process filter selects the game. The output path gives the file a known location. The command waits five seconds, records for sixty seconds and then exits. Start with the game already running and position yourself for the route before starting the recorder.
The --v1_metrics option requests the older metric set used for the interval example below. Without that option, do not assume your CSV has the same column names.
For repeated tests, change the filename to baseline-02.csv and baseline-03.csv. If the executable name differs, use the actual filename. If no game frames are captured, fix the process selection; an empty file is not evidence of smooth play.
Read the correct interval, in the correct units
First check the Application column. Then identify what your chosen timing field measures. In the requested older metric set, MsBetweenPresents describes the interval between application presentation calls. That is not automatically the same as the time between visible changes on the display.
PresentMon also documents display-related timings and newer metrics. Read their definitions before switching columns. A graph of one measure cannot silently be relabelled as another.
Plot the selected interval against time or frame order. Look for repeated clusters of larger intervals. A single isolated spike may be worth noting, but a recurring pattern gives you a better place to investigate.
A percentile or “1% low” figure can summarise slower portions, but tools can calculate those labels differently. Keep the tool and method consistent. The graph and workload context remain useful alongside the summary.
Connect a spike with what happened in the game
Note where a repeated delay appears. Does it happen when entering the same area, starting recording, loading new material or after a long session? Return to that event and test it again.
A spike shows a delay, not a component diagnosis. CPU work, graphics work, storage, shader preparation, background tasks and other interactions can all matter depending on the game.
Also separate frame delivery from network problems. A character jumping because of connection behaviour and the whole local image pausing can be different symptoms. A new GPU should not be expected to repair every form of lag.
If you collect CPU, GPU or memory metrics alongside the capture, use them as supporting clues. One high percentage or timing number does not prove that a single part is responsible for everything you see.
Change one thing and repeat
Start with an intervention related to the pattern. For example, compare the same route with optional recording off, or lower one relevant graphics setting. Keep the rest of the conditions as close as possible.
For a memory investigation, use the RAM and VRAM guide to keep the resources separate. For a graphics-load check, changing rendering resolution can provide a clue, but not a complete diagnosis by itself.
Record exactly what changed. If you lower image quality and FPS rises, that is a useful tradeoff. It is not proof that hardware became faster without a compromise.
After a hardware replacement, repeat the original settings and scene first. You can explore new settings later, once you know how the same workload changed.
Frame generation and measurement limits
Generated frames and application-rendered frames are different categories. If frame generation is active, record it and use the tool’s supported frame-type information where available. Do not compare a total displayed-frame number with an application-rendered number as though they count the same work.
A higher displayed rate also does not by itself explain responsiveness or every interruption. Keep the base workload and frame-delivery pattern in the record.
PresentMon documents limitations for certain graphics APIs and scheduling arrangements. Some GPU timing measurements can be less precise with particular configurations. Read those limitations before treating a timing field as an exact account of the hardware’s work.
You do not need perfect laboratory conditions to learn something practical. You do need to state what you measured and avoid conclusions the measurement cannot support.
Keep a result card before spending money
Write the game, route, duration, settings, versions and exact change beside the saved captures. Add the range of results and the pattern you observed.
A useful conclusion might be: “The same area shows repeated long intervals in all baseline runs. Reducing this one setting consistently reduces them, with this visible image compromise.” That is a clear result even if it does not yet identify a purchase.
If the next step is new hardware, use the upgrade decision guide to compare the measured benefit with the complete cost and compatibility checks. Your test now gives the purchase something real to improve.
