Czy odblokowanie framerate w XNA / MonoGame powie mi, jak skuteczny jest mój kod?

12

Odblokowałem ilość klatek na sekundę w MonoGame poprzez:

this.graphics.SynchronizeWithVerticalRetrace = false;
base.IsFixedTimeStep = false;

Wykorzystując go jako podstawę do aktualizacji i rysowania w grze.

Przy rozdzielczości 240 x 160 bez rysowania lub aktualizowania niczego oprócz licznika klatek otrzymuję wartość FPS od 9 000 do 11 000 FPS.

Jeśli dodam z powrotem cały mój kod, spada do około 1100 FPS.

Czy to dobra wskazówka, że ​​mój kod znacznie spowalnia procesor graficzny (10x) i czy powinienem się martwić? Gra będzie działać przy 60 FPS, więc wciąż jestem daleko od tego, ale w którym momencie w odblokowanej liczbie klatek powinienem się martwić?

Karta graficzna: AMD FirePro W5000 (FireGL V)

monogame frame-rate test
źródło
1
Na marginesie: na swojej ścieżce programowania sugeruję, abyś utrzymywał docelowy FPS w debugowaniu, a także w wersji; coś może działać dobrze w wydaniu, ale może być powolne jak diabli w debugowaniu, co naprawdę nie jest przydatne :)
Vaillancourt
Nie całkiem. Inne odpowiedzi odpowiadają na to dobrze, ale główny punkt jest taki, że większość ciężkiego podnoszenia zostanie wykonana przez kartę graficzną przy użyciu przyspieszenia sprzętowego. O ile nie wykonujesz pracy w tym samym wątku co grafika (nie powinieneś być), to nie ma powodu, aby kod FPS miał wpływ na kod - w rozsądnym zakresie - w ogóle.
Dan Pantry

Odpowiedzi:

30

Tylko nieuprzejmie.

Po pierwsze, FPS nie jest miarą liniową . Różnica między 11k FPS a 9k jest bardzo mała (0,0000201 sekundy na klatkę). Ale różnica między 60 a 2060 FPS (delta 2k FPS, ta sama, która istnieje między 11k a 9k) wynosi 0,0161 sekundy ... znacznie większa. Może być więc niebezpieczny jako wskaźnik wydajności po prostu dlatego, że duże różnice mogą, ale nie muszą być tak złe.

Zamiast tego użycie czasu na klatkę jest nieco łatwiejsze do uzasadnienia, ale nawet wtedy jest to bardzo szeroki obraz sytuacji. Mówi tylko, ile sekund zajmuje jedna klatka gry. Nie mówi ci dlaczego , chyba że spojrzysz na znaczny wzrost czasu klatek natychmiast po dodaniu lub włączeniu jednej konkretnej funkcji.

Może to być podstawowy barometr do decydowania o czasie do bardziej szczegółowego profilowania. Szczególnie źle jest używać FPS do określania, czy jesteś związany z procesorem, czy GPU; Profilowanie GPU nie jest tak łatwe jak mierzenie czasu na procesorze (gdzie prawdopodobnie znajduje się twój taktowanie i kod obliczeniowy FPS).

Jeśli chodzi o to, kiedy powinieneś się martwić ... cóż, powiedziałeś, że gra była ukierunkowana na 60 FPS. Jeśli zaczniesz spadać w pobliżu lub poniżej tego, prawdopodobnie musisz zacząć uważniej myśleć o swoich problemach z wydajnością. Do tego czasu skupiałem się na tym, aby wszystko działało, a potem martwiłem się, aby było to szybkie .


źródło
6
+1 za ostatnie zdanie. Przedwczesna optymalizacja wydajności jest moim zdaniem dość złą praktyką (mówiąc z doświadczenia).
sirdank
1
c2.com/cgi/wiki?PrematureOptimization - Zalecane lektury na ten temat
Machinarius
Nie zawsze, jeśli masz wysokiej klasy maszynę i osiąga ona około 80 FPS, to byłoby wystarczająco dobre na twoim komputerze, ale jeśli chcesz atakować komputery z niższej półki, mogą one uzyskać tylko 15 FPS, idealnie byłoby najlepiej aby wykonać test na komputerze z minimalnymi specyfikacjami, na które chcesz kierować, ale jeśli to nie powiedzie się, optymalizacja dla twojego komputera może również zoptymalizować go dla nich. Oczywiście, jeśli działa wystarczająco szybko na niskich komputerach, nie ma powodu, aby poświęcać dodatkowy wysiłek na dalszą optymalizację, szczególnie na ryzyko zwiększonych błędów.
Programmdude
5

Nie rozumiem, dlaczego nie mogłeś tego użyć! Pamiętaj, że być może będziesz musiał kodować inaczej, aby uwzględnić różnice między stałym / zmiennym znacznikiem czasu, więc jeśli planujesz naprawić go w momencie wydania, musisz wprowadzić poprawki. Zobacz ten artykuł: http://rbwhitaker.wikidot.com/time-steps

Czy to dobra wskazówka, że ​​mój kod znacznie spowalnia procesor graficzny

Może to być również procesor. Zalecam okresowe uruchamianie wbudowanego profilera Visual Studio (lub za każdym razem, gdy zauważysz duży spadek liczby klatek na sekundę), aby znaleźć gorące punkty w kodzie.

powinienem się martwić?

To oczywiście zależy od sprzętu, na który celujesz. Musisz przetestować swój kod na komputerach o najniższych wymaganiach minimalnych, które chcesz obsługiwać. Jeśli działa tam co najmniej 60, nie martwiłbym się zbytnio.

Tandersen
źródło