The problem with "Frames Per Second" is that it implies an evenness that isn't necessarily there. A pitchers fastball will essentially have the same velocity from the moment it leaves his hand to the moment it ends up in the catcher's mitt, with little deceleration in the forward direction. A car moving at 50 mph will travel 50 miles in an hour, and if that is his average speed, he will travel 50 miles in an hour even with short periods of acceleration and braking. A monitor at 60 Hz will refresh every pixel 60 times in a second.
But 60 FPS on a 60 Hz monitor does not
mean that the animation is smooth. Having an instance of a certain FPS is meaningless because, as PC Perspective is exploring with the idea of "runt" frames, those frames might only be displayed as a sliver on the screen, causing massive tearing in the image. Or, the screen might appear "stuck" on a certain image because the next frame hasn't been rendered. This is not represented by FPS measurements.
And as I said before, this is a discrete time system, which means we have a finite number of snapshots (frames). A fastball, a car's speed, and the air speed velocity of a swallow is a continuous time system, which means that the speeds won't change in an instant. Speeding up and slowing down is always smooth unless they run into something (and having something with high velocity suddenly stop results in massive damage). Since computers are discrete time systems, "frame rates" CAN change from frame to frame, and the metrics Tech Report and others are working on are trying to analyze THAT. Using terminology that implies evenness that is not necessarily there confuses the issue more than forcing gamers to learn about time sensitive metrics.
Meadows wrote:Superjawes also had an idea about a "smoothness rating" formula, that sounds like something TR might look into.
There are some people looking into it. When I first saw PC Perspective's stuff showing the results on screen, I thought it was beyond excellent. There are two problems with coming up with this rating, however.
1. Although PC Perspective is doing great work showing the problem, it's very hard to turn that into a usable metric. Sure, you can SEE the problems, but unless you want to show video for every card and every game, that doesn't quite quantify what we want to see.
2. That work doesn't necessarily identify where the problem is. Scott's work with Fraps and timestamps definitely shows some of the variance in smoothness on the back end, but as PCP pointed out, other processing might go into the image after Fraps stamps it, and that might vary by game engine. On the other foot, PCP can measure the images at the monitor, but that doesn't identify where the hiccup happened. It might have happened before Fraps would have stamped the image, but it could also have happened between stamping and displaying. You need to identify where the problem occurred to fix it.
So yeah...like I said, we've got more work to do, but we're still way ahead of where we were a couple years ago, and I am much happier moving forward with better metrics than trying to explain them in terms of old ones.
"A life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP"
-RIP Leonard Nimoy