Simple Short Answer
For end users
BazzerBiller wrote: ↑02 Feb 2020, 18:01
My framerate was not constant and it goes between 70-141 according to the situations ( fight, or in building etc . ) but I didnt notice any stutter
FreeSync and G-SYNC is quite miraculous in erasing stutters in PUBG
BazzerBiller wrote: ↑02 Feb 2020, 18:01
But... Apex Legends was horrible in terms of gameplay. So, in Apex Legends my fps pattern almost same in Pubg ( 70 min on cities and 141 maxed in building or more optimized locations ).
...But Apex has been very variable refresh rate unfriendly.
Sometimes it works well, but often it doesn't want to play well. You're not the only person who experienced this.
Different games are less friendly to GSYNC/FreeSync than other games. Some games are also optimized to specific sync technologies (e.g. consoles are optimized for fixed-Hz VSYNC ON), making it difficult to port it to VRR compatibility.
Long Complex Answer
For software developers
(Just because many game developers lurk Blur Busters to read stuff -- many view counts from game studios).
The below is textbook reading for software developers who want to make their game engine more compatible with VRR. Stop reading the below if you're not a software developer. The below is mainy for other technical readers that visit these forums.
<Technical>
VRR can does amazing work to keep gametime:photontime consistent. When the game time is in perfect sync with the frames becoming visible to human eyes --
even with erratic delivery of frames -- things look smooth despite nearly random frametimes -- as seen in the demo at
www.testufo.com/vrr
However, sometimes there are games that just really skew the frametimes around in ways that VRR cannot fix. For example, erratic frame rendering times, or erratic input-read times, or erratic game clocks. Even with Google search, typing "Apex doesn", it autocompletes to "Apex doesn't feel smooth" -- so everybody has the same problem with Apex.
The best thing game developers can do is to make sure that frame presentation is in sync with gametime, and that rendertimes are consistent.
Even 1 millisecond errors in gametimes generates visible stutters. 4000 pixels per second turning = 1ms stutter = 4 pixeljump stutter! Not all game developers realize how much milliseconds matters for stutter. Game clocks need to be microsecond accurate wherever possible --
Preliminary virtual reality headset tests show that
0.2ms gametime errors sometimes still create human visible stutter -- during low-persistence 8K (e.g. strobed ultra-high-resolution virtual reality during fast head turning speeds -- 8K virtual reality head-turning 2 screenwidths per second = 16,000 pixels per second = one 0.2ms stutter is a 3.2 pixel stutterjump, which can be visible if the strobed MPRT persistence is sufficiently low, such as 0.1ms-0.2ms -- the Valve Index doesn't quite go low, but it does 0.33ms persistence). The higher the resolution, the lower the persistence, and the faster the eye-trackable motionspeeds, with more eyetracking time (wide 180 FOV virtual reality headset), the more visible tiny gametime errors become visible. So if strobed persistence is really low (e.g. 0.3ms persistence found in Valve Index virtual reality) and resolution is really high (e.g. nearly 4K), sub-millisecond sudden stutter begins to become human visible.
The point being,
Most software developers do not realize how important the millisecond is in this refresh rate race to retina refresh rates.
Now, variable refresh rate cannot fix certain kinds of stutters (e.g. game clocks greatly divering from frame presentation clock, as well as ultra-volatile rendering times).
Stutters UNFIXABLE by G-SYNC and FreeSync
Stutters caused by frame presentation (aka frame visibility to eyes) diverging away from game clock (aka gametime).
Sometimes it diverges because of a programming bug
sometimes it diverges because engine is prioritizing to netcode (prone to network quality)
sometimes it diverges because of power management
sometimes it diverges because of wildly fluctuating frame rendering times
sometimes it diverges because the game engine is optimized for VSYNC ON
sometimes it diverges because of a buggy frame rate cap (switch to RTSS cap instead of game engine cap)
Etc.
Games that have a built-in "VSYNC OFF" feature usually are generally more compatible with VRR, since VSYNC OFF has behaviours that are inherently compatible with variable refresh rate technology.
I don't know if Apex netcode has any effect on panning fluidity -- but it varies by game. The original early DOOM (1994) often prioritized local strafing and lateral movements to netcode, which is why modem errors sometimes created weird strafing speed effects, like your movements suddenly lurching etc. While today, CS:GO prioritized local movements to gametime:presenttime sync, which is why it still feels relatively smooth (mouseturns, strafing, etc) independently of network volatility. Your fragging might be erratic (hitreg varies with network volatility, argh), but your panning/turning/strafing/etc never gets erratic. Battle(non)sense YouTube channel covers ton of netcode material. Great textbook study. But local gametimes for local movements (camera view) should NOT be slaved to network -- CS:GO doesn't make that mistake -- and CS:GO is still popular today.
Most of the time, game times are naturally in sync with frame presentation times. That's why variable refresh is retroactively with many games made long before GSYNC/FreeSync. But unfortunately, not all game engines play well with variable refresh.
Public Service Advisory To Game Developers / Game Studios
Best-practice guideline for game developers and game studios: Do your best to make your gametime clocks & frame presentation times, as
microsecond-accurate as possible. Please. In order to futureproof your game in the refresh rate race to retina resolutions. Today's 1ms-visible microstutter may be tomorrow's 0.4ms-visible microstutter (at increased resolutions & lowered persistence.
Stutter Math:
2000 pixels/second screen panning
+
2ms sudden divergence in game time away from frame Present() time
=
4 pixel stutter-jump even in G-SYNC and FreeSync
regardless of Hz! regardless of framerate! Though higher Hz & higher frame rate will amplify visibility of momentary gametime divergences.
Human-Visible Millisecond Errors
Let's say your code frequently inserts timing errors ("game time-vs-frame present time" divergence for any reason), at very frequent or regular intervals:
--> A 10ms gametime-presenttime sudden error at 33ms 30fps is no big deal in the Classic Olden Days. I didn't see it.
--> A 10ms gametime-presenttime sudden error 3ms 300fps is a holy GIANT microstutter; why is my game unsmooth?
I want my money back!
Especially if
--> 10ms sudden timing error at 30fps on 640x480 of yesteryear = 1/100th of 640 = only 6.4 pixel stutterjump at one screenwitdh per second turning/panning (totally hidden by middle of ~21 pixels of LCD motion blurring because of high persistence simultaneously combined with slow GtG back in those olden days)
Here, the stutter jump is only ~25% of motion blur size. I couldn't see it.
--> 10ms sudden timing error at 300fps on 2560x1440 ULMB of future = 1/100th of 2560 = big 25.6 pixel stutterjump at one screenwidth per second turning/panning (BLATANTLY visible stutter during 1ms MPRT strobed motion blur reduction = 2.5 pixel of motion blurring).
Here, the stutter jump is ~1,000% of motion blur size. Owie, painful stutter.
The amplified visibility effect is an important textbook lesson in the refresh rate race.
Here, the humble millisecond matters -- it
is one of those "millisecond is human visible" situations. The "surely that millisecond doesn't matter" accidential assumption -- can bite a game developer's ass when de-stuttering a game engine on G-SYNC and FreeSync!
Causing a game studio to waste money fixing their engine to behave better for G-SYNC and FreeSync. Companies can save money and learn from Blur Busters. For software developers and game programmers who want to learn more,
Understand The Black Box Between Present()-to-Photons. That what Blur Busters does -- we understand what happens between the game software & the photons hitting human eye balls.
TL;DR: Software Developers Should Aim For Microsecond-Accurate Sync Between Game Clocks -> Frame Presentation Time
Yes, I know it's aspirational. You will not truly get microsecond accurate. But there are already many microsecond clocks and many ways to avoid adding accidental delays between game times & frame presentation times. Skip the accidental shoot-feet mistakes and just try to make sure the microsecond you Present() is in relative sync to the microsecond of your gametime clock.
Presto. That's it. That's really mostly all a game need to do to avoid stutters that G-SYNC and FreeSync is unable to fix. Future faster computers become more and more microsecond accurate, benefitting your game naturally.
Some games like CS:GO already does it naturally. Which is why many old games just works fine: The game naturally improved smoothness far beyond frame rates they were remotely tested back then. It's amazing how many game engines insert so much frametime / gametime errors, and from so many unexpected reasons. Many studios hire developers that are not high-Hz experienced, and they make natural "that millisecond doesn't matter" mistakes peppered throughout a lot of perfectly good code. This is probably not what happened to Apex, but it has happened to a few games. Sometimes it's even worse (e.g. games not properly working at above 60 frames per second).
Local gametime (for local movement purposes) DOES NOT mean networktime (for hitreg purposes), they can be different, like it is for CS:GO and many games that just still feel delicious in this refresh rate race far beyond the original Hz the game was designed at. And even PUBG while the engine is stuttery (even allegedly unoptimized), it still keeps sufficient gametime:presenttime sync for G-SYNC/FreeSync to do miracles on it, creating beauty smoothness out of a stuttery engine.
Bosses/CEOs/CFOs/PMs Of Game Studios, It Matters To Your Company's Bottom Line.
So you game studios -- Want your game to last as long in esports as CS:GO? Want your game to keep up with the refresh rate race -- and in both fixed-Hz and variable-Hz situations? Want more profits longer? Even at future frame rates and refresh rate not yet tested? Good, you're listening. Many engines (Source, Unreal, Unity), in most default programming workflows, automatically works to keep game-time-vs-presentation-time sync to the microsecond as much as possible. But if you're building an in-house engine, or do an unconventional workflow with an existing engine, then please futureproof your game engines by following the above simple rule!
And hey, look at how everybody is milking their games on app stores 10 years later. It's no longer bricks and mortar. Pay attention to future proofing, and you'll have revenues for longer (= you get to pay more employees & happier employees too). Just please don't mis-design your netcode/game engine to make your game non-futureproof in this refresh rate race.
Don't be the game studio with a 1-line bug making your game VRR-incompatible -- your influencer gamer is going to switch to CS:GO or other smoother games -- and not bother being your influencer for your game if it's not fun for them to play your game, if your game is unsmooth, because you didn't follow a microsecond "gametime:presenttime" rule. Millisecond errors are literally 100x+ more human visible with the new "refresh rate race" variables explained in above paragraphs.
Besides, it is not an expensive Apollo Space Mission to make a game VRR compatible. Who knows, maybe your game company might get more free sponsored equipment (like free GPUs for your game company) if you're on their good side being compatible with the world's entire sync technologies -- and your game is smoother than your competitor's. Keeping up with the refresh rate race. It's the bottom line for your video game business, isn't it? And don't employees and stockholders need to be rewarded by better game profits, and less time fixing stutter bugs?
Simply following a cheap, inexpensive, microsecond "gametime:presenttime" rule, automatically makes your game work better with all sync tech, anyway -- Fast Sync, Enhanced Sync, VSYNC OFF -- and whatever future sync technologies that nas not yet been invented. It automatically futureproofs your game to all future sync tech.
So, whenever the game is in VSYNC OFF mode in menus, make the game engine synchronize gametime to the timing of Present().
(A) It makes VSYNC OFF behave better
(B) It makes game work better with G-SYNC and FreeSync (perpetual VSYNC ON look at fluctuating framerates -- like
www.testufo.com/vrr animation ...!)
</Technical>
(I know a few employees of big-name game companies already lurk these forums. If that's you, please forward this message -- LINK:
posting.php?mode=edit&f=2&p=47076 -- if somebody at your game company say stutters on G-SYNC and FreeSync don't matter, or those "stutters that only become visible at refresh rates above 60Hz" situations. That's a warning signal that your game is not properly fluidity-futureproofed to be compatible with all Hz / all sync tech.)