Laggy Animations vs ADAD Spam

Some of you may have noticed that enemy movement gets kinda jerky in big battles. This is especially annoying when you’re trying to hit headshots, and have enemy’s head jerk out right from under your crosshair.

There is also a known phenomenon known as “ADAD Warping“, which happens when the enemy rapidly switches strafing direction in a firefight, and their player models appears to be teleporting left and right rather than smoothly walking.

During my recent tests on the subject of Rate of Fire vs Framerate, I discovered a reliable way to trigger laggy animations – reduce the number of active cores. If you have a CPU that can work only on 4 threads or less at the same time, you may get laggy animations in big battles, or when you a lot of background processes running. However, reducing the number of active CPU cores to 1 allows to reliably trigger laggy animations at all times, even if you’ll still have acceptable framerate.

So I developed a theory that laggy animations could have something to do with warping, and performed a simple test – asked a friend to ADAD while I was recording with 1 active core, and with all 4.

To exclude the possibility of recording having an impact on the PC, I had to use my shitty phone to record the video, so pardon the quality.

The video shows an interesting thing. Even with laggy animations, enemy’s position in the world changes smoothly. However, enemy’s player model is jerking and twitching. Landing headshots on such a derpy hitbox would be impossible.

It seems the ADAD Warping is caused by server lag after all. But jerky animations are a problem nonetheless, and to avoid being affected by it:

  • Disable as many background processes and services as possible before launching the game. Consider using Razer Gamebooster if you don’t know how to do that.
  • Upgrade your CPU to something with more cores in it, giving preference to CPUs with Hyper Threading or SMT technology – it’s been confirmed they solve this issue for the most part.
  • In big battles shoot for enemy’s center mass instead of head.
  • If all else fails, avoid big battles.
FPS vs RoF

Rate of Fire vs Framerate

It’s a somewhat widely known phenomenon that the Rate of Fire of PlanetSide 2 weapons depends on your PC’s performance. Getting killed because your PC lags too much is bad enough, but dying because your gun literally shoots slower than the other guys’ is just horrible.

Unfortunately, this seems to be the limitation of PlanetSide 2’s engine, and there’s not much the current development team can do to fix it. 

There is a lot of drama revolving around this issue, and there seems to be  a lot of myths or unclear information, so I decided to run my own set of tests to find out what exactly causes the reduction in Rate of Fire, and how strong this effect is.

Usually game’s performance is bottlenecked either by CPU or GPU (Graphics Card). I wanted to figure out which of the two causes Rate of Fire issues. 

GPU Bound Results

Weapon Settings FPS Cap FPS Time, sec Expected Time
EM6
(600 RPM)
Very Low Uncapped ~200 ~20.3 (98%) 19.9
Usual Settings Uncapped ~180 ~20.7 (96%)
RTSS FPS Limiter = 120 120 ~21.2 (94%)
RTSS FPS Limiter = 150 150 ~21 (95%)
Smoothing ~120 ~20.3 (98%)
RQ = 1.41 Uncapped ~100 ~21.6 (92%)
RQ = 2.0 Uncapped ~50 ~23.1 (86%)
M18 Rotary
(1000 RPM)
Uncapped ~60 ~3.6 3.54
RTSS FPS Limiter = 30 30 ~3.6
Kobalt
(Sunderer)
(550 RPM)
Uncapped ~50 ~16.3 16.25
RTSS FPS Limiter = 30 30 ~16.3
EM6
(600 RPM)
MaximumFPS = 45 43 ~20.3 (98%) 19.9
RTSS FPS Limiter = 45 45 ~24.1 (83%)
Smoothing ~54 ~21.5 (93%)
Gauss SAW
(500 RPM)
Uncapped ~50 ~13.7 (87%)  11.88
Watchman
(857 RPM)
Uncapped ~10.9 (80%)  8.68
RTSS FPS Limiter = 30 30 ~12.6 (69%)  

For most of my tests I used EM6 with Extended Mags. It has convenient 600 RoF, which means the time period between two shots should be equal to 0.1 seconds. There are 199 time periods between 200 shots, so firing them should take 19.9 seconds.

To establish some baselines, first I recorded the time to empty a magazine using my Usual Settings, and then with all settings set to Very Low. In both cases I wasn’t capping FPS in any way, and RoF was close to expected values.

Test methodology: I went to Koltyr, stepped outside of the spawn building, and fired at full auto. I recorded using my shitty phone, as I wanted to avoid any potential impact from my own PC. I kinda forgot to disable Shadowplay’s background recording, though. I ran each test only once, and it’s possible the results would be inconsistent.

Then I used RTSS to cap FPS at 120, and then at 150. In both cases there was a negative impact to Rate of Fire.

Then I enabled Smoothing, which caps FPS at your monitor’s Refresh Rate. In my case, this is 120 Hz. That fixed the Rate of Fire issues.

Then I created a GPU-bound scenario by increasing Render Quality to 1.41, making the game render at double resolution, putting a lot of raw workload on my GTX 1060 3 GB. This had a noticeable negative impact to Rate of Fire.

Then I made GPU-bound situation more severe by increasing Render Quality to 2.0, making the game render at quadruple resolution. That reduced RoF even further, and introduced some horrible Input Lag.

Thanks to /u/Octiceps, we know that being GPU bound causes Input Lag, and indeed, it felt like an eternity would pass between moving the mouse and seeing the crosshair move on screen. According to my measurements, the delay was around 0.1 seconds, but it felt much longer, and the game would definitely be unplayable.

Capping the FPS by any means should remove the Input Lag. First I used RTSS to cap FPS at 45. That removed Input Lag, but impacted Rate of Fire even further.

Then I set an FPS limit through UserOptions.ini by setting MaximumFPS to 45. That removed Input Lag and solved the Rate of Fire issues. 

Note that according to Octiceps, using MaximumFPS to cap FPS still adds some Input Lag, but it seems miles better than being GPU bound, and I couldn’t feel any during my short tests.

I also ran a test with Smoothing enabled while GPU bound. In this case having an FPS cap at 120 should not have affected anything, but it’s possible that Smoothing actually does something else behind the scenes. And indeed the RoF impact was lower than while simply being GPU-bound, but it’s possible this was just a statistical margin of error. Since I’m lazy and ran each test only once, there’s no way to tell.

Finally, I wanted to test whether low RoF or high RoF weapons are more affected, so I removed the FPS Cap and ran tests with 500 RPM Gauss SAW and 857 RPM Watchman. As you can see from the results, the impact to higher RoF Watchman was nearly double.

Per /u/Punisherlceman’s suggestion, I ran tests with a couple of vehicle weapons, and surprisingly they seem to be unaffected by this issue at all. Even when I used RTSS to limit FPS at 30, which made the Watchman fire at 69% of its intended Rate of Fire.

CPU Bound Results

Weapon Settings FPS Time, sec Expected Time
EM6
(600 RPM)
1 Core, 1200 MHz ~25 ~24.4 sec (82%) 19.9  
4 Cores, 1200 MHz ~65 ~21.8 sec (91%)
1 Core, 4500 MHz ~120 ~20.6 sec (97%)

My CPU is Core i5 7600k. To create a CPU-bound scenario, I went to BIOS and manually reduced its maximum multiplier to 12 and disabled 3 of the 4 cores, as well as reduced memory frequency to 2133 MHz. 

For the test I set all settings to Very Low to make sure the FPS is not GPU-bound. 

It didn’t feel like there’s any Input Lag, but all animations would play at super low FPS, the famous “Doom Animations“. 

There was a significant impact to Rate of Fire. Then I increased the number of active cores to 4, and impact to RoF was not as huge, but it was still there. “Doom Animations” went away as the number of cores increased, so we can conclude that laggy animations happen when the CPU cannot handle several threads at the same time.

Normally my CPU runs at 4500 MHz, and RAM at 3000 MHz, so I went back to these settings, but once again left only one active core. I would still get laggy animations, but negative impact to RoF all but evaporated. 

During these tests the PlanetSide’s FPS counter was showing [GPU] half the time, in a situation where being GPU-bound is practically impossible, which just goes to show that indicator cannot be trusted.

It’s worth noting that while CPU-bound, the framarate fluctuated like crazy.

Second PC Results

Weapon Settings FPS Time, sec Expected Time
EM6
(600 RPM)
Low Settings, Uncapped FPS ~65 ~21 sec (95%) 20
High Settings, Uncapped FPS ~38 ~20.8 sec (95%)
Low Settings, Capped FPS 53 ~20.5 (98%)

I ran one more round of tests on my brother’s PC, who’s using entry-level Ryzen R3 1200, overclocked to 3.8 or 3.9 GHz, and an obsolete HD5770, middle of the road graphics card from 2009.

  • “Low Settings” = Very Low preset with Ultra Textures.
  • “High Settings” = Ultra Preset with Shadows Disabled. 
  • Render Distance of 800m and FullHD resolution in both cases.

Similar to before, there was considerable Input Lag while GPU-bound with uncapped FPS. Using MaximumFPS in UserOptions.ini to cap FPS at 55 removed Input Lag and mostly solved RoF issues. 

It’s interesting to note that even in worst case scenario RoF impact was not as severe as on my machine.

Conclusions

  • Rate of Fire is reduced when you are:
    • GPU-bound at low FPS.
    • Using RTSS to cap FPS.
    • CPU-bound by frequency.
  • It’s possible to have reduced RoF without any Input Lag.
  • You don’t need high FPS to fire at nearly full RoF.
  • RoF issues can be solved by:
    • Having very high FPS.
    • Setting an FPS Cap through MaximumFPS in UserOptions.ini just below your usual FPS.
    • Using Smoothing if your FPS is usually above your monitor’s Refresh Rate.
    • Preferring weapons with low Rate of Fire.

This set of tests is not intended as the last word on this topic, I mainly just wanted to see the problem with my own eyes and confirm tests done /u/ChasseurDePorcinet and /u/Datnade, and /u/Ahorns, as well as rule out Input Lag as the primary cause.