2010-01-05 13 views
5

Zauważyłem, że niektórzy programiści animują obiekty na podstawie różnicy w czasie. Nie jestem pewien, dlaczego, a nawet jeśli jest to logiczne. Czy ktoś zna znaczenie?Dlaczego animacje są czasami wykonywane przy użyciu kroków opartych na czasie, który upłynął?

Poniżej znajduje się fragment kodu, który wyjaśnia, co to znaczy:

var timePassed:int = getTimer()-lastTime; 
lastTime += timePassed; 
var newBallX = ball.x + ballDX*timePassed; 
var newBallY = ball.y + ballDY*timePassed; 
+0

Sprawdź ten wątek: http://stackoverflow.com/questions/1284886/optimizing-transition-movement-smoothness-for-a-2d-flash-game – Cay

Odpowiedz

16

Kiedy animować na podstawie czasu, można zrobić sobie niezależny od prędkości klatek. Bez względu na to, ile klatek minęło, twoja piłka będzie poruszać się w tej samej odległości w danym przedziale czasu. Porównaj to w zależności od liczby klatek na sekundę, która jest zależna od wielu zmiennych, np. Ile mocy obliczeniowej jest dostępne do wykonania animacji.

Jest to typowy problem z fizyką gry - sprawdź doskonałą ocenę Glenna Fiedlera: "Fix Your Timestep!" article, aby uzyskać bardziej szczegółowe informacje na ten temat. (Robienie tego dobrze jest nieco bardziej skomplikowane niż tylko pomnożenie wektorów kierunkowych przez czas).

+1

I jeśli kiedykolwiek oglądałeś liczbę klatek na sekundę działający SWF, całkowicie zrozumiesz konieczność odpowiedzi Johna :) – Aaron

1

Dlaczego NIE zrobić tego w ten sposób? W przeciwieństwie do robienia czego? To prosty liniowy ruch w prawo? Oto myśl: dzięki temu piłka może nadrobić zaległe położenie w przypadku, gdy inne programy spowalniają komputer.

+0

Myślałem o tym. – numerical25

0

Nowoczesny komputerowy system operacyjny wykonuje wiele zadań naraz i nie zawsze otrzymuje wycinki czasu w regularnych odstępach czasu. Używając różnicy w zegarze czasu rzeczywistego, wygładzasz ruch w porównaniu do tego, czy przesuwałeś tę samą ilość za każdym razem przez pętlę, co może spowodować, że będzie wyglądać zgubnie, jeśli system wyda kilka milisekund na inny proces, zanim wróci. do Twojego.

4

Logika jest prosta.

BallDX => kulowy Delta X => Odległość jaką kulka może przejść współrzędnej x na sekundę

timepassed => ilość upływu czasu

if OldBallX = 0 
if BallDX = 10 
if TimePassed = 1 sec 
Then NewBallX = OldBallX + (BallDX*TimePassed) 

środki, które

NewBallX = 0 + (10 * 1) = 10 pixels 

W takim przypadku

if TimePassed = 0.5 sec (half a second) 

Następnie

NewBallX = 0 + (10 * 0.5) = 5 pixels 

Logiczna?

0

Najważniejszym aspektem niezależności od liczby klatek na sekundę jest to, że nie musisz ograniczać framerate. Kiedyś, w czasach mrocznych, gry pisane były tak, by używać CPU tak dużo, jak to tylko możliwe, a szybkość klatek była określona przez szybkość procesora. Pamiętam, że grałem na mojej maszynie 16 MHz, która sprawiałaby, że rzeczy latałyby tak szybko, że nie moglibyście zareagować, ponieważ były napisane na maszyny 1MHz. Programiści do tego doszli i zaczęli pisać gry, które ograniczyły liczbę klatek na sekundę, zwykle o 30 klatek na sekundę we wczesnych latach, później o 60 klatek na sekundę (zwykle blokowane na VSYNC monitora). To rozwiązało problem, ale było naprawdę denerwujące dla tych z nas, którzy mieli niesamowite komputery, które chciały bardziej płynnego ruchu. W końcu zaczęli pisać gry całkowicie niezależne od framerate, co pozwala na grę w 700 klatek na sekundę i uzyskać takie same wrażenia jak przy 20 klatkach na sekundę, z wyjątkiem gładszej grafiki. Może też poradzić sobie z ładowaniem zmieniającym się podczas gry, jak powiedzieli inni, co może być bardzo ważne w dzisiejszych wielozadaniowych systemach operacyjnych.

0

Jeśli się animację jako funkcję czasu, możesz być niezależna od szybkości klatek nieco, co oznacza, że ​​jeśli zrobić animację do 24fps, można łatwo dostosować animacji, aby pasowały do ​​30 fps scenariusz czy to dynamiczny (jak w zdefiniowany przez funkcję/przeciwieństwie do poklatkowe rysunki gdzie planowanie jest wszystko)

to opowiadanie, dla pełnego wyjaśnienia spojrzeć na dobre ol Robert Penner za "rozdział o Motion, Tweening and Easing.

Powiązane problemy