Autor Wątek: fps w czasie rzeczywistym  (Przeczytany 14053 razy)

Offline andnoonesthere

  • Użytkownik

# Sierpień 29, 2006, 18:42:35
//OT: lol, za co Karma-- ?

więcej się nie odzywam, jak ktoś próbuje pomóc i przy okazji paru rzeczy się dowiedzieć to jeszcze mu karmę obniżają ...

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

kosmonauta

  • Gość
# Sierpień 29, 2006, 18:51:17
doskonale cie rozumiem. jedna osoba przez jednego posta dostala karma -= 25 czy iles... sam tez zjechalem w pewnym momencie z 8 do 1..

kosmonauta

  • Gość
# Sierpień 29, 2006, 20:33:46
pobawilem sie w testowanie GetTickCount vs QPC czy zdecydowanie ten drugi wypada lepiej. GetTickCount zwraca mi (kiedy rendering jest plynny) wartosc 15 albo 16 na przemian co powoduje ze mozna odczuc lekkie szarpanie. nie jest ono mocne, ale minimalne, prawie niezauwazalne. ale jednak jest. przy QPC nie ma tego problemu (w koncu dziala na float'ach ;)) i chyba jednak bezpieczniej jest korzystac z QPC niz z GetTickCount.

Offline shyha

  • Użytkownik
    • Shyha@Flickr

# Sierpień 29, 2006, 23:04:35
pobawilem sie w testowanie GetTickCount vs QPC czy zdecydowanie ten drugi wypada lepiej. GetTickCount zwraca mi (kiedy rendering jest plynny) wartosc 15 albo 16 na przemian co powoduje ze mozna odczuc lekkie szarpanie. nie jest ono mocne, ale minimalne, prawie niezauwazalne. ale jednak jest. przy QPC nie ma tego problemu (w koncu dziala na float'ach ;)) i chyba jednak bezpieczniej jest korzystac z QPC niz z GetTickCount.
QPC zwraca coś we floatach? Na moje oko to to co QPC zwraca raczej nie mieści się w zakresie floata i na dodatek nie jest zmiennoprzecinkowe :D

kosmonauta

  • Gość
# Sierpień 29, 2006, 23:09:38
przepraszam, moj blad :) zwraca int64 przez co uzyskujemy olbrzymia dokladnosc ;) jeszcze raz przepraszam ze moj, dosc spory, blad

Offline Krzysiek K.

  • Moderator
    • DevKK.net

# Sierpień 29, 2006, 23:41:43
Na moje oko to to co QPC zwraca raczej nie mieści się w zakresie floata i na dodatek nie jest zmiennoprzecinkowe :D
Akurat int64 się w zakresie floatów zawsze mieści (-3.4*10^38 - 3.4*10^38). ;)

kosmonauta

  • Gość
# Sierpień 30, 2006, 04:05:06
Jesli sprawdzamy czas od ostatniej klatki za pomoca GetTickCount() lub timeGetTime() i na jego podstawie kierujemy animacjami to nie jest to najlepsze rozwiazanie. U mnie na komputerze GetTickCount zwraca dosc czesto (kilka razy na sekunde) taka sama wartosc dla dwoch kolejnych klatek nawet przy FPSie ~50!! Co oznacza, ze delta w tym przypadku wynosi 0 i w danej ramce wszystko stoi (mimo, ze nie powinno). Z timeGetTime() jest juz troche lepiej, ale na naprawde szybkich maszynach gdzie FPS moze wyniesc ok. 500 zaczna sie i tu pojawiac delty zero. Czym szybszy sprzet tym czesciej. A przy FPS>1000 juz prawdopodobnie wszystko stanie bez ruchu bo roznica w ms wynosic zawsze bedzie 0. Oczywiscie mozna kombinowac dodajac sredni czas z ostatnich klatek i w ten sposob ratujac sie przed delta 0. Ale to tylko zafalszuje wynik (animacja nie bedzie precyzyjnie sterowana). Mozna rowniez dla delty 0 pzesuwac obiekty o taki sam wektor jak w poprzedniej ramce (w imie zasady, ze skoro minelo 0 ms to napewno obiekt powinien poruszyc sie przynajmniej tyle co ostatnio. No wlasnie. przynajmniej. Ale tak naprawde pownien poruszyc sie o wiecej... a ile wiecej tego juz nie da sie zmierzyc) tylko z nowu falszujemy wyniki. Jedynym sensownym obejsciem problemu delty zero w tym przypadku jest umieszczenie w kazdym obiekcie oddzielnego licznika czasu. Tzn. np. obiekt A ma sie przesuwac z predkoscia 10cm/s. Zapamietujemy wartosc GetTickCount albo timeGetTime na poczatku animacji, i przy kazdej aktualizacji polozenia obiektu sprawdzamy ile minelo ms od jego powstania i na tej podstawie przeliczamy przesuniecie. Ale chyba nie oto chodzi, aby kazdy obiekt mial  wlasna zmienna czasowa. Dlatego odradzam obie te funkcje.

Pozdrawiam.

Offline Krzysiek K.

  • Moderator
    • DevKK.net

# Sierpień 30, 2006, 04:18:59
Cytuj
Z timeGetTime() jest juz troche lepiej, ale na naprawde szybkich maszynach gdzie FPS moze wyniesc ok. 500 zaczna sie i tu pojawiac delty zero.
Nie widziałem jeszcze monitora, który byłby w stanie wyświetlić więcej niż 120 klatek na sekundę (może gdzieś obił mi się o uszy taki, który potrafi wyciągnąć 200, ale nie wiem, na ile dobrze pamiętam). W przypadku monitorów LCD jest jeszcze gorzej, bo aktualizują one obraz jeszcze rzadziej (po prostu olewają niektóre klatki, bo piksele i tak za szybko nie mogą zareagować).

Cytuj
A przy FPS>1000 juz prawdopodobnie wszystko stanie bez ruchu bo roznica w ms wynosic zawsze bedzie 0.
Masz tu błąd logiczny. Nawet jeżeli renderował byś 10000 klatek na sekundę, to od czasu do czasu (1000 razy na sekundę) timeGetTime() zmieni zwracaną wartość i wtedy animacja posunie się do przodu, a dla użytkownika wszystko będzie działało w normalnym tempie. Poza tym, są to czysto teoretyczne rozważania, ponieważ monitory i tak tyle nie wyciągną i nadmiarowe klatki są po prostu przez nie przegapiane (służą one tylko do testowania szybkości sprzętu i renderera, ale nie przyczyniają się już do wizualnego efektu). :)

Cytuj
Mozna rowniez dla delty 0 pzesuwac obiekty o taki sam wektor jak w poprzedniej ramce (w imie zasady, ze skoro minelo 0 ms to napewno obiekt powinien poruszyc sie przynajmniej tyle co ostatnio.
Wtedy generujesz dodatkowe milisekundy i w efekcie wszystko rusza się szybciej, niż powinno. Jeżeli delta wynosi zero, to nic nie powinno się poruszyć i należy czekać, aż timer nadrobi tą zaległość i wszystko się wyrówna. :)

kosmonauta

  • Gość
# Sierpień 30, 2006, 04:30:47
Nie widziałem jeszcze monitora, który byłby w stanie wyświetlić więcej niż 120 klatek na sekundę (może gdzieś obił mi się o uszy taki, który potrafi wyciągnąć 200
Nie mowilem o ramkach wyswietlanych na monitorze, tylko o ramkach przechodzacych przez glowna petle gry (ktorych ilosc moze byc wiele wieksza). Wiele z nich bedzie zafalszowanych przez bledne wskazania funkcji mierzenia czasu. Pozatym tak jak wspomnialem na mojej maszynie GetTickCount nawet przy 50 klatkach na sekunde generuje w kazdej sekundzie wiele delt zero. Co oznacza, ze w tych ramkach NIC nie zostanie przesuniete. A wiec  nawet aplikacja z RefreshRate=60 gdzie wszystko powinno byc odswiezane w czestotliwosci 60Hz czyli 60 razy na sekunde bedzie "przytrzymywana" przez nedokladnosc GetTickCount. I zamiast animowac wszystko z predkoscia 50 klatek na sekunde bedzie to robila np. 40 razy. A to juz moze byc zauwazalna roznica golym okiem. Wiec nie mowimy tu tylko o testowaniu szybkosci renderera.
« Ostatnia zmiana: Sierpień 30, 2006, 04:34:49 wysłana przez kosmonauta »

Offline Krzysiek K.

  • Moderator
    • DevKK.net

# Sierpień 30, 2006, 04:41:56
Nie mówiłem akurat niskiej precyzji GetTickCount(). Chodziło mi o to, że jeżeli timeGetTime() ma dokładność 1ms, to wszystko będzie chodziło dobrze, niezależnie, czy FPS będzoe 60, 100, 1000, czy 10000. :)

kosmonauta

  • Gość
# Sierpień 30, 2006, 04:47:44
Nie mówiłem akurat niskiej precyzji GetTickCount(). Chodziło mi o to, że jeżeli timeGetTime() ma dokładność 1ms, to wszystko będzie chodziło dobrze, niezależnie, czy FPS będzoe 60, 100, 1000, czy 10000. :)
Tylko ze timeGetTime() nie ma precyzji 1ms, a GetTickCount() nie ma nawet precyzji 15ms. Ale ok, masz racje - w idealnym swiecie by wszystko dzialalo idealnie :)

Offline shyha

  • Użytkownik
    • Shyha@Flickr

# Sierpień 30, 2006, 09:53:41
Na moje oko to to co QPC zwraca raczej nie mieści się w zakresie floata i na dodatek nie jest zmiennoprzecinkowe :D
Akurat int64 się w zakresie floatów zawsze mieści (-3.4*10^38 - 3.4*10^38). ;)
Dobrze, że dałeś to przymróżone oczko :) Oczywiście - teoretycznie się mieści, tylko z "trochę" inną dokładnością :]

Offline Kamil Trzciński

  • Użytkownik

# Sierpień 30, 2006, 12:58:14
tak, gdzie float ma dokladnosc gdzies 6-7 liczb ;) a int64 troche wiecej tych liczb :P

Offline Krzysiek K.

  • Moderator
    • DevKK.net

# Sierpień 30, 2006, 13:04:57
tak, gdzie float ma dokladnosc gdzies 6-7 liczb ;) a int64 troche wiecej tych liczb :P
Zarówno w formacie int64, jak i we float można zapisać jednocześnie tylko jedną liczbę. ;)


(tak, wiem, że chodziło Ci o znaczące cyfry dziesiętne, tak się tylko czepiam) :)

kosmonauta

  • Gość
# Sierpień 31, 2006, 04:48:18
Pisze wlasnie gierkie gdzie bohater jest caly czas na srodku ekranu. Tzn. jak chodzi to rusza sie za nim tez kamera tak ze wzgledem ekranu jego pozycja nie zmienia sie. No i wlasnie mam problem przy zmianie pozycji, bo gracz sie "trzesie" jak sie przemieszna. Wynika to z tego, ze czas kazdej ramki jest troche inny wiec gracz jest zawsze ten pixel czy dwa do przodu lub do tylu wzgledem poprzedniej ramki. Gdyby gracz przemieszczal sie wzgledem ekranu pewnie wszytko by bylo ok (nie zauwazalne drgania). Ale tak niestety sprawia to problem. Czy jest jakis sposob aby rozwiazac ten problem przy zachowaniu jak najwiekszej precyzji przesuniec? Tzn. zalezy mi na tym aby gracz na kazdym komputerze ruszal sie z dokladnie taka sama predkoscia, wiec przesuwanie go z srednia predkoscia ramki np. z ostatniej minuty raczej odpada. Dodam, ze jak przesuwam go o stala wartosc w kazdej ramce to drgania oczywiscie znikaja. Tylko, ze to nie jest zadne rozwiazanie bo chce miec ruch niezalezny od FPS.