Jestem początkującym uczącym się animacji komputerowej (do gier). Jak dotąd jedyną metodą, na którą się natknąłem, jest rysowanie każdej klatki, każdej aktualizacji klatki. Tak więc na początku każdej klatki cała klatka jest usuwana, a następnie potrzebne są rzeczy, które są przerysowywane.

Moje pytanie brzmi, czy ta metoda jest jedyną, która jest używana do tworzenia animacji i gier. Wygląda na to, że jest to trochę nieefektywne. Nie do końca rozumiem też, jak ta metoda działałaby w grach 3D . Czy ktoś mógłby wyjaśnić to bardziej szczegółowo?

Bardzo stare gry używały techniki, w której przerysowywano tylko te części ramki, które zmieniły się w tej ramce. Co pamiętam, gra „Little Big Adventure” wykorzystuje tę technikę (1994). Ale widać, że gra przez większość czasu ma nieruchomą kamerę. scena zostanie przerysowana tylko wtedy, gdy wyjdziesz z widocznego obszaru. Jeśli grasz w tę grę, zauważysz również niewielkie opóźnienie w tej ramce. W nowoczesnych procesorach graficznych z nowoczesnymi silnikami gier sytuacja się zmieniła. Wszystko jest przerysowane na każdej ramce. W zależności od techniki renderowania rzeczy mogą być renderowane nawet kilka razy. Moc obliczeniowa GPU jest niewiarygodnie wysoka, jeśli używasz go poprawnie. Ale zdarza się ponowne użycie. Na przykład silnik może zdecydować o aktualizacji mapy cienia tylko co 5 klatkę. Lub oświetlenie nie jest aktualizowane, dopóki nie ma zmian w źródłach światła.

Nie.

Przynajmniej jeśli dodasz stare gry z lat 70., w których korzystano z wyświetlaczy wektorowych.

Na przykład szeroko znana gra Asteroids, która została pierwotnie opracowana dla wyświetlaczy wektorowych, które są zasadniczo innym sposobem renderowania grafiki na ekranie.

Monitory wektorowe były również używane w niektórych grach arkadowych z końca lat 70. i połowy lat 80., takich jak Asteroidy, Burza i Gwiezdne Wojny. Atariuszuję pojęcie Quadrascan, aby opisać technologię stosowaną w arkadach gier wideo.

https://en.wikipedia.org/wiki/Vector_monitor

Nowoczesne grafiki są w 100% stworzone dla rasterizaton, który z definicji zapisuje zawartość bufora graficznego na wyświetlaczu każdej klatki.

Na najniższym poziomie procesor graficzny na twoim komputerze rzeczywiście obliczy każdą klatkę od podstaw i wyśle ​​ją na ekran. Będziesz jednak na to narażony, tylko jeśli sam poradzisz sobie z tymi niskopoziomowymi rzeczami [1]. Jednak każda grafika (a wraz z nią silnik gry) poradzi sobie z tymi rzeczami i możesz wyrazić scenę pod względem wielu elementów, które można modyfikować między ramkami, ale będą trwałe.

... jak ta metoda działałaby w grach 3D ...

Elementy w przestrzeni 3D są trwałe, silnik graficzny ponownie obliczy obraz na ekranie dla wszelkich dokonanych zmian (ruch kamery itp.)

[1] ... na przykład, jeśli piszesz własny silnik [2] z czymś takim jak OpenGL. Nawet w takim przypadku prawdopodobnie przechowujesz trwałe elementy między ramkami.

[2] Która nie jest opcją na twoim obecnym poziomie umiejętności.

Krótka odpowiedź: nie

Długa historia:

Kiedy w szkole nauczyłem się programowania gier, nauczono nas:

Zdecyduj, jaką szybkość klatek na sekundę chcieliśmy w grze (na przykład 30).

Napisz kod, który dodaje 1 do licznika dla każdego interwału (33 ms dla 30 fps). Ten kod działa równolegle z pętlą gry.

Następnie pętla gry, która wykonuje obliczenia dla gry (aktualizacja stanu gry), zmniejszy ten sam licznik o 1 dla każdej klatki. Ale obliczenia graficzne i rysowanie na ekranie zostaną wykonane tylko wtedy, gdy licznik będzie wynosił zero.

Rezultat jest taki, że graficzna szybkość klatek dostosowuje się w zależności od tego, jak dobrze procesor obsługuje obliczenia w grze. Gdy w grze nie dzieje się zbyt wiele, obliczenia są łatwe, a liczba klatek na sekundę grafiki będzie wyższa niż faktyczna aktualizacja stanu gry (w zasadzie marnowanie cykli, ponieważ rysujemy ten sam stan gry więcej niż raz na ekranie).

Ale potem dużo się dzieje w grze, procesor będzie miał więcej do zrobienia, a aktualizacje stanu gry będą miały pierwszeństwo przed rysowaniem na ekranie.

Przez większość czasu gra będzie aktualizować się w zamierzonym tempie, ale będzie się wydawać „opóźniona”, ponieważ nie będzie widać każdej aktualizacji na ekranie. Może to być lepsze niż spowolnienie całej gry, ponieważ zmuszasz ją do losowania każdej aktualizacji na ekranie.

Wszystko to zostało wykonane w C ++, bez silnika gry ani karty graficznej. Wszystko działało na jednym rdzeniu procesora. Użyliśmy bibliotek do grafiki 2D.

Zanim będzie można stwierdzić, czy gry wideo „rysują” wyświetlanie każdej klatki, należy najpierw zdefiniować, co oznacza „rysować”. Z pewnością istnieje wiele gier wideo, z pewnością nie wszystkie rysują każdą klatkę, tworząc mapę bitową od zera; Rzeczywiście, wielu platformach nigdy zebrać pełne mapy bitowe w ogóle .

Istnieje kilka metod generowania wyświetlania przez gry wideo. Bardzo mała liczba ma procesor włączający i wyłączający wiązkę elektronów lub dla każdego piksela lub, w przypadku gier ze skanowaniem wektorowym, ustaw współrzędną XY każdej kropki do wykreślenia. Większość gier, które to robią, robi to głównie w celu wykazania, że ​​procesor jest wystarczająco szybki. Częściej gry będą miały sprzęt, który przy braku zaangażowania procesora wielokrotnie wyświetlałby pewien wzór pikseli lub wektorów. Ten wzorzec może być wytworzony przez sekwencyjny odczyt danych z regionu pamięci i interpretację każdego bitu lub grupy bitów jako koloru piksela (nazywa się to wyświetlaniem mapy bitowej). W niektórych przypadkach sprzęt może odczytać bajt pamięci dla każdego 8x8, 16x16, lub inny obszar wielkości wyświetlacza, a następnie użyj tego bajtu, aby wybrać zakres pamięci do odczytu dla danych pikseli (jest to często nazywane wyświetlaniem mapy znaków). Niektóre platformy sprzętowe mogą nakładać wiele ekranów bitmapowych z konfigurowalnymi pozycjami. Są to tak zwane duszki.

Niektóre platformy nie pozwalają na zmianę wzorca wyświetlania podczas wysyłania go na ekran, ale zamiast tego wymagają, aby wszystkie aktualizacje pojawiły się po zakończeniu rysowania jednej ramki przez belkę, ale przed rozpoczęciem rysowania następnej. Na takich platformach wszystko, co pojawi się na ramce, musi zostać załadowane do sprzętu wyświetlającego przed rozpoczęciem tej ramki, a wyświetlanie będzie ograniczone do pokazania wzorca, który można ustawić naraz. Gdyby procesor przestał działać podczas wyświetlania ramki, ta sama ramka byłaby pokazywana w nieskończoność. Inne platformy umożliwiają zmianę lub ponowną konfigurację wzoru podczas rysowania go na ekranie. Umożliwia to pokazanie ekranu, który jest o wiele bardziej skomplikowany niż sam obwód wideo.

Większość osobistych gier komputerowych używa sprzętu skonfigurowanego do rysowania pojedynczego ekranu bitmapy, a następnie rysowania na tym ekranie wszystkiego, co musi różnić się od tego, co już jest. Czasami może być łatwiej rysować rzeczy bez względu na to, czy jest to rzeczywiście konieczne w konkretnym przypadku, ale jeśli kod może łatwo stwierdzić, że nie ma powodu, aby część ekranu uległa zmianie, wydajność można poprawić, pomijając tę ​​część. Dzisiejsze platformy są często wystarczająco szybkie, aby w trakcie kadru mogły wielokrotnie rysować cały ekran, ale historycznie tak nie było. Na przykład najszybszy możliwy kod do zapisania wszystkich pikseli na ekranie wysokiej rozdzielczości komputera Apple II zająłby więcej niż dwie klatki, a najszybszy możliwy kod do skopiowania wszystkich pikseli na komputerze Apple II ” Ekran o wysokiej rozdzielczości z innego bufora zająłby dwa razy więcej. Uzyskanie dobrej wydajności wymagało, aby gry aktualizowały tylko rzeczy, które faktycznie się zmieniały, i to właśnie robiły dobre gry.

Krótko mówiąc, powiedziałbym, że nie wszystkie ramki są narysowane, ale tylko te, które są wymagane do przedstawienia twojej historii lub tematu gry lub rozgrywki. Ponadto liczy się czas, w którym w określonych przypadkach chcesz się zdarzyć.