Sup Quakers!

UPDATE: tests of new patch here !!



This is a looong thread where I'll post all the results and statistics I got after running a few performance test during these days, especially I wanted to compare the frametimes over time using different framerate modes (specific tests were 110FPS, 125FPS, 180FPS, external 125 FPS cap, Uncapped and VSync); have you ever been curious if it's best to cap your framerate (and if so, how to do it better) or leave it uncapped ? Do you want to know how QC really runs under the hood ? Then this thread is for you, prepare for a ride!

METHODOLOGY : Now this was a bit problematic to choose, since QC being a multiplayer game means that matches are highly variable and it's hard to reproduce similar scenarios (and solo custom matches would have not been representative of actual gameplay), I did my best to reduce the number of variables to a minimum : all the analyzed matches were FFAs with 8 players, all played on the same map , with the same champion (Slash) and all the matches were played after a fresh game restart to be in the same conditions; in every match I recorded from immediately after the warmup end to the final podium.

EDIT: since PresentMon64 was yielding some weird results regarding framerate stability, I decided to switch to the Fraps logging tool, which also provides frametimes but in a ''clearer'' way; for postprocessing I still used some C code that I wrote for the occasion (had to rewrite it since I changed the analysis tool, but it's extremely simple and I can share if anyone is interested) and in Excel for graphical visualization (sidenote: don't use Excel when you have very big data pools 'cause he likes to crash out of nowhere apparently).

Fraps log file format

My piece of software used to crunch the Fraps log data







EVALUATED STATISTICS AND MEANING : Fraps kindly outputs a log file with data for EVERY SINGLE FRAME rendered by the GPU (even dropped ones), so the sample size for every match is around 60 to 80 THOUSAND frames; clearly posting those number here would have no meaning so I had to crunch those huge amount of numbers into some valuable statistics (as you can see from the console screenshot); here's what this numbers represent:

Number of samples: number of frames captured by PresentMon (this increases if the framerate is higher, which explains why uncapped results have more samples than capped ones)

Minimum/Maximum/Average frametimes: this is pretty self-explanatory, min and max frametimes over the whole match and the average value

Variability: ( EDIT : I realized that the previously evaluated 'variance' could be used only to compare functions with the same average value, and since the different framerate caps have different average frametimes, that value was useless, so I switched to a more representative statistic) this value is basically an indicator of the ''intensity'' of framerate spikes: it is calculated by summing together the value of all the spikes (the delta from the average frametime) and dividing it by the number of spikes (see below), the result is then shown in precentage.

: I realized that the previously evaluated 'variance' could be used only to compare functions with the same average value, and since the different framerate caps have different average frametimes, that value was useless, so I switched to a more representative statistic) this value is basically an indicator of the ''intensity'' of framerate spikes: it is calculated by summing together the value of all the spikes (the delta from the average frametime) and dividing it by the number of spikes (see below), the result is then shown in precentage. Average framerate: simply 1000/AVGframetime, to give an understandable representation of how 'fast' the game ran in that test

Number of spikes: what I did was setting 2 thresholds (for these tests, 1ms and 2ms) that I used to define a 'spike', which is basically a frame who's time exceeded the average frametime +- the lower threshold value, and then to divide the spikes into 2 categories: lesser spikes those which are kept under the higher threshold, and major spikes those that exceed that higher threshold.



RESULTS (discussion is below): I made a summary table with all the relevant statistics and also graphs for the frametimes over time for every single match (the number on the X axys is the frame number, on the Y axis it's the frametime in microseconds

#1 Frametimes with VSync enabled

#2 Frametimes with 110 FPS cap

#3 Frametimes with the in-game 125 FPS cap

#4 Frametimes with RivaTuner's 125 FPS cap

#5 Frametimes with 180 FPS cap #6 Frametimes with uncapped framerate





DISCUSSION OF RESULTS (EDITED) : These are some slightly different results from what I got last time, and the new tests shed some light on a few things, but let's see exactly what we can extract from this numbers and graphs

In the first half of every match, we can see a 70+ millisecond spike in the frametimes (it may be slightly cut off in the graphs since I reduced the Y scale), as you may have guessed, this is what happens when you fire the railgun for the first time (curiously enough its the only weapon that causes a big lag spike when fired the first time) but I didn't expect it to be so serious, I'd say this is a priority to fix in the next updates No surprise, running the game with higher cap or uncapped yields a much higher framerate (playing with RX570 and Ryzen 1500X on Low settings + High AA and Anisotropic filtering), and I can tell from my experience in those matches (nothing that I can quantify with a number tho) that the input lag was reduced compared to running with a capped framerate

From the VSync test's graph, which is the most consistent and with less spikes, I noted that there are some major ''double'' spikes (20+ ms, both above and below the target frametime) which stand out the most from the others, and that are always followed by a second spike a few seconds later; luckily enough I wrote down the number of deaths in all of the matches, and the number of those major spikes is exactly the number of my deaths in the game, leading to the conclusion that the game has severe frametime spikes (dropped frames probably) both at the moment of death and at the player respawn (tho the respawn one is less noticeable than the other). Devs might want to look into this, since it's probably some game logic code not properly optimized which is causing these spikes. The framerate cap, both in-game and external, does not provide a perfect frame pacing, but still suffers from some variability tho it is MUCH less than the uncapped or high cap tests Talking about variability, this new statistic is the most representative of these tests IMHO, since it summarizes in one value ''how much the frametime graph is variable from an ideal straight line''; clearly the VSync-ed mode has the most consistent frametimes but I wouldn't suggest playing in that mode unless you really wanna experience some bad input lag, the second best performer is the external framerate limiter (which explains why some people has been getting smoother experience than with the in-game one, tho the line is not as flat as rivatuner's own monitoring tool is telling you) followed by the internal framerate caps; the worst performers according to this value are clearly the uncapped and highly capped versions of the test, and this is also noticeable by looking at the frametime graphs which show a high variability in frametimes. Comparing the amount and ''intensity'' of the spikes, I can't really justify the really low numbers of the 110 FPS test (it might be a game where some people left the match in the second half, but I'm not 100% sure), but what is clear is that again the uncapped framerate has the most (and most intense) spikes, while comparing the in-game 125 FPS cap to the Rivatuner's one it looks likethat this second one is better because limits the ''intensity'' of spikes to a lower number (which also justifies the lower variability number as discussed above).

CONCLUSIONS (TL:DR) (EDITED !!) : After all this numbers, you may be asking 'Then what is the best setting to run at ?', so this is what I think after doing all this tests: framerate cap isn't the all-perfect feature that we may have thought it was and doesn't provide a perfectly smooth and equally paced framerate but it does help in reducing a lot of the frametime spikes and providing a more consistent experience; let's get this out of the way first, VSync is NOT to be used by anyone here whos PC can render more than 60 fps unless you wanna suffer from severe input lag and at the same time I DO NOT recommend running with uncapped or highly capped framerates (it may be worth it ONLY if you want the absolute lowest input lag possible) because it doesn't provide a consistent experience, it may interfere with some of the game's physics and it also overloads you CPU/GPU in the menus by rendering an insane amount of frames. The best way to play the game then looks like it's with a framerate cap active, so my suggestion is to run with a framerate cap close (possibly slightly higher) to your screen's refresh rate or a multiple of it but lower than the framerate your CPU/GPU can handle (in my case, having a 60hz screen and being able to get 160 average fps, I ran the tests at 110 and 125 FPS and I'm probably sticking to the second value); the topic of going with internal limiter vs an external one is a bit more complicated, since technically NO EXTERNAL SOFTWARE IS ALLOWED IN QC: know that RivaTuner's limiter may provide a better and more consistent experience regarding to frametimes but at the same time the difference with the internal one is not that huge, but the choice is yours.



Thanks everyone who read through all this, and I hope you found this tests helpful; if you did, please like this thread and/or leave your opinions down below, and share this with other players so everyone can get to know exactly how QC runs under the hood and set their game properly.

Peace out,

- JackaL

