¿Cómo pueden los dispositivos como el Game Boy Advance alcanzar su velocidad de fotogramas?

Otras respuestas cubren su pregunta bastante bien en un nivel abstracto (hardware), pero teniendo experiencia real con el GBA en particular, pensé que valdría la pena una explicación más detallada.

El GBA tenía muchos modos de dibujo y configuraciones que podían usarse para controlar cómo el procesador de gráficos interpretaba la RAM de video, pero una cosa era inevitable: la velocidad de cuadros. El procesador gráfico estaba dibujando en la pantalla casi en un bucle constante (más sobre esto a continuación). (Este es probablemente el bit más relevante para su pregunta).

Dibujaría una línea a la vez y tomaría un breve descanso entre cada una. Después de dibujar la última línea para el marco, tomaría un descanso aproximadamente igual al tiempo que toma dibujar 30 líneas. Entonces comienza de nuevo. El tiempo de cada línea y el tiempo de cada cuadro fueron predeterminados y establecidos en piedra. En muchos sentidos, el procesador de gráficos era realmente el maestro de ese sistema y usted necesitaba escribir sus juegos en torno a su comportamiento, ya que continuaría haciendo lo que hizo si estuviera listo o no.

Aproximadamente el 75-80% del tiempo estuvo presionando activamente en la pantalla. ¿Qué velocidad de fotogramas podrías lograr si estuvieras haciendo lo mismo?

Ese 80% del tiempo también fue lo que la CPU tuvo que procesar las entradas del usuario, calcular el estado del juego y cargar sprites / mosaicos en áreas de VRAM que estaban actualmente fuera de pantalla (o al menos no se incluyeron en la línea actual que se está dibujando ).

El 20% entre cuadros, fue todo lo que la CPU tuvo que ajustar la configuración de video o RAM que impactaría en todo el siguiente cuadro.

Al final de cada línea, el procesador de gráficos enviaría una interrupción de sincronización de línea a la CPU. Esta interrupción se podría usar para modificar configuraciones en algunos sprites, o en algunas capas de fondo (así es como puede obtener un efecto como un foco cónico, cambiando el tamaño y la ubicación de una de las máscaras rectangulares entre cada línea dibujada. en lo que concierne al hardware, todas esas regiones son rectangulares). Debe tener cuidado de mantener estas actualizaciones pequeñas y terminarlas antes de que el procesador gráfico comience a dibujar la siguiente línea o puede obtener resultados feos. El tiempo dedicado al procesamiento de estas interrupciones también se reduce al 80% del tiempo de procesamiento de la CPU ...

Para los juegos que sacaron el máximo provecho de este sistema, ni la CPU ni el procesador gráfico tomaron un verdadero descanso; cada uno perseguía al otro por el circuito actualizando lo que el otro no estaba mirando actualmente.

La característica clave de todas las consolas de juegos que las distinguían de las primeras PC y prácticamente todas las computadoras domésticas (1) era sprites de hardware .

La guía de programación GBA vinculada muestra cómo funcionan desde el punto de vista del procesador principal. Los mapas de bits que representan al jugador, el fondo, los enemigos, etc. se cargan en un área de memoria. Otra área de la memoria especifica la ubicación de los sprites. Entonces, en lugar de tener que volver a escribir toda la RAM de video en cada fotograma, lo que requiere muchas instrucciones, el procesador solo tiene que actualizar la ubicación de los sprites.

El procesador de video puede trabajar píxel por píxel para determinar qué sprite dibujar en ese punto.

Sin embargo, esto requiere una memoria RAM de doble puerto compartida entre los dos, y creo que en el GBA el procesador de video está en el mismo chip que el ARM principal y el procesador secundario Z80.

(1) Excepción notable: Amiga

"Mi pregunta es: ¿cómo logró un dispositivo como el GBA una velocidad de cuadros de casi 60 fps?"

Para responder solo a la pregunta, lo hicieron con un procesador de gráficos. Estoy bastante seguro de que el Game Boy usaba gráficos sprite. En un nivel superior, eso significa que el procesador de gráficos se carga cosas como una imagen de fondo, una imagen de Mario y una imagen de Princess Peach, etc. Luego, el procesador principal emite comandos como "mostrar el desplazamiento de fondo con este tanto en x como en y, superponiendo la imagen de Mario # 3 en esta posición x, y ", etc. Por lo tanto, el procesador principal no se preocupa absolutamente absolutamente de dibujar cada píxel, y el procesador gráfico no se preocupa absolutamente absolutamente de calcular el estado del juego. Cada uno está optimizado para lo que tiene que hacer, y el resultado es un videojuego bastante bueno sin utilizar mucha potencia de cálculo.

El GBA tenía un procesador bastante lento. El ARM7 es muy bonito; simplemente lo ejecutaron lentamente y lo dieron casi sin recursos.

Hay una razón por la que muchos de los juegos de Nintendo en ese momento y antes eran de desplazamiento lateral. HARDWARE. Todo está hecho en hardware. Tenías varias capas de mosaicos más uno o más sprites y el hardware hizo todo el trabajo para extraer píxeles de esas tablas y controlar la pantalla.

Construyes el conjunto de mosaicos al frente y luego tuviste una memoria pequeña que era un mapa de mosaicos. ¿Quieres que el azulejo inferior izquierdo sea azulejo 7? Pones un 7 en esa ubicación de memoria. ¿Quieres que la próxima baldosa sea la baldosa 19? En el conjunto de mosaicos, colocas un 19 allí, y así sucesivamente para cada capa que hayas habilitado. Para el sprite, simplemente establece la dirección x / y. También puede realizar escalas y rotaciones configurando algunos registros y el hardware se encarga del resto.

Modo 7, si recuerdo bien, era un modo de píxel, pero era como una tarjeta de video tradicional en la que colocas bytes en el color de un píxel y el hardware se encarga de la actualización del video. Creo que puedes hacer ping pong o al menos cuando tienes un nuevo marco puedes voltearlos, pero no recuerdo bien. Nuevamente, el procesador estuvo bastante cerrado en ese momento y no tenía demasiados recursos rápidos. Entonces, mientras que algunos juegos eran modo 7, muchos eran desplazadores laterales basados en mosaicos ...

Si desea una solución con una velocidad de cuadros alta, debe diseñar esa solución. No puedes simplemente tomar cualquier pantalla vieja que encuentres y hablar con ella a través de SPI o I²C o algo así. Coloque al menos un framebuffer delante de él, idealmente dos, y tenga control de filas y columnas si es posible sobre esa pantalla.

Algunas de las pantallas que sospecho que está comprando tienen un controlador con el que están hablando. Si desea un rendimiento de tipo GBA / consola, cree / implemente el controlador. O compra / construye con una GPU / chip de video / lógica y usa HDMI u otra interfaz común en un monitor de valores.

El hecho de que una bicicleta tenga neumáticos y una cadena y engranajes no significa que pueda ir tan rápido como una motocicleta. Debe diseñar el sistema para satisfacer sus necesidades de rendimiento, de principio a fin. Puede poner esa rueda de bicicleta en esa motocicleta, pero no funcionará como se desea; Todos los componentes deben ser parte del diseño general.

Asteroids también funcionó de esta manera; solo necesitaba un 6502. Los gráficos vectoriales se hicieron con lógica separada; el 6502 envió una pequeña cadena de datos al controlador de gráficos vectoriales, que usaba una ROM y esos datos para realizar el trazado xy de la viga y la z, encendido / apagado ... Algunas pantallas tenían procesadores separados para manejar el audio y el video por separado. El procesador de computación del juego. Por supuesto, hoy en día, el video es manejado por cientos, si no miles, de procesadores que están separados del procesador principal ...

  

¿Cómo logró un dispositivo como el GBA una velocidad de cuadros de casi 60 fps?

Hardware.

Tiene memoria de gráficos, que puede o no compartir el mismo bus que la memoria de programa / datos ... pero lo importante es que tiene un procesador de gráficos que lee la memoria 60 veces por segundo y envía los datos a la LCD mediante una interfaz optimizada que está diseñada para hacerlo de manera eficiente.

Puede hacer lo mismo con cualquier microcontrolador moderno equipado con un periférico de "interfaz LCD", por ejemplo, el LPC4330, aunque esto podría ser excesivo. Por supuesto, necesitará un panel LCD compatible.

Con los modernos microcontroladores rápidos (es decir, ARM no AVR) y una pantalla tan pequeña, es probable que no necesite sprites o blitter para acelerar las operaciones gráficas. Con un AVR de 8 bits puede ser lento.

Pero no importa la CPU, el bit que golpea la interfaz a la pantalla va a apestar.

Creo que el Atari 2600 utilizó CPU bit banging para enviar la imagen al televisor. Eso es un poco obsoleto.