Soy un principiante aprendiendo sobre animación por computadora (para juegos). Hasta ahora, el único método que he encontrado es dibujar cada cuadro, cada actualización de cuadro. Entonces, al comienzo de cada fotograma, se borra todo el fotograma, y ​​luego se vuelven a dibujar las cosas para eso.

Mi pregunta es si este método es el único que se usa para hacer animaciones y juegos. Parece que es un poco ineficiente. Tampoco entiendo cómo funcionaría este método para los juegos en 3D . ¿Alguien podría explicar esto con más detalle?

Los juegos muy antiguos usaban una técnica en la que solo esas partes de un cuadro se vuelven a dibujar que cambiaron en ese cuadro. Lo que puedo recordar, el juego "Little Big Adventure" utiliza esta técnica (1994). Pero puedes ver que el juego tiene la mayoría de las veces una cámara estática. solo cuando te mueves fuera del área visible, la escena se vuelve a dibujar. Si juegas, también notarías un pequeño retraso en ese cuadro. En las GPU modernas con motores de juego modernos, las cosas han cambiado. Todo se vuelve a dibujar en cada cuadro. Dependiendo de la técnica de renderizado, las cosas pueden incluso renderizarse varias veces. La potencia informática de una GPU es increíblemente alta cuando la usas correctamente. Pero la reutilización está sucediendo. Por ejemplo, un motor podría decidir actualizar el mapa de sombras solo cada quinto cuadro. O la iluminación no se actualiza siempre que no haya cambios en las fuentes de luz.

No.

Al menos si incluye juegos antiguos de los años 70 que usaban pantallas vectoriales.

Por ejemplo, el conocido juego Asteroids, que se desarrolló originalmente para pantallas vectoriales, que son una forma fundamentalmente diferente de representar gráficos en una pantalla.

Los monitores vectoriales también fueron utilizados por algunos juegos de arcade de finales de los años setenta a mediados de los ochenta, como Asteroids, Tempest y Star Wars. Atarius usó el término Quadrascan para describir la tecnología cuando se usaba en sus videojuegos.

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

Los gráficos de hoy en día están hechos casi al 100% para rasterizar, que por definición escribe el contenido de un búfer de gráficos en la pantalla en cada fotograma.

En el nivel más bajo, el procesador de gráficos de su máquina calculará cada cuadro desde cero y lo enviará a su pantalla. Sin embargo, solo estará expuesto a esto si maneja estas cosas de bajo nivel usted mismo [1] Cualquier gráfico (y con ese motor de juego) sin embargo, manejará estas cosas por usted, y usted es libre de expresar la escena en términos de muchas entidades que podría modificar entre marcos, pero serán persistentes.

... cómo funcionaría este método para juegos en 3D ...

Los elementos en el espacio 3D son persistentes, el motor de gráficos, nuevamente, volvería a calcular la imagen en su pantalla para cualquier cambio que ocurriera (movimiento de la cámara, etc.)

[1] ... por ejemplo, si escribe su propio motor [2] con algo como OpenGL. Incluso en ese caso, es probable que almacene cosas persistentes entre cuadros.

[2] Que no es una opción en tu nivel de habilidad actual.

Respuesta corta: no.

Larga historia:

Cuando aprendí algo de programación de juegos en la escuela, nos enseñaron a hacer lo siguiente:

Decide qué tasa de fps queríamos en el juego (30 por ejemplo).

Escriba un código que agregue 1 a un contador para cada intervalo (33 ms para 30 fps). Este código se ejecuta simultáneamente con el bucle del juego.

Luego, el ciclo del juego que realiza los cálculos para el juego (actualización del estado del juego) reducirá el mismo contador en 1 para cada cuadro. Pero los cálculos gráficos y el dibujo a la pantalla solo se realizarán si el contador está en cero.

El resultado es que la velocidad de cuadros gráfica se ajustará dependiendo de qué tan bien la CPU maneja los cálculos en el juego. Cuando no sucede demasiado en el juego, los cálculos son fáciles y la velocidad de fotogramas de los gráficos será mayor que la actualización del estado del juego real (básicamente ciclos de pérdida ya que dibujamos el mismo estado del juego más de una vez en la pantalla).

Pero luego están sucediendo muchas cosas en el juego, la CPU tendrá más trabajo que hacer y las actualizaciones de estado del juego tendrán prioridad sobre el dibujo en la pantalla.

La mayoría de las veces, el juego seguirá actualizándose a la velocidad prevista, pero aparecerá "lento" ya que no verá cada actualización en la pantalla. Esto puede ser preferible a que todo el juego se desacelere porque lo obligas a dibujar cada actualización en la pantalla.

Todo esto se hizo con C ++ y sin motor de juego, ni tarjeta gráfica. Todo funcionó en una sola CPU central. Utilizamos algunas bibliotecas para gráficos 2D.

Antes de poder decir si los videojuegos "dibujan" la pantalla en cada cuadro, primero es necesario definir qué se entiende por "dibujar". Ciertamente, hay muchos videojuegos que no dibujan todos los cuadros al ensamblar un mapa de bits desde cero; de hecho, muchas plataformas de juegos nunca ensamblan mapas de bits completos en absoluto .

Hay algunos enfoques que los videojuegos pueden tomar para generar una pantalla. Un número muy pequeño hace que la CPU active y desactive el haz de electrones o para cada píxel o, para juegos de escaneo de vectores, establezca la coordenada XY de cada punto que se trazará. La mayoría de los juegos que hacen esto lo hacen principalmente para demostrar que la CPU es lo suficientemente rápida. Más comúnmente, los juegos tendrán hardware que, en ausencia de la participación de la CPU, generaría algún patrón de píxeles o vectores en la pantalla repetidamente. Este patrón puede producirse leyendo datos secuencialmente desde una región de memoria e interpretando cada bit o grupo de bits como un color de píxel (esto se denomina visualización de mapa de bits). En algunos casos, el hardware puede leer un byte de memoria por cada 8x8, 16x16, u otra región de tamaño de la pantalla y luego use ese byte para seleccionar un rango de memoria para leer datos de píxeles (esto a menudo se llama una pantalla de mapa de caracteres). Algunas plataformas de hardware pueden superponer múltiples pantallas de mapa de bits con posiciones configurables. Estos se conocen como sprites.

Algunas plataformas no permiten cambiar el patrón de visualización mientras se envía a la pantalla, sino que requieren que todas las actualizaciones se realicen después de que el haz haya terminado de dibujar un cuadro, pero antes de que comience a dibujar el siguiente. En tales plataformas, todo lo que va a aparecer en un marco debe cargarse en el hardware de la pantalla antes del inicio de ese marco, y la pantalla se limitará a mostrar un patrón que se pueda configurar de una vez. Si la CPU dejara de funcionar mientras se muestra el marco, ese mismo marco se seguiría mostrando indefinidamente. Otras plataformas permiten cambiar o volver a configurar el patrón mientras se dibuja en la pantalla. Esto hace posible mostrar una pantalla que es mucho más complicada de lo que el circuito de video podría manejar por sí solo.

La mayoría de los juegos de computadora personal usan hardware configurado para dibujar una sola pantalla de mapa de bits, y luego dibujan en esa pantalla cualquier cosa que deba ser diferente de lo que ya existe. A veces puede ser más fácil dibujar cosas sin tener en cuenta si es realmente necesario en un caso particular, pero si el código puede decir fácilmente que no hay razón para que cambie parte de la pantalla, el rendimiento puede mejorarse omitiendo esa parte. Las plataformas actuales a menudo son lo suficientemente rápidas como para poder dibujar la pantalla completa muchas veces durante el transcurso de un marco, pero históricamente ese no fue el caso. El código más rápido posible para escribir todos los píxeles en la pantalla de alta resolución de la computadora Apple II, por ejemplo, tomaría más de dos cuadros, y el código más rápido posible para copiar todos los píxeles en la computadora Apple II ' La pantalla de alta resolución de otro buffer tomaría el doble de eso. Obtener un buen rendimiento requería que los juegos solo actualizaran cosas que realmente estaban cambiando, y eso es lo que generalmente hicieron los buenos juegos.

Para decirlo brevemente, diría que no todos los cuadros están dibujados, sino solo los que se requieren para presentar su historia o tema del juego o juego. Además, el momento de las cosas que le gustaría que suceda en ciertos casos sería importante.