Dynamiczne skalowanie rozdzielczości pomaga utrzymać płynność wtedy, gdy scena zaczyna być dla GPU zbyt ciężka. Zamiast trzymać jedną, sztywną rozdzielczość przez całą klatkę, silnik potrafi chwilowo obniżyć wewnętrzną skalę renderowania, a potem wrócić wyżej, gdy obciążenie spada. W tym artykule pokazuję, jak ten mechanizm działa w praktyce, kiedy daje realny zysk, czym różni się od upscalerów i na co uważać, żeby obraz nie zrobił się miękki lub niestabilny.
Najważniejsze informacje w skrócie
- Technika zmienia wewnętrzną rozdzielczość renderingu w czasie rzeczywistym, a nie docelową rozdzielczość monitora.
- Największy zysk daje wtedy, gdy wąskim gardłem jest GPU, a nie CPU.
- Obraz zwykle wygląda najlepiej, gdy zmiany skali są łagodne, a interfejs pozostaje w natywnej rozdzielczości.
- To nie to samo co DLSS, FSR czy ręczne obniżenie rozdzielczości, choć rozwiązania mogą się uzupełniać.
- Najlepiej działa w grach z dużymi skokami obciążenia: otwarte światy, efekty cząsteczkowe, gęste sceny i VR.
Jak działa w silniku renderującym
W praktyce dynamiczne skalowanie rozdzielczości jest pętlą sterowania, a nie pojedynczym suwakiem. Silnik sprawdza czas GPU z poprzednich klatek, porównuje go z budżetem i decyduje, czy scena ma dostać trochę mniej, czy trochę więcej pikseli.
To oznacza, że render target, czyli bufor obrazu, może być przygotowany raz, a jego użyteczna skala zmienia się w locie. W materiałach Unity opisuje się to jako redukcję liczby pikseli przetwarzanych przez GPU i lekkie aliasowanie wariantów skali na tej samej pamięci, jeśli platforma i API na to pozwalają. Dzięki temu mechanizm jest dużo tańszy niż ciągłe przebudowywanie buforów od zera.
Najpierw pomiar, potem korekta
Silnik nie zgaduje w próżni. Patrzy na realny czas renderu, często z kilku ostatnich klatek, i dopiero na tej podstawie podnosi albo obniża primary screen percentage, czyli procent rozdzielczości używany do renderowania sceny. Jeśli nagle pojawia się ciężki efekt, tłum postaci albo deszcz z gęstym postprocess, skala może spaść, żeby utrzymać docelowy FPS.
Przeczytaj również: Sims 4 aktualizacje 2026 - Co zmieniają i jak nie stracić modów?
Dlaczego zmiany nie powinny skakać co klatkę
Tu wchodzi histereza, czyli mechanizm, który tłumi nerwowe wahania. Bez niej obraz mógłby w jednej chwili iść w górę, a w następnej spadać, co od razu rzucałoby się w oczy jako „pompowanie” ostrości. Dobre implementacje zmieniają rozdzielczość płynnie, stopniami i z pewnym opóźnieniem, żeby użytkownik widział stabilność, a nie walkę algorytmu z wydajnością.
Gdy ten fundament jest jasny, łatwiej zrozumieć, jak silnik ustala granice tej skali i dlaczego nie każda klatka powinna reagować tak samo.
Jak silnik decyduje o zmianie skali
Decyzja zwykle opiera się na heurystyce, czyli zestawie reguł, które oceniają obciążenie GPU. Dokumentacja Unreal Engine pokazuje to bardzo jasno: system porównuje wcześniejsze czasy GPU z budżetem klatki i na tej podstawie zmienia screen percentage w określonym zakresie. W praktyce nie chodzi o jedną magiczną wartość, tylko o widełki i tempo reakcji.
| Parametr | Co oznacza | Przykład z Unreal Engine |
|---|---|---|
| Min screen percentage | Dolny limit skali renderu, poniżej którego silnik nie schodzi | 50 |
| Max screen percentage | Górny limit skali renderu, zwykle odpowiadający pełnej rozdzielczości | 100 |
| Frame time budget | Budżet czasu na jedną klatkę, po przekroczeniu którego zaczyna się obniżanie skali | 33,3 ms |
To są domyślne wartości z jednego silnika, a nie uniwersalny standard branżowy. Przy 60 FPS budżet klatki wynosi około 16,7 ms, przy 30 FPS około 33,3 ms, więc im ambitniejszy target, tym szybciej system musi reagować na skoki obciążenia.
W niektórych pipeline’ach znaczenie ma też to, czy gra jest ograniczana przez GPU, czy przez CPU. Jeśli procesor nie nadąża z logiką gry, AI albo symulacją, samo obniżenie rozdzielczości niewiele da. Dlatego sensowne implementacje potrafią uwzględniać inne progi dla scen CPU-bound, czyli takich, w których wąskim gardłem nie jest rasteryzacja obrazu.
Gdy masz już rozrysowaną samą pętlę decyzyjną, warto sprawdzić, w jakich sytuacjach ta technika naprawdę pomaga, a kiedy tylko maskuje problem.
Kiedy ta technika naprawdę pomaga
Największy sens widzę tam, gdzie obciążenie skacze z klatki na klatkę. W otwartych światach, przy eksplozjach, gęstych efektach cząsteczkowych, dymie, deszczu albo w scenach z dużą liczbą postaci render potrafi nagle przyspieszać i zwalniać. Dynamiczna skala pozwala wtedy utrzymać rytm, zamiast uderzać gracza szarpnięciami frametime.
| Sytuacja | Efekt | Wniosek praktyczny |
|---|---|---|
| GPU-heavy open world | Duży zysk płynności | To jeden z najlepszych scenariuszy dla tej techniki |
| Dużo efektów i cieni | Zysk wyraźny | Skala często działa lepiej niż ręczne obniżenie presetów |
| CPU-bound scena | Mały zysk | Najpierw usuń wąskie gardło po stronie procesora |
| Menu i statyczne interfejsy | Zysk zwykle niewielki | Nie ma potrzeby agresywnego skalowania |
| VR i urządzenia mobilne | Często kluczowy element stabilności | Budżet klatki jest tam wyjątkowo ciasny |
W praktyce ta metoda sprawdza się lepiej niż stałe obniżenie rozdzielczości, bo nie karze gracza gorszym obrazem w lżejszych momentach. Ja traktuję ją jako adaptacyjny amortyzator, nie jako zamiennik porządnego renderingu. Gdy jednak porównujesz ją z innymi technikami skalowania obrazu, różnice robią się ważniejsze niż sam wzrost FPS.
Czym różni się od DLSS, FSR i ręcznego obniżania rozdzielczości
Tu łatwo o pomyłkę, bo wszystkie te techniki dotyczą pikseli, ale robią coś innego. Dynamiczne skalowanie zmienia ile pikseli GPU ma narysować w danej chwili. Upscaler, taki jak DLSS, FSR czy XeSS, próbuje z kolei odtworzyć obraz końcowy z niższej liczby próbek. To nie jest to samo, choć w nowoczesnych grach często działa razem.
| Mechanizm | Co robi | Największa zaleta | Typowe ograniczenie |
|---|---|---|---|
| Dynamiczne skalowanie | Automatycznie zmienia wewnętrzną rozdzielczość w czasie rzeczywistym | Dopasowuje się do chwilowego obciążenia | Skala może być widoczna w detalach obrazu |
| Ręczne obniżenie rozdzielczości | Ustawia stałą, niższą rozdzielczość renderowania | Przewidywalność i prostota | Stała utrata jakości przez cały czas |
| DLSS / FSR / XeSS | Rekonstruuje obraz z niższego inputu | Lepszy kompromis między ostrością a FPS | Jakość zależy od implementacji i rodzaju sceny |
Warto też rozdzielić to od Nvidia DSR, które działa odwrotnie i renderuje obraz powyżej natywnej rozdzielczości monitora, żeby poprawić jakość obrazu. Nazwy są podobne, ale zastosowanie zupełnie inne. W praktyce dynamiczne skalowanie i upscaler mogą się uzupełniać: jedno steruje obciążeniem, drugie ratuje czytelność końcowego кадru.
Skoro wiemy już, czym to się różni od innych metod, zostaje najważniejsze pytanie dla kogoś wdrażającego to w grze: jak to ustawić, żeby naprawdę pomogło, a nie tylko coś „włączyło”.
Jak to ustawić i przetestować, żeby nie zepsuć obrazu
Gdy testuję taki system, zaczynam od budżetu klatki, a dopiero potem dobieram zakres skali. Jeśli celujesz w 60 FPS, myśl o około 16,7 ms na klatkę. Jeśli projekt jest celowany w 30 FPS, masz około 33,3 ms. To brzmi banalnie, ale bez tego łatwo ustawić zbyt agresywny lub zbyt zachowawczy próg.
- Ustal target FPS i zamień go na budżet czasu w milisekundach.
- Zacznij od wąskiego zakresu skali, zamiast od razu schodzić mocno nisko.
- Utrzymuj HUD i tekst w natywnej rozdzielczości, żeby interfejs nie robił się miękki.
- Testuj najcięższe sceny, a nie tylko spokojny fragment poziomu.
- Sprawdź, czy zmiana skali nie powoduje migotania drobnych detali, trawy, siatek i cienkich krawędzi.
- Obserwuj frametime, nie tylko średnie FPS, bo to właśnie skoki czasu klatki psują odczucie płynności.
Jeśli silnik to wspiera, dobrze jest podejrzeć statystyki GPU i wykresy czasów klatek. W Unrealu robi się to przez narzędzia typu `Stat Unit` i `Stat UnitGraph`, a w innych środowiskach szukasz odpowiednika, który pokaże nie tylko średnią, ale też wahania. To właśnie wahania zdradzają, czy system działa stabilnie, czy tylko „goni” wydajność.
W grach stylizowanych można zwykle pozwolić sobie na trochę szerszy margines błędu, bo miękkość obrazu mniej razi. W produkcjach opartych na drobnych fakturach, czytelnym konturze i dużej ilości cienkich elementów lepiej trzymać skalę wyżej i ograniczyć zakres zmian. Gdy to przemyślisz zawczasu, unikniesz sytuacji, w której technika działa technicznie poprawnie, ale wizualnie jest zbyt kosztowna.
Co zwykle decyduje o jakości bardziej niż sam suwak
Największą różnicę robi nie sam fakt użycia tej techniki, tylko to, jak łagodnie system nią steruje i co jeszcze dzieje się w pipeline. Dobra rekonstrukcja temporalna, rozsądna histereza, osobno renderowany interfejs i sensownie dobrany minimalny poziom skali potrafią zrobić więcej niż każde agresywne cięcie rozdzielczości.
- Najpierw rozwiązuję bottleneck GPU, bo CPU-bound nie da oczekiwanego efektu.
- Trzymam UI w natywnej rozdzielczości, jeśli to tylko możliwe.
- Testuję skrajne sceny, nie tylko „ładny” fragment gry z dema.
- Nie ustawiam zbyt szerokiego zakresu skali, jeśli styl graficzny opiera się na drobnych detalach.
- Łączę tę technikę z temporal upsample, gdy pipeline rzeczywiście na to pozwala.
Jeśli miałbym zostawić jedną praktyczną myśl, to tę: dynamiczna adaptacja rozdzielczości działa najlepiej wtedy, gdy pozostaje prawie niewidoczna. Ma ratować płynność w trudnych momentach, ale nie przypominać graczowi co kilka sekund, że silnik walczy o oddech. W dobrze ustawionym projekcie to właśnie ona pozwala utrzymać tempo bez brutalnego kompromisu między ostrością a wydajnością.
