¿Todos los juegos se hacen dibujando cada cuadro?

60

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?

eeze
fuente
Los comentarios no son para discusión extendida; Esta conversación se ha movido al chat .
Josh
John Carmack casi inventó el enfoque en PC para desplazarse lateralmente a pantalla completa dibujando solo la delgada porción vertical de la pantalla que ha cambiado. Las PC simplemente no podían actualizar la pantalla completa lo suficientemente rápido sin esta técnica. Lo usó en muchos juegos 2D a principios de los 90, como el Comandante Keen. Lea "Masters of Doom" para más información.
Ceniza

Respuestas:

68

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.

Arne
fuente
23
No son solo juegos antiguos. En EA, hubo un impulso para reducir el uso de la batería de la computadora portátil para ciertos juegos "casuales", y una técnica consistía en volver a dibujar partes de la pantalla. A veces podría ver esto en Los Sims 3 si dejaba la cámara inmóvil y un sim caminaba por la pantalla, a veces había un error en el que el redibujado no era lo suficientemente grande y se veían píxeles en una línea a través de la pantalla. pantalla. Solo tenía que mover la cámara ligeramente para forzar un redibujo completo y la línea desaparecería.
Kevin Fee
12
Muy viejo .. 1994 ... me siento viejo ahora ...
además
44
@alseether de edad en términos de juego. Recuerde que pasamos de manchas de píxeles de 8 bits a realismo fotográfico (en escenas pre-renderizadas, si no en acción en vivo) en solo 20 ~ 30 años.
Jared Smith
16

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.

Sandy Chapman
fuente
77
Las pantallas de vectores ni siquiera tienen obviamente un "marco".
hobbs
2
@hobbs Correcto, lo que hace que mi respuesta siga siendo correcta ya que la respuesta a "¿Todos los juegos se hacen dibujando cada cuadro?" es "No, ni siquiera todos los juegos se basan en cuadros".
Sandy Chapman
1
sin embargo, en un sentido más profundo, la pregunta era dibujar repetidamente todos los elementos visibles, no solo los elementos que se mueven, y para la mayoría de las pantallas de vectores la respuesta sigue siendo "sí" (el tubo de almacenamiento de imágenes sería una excepción)
szulat
@szulat de una manera que es cierta, pero para ser justos, todavía no dibuja los huecos donde la pantalla es negra. Solo actualiza los elementos visibles en la pantalla. Es decir, en los asteroides, solo se vuelve a dibujar la nave y los asteroides restantes en la pantalla.
Sandy Chapman
@SandyChapman y en otro nivel, realmente hay poca diferencia. un juego actualiza la memoria de la pantalla o los sprites cuando algo cambia. de lo contrario, la parte correspondiente de la pantalla permanece estática. Esto es cierto tanto para los sistemas de trama como de vector: los "asteroides" manejan la actualización de la pantalla desde la memoria de la pantalla (¡vector!) sin molestar a la CPU, de manera similar a cómo el hardware del espectro zx genera su señal de video de trama. si el haz real o imaginario de CRT está dibujando polígonos o escaneando la pantalla en un patrón fijo, es secundario.
szulat
11

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.

TauCraft
fuente
¿Tiene referencias para admitir que "el procesador de gráficos de su máquina calculará cada cuadro desde cero"?
Kromster dice que apoya a Monica el
@Kromster: es sobre todo una cuestión de eficiencia. Como cada cuadro puede requerir un cálculo completo, y no se sabe exactamente qué partes no lo hacen, necesitaría un cálculo costoso para determinar exactamente qué bits se podrían guardar. Incluso si fuera una mejora del rendimiento neto, conduciría a velocidades de cuadro inconsistentes.
MSalters
@MS modifica la forma en que está redactada, contradice muchos puntos en muchas respuestas vecinas.
Kromster dice que apoya a Mónica el
Yo diría que la afirmación "el procesador de gráficos en su máquina calculará cada cuadro desde cero" es técnicamente falsa. La GPU calcula exactamente lo que le dices. Si desea reutilizar el marco anterior, lo hará (de hecho, ese es su valor predeterminado). Muchos motores de juegos modernos (e incluso las GUI del sistema operativo) eligen comenzar desde cero (donde el marco anterior solo se muestra si el nuevo marco no terminó de renderizarse a tiempo), pero no es necesario.
Ove
Ni siquiera estoy seguro de qué constituiría una referencia para "la pantalla tiene que ser borrada", pero tengo una referencia de cómo se representa un marco en Doom: adriancourreges.com/blog/2016/09/09/doom-2016- estudio de gráficos ; No olvide que una tarjeta gráfica moderadamente alta debería ser capaz de gestionar un billón de cálculos por segundo, varios miles por píxel.
pjc50
2

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.

usuario985366
fuente
1
Recuerdo el juego "Golden Axe". Cuando se jugaba en 8086, el juego era más lento y mucho más fácil de manejar que en 286, por ejemplo, donde las cosas se movían más rápido. Solo para tu información.
akostadinov
0

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.

Super gato
fuente
1
Llegué a la mitad de esta respuesta y no estoy seguro de cómo realmente está respondiendo la pregunta. Su primer párrafo habla de CPU, coordenadas XY, haces de electrones, bytes de memoria y sprites, pero nada de esto se trata visiblemente de dibujar cada cuadro. El segundo párrafo habla sobre los patrones de visualización en detalle, y luego me pierde. Creo que debe tomar cualquier parte de esto sobre volver a dibujar la pantalla, colocarla en la parte superior en una declaración clara y luego conectar cualquier otra cosa sobre la que deba hablar para explicar lo que está sucediendo.
doppelgreener
1
@doppelgreener: La noción de "dibujar" cada fotograma es un poco vaga. Algo tiene que hacer todo lo necesario para generar cada trama, pero hay muchas formas en que el trabajo puede dividirse entre la CPU y el hardware. Algunas formas requieren que la CPU esté involucrada en cada cuadro, incluso con partes de la pantalla que parecen iguales entre un cuadro y el siguiente, mientras que otros no. Si bien cualquier juego de LCD o CRT requerirá que algo salga por cada marco que no esté en blanco [los juegos que usan papel electrónico o pantallas de punto invertido podrían no], las acciones necesarias pueden considerarse o no "dibujar".
supercat
Le sugiero que comience con un lenguaje sencillo (ya sea que "dibujemos un marco" constantemente) y trabaje desde allí explicando más detalles técnicos sobre por qué esa podría no ser una forma precisa de expresarlo, en lugar de sumergirse directamente en los detalles. . Su publicación necesita un resumen ejecutivo, básicamente, y una introducción, antes de comenzar a examinar las cosas en profundidad.
doppelgreener
-11

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.

Sakib Zang
fuente
99
Esto ni siquiera tiene sentido en contra de la pregunta formulada ... Creo que has confundido el "marco" para otra cosa ... ¿te estás confundiendo con elementos de un guión gráfico? OP está hablando específicamente de marcos en el contexto de renderizado
Trotski94