Experimental Zen 3 Support
New Sensor IDs have been added to ensure the sensor values for Zen 3 CPUs are working as intended. As we don't have any official info from AMD this is highly experimental and needs to be confirmed once the CPUs are out. If there are problems with sensors, a new version will follow soon after the official release.
Decimal values for capture time and more precise capture length
We've included the possibility to use decimal numbers as capture time for those who need a benchmark to stop at a very exact time.
You already could type in decimal numbers before, but when trying to start a capture this resulted in an app crash.
While we were at it, we also adjusted the creation of the capture file to get more precise times.
By normalizing the frametimes to have the first frame start at 0s, the actual time value for all frames is lowered by the value of the first frametime so often there was enough time left for an additional frame at the end.
This resulted in many "x.98s" or "x.99s" values even if the next frametime was low enough to fit.
Now we take the time we gained by setting the first frame to 0s and use it to potentially get another frame in, the sequence lenght at which we cut before normalizing the times is therefor now "capture time + first frametime"
Here's an example of set capture times from 1s to 10s. As you can see, even when using decimal values it's often precice enough to get to the exact time.
"Low FPS" value added to the stuttering pie chart
While the stuttering time is a good indicator for frametimes that are way above the average, you can now also set a specific FPS value that you consider too low to be smooth.
Every frame that is not already considered as stuttering but is still lower than this FPS value gets added to the new low FPS time.
Of course this value will be 0 when all low framerates are so low that they are all considered as stuttering, otherwise the same times would be counted twice.
Here's an example for which I played around with a frame limiter to get some low FPS values(default threshold is 25FPS) and also some stuttering values.
In this case, the total amount of time under 25FPS is represented by the sum of "Low FPS" and "Stuttering" but keep in mind that this may not always be the case, as "Stuttering" is related to the average FPS while "Low FPS" is a fixed point, so with very high framerates a frame can be considered stuttering even without going below that 25FPS.
Also keep in mind, that for these values every single frametime is analyzed individually, so if you'd set a limiter to 60fps and also set the "Low FPS" threshold to 60fps, you can expect the chart to show ~50% of "Low FPS" time because the frametimes are always fluctuating above and below 16.66ms and every frametime of 16.661 or higher will be counted as low FPS.
So don't set this threshold too close to the average framerate you want to stay above.
New config switch hotkey
The overlay page got a new hotkey to toggle through the 3 different overlay configurations so that you can switch them whithout having to tab out the game to change them in CX.
New remote control functionality
Version 1.5.6 will feature the first basic implementation of CXRemote, giving developers and testers a tool to make fully automated benchmarks that can be implemented in many different programming languages.
You can send commands to start a capture with a set time or send a separate stop command and you can also set the output directory for your files with each capture command or leave it at null to use the directory set in CX.
To try out the feature and find documentation on how to implement this in your code, see our specification on SwaggerHub.
Nvidia changed some dll directories with the latest driver (again) that could lead to missing power sensors, they should now be working properly.
Also some users had missing dll files after a clean installation of CapFrameX that lead to the software being unusable. These should now also install properly.