ArmaFPSAnalyser is a tool that can show you the performance of your game based on some specially-instrumented mission files. In addition, the scripts are available to allow you to create your own benchmark missions. The screenshot below gives you an idea of the kind of information the tool provides - in this example performance across three different kinds of location (city, coast and forest) is being compared. (In this case you can see quite clearly that performance of the 1.05 patch is poorer in city locations than elsewhere.)
How is this different to FRAPS or ArmaMark?:
Most benchmarks show you an average fps (frames per second) reading and, if you are lucky, a minimum fps reading. The problem with these is that even the minimum fps number is an average across several frames. This is not a good approach for ArmA where the main issues seem to be around 'stutter'; ie, individual frames that take considerably longer than the ones before and after them. FPSAnalyser records the time taken for _every_ frame, as reported by the game and shows you the information in several different ways. It also uses a script-based approach to ensure that benchmarks are as repeatable as possible so you can truly isolate the factors that are affecting performance. Finally, the analyser allows you to plot multiple runs so you can directly compare benchmarks as you change settings.
How does it work ?:
The scripts create a camera which flies between a set of markers. As this is happening, a loop within the scripts records the timestamp of each individual frame. After the run is completed, the result are written to your arma2.rpt file. The analyser is then reads out the results and plots them
What does it all mean ?:
Although the plots all show 'fps' it's important to realise that what is being plotted is actually 1/frame-duration for each and every frame. I've chosen to use this presentation rather than frame-duration because most people are a lot more comfortable with fps and have an inherent feeling for what is 'good'.
The simplest plot to understand is "FPS over time". This just shows the instantaneous fps for each frame during the course of the benchmark. You can see in this example plot that although most frames are at >20fps, there are some dips down to around 10 which will be perceived as stuttering.
The '% time spent below framerate' plot shows the information in a slightly different way. Rather than plotting the frames in the order they occurred, it looks at the distribution of fps. The stuttering can be seen here as the circled 'tail' of low-fps frames.
The auto-correlation plot shows the same information in yet another way - it shows the relationship of each frame to the frame immediately before it. A game that is running rock-solid at 60fps would show a very dense blob at the the top right this graph. A game where the frame-rate was varying smoothly will tend to cluster around a diagonal-line (shown in red in the example). If the framerate is varying wildly (ie stuttering) you will see 'outliers' such as those circled in orange. These are frames which have taken much longer to render than the frame immediately before them.
To install, download the archive from here.
Run the setup utitility to install the analyser. Copy the benchmarks in the missions folder to your own ArmA2 missions directory.
How to use the tool – getting started:
Run one of example benchmarks in ArmA2. After the camera has stopped moving you will see a report “LOG WRITTEN”. If you want to you can re-run the benchmark with different settings (eg, try changing the view distance or texture details).
Tab out of ArmA2 and start up the analyzer tool. By default it will display plots for the last benchmark you ran. You can compare several benchmarks together by using the Benchmarks->Add/Remove option.
You can give benchmarks useful labels using the Benchmarks->Details menu option. You will also see information here such as the aram2.exe build that was used and the startup parameters (very useful for comparing betas!)
IMPORTANT The analyser expects to see some header information written by ArmA (build id, startup parameters, resolution etc) so if you edit the rpt file by hand you can confuse it. If you want to start with a 'clean' rpt file, the best approach is just to delete it before starting ArmA.
Creating your own benchmarks:
The scripts (in the 'scripts' folder) make it very easy to create your own benchmarks. Just create a new mission in the editor and copy the init.sqf file and ctf folder into the mission folder. In the editor you will need to add some markers to tell the camera what route to follow. The markers need to be name fps_0,fps_1,fps_2 etc, as many as you want. You can control the way the camera behaves at each point by adding keywords to the marker text.
speed=N will change the speed of the camera when it hits this marker.
height=N will ensure the camera is at this height when it reaches the marker
target=x changes the direction the camera faces.
Target=next means that the camera will always face the next marker, ie it will look straight ahead
Target=player means that the camera will face the player
Any other value, eg target=zzz will cause the camera to face a marker of that name.
When developing new benchmarks you can temporarily disable logging using the nolog keyword. You can change the 'name' of the benchmark (which will be shown in the analyser) by placing text before the keywords.
Here's an example from the BM_cityRun benchmark...
FPS is only one aspect of the game experience- this tool can't measure other issues such as lod pop-up. The tool almost certainly contains bugs. If you find one or have the tool crash, please report it here and I will try to fix it.
- Users can run large sets of benchmarks and then examine what settings are likely to give them the best performance
- Missions and scripts updated to use diag_tickTime as per Suma's advice.
- First release
- BI forums
Tags: No tags