Frame pacing w grach: dlaczego stabilne 60 FPS nadal może wyglądać na zacinanie?

60 FPS nie gwarantuje płynności: czym naprawdę jest frame pacing

FPS mierzy tempo, frametime mierzy rytm

Wynik 60 FPS oznacza, że gra generuje średnio 60 klatek na sekundę. W idealnym przypadku każda kolejna klatka powinna zostać przygotowana i wyświetlona po około 16,67 ms. To właśnie taki równy odstęp daje wrażenie spokojnego, przewidywalnego ruchu kamery, animacji i obiektów przesuwających się po ekranie.

Problem polega na tym, że licznik FPS pokazuje zwykle wartość uśrednioną. Nie informuje, czy klatki pojawiają się regularnie. Gra może przez moment generować klatkę w 10 ms, następną w 23 ms, potem znów w 10 ms i 23 ms. Średnia nadal może sugerować okolice 60 FPS, ale obraz nie będzie poruszał się równomiernie. Kamera zacznie sprawiać wrażenie, jakby co chwilę lekko zwalniała i przyspieszała.

Frame pacing to regularność odstępów między kolejnymi prezentowanymi klatkami. Z perspektywy gracza nie liczy się wyłącznie to, ile klatek silnik potrafi wygenerować w ciągu sekundy. Liczy się również to, czy każda klatka dociera na ekran w odpowiednim momencie. Równe 50 FPS może wyglądać przyjemniej niż niestabilne 60 FPS, jeśli czas klatki jest bardziej przewidywalny.

Najprościej ująć to tak: FPS odpowiada na pytanie „ile”, a frametime odpowiada na pytanie „jak regularnie”. W analizie wydajności gry oba parametry są potrzebne, ale przy diagnozowaniu szarpania obrazu zdecydowanie ważniejszy staje się wykres czasu klatki. ^[4]

Dlaczego problem jest szczególnie widoczny przy ruchu kamery

Nierówny frame pacing najmocniej ujawnia się wtedy, gdy kamera porusza się jednostajnie. Wystarczy powoli obracać widok w otwartej lokacji, przejechać pojazdem obok płotu albo przesuwać celownik wzdłuż kontrastowej ściany. Jeżeli kolejne klatki nie są prezentowane w równych odstępach, ruch zamiast płynnego przesuwania będzie przypominał serię drobnych przeskoków.

Wysoki kontrast dodatkowo wzmacnia problem. Cienkie gałęzie, krawędzie dachów, balustrady, ogrodzenia, słupy i elementy interfejsu przesuwające się po tle są świetnym „testem wzrokowym” dla frame pacingu. Gracz może nie zauważyć krótkiego piku frametime’u podczas statycznej sceny, ale dostrzeże go niemal natychmiast podczas panoramowania kamery.

Nie należy mylić tej sytuacji ze zwykłym spadkiem FPS. Spadek z 60 do 45 FPS może być widoczny, ale jeśli utrzymuje się stabilnie, obraz nadal może wyglądać względnie równo. Z kolei nieregularne oscylowanie czasu klatki wokół wartości odpowiadającej 60 FPS często wygląda gorzej, mimo że licznik nie alarmuje. Dlatego test płynności powinien zawsze obejmować zarówno pomiar, jak i powtarzalny scenariusz ruchu kamery.

Stutter, microstutter, hitch i input lag nie oznaczają tego samego

W praktyce terminy związane z płynnością bywają używane zamiennie, co utrudnia zgłaszanie błędów i późniejszą optymalizację renderowania. Stutter jest szerokim określeniem na widoczne szarpanie obrazu. Może wynikać z problemów CPU, GPU, pamięci, streamingu danych, synchronizacji obrazu albo działania systemu operacyjnego. ^[2]

Microstutter to zwykle subtelniejsze, częste i rytmiczne zaburzenie płynności. Nie musi powodować pełnego zatrzymania obrazu. Często daje wrażenie nierównego przesuwania świata, szczególnie w grach z kamerą z trzeciej osoby, wyścigach i strzelankach. Hitch jest mocniejszy: pojedyncza klatka trwa zauważalnie dłużej, przez co gra wyraźnie „szarpie” w konkretnym momencie.

Input lag to osobna kwestia. Gra może mieć równy frame pacing, ale reagować z opóźnieniem, gdy kolejka renderowania jest zbyt głęboka albo włączona konfiguracja synchronizacji zwiększa liczbę buforowanych klatek. Może też wystąpić odwrotna sytuacja: sterowanie jest responsywne, ale obraz szarpie przez nieregularne czasy klatki. Dobra diagnoza wymaga rozdzielenia tych objawów.

Zamiast oceniać płynność wyłącznie po liczniku FPS, uruchom wykres frametime’u i sprawdź, czy linia przypomina spokojny przebieg, czy serię ostrych zębów. To najszybsza droga do odróżnienia realnej wydajności od mylącej średniej.

Błąd nr 1: ocenianie wydajności tylko przez średni FPS

Dlaczego średnia ukrywa problem

Średni FPS jest wygodny, ponieważ daje jeden prosty wynik. Niestety taki wynik potrafi ukryć niemal wszystko, co istotne dla odczuwalnej płynności. Jeśli gra przez większość testu działa bardzo szybko, a co kilka sekund generuje jedną klatkę trwającą 80 lub 120 ms, średnia może nadal wyglądać dobrze. Gracz nie odczuje jednak średniej. Odczujemy właśnie tę pojedynczą, zbyt długą klatkę.

Załóżmy, że test trwa minutę. Przez większość czasu gra mieści się w budżecie 16,67 ms, ale przy wejściu do nowej lokacji następuje doczytanie tekstur i czas jednej klatki skacze do 100 ms. Raport nadal może pokazać 60 FPS. W rzeczywistej rozgrywce gracz dostrzeże krótki, irytujący przeskok kamery dokładnie w momencie, gdy powinien skupić się na walce lub eksploracji.

Podobny efekt pojawia się przy kompilacji shaderów, tworzeniu obiektów po raz pierwszy, generowaniu cieni, aktywowaniu efektów cząsteczkowych albo intensywnym działaniu skryptów. Średnia FPS maskuje te zdarzenia, ponieważ nie mówi, kiedy wystąpiły i jak bardzo przekroczyły budżet czasu klatki.

W przypadku celu 60 FPS każda klatka powinna zmieścić się w około 16,67 ms. Pojedyncza klatka trwająca 33,33 ms oznacza już pominięcie jednego cyklu odświeżania na ekranie 60 Hz. Klatka o czasie 50 ms lub 100 ms będzie jeszcze bardziej widoczna. Nawet jeżeli takie skoki zdarzają się rzadko, mogą obniżyć odbiór gry bardziej niż stabilna praca w niższej liczbie FPS. ^[1]

Jak rozpoznać ten błąd w raportach i testach

Najłatwiej wykryć problem po raporcie, który zawiera wyłącznie średni FPS. Wersja gry A ma 62 FPS, wersja B ma 60 FPS, więc ktoś uznaje wersję A za lepszą. Bez wykresu frametime’u taka decyzja może być błędna. Wersja A może mieć większą średnią, ale też regularne skoki do 40–60 ms, podczas gdy wersja B utrzymuje równe 16–18 ms.

Przy planowaniu kolejnych kroków pomocny może być tekst: Visual Debugging – jak wykorzystać silnik do analizy gry?.

Niepokojącym sygnałem jest także raportowanie samego „minimalnego FPS”. Minimum często wynika z jednej wyjątkowej klatki, a bez informacji o miejscu i czasie jego wystąpienia ma ograniczoną wartość. Minimalny FPS nie pokazuje również, czy problem zdarzył się raz podczas ładowania poziomu, czy powtarzał się co kilka sekund w normalnej rozgrywce.

W testach wydajnościowych QA należy zwracać uwagę na zgłoszenia typu „gra działa w 60 FPS, ale kamera szarpie”. Taki opis nie jest sprzeczny. To bardzo cenna informacja o jakości frame pacingu. Należy ją uzupełnić nagraniem, wykresem czasu klatki, dokładną lokalizacją, kierunkiem ruchu kamery, stanem zapisu gry i informacją o tym, czy problem występuje po pierwszym uruchomieniu lokacji.

Lepsze rozwiązanie: metryki, które pokazują nierówności

Podstawowy zestaw danych do oceny płynności powinien obejmować średni FPS, wykres frametime’u, wartości 1% low oraz 0,1% low. Percentyle nie zastępują wykresu, ale dobrze pokazują, jak wyglądają słabsze fragmenty testu. Wartość 1% low opisuje wydajność najwolniejszego procenta klatek, a 0,1% low skupia się na jeszcze rzadszych i poważniejszych spadkach.

Trzeba jednak interpretować te liczby ostrożnie. Dwa testy mogą mieć identyczne 1% low, ale inny charakter problemu. W jednym przypadku wystąpi kilka pojedynczych hitches, w drugim zaś przez cały przejazd testowy będzie obecne drobne, rytmiczne microstuttering. Właśnie dlatego wykres czasu klatki pozostaje kluczowy: pokazuje kształt i częstotliwość zakłóceń.

Dobry raport powinien łączyć pik frametime’u z konkretnym zdarzeniem. Przykładowe oznaczenia mogą wyglądać następująco:

• wejście do nowej części mapy i rozpoczęcie streamingu świata;
• pierwsze użycie broni, czaru lub efektu pogodowego;
• otwarcie ekwipunku albo mapy;
• pojawienie się dużej grupy przeciwników;
• zmiana pory dnia, cieni lub poziomu szczegółowości;
• minimalizacja okna, powrót z pulpitu lub pojawienie się nakładki systemowej.

Porównuj buildy na identycznej trasie, z tym samym sejwem, ustawieniami graficznymi, wersją sterownika i długością próby. Jeden czytelny wykres czasu klatki dostarcza zespołowi więcej użytecznej informacji niż kilka imponujących wartości FPS.

Błąd nr 2: ignorowanie synchronizacji obrazu i kolejki renderowania

Jak V-Sync może pomóc, a kiedy ujawnia problem

V-Sync synchronizuje prezentację klatek z odświeżaniem monitora. Na ekranie 60 Hz oznacza to zwykle próbę wyświetlania nowej klatki co 16,67 ms. Główną korzyścią jest eliminacja tearingu, czyli widocznego „rozerwania” obrazu, gdy ekran pokazuje fragmenty dwóch różnych klatek naraz.

V-Sync nie usuwa jednak źródła problemów z frame pacingiem. Jeżeli CPU lub GPU nie przygotuje klatki na czas, synchronizacja może jedynie sprawić, że opóźnienie stanie się bardziej widoczne. Przy klasycznym V-Sync gra, która nie mieści się w budżecie 16,67 ms, może spaść do kolejnego rytmu prezentacji. Na ekranie 60 Hz oznacza to często przejście w okolice 30 FPS albo nieregularne przeskoki między poziomami płynności.

To nie znaczy, że V-Sync jest błędem. Jest użytecznym narzędziem, jeśli gra rzeczywiście potrafi utrzymać wymagany budżet czasu klatki. Gdy wydajność często balansuje na granicy możliwości sprzętu, klasyczna synchronizacja może obnażyć niestabilność, której wcześniej nie było widać za licznikiem FPS.

Kolejka renderowania: płynny obraz nie zawsze oznacza szybką reakcję

Między ruchem myszą lub naciśnięciem przycisku a obrazem widocznym na ekranie znajduje się kilka etapów: gra przetwarza wejście, CPU przygotowuje polecenia renderowania, GPU tworzy klatkę, a gotowy obraz czeka na prezentację. Kolejka renderowania określa, ile przygotowanych klatek może oczekiwać przed GPU lub przed wyświetleniem.

Niewielka kolejka pomaga ograniczyć opóźnienie sterowania, ponieważ ekran szybciej pokazuje efekt ostatniego ruchu gracza. Głębsza kolejka może z kolei ułatwić utrzymanie pracy GPU bez przerw, ale ma koszt: obraz, który widzisz, może przedstawiać stan gry sprzed kilku klatek.

Przy celu 60 FPS jedna klatka trwa około 16,67 ms. Jeśli w kolejce znajdują się dwie dodatkowe klatki, samo oczekiwanie może dodać ponad 30 ms opóźnienia, zanim uwzględni się czas renderowania, odświeżania monitora i przetwarzania obrazu przez wyświetlacz. W strzelance, grze rytmicznej lub wyścigach taka różnica jest często wyczuwalna. ^[3]

Problem nasila się wtedy, gdy GPU stale pracuje na granicy 99–100%. W takiej sytuacji kolejne klatki nie mają zapasu czasu, a kolejka zaczyna pełnić funkcję bufora. Licznik FPS może wyglądać poprawnie, lecz obracanie kamerą sprawia wrażenie cięższe, niż sugeruje wynik testu.

Jak rozpoznać zbyt głęboką kolejkę

Typowym objawem jest sytuacja, w której obraz wydaje się względnie równy, ale celownik lub kamera reagują z zauważalnym opóźnieniem. Najłatwiej sprawdzić to w powtarzalnym scenariuszu: wykonaj szybki ruch myszą, zatrzymaj ją i obserwuj, czy obraz zatrzymuje się natychmiast, czy „dokańcza” reakcję z wyraźnym poślizgiem.

Nie należy jednak przypisywać każdego opóźnienia wyłącznie kolejce renderowania. Podobne odczucie może powodować wysoka liczba milisekund na klatkę, filtrowanie ruchu myszy, bezprzewodowe urządzenie wejściowe, telewizor działający poza trybem gry albo funkcje poprawy obrazu. Dlatego test powinien ograniczać zmienne: użyj tego samego monitora, wyłącz dodatkowe upłynniacze obrazu i porównuj ustawienia w tej samej lokacji.

Dobrym uzupełnieniem tego tematu jest także poradnik: Testy wydajności – jak sprawdzić, czy gra wytrzyma graczy?.

• Objaw: gra jest wizualnie stabilna, ale celowanie wydaje się spóźnione.
  Możliwa przyczyna: zbyt wiele klatek oczekuje w kolejce.
• Objaw: opóźnienie rośnie głównie w wymagających scenach.
  Możliwa przyczyna: GPU pracuje stale przy pełnym obciążeniu i nie ma zapasu na szybką reakcję.
• Objaw: po wyłączeniu określonej synchronizacji sterowanie staje się szybsze, lecz pojawia się tearing.
  Możliwa przyczyna: wcześniejsza konfiguracja poprawiała prezentację obrazu kosztem opóźnienia.

Lepsze rozwiązanie: ogranicz kolejkę świadomie

Najpierw sprawdź ustawienia gry i sterownika odpowiedzialne za liczbę renderowanych z wyprzedzeniem klatek, tryb niskiego opóźnienia lub funkcje redukcji latency. Ich nazwy zależą od silnika gry i producenta GPU, dlatego nie należy zakładać, że jedna opcja działa identycznie w każdym tytule.

W grach e-sportowych zwykle priorytetem jest możliwie niskie opóźnienie. Sensowne może być wtedy ograniczenie kolejki oraz ustawienie limitu FPS, który nie doprowadza GPU do ciągłego pełnego obciążenia. W grach nastawionych na spokojną eksplorację można zaakceptować nieco większe opóźnienie, jeśli w zamian konfiguracja daje równiejszą prezentację obrazu.

Najważniejsze jest porównanie ustawień na podstawie realnego odczucia i pomiarów, a nie samej nazwy opcji. Zmiana trybu niskiego opóźnienia może poprawić reakcję sterowania, ale jeśli gra jest ograniczona przez CPU albo regularnie doczytuje zasoby, nie naprawi źródła hitchy. W takim przypadku kolejka nie jest przyczyną problemu, tylko miejscem, w którym jego skutki stają się widoczne.

Błąd nr 3: brak limitu FPS dopasowanego do realnego budżetu sprzętowego

Dlaczego „bez limitu” często nie jest najszybszą opcją

Odblokowany FPS może brzmieć jak oczywisty wybór: więcej klatek powinno oznaczać większą płynność i niższe opóźnienie. To działa tylko wtedy, gdy sprzęt potrafi utrzymać wysoką wydajność bez gwałtownych wahań. Jeżeli GPU renderuje raz 110 FPS, a chwilę później 65 FPS, jego obciążenie może stale skakać, a czasy klatek staną się mniej przewidywalne.

Brak limitu często powoduje również, że karta graficzna przez większość czasu pracuje przy 99–100% wykorzystania. W lekkiej scenie generuje znacznie więcej klatek, niż monitor jest w stanie sensownie wykorzystać, a po wejściu do bardziej wymagającego miejsca nie ma żadnego zapasu mocy. Rezultatem mogą być większe wahania frametime’u, wyższe temperatury, głośniejsza praca chłodzenia i rosnące opóźnienie wejścia przy pełnym obciążeniu GPU.

Limit FPS nie jest więc wyłącznie narzędziem do oszczędzania energii. Dobrze dobrany limit stabilizuje obciążenie i zostawia margines na bardziej złożone fragmenty sceny. Zamiast próbować osiągać maksymalny wynik w pustym korytarzu, celem jest utrzymanie powtarzalnego czasu klatki podczas właściwej rozgrywki.

Najczęstszy błąd: limit ustawiony dokładnie na granicy możliwości

Gracz widzi średnio około 60 FPS, więc ustawia limit na 60. Jeśli jednak w intensywniejszych scenach komputer regularnie potrzebuje 18, 20 lub 24 ms na przygotowanie klatki, taki limit nie rozwiązuje problemu. Gra nadal próbuje dotrzymać celu, którego nie jest w stanie utrzymać w najtrudniejszych momentach.

Lepszym wyborem może być limit 50 FPS, jeśli pozwala on uzyskać znacznie równiejszy przebieg. Dla 50 FPS budżet wynosi 20 ms na klatkę. Jeżeli sprzęt mieści się w nim konsekwentnie, jednostajny ruch kamery może wyglądać lepiej niż przy niestabilnej próbie osiągnięcia 60 FPS.

To nie oznacza, że należy automatycznie obniżać limit przy każdym spadku. Najpierw trzeba ustalić charakter problemu. Jednorazowy hitch podczas pierwszego wejścia do lokacji może wynikać z kompilacji shaderów i nie zniknie tylko dlatego, że limit zmieniono z 60 na 50 FPS. Jeżeli jednak wykres frametime’u pokazuje częste przekroczenia budżetu w normalnej walce lub podczas jazdy przez miasto, niższy, stabilniejszy cel ma sens.

Jak dobrać limit FPS krok po kroku

1. Wybierz wymagający, ale powtarzalny fragment gry: gęstą lokację, walkę, szybki przejazd albo obszar z dużą liczbą efektów.
2. Uruchom monitoring frametime’u i sprawdź, jaki czas klatki sprzęt utrzymuje bez regularnych pików.
3. Ustaw wstępny limit zgodny z realnym wynikiem, a nie z najwyższym FPS osiąganym w prostych scenach.
4. Przetestuj kilka wartości, na przykład 60, 55 i 50 FPS, wykonując identyczny fragment rozgrywki.
5. Wybierz ustawienie z najrówniejszym przebiegiem oraz akceptowalną reakcją sterowania, niekoniecznie z najwyższą średnią.

W praktyce limit powinien pozostawiać niewielki zapas. Jeśli gra przez większość testu osiąga 60 FPS, ale GPU stale jest maksymalnie obciążone, limit 57 lub 58 FPS może dać spokojniejszą pracę niż sztywne 60. Dokładna wartość zależy od gry, sterownika, API, monitora i sposobu ograniczania liczby klatek.

Limit w grze, sterowniku czy zewnętrznym narzędziu?

Najpierw użyj limitera wbudowanego w grę, o ile działa poprawnie i zapewnia równy frametime. Jest on zwykle najlepiej zintegrowany z silnikiem oraz jego mechanizmami prezentacji obrazu. Nie każda implementacja jest jednak równie dobra: niektóre limity powodują nierówne odstępy między klatkami albo zbyt agresywnie usypiają proces.

Limiter w sterowniku GPU bywa wygodny, gdy gra nie ma własnej opcji albo jej ograniczenie działa wadliwie. Zewnętrzne narzędzia dają większą kontrolę, ale należy testować je ostrożnie. Nakładanie kilku limiterów jednocześnie może prowadzić do trudnych do wyjaśnienia zachowań, dlatego aktywny powinien być jeden główny limit FPS.

Po każdej zmianie sprawdź nie tylko licznik klatek, lecz także wykres frametime’u, wykorzystanie GPU i odczucie podczas szybkiego ruchu kamery. Limit, który wygląda dobrze na wykresie w menu lub na pustej mapie, nie musi zachowywać się tak samo w docelowej rozgrywce.

Co sprawdzić przed podjęciem decyzji o limicie

• Czy problem występuje stale, czy tylko przy pierwszym wejściu do nowej lokacji?
• Czy GPU pracuje niemal cały czas przy 99–100% wykorzystania?
• Czy spadki pojawiają się w scenach obciążających CPU, takich jak tłum postaci, fizyka lub rozbudowane skrypty?
• Czy limit jest ustawiony tylko w jednym miejscu, a nie jednocześnie w grze, sterowniku i programie zewnętrznym?
• Czy po zmianie limitu poprawił się wykres frametime’u, a nie wyłącznie temperatura lub średni FPS?
• Czy test został wykonany na tym samym sejwie, trasie i ustawieniach graficznych?

Końcowa checklista konfiguracji płynności

• Nie oceniaj płynności wyłącznie po średnim FPS.
• Sprawdzaj wykres frametime’u w ruchu kamery, a nie tylko w statycznej scenie.
• Rozdziel problem nierównej prezentacji klatek od opóźnienia sterowania.
• Dobierz sposób synchronizacji obrazu do monitora i rzeczywistej wydajności gry.
• Nie utrzymuj GPU stale na granicy możliwości, jeśli powoduje to wzrost opóźnienia lub niestabilne czasy klatek.
• Ustaw jeden, przetestowany limit FPS zamiast kilku nakładających się ograniczeń.
• Dobieraj limit na podstawie najtrudniejszych typowych scen, a nie maksymalnego wyniku w prostym miejscu.
• Po każdej zmianie porównuj tę samą trasę testową, ten sam zapis gry i ten sam zestaw ustawień.

Co warto zapamiętać

• 60 FPS opisuje średnią liczbę klatek, ale nie informuje o regularności ich prezentacji.
• Równy frametime, wynoszący przy 60 FPS około 16,67 ms, ma kluczowe znaczenie dla płynności obrazu.
• Stutter, microstutter, hitch i input lag są różnymi problemami i wymagają osobnej diagnozy.
• Średni FPS oraz minimalny FPS mogą ukrywać pojedyncze, długie klatki i powtarzalne nierówności.
• Najlepszy raport wydajności łączy wykres frametime’u, percentyle 1% low i 0,1% low z opisem konkretnego zdarzenia w grze.
• Testy należy wykonywać w powtarzalnych warunkach: na tej samej trasie, z tym samym sejwem i ustawieniami.

Źródła

• [1] NVIDIA – FCAT | Technology ↑
• [2] Microsoft Learn – Profiling DirectX Apps ↑
• [3] PCWorld – Forget FPS. Here's why Frame Time is the PC gaming stat that matters most ↑
• [4] arXiv – The Influence of Variable Frame Timing on First-Person Gaming ↑