UPS i FPS - co powinienem ograniczyć i dlaczego?

Obecnie piszę grę przy użyciu C ++ i SDL2 i zastanawiam się nad jedną rzeczą - czy ma sens ograniczanie liczby klatek na sekundę (FPS) i / lub moich aktualizacji na sekundę (UPS)?

Rozumiem, że jeśli ograniczysz UPS, w zasadzie kontrolujesz szybkość gry - jeśli gracz porusza się 1px na aktualizację i zawsze aktualizujesz ją 30 razy na sekundę, porusza się z prędkością 30px / s, a ty Prawdopodobnie też zwolnię procesor, ponieważ zmniejsza się ilość obliczeń na sekundę. Jeśli ograniczysz liczbę klatek na sekundę, liczba przeciągnięć na sekundę zmniejsza się, dlatego odciążasz swój procesor graficzny. Mam nadzieję, że wszystko zrozumiałem poprawnie, jeśli nie, popraw mnie.

Moje pytanie brzmi - co mam ograniczyć w mojej grze? FPS? UPS? Obie? Ani? Czy istnieje inne, lepsze podejście do tego? Jak to się robi w większości gier i dlaczego?

Odpowiedzi są mile widziane!

game-loop logic sdl2

— DocCoock
źródło

Naprawdę nie jest to odpowiedź, ale może ci się to przydać: gafferongames.com/game-physics/fix-your-timestep

— Cypher

Odpowiedzi:

Tak, to ma sens.

Jak powiedziałeś, zmniejszy to obciążenie systemu, co jest dobre dla termiki i innych zastosowań.

Jednak .... Twoja logika gier NIE powinna zależeć od aktualizacji na sekundę. Dlatego polecam przyjrzeć się deltatime, który uniezależni twoją grę od aktualizacji na sekundę.

Polecam przyjrzeć się temu pytaniu. Wyjaśnia całkiem dobrze, jak go obliczyć i używać. Jak zdobyć i wykorzystać czas delta

Mam nadzieję, że to pomogło!

— KaareZ
źródło

Czy powinienem ograniczyć oba, czy tylko jedno?

— DocCoock,

Oba, ale dodaj opcję w ustawieniach, aby dostosować.

— KaareZ,

Uwaga: jeśli korzystasz z silnika fizyki, nie polegaj na ramce aktualizacji delta w czasie / zmiennej, ponieważ rzadko są one obsługiwane; wymagają stałego podejścia do ramy. A jeśli twoja ramka bardzo się waha, może to oznaczać, że masz problemy ze swoim oprogramowaniem i powinieneś się zastanawiać, dlaczego tak się dzieje. Biorąc to pod uwagę, możesz ponownie rozważyć zastosowanie metody ID.

— Vaillancourt

Pamiętaj, że korzystanie z aktualizacji opartych na czasie delta może prowadzić do niestabilności fizyki i błędów, które są bardzo trudne do odtworzenia. W niektórych grach istnieją sztuczki, które są możliwe tylko przy określonych częstotliwościach klatek. Dlatego fizyka często działa ze stałą liczbą klatek na sekundę. Zawsze możesz interpolować przy niższych częstotliwościach aktualizacji, ale jeśli twoja symulacja jest niestabilna, nic nie może ci pomóc.

— Dietrich Epp

Szczerze mówiąc, myślę, że deltatime nie jest dobrym pomysłem. Używam go od lat i wiąże się z dwoma głównymi problemami. Wiele różnych artykułów dla wielu graczy zaleca stosowanie stałych kroków czasowych, a jeśli deltatime idzie zbyt wysoko, możesz teleportować się przez ściany lub podobne błędy, chyba że weźmiesz to pod uwagę.

— Programmdude

Najlepsza odpowiedź brzmi: to zależy .

Nie musisz ograniczać żadnego z nich

Aktualizacje : Jeśli twoje aktualizacje nie są ograniczone do górnego limitu, logika gry powinna zależeć od czasu delta , aby uniknąć szybszego lub wolniejszego uruchamiania gry w zależności od komputera, na którym jest uruchomiona. Jest to bardzo popularne podejście stosowane w wielu grach, ale nie tylko.

Renderowanie : jeśli renderowanie nie jest ograniczone do górnej granicy, bufor ramki może być prezentowany w stanie niekompletnym lub błędnym, powodując artefakty rozdzierania . Właśnie dlatego wiele gier wykorzystuje synchronizację pionową (v-sync)

Możesz ograniczyć jedno i drugie

Aktualizacje : Niektóre gry wykorzystują ustalone czasy dla niektórych lub wszystkich swoich systemów rozgrywki. To podejście działa tak, jak opisano. Liczba aktualizacji na sekundę jest ograniczona do górnej granicy, aby zapewnić, że rzeczy nie poruszają się zbyt szybko na najwyższym poziomie. Eliminuje to potrzebę synchronizacji delta. Niektóre aplikacje są lepsze ze stałymi krokami czasowymi, niektóre z czasem delta. Wybór podejścia zależy całkowicie od tego, co dokładnie próbujesz osiągnąć. Książka online GameProgrammingPatterns zawiera rozdział poświęcony pętlom gry, które dotyczą obu architektur.

Renderowanie : Liczba klatek na sekundę powinna być ustawiona na górną granicę, aby uniknąć wyżej wspomnianego problemu z rozrywaniem, jednak aplikacja nie powinna próbować tego robić ręcznie z pewną blokadą procesora. Zamiast tego włącz synchronizację pionową i pozwól, aby sprzęt podkładowy zsynchronizował się z częstotliwością odświeżania monitora. W ten sposób twoja gra będzie kompatybilna z przyszłymi monitorami, które mogą działać na znacznie wyższej częstotliwości niż obecnie powszechne 60 Hz. Warto również zauważyć, że wielu graczy, szczególnie tych, którzy biorą udział w testach porównawczych, nadal woli biegać bez synchronizacji pionowej, aby umożliwić najwyższą możliwą częstotliwość klatek. Dlatego rozsądnie jest zezwolić na włączenie lub wyłączenie tej funkcji w czasie wykonywania.

Czego nie powinieneś ograniczać

Jeśli gra wykorzystuje podejście oparte na sondowaniu do wprowadzania danych przez użytkownika, np .: wywołuje pewnego getInput()rodzaju aktualizację stanów kontrolera podczas etapu aktualizacji, jest to lepsze, jeśli nie ograniczone. Lub jeśli jest ograniczony, ustaw bardzo wysoką górną granicę. Im częściej pytasz o dane wejściowe użytkownika i reagujesz na nie, tym bardziej responsywna i płynna będzie gra. Tak zwane gry 60 Hz, o których dziś słyszymy, nie aktualizują AI i wszystkich stanów świata w tym tempie, niektóre nawet nie renderują tak szybko, ale sprawdzają dane wejściowe kontrolera co najmniej 60 razy na sekundę i odpowiednio aktualizują awatar gracza. To prawda, że dotyczy to tylko szybkich gier akcji.

— glampert
źródło

Jednak moje aktualizacje są również automatycznie ograniczone, gdy VSync jest włączony. Dlatego najwyraźniej muszę zdecydować między problemem rozdarcia a problemem aktualizacji-odpytywania, prawda?

— DocCoock,

@DocCoock, jeśli Twój renderer i logika gry działają w tym samym wątku, tak, włączenie v-sync również naprawia częstotliwość aktualizacji. To jeden z powodów, dla których niektóre gry dzielą renderowanie i logikę gry na różne wątki.

— glampert

Są dwa posty, które możesz chcieć obejrzeć:

Napraw swój Timestep

Interpolowane renderowanie fizyki

Uważam, że dyskusje na temat postów są naprawdę bezcenne, ale moim zdaniem najbardziej sensowne jest, gdy w grze jest znaczna ilość symulacji fizyki. Podsumowując, chodzi o to, że symulacja powinna mieć ustalony krok czasowy (w przeciwnym razie fizyka może eksplodować w punkcie, w którym delta jest zbyt duża), podczas gdy rendering powinien mieć swobodę działania z maksymalną możliwą szybkością. Aby zsynchronizować oba elementy (symulację i rendering), stan renderowania jest interpolowany przez czynnik, który zależy od odległości symulacji od następnej aktualizacji (pamiętaj, że symulacja jest stała).

Mam nadzieję, że to pomoże.

— Francis Moy
źródło