Jakie są zalety ograniczania klatek na sekundę? (Jeśli w ogóle)

Pracuję nad prostą grą w OpenGL, używając SDL do inicjalizacji wyświetlania i wprowadzania danych, i wydaje się, że pod względem czasu mam dwie dostępne opcje. Numer jeden to właśnie śpiący dla optimTimePerFrame - theTimeTakenToRender, gdy optimTimePerFrame w sekundach = 1 / theFramerateCap. (Nie jestem do końca pewien, czy jest to konieczne, ponieważ jest to równoważne z użyciem vsync, co może być dokładniejsze. Jeśli moje założenie jest prawidłowe, proszę powiedzieć, czy SDL + OpenGL ma domyślnie vsync, a jeśli nie, to w jaki sposób aby to umożliwić.) Drugim jest pomiar czasu od ostatniej renderowanej klatki i odpowiednie dostosowanie ruchu. (Im krótszy czas renderowania ramki, tym mniej jednostek porusza się w tej ramce). Pod względem wydajności i malejącego migotania itp. Jakie są zalety i wady tych dwóch metod?

Jeśli czas wyświetlania klatek jest nieprzewidywalny (niezależnie od tego, czy jest to Twoja wina; system operacyjny może czasami zużywać zasoby itp.), Ograniczenie do przewidywalnej liczby klatek na sekundę nieco niższej niż osiągalna liczba klatek na sekundę znacznie przyczyni się do przewidywalnego opóźnienia , które może sprawi, że gra poczuje się znacznie lepiej.

Zmieniając, jak długo pomiędzy przetwarzaniem danych wejściowych i renderowaniem zmian związanych z tymi danymi wejściowymi może się czuć źle - nawet jeśli średnio osiągasz mniejsze opóźnienia między nimi, „drgania” mogą być zauważalne dla ludzi (świadomie lub nieświadomie).

Zobacz prezentację Microsoft GameFest Co jest w ramce: łzawienie, opóźnienie i szybkość klatek, aby uzyskać wgląd tutaj. Carmack ma również serię postów na blogu, które są w tym przydatne.

Pamiętaj również, że niektóre matematyki mogą się zepsuć, gdy uruchamiasz ramki przy użyciu niskich deltaTwartości - lub nawet w ogóle używasz zmiennej deltaT(rzeczy mogą stać się trudniejsze lub nawet trudniejsze do zrobienia w „stabilny” i przewidywalny sposób, co jest ważne dla rzeczy takie jak powtórki i niektóre formy synchronizacji sieci). Zobacz Napraw swój Timepep, aby uzyskać wgląd tutaj.

Skończysz zużywać znacznie mniej procesora (wielozadaniowcy będą ci wdzięczni), a ludzie na urządzeniach mobilnych też to docenią.

Nigdy nie powinieneś nigdy, nigdy, nigdy, nigdy nie używać Snu do kontrolowania prędkości klatek .

To już zostało omówione wcześniej i odniosę się do drugiego pytania w celu omówienia powodów. Jedną z rzeczy, o których nie wspomniano, jest to, że przy typowej współczesnej częstotliwości odświeżania wynoszącej 60 Hz i przy typowej ziarnistości wywołań uśpienia wynoszącej 1 milisekundę, w rzeczywistości nie można spać przez właściwy czas między ramkami.

Ja nie mówiąc, że otrzymując procesora jeśli nic mam jest złe; daleko stąd. Ale to nie to samo, co kontrolowanie liczby klatek na sekundę, a Sleep jest rozwiązaniem odpowiednim dla pierwszego, ale nie drugiego.

Zamiast tego sprawdź czas, który upłynął, a jeśli nadszedł czas, aby uruchomić ramkę, zrób to, w przeciwnym razie - a jeśli chcesz uzyskać trochę procesora - Uśpij przez absolutny minimalny czas - 1 milisekundę. Upewnij się również, że twój wyłącznik czasowy jest odpowiednio skonfigurowany dla twojej platformy, aby zapewnić ci dobrą rozdzielczość; tzn. kiedy wydasz to wywołanie „Sleep (1)”, naprawdę masz szansę na naprawdę Sleeping na 1 milisekundę, a nie na coś takiego jak 15, 20 lub 30 (co byłoby w innym przypadku). Wierzę, że SDL zrobi to automatycznie.

Możesz również wbudować w nią trochę luzu, aby w momencie, gdy zbliża się czas uruchomienia ramki, przestajesz spać i zaczynasz biegać płasko, aż ramka się uruchomi, co może pomóc w dokładniejszym trafieniu żądanego interwału klatek.

Tak to wygląda na całą masę wywołań Sleep (1) przeplatanych od czasu do czasu ramką, i to jest OK. Nadal rezygnujesz z procesora, gdy go nie potrzebujesz, ale Twoje ramki będą mogły działać na czas.

Prawdopodobnie najważniejszą zaletą ograniczenia liczby klatek na sekundę jest to, że może on pomóc zapobiec dosłownemu fizycznemu uszkodzeniu maszyny. Zapomnieli zrobić to w Starcraft II, który okazał się bardzo problematyczny (i drogi) dla niektórych użytkowników, dopóki go nie załatał.

Jak wspomniano wcześniej, zmniejsza zużycie procesora. Z drugiej strony, a także coraz ważniejsze, co również wyczerpuje żywotność baterii. Jako dobry przykład, FTL działa na prawie 100% procesorze na moim MBA. W rezultacie rozładowuje baterię w ciągu> 2 godzin i działa bardzo gorąco. (Jako bardziej bezpośredni wynik odinstalowałem i już go nie odtwarzam ...). Czapka z ramą by temu zapobiegła.

Kolejną niewymienioną zaletą jest to, że jeśli jest to gra wieloosobowa, wyrównywasz również szanse, zapewniając wszystkim takie same wrażenia.