The hitch you feel

A friend of ours plays on a 4090. Two hundred frames a second, a 240 Hz panel, everything the internet says you need. And every so often, in the middle of a fight, the game hitches. Not a crash, not a drop to zero, just a stumble long enough to lose the duel.

He checked his framerate counter. It said 200.

That is the whole problem in one number. Average framerate is the metric everybody quotes, and it is close to useless for the thing people actually complain about. A game can average 200 frames per second and still deliver one frame that takes 80 milliseconds. Your eyes catch that frame. Your aim catches it. The counter never mentions it, because 199 fast frames and one slow one still average out beautifully.

Vera now measures the thing you feel instead.

What gets measured

Frame pacing, not framerate. For each session with a game we recognize, the collector records how long each frame actually took and then keeps the shape of that distribution:

• average FPS, because it is still the number you know
• 1% low and 0.1% low, the average of your worst frames, which is where stutter lives
• frametime at the 50th, 95th, and 99th percentile, in milliseconds
• a hitch count, frames that took longer than 50 milliseconds

The percentiles are the useful part. A 144 Hz monitor asks for a frame every 6.9 milliseconds. If your median frame arrives in 6.9 and your 99th percentile arrives in 53, you do not have a horsepower problem. You have a pacing problem, and those have different fixes.

How it works, and what it does not touch

Capture runs through Event Tracing for Windows, the timing facility Windows already keeps for itself, using Intel's open-source PresentMon. Nothing is injected into the game. No game memory is read. Vera watches the timestamps the operating system already writes down when a frame is handed to the display, and does arithmetic on them.

That distinction is the entire design. Tools that hook into a game process to count frames have to look, to an anti-cheat, a lot like the things it exists to stop. Plenty of them are honest and widely used, and we would still rather not ask a player to make that argument on our behalf. Reading the OS's own event stream is a different act. It works from outside, it is what the benchmarking press already builds on, and it asks nothing of your game.

A session of Fortnite with Easy Anti-Cheat running captured cleanly, start to finish, twice, on a machine in our own house. That is one title on one machine, which is exactly as much as we will claim.

The frame-by-frame stream never leaves your PC. It is reduced to about a dozen numbers on your machine and the rest is discarded. What uploads is the summary.

What it costs you

A performance feature that will not state its own cost has no business measuring anyone else's. So we measured ours.

On a Ryzen 5 5600X with an RTX 3060, capturing a live Fortnite session:

• PresentMon used 0.27% of one CPU core and 12.8 MB of memory at peak while capturing
• the session summary was 429 bytes of a 426 KB upload, roughly one tenth of one percent
• nothing new runs when you are not in a game, because capture only starts when a game we recognize is running

For scale, the heaviest thing the collector does is something it already did before this feature existed: fingerprinting the several hundred drivers loaded on your machine, every five minutes, which accounted for about 300 KB of that same upload. Frame pacing is a rounding error next to the work that was already happening.

What we did not measure: the collector's own share of the work. Parsing the capture and aggregating it happens inside the collector service, not inside PresentMon, so that part is not in the 0.27%. The service was busier during the game, but the same stretch had it enumerating a longer process list and taking a driver snapshot, so that increase is not the sampler's to claim and we are not going to claim it.

Also not measured: a controlled A/B test of your framerate with capture on and off. Industry tools built on the same capture path treat the overhead as negligible, and our numbers agree, but we have not run that experiment ourselves and we are not going to imply we have.

The version we refused to build

Frame data makes an obvious accusation possible: a monster rig delivering weak frames means something invisible is eating the machine, and that something might be a cheat. It is the first idea everyone has, including us. We are not building it.

Ordinary explanations dominate. The fix order this work produced has six entries and not one of them is a cheat: frames not paced against the panel, monitors at mixed refresh rates, a monitor routed through the wrong GPU, a driver holding the CPU, background contention, and shader compilation last. A flag on "strong rig, weak frames" would accuse a hundred honest players to maybe catch one dishonest one, and false accusation is the specific harm Vera exists to prevent.

The cheats that matter leave no trace here anyway. A serious setup reads game memory from a second computer and feeds inputs through hardware. The gaming PC does almost no extra work. Frames stay clean by design. A frame-based detector would wave through exactly the people it claims to catch, while handing everyone else a false sense of safety. And anyone streaming is dropping frames to their encoder all night, which would put our own creators at the top of the suspicion list for the crime of going live.

So as a detector it is cruel to the innocent and blind to the guilty. As help, it is genuinely useful. We built the useful one.

Your frame numbers are a record of how your machine ran. They are not a claim about how you played, and Vera will not turn them into one.

What you will see

If you have the collector installed and you play a game Vera recognizes, a Performance card appears on that session once a measurement lands, showing the numbers above and a small chart of where your frames landed against your monitor's refresh budget and, when your frames get near it, the 50 millisecond hitch line. The shape is the point: you can see the spread between a typical frame and a bad one without reading a single digit.

Those numbers sit on the session like the rest of your record, public the way the rest of it is.

One part is yours alone. When we have a published benchmark for your graphics card, at your resolution, in that game, the card adds a plain-English read of how your session compares, and links to the fix order. That comparison shows only to you. Help belongs to the player, not to whoever is scrolling their profile.

If we have no sourced benchmark for your combination, you get your numbers and no comparison. We would rather show you nothing than invent a baseline.

What it still cannot see

• Your G-Sync, V-Sync, and frame cap settings. Not captured. The first fix on our checklist is worth doing regardless.
• Driver version numbers. The record has names, paths, and signatures, not versions.
• Shader compilation. That happens inside the game.
• The difference between playing and loading. A session that was mostly a loading screen produces honest numbers about a loading screen. We know this one is a real gap, and we would rather name it than let you read a loading stall as a verdict on your hardware.

Anti-cheat systems can also block event tracing. If that happens, the capture ends with nothing rather than something invented, and the card simply does not appear.

Where to start

If your frames look worse than your hardware should allow, or they look fine and the game still stumbles, the fix order is the place to begin. Six checks, most likely first, each with the actual setting to change: High-FPS hitching, in fix order.

The first one takes two minutes and fixes it more often than anything else on the list.