Mam to w moim kodzie w głównej pętli (gra 2D w oknie):

try{
  synchronized(this){

    wait(3);
  }
}
catch(Exception ex) {
  System.out.println(ex);
}

Ten fragment kodu powoduje ograniczenie FPS do 64 i nie wiem dlaczego. Nie używam żadnych innych zsynchronizowanych bloków. Co zabawne, gdy przeglądarka internetowa jest otwarta, liczba klatek na sekundę nie jest już ograniczona. Czy ktoś mógłby mi powiedzieć, jak pozbyć się tego limitu 64 fps? Nie udało mi się znaleźć innych tematów z tym problemem.

EDYTOWAĆ:

  • Bez czekania(3); - 180fps.
  • Z wait(3) i otwartą przeglądarką (Opera) - ~113 fps.
  • Z wait(3) i bez przeglądarki - 64 fps.

Jak przeglądarka może zmienić fps?

1
Jan Burak 29 luty 2012, 02:05

3 odpowiedzi

Najlepsza odpowiedź

Chociaż rozdzielczość parametrów wait i sleep jest w milisekundach, prawie na pewno nigdy nie otrzymasz dokładnie takiego opóźnienia, o które prosisz.

W systemie Windows rozdzielczość wynosi około 15 ms, co daje 1000/15 = 66 fps

5
OldCurmudgeon 29 luty 2012, 02:19

Jeśli nie używasz żadnych innych zsynchronizowanych bloków, nie ma nikogo, kto mógłby notify() twój wątek. Oznacza to, że prawdopodobnie każesz swojej aplikacji uśpić co najmniej 3 milisekundy w każdej iteracji. Dodatkowo możesz stracić trochę więcej czasu, ponieważ wątek rezygnuje ze swojego kwantu czasu, gdy przechodzi w stan uśpienia, a rozdzielczość zegara jest zwykle większa niż 1 ms, w zależności od systemu operacyjnego.

64 FPS oznacza, że ​​klatka zajmuje nieco ponad 15 ms. Powiedz nam, jaki jest twój „nieograniczony” FPS, oblicz, o ile ms na klatkę przekłada się i zobacz, jaka jest różnica. Jeśli różnica w czasie wyświetlania ramek z ręką bez utraconego kodu jest rzędu 3-10 ms (10 ms to prawdopodobnie rozsądny górny limit ziarnistości zegara w rozsądnym systemie), jest to prawdopodobnie tylko wynik wait(). Jeśli bez wait() twoje klatki zajmują tylko 1 ms, prawdopodobnie jest jakiś dodatkowy efekt.

EDIT po komentarzu Jana: 115 FPS oznacza 8,7 ms na klatkę. Przejście od tego do 15 z powodu wait(3) wydaje się prawdopodobne. Nie jestem pewien, jak może na to wpłynąć uruchomienie innej aplikacji w tle. Być może posiadanie innego zadania w tle wpływa na zachowanie harmonogramu. Czy drugie zadanie przywraca FPS do 115 lub do jakiejś wartości pośredniej?

EDIT po drugim komentarzu Jana: jeśli jest 180 zamiast 115, mamy 5,5 ms na klatkę. Zwiększa to różnicę, ale biorąc pod uwagę, że zegar systemu Windows jest dość chudy (jak zauważyli inni), jest to nadal w granicach efektu opisanego powyżej.

2
Michał Kosmulski 29 luty 2012, 12:12

Nie próbuj uzyskać więcej niż 60 fps. Nowoczesny wyświetlacz nie pokaże więcej niż 60 klatek na sekundę.

0
Christian Kuetbach 29 luty 2012, 02:10