¿Cómo consiguen su velocidad de fotogramas dispositivos como la Game Boy Advance?

Question

He estado diseñando mi propio dispositivo de juegos de mano basado en un microcontrolador AVR y una pequeña pantalla OLED.

Empecé con una pantalla monocromática de 128x64 píxeles y puedo dibujar cómodamente en ella a más de 60 fotogramas por segundo.

Hace poco lo rehice para utilizar un OLED RGB de 128x128 píxeles sin pensar demasiado sólo para descubrir que sólo podía conseguir unos 4 FPS. ¡Después de un poco de pensamiento y refactorización cuidadosa puedo conseguir que hasta ~ 12fps si no me importa demasiado acerca de hacer cualquier otra cosa!

Mi pregunta es: ¿cómo consiguió un dispositivo como la GBA (Game Boy Advance) una tasa de fotogramas de casi 60 fps? Pensé en tener un "procesador gráfico" separado, pero me di cuenta de que seguiría siendo un cuello de botella al transferir los datos de la pantalla a eso.

También me he planteado utilizar la vestigial interfaz paralela de 8 bits que suelen tener la mayoría de estas pantallas, lo que podría suponer un aumento de velocidad de 8 veces, pero los MCUs modernos no suelen tener interfaces paralelas de hardware como las de serie, y los golpes de bits probablemente se llevarán gran parte de la ganancia de velocidad.

¿Qué otras opciones existen?

Actualmente estoy usando un ATmega1284P conectado a un controlador OLED SSD1306 vía USART-SPI. Es la versión monocromática.

La pantalla en color era un SSD1351, no conectado originalmente al hardware SPI. No estaba convencido de que hiciera suficiente diferencia, es demasiado lento en general

Sé que puedo conseguir MCUs más rápidos, pero quiero saber qué otras opciones podría explorar - ¡el procesador de GBA es mucho más lento que mi 1284!

Answer 1

Otras respuestas cubren bastante bien tu pregunta a nivel abstracto (hardware), pero al tener experiencia real con la GBA en particular me imaginé que una explicación más detallada podría valer la pena.

La GBA tenía muchos modos de dibujo y ajustes que podían utilizarse para controlar la forma en que el procesador gráfico interpretaba la RAM de vídeo, pero una cosa era ineludible: la velocidad de los fotogramas. El procesador gráfico dibujaba en la pantalla en un bucle casi (más adelante) constante. (Esta es probablemente la parte más relevante para su pregunta).

Dibujaría una línea a la vez tomando un breve descanso entre cada una. Después de dibujar la última línea para el marco, se tomaría un descanso aproximadamente igual al tiempo que se tarda en dibujar 30 líneas. Y luego vuelve a empezar. El tiempo de cada línea y el tiempo de cada cuadro estaban predeterminados y grabados en piedra. En muchos sentidos, el procesador gráfico era realmente el maestro de ese sistema y había que escribir los juegos en torno a su comportamiento, porque seguiría haciendo lo que hacía tanto si estabas preparado como si no.

Aproximadamente el 75-80% del tiempo estaba empujando activamente a la pantalla. ¿Qué tasas de fotogramas podrías conseguir si hicieras lo mismo?

Ese 80% del tiempo era también el que tenía la CPU para procesar la entrada del usuario, calcular el estado del juego y cargar los sprites/tiles en zonas de la VRAM que en ese momento estaban fuera de la pantalla (o al menos no estaban incluidos en la línea que se estaba dibujando).

El 20% entre fotogramas, era todo lo que tenía la CPU para ajustar la configuración de vídeo o la memoria RAM que repercutiría en todo el siguiente fotograma.

Al final de cada línea, el procesador gráfico enviaba una interrupción de sincronización de línea a la CPU. Esta interrupción podría usarse para ajustar la configuración de unos cuantos sprites, o unas cuantas capas de fondo (así es como se puede conseguir 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 respecta al hardware, todas esas regiones son rectangulares). Hay que tener cuidado de que estas actualizaciones sean pequeñas y terminen antes de que el procesador gráfico comience a dibujar la siguiente línea o se pueden obtener resultados feos. Cualquier tiempo dedicado a procesar estas interrupciones también recorta ese 80% del tiempo de procesamiento de la CPU...

En los juegos que sacaban el máximo partido a este sistema, ni la CPU ni el procesador gráfico se tomaban un verdadero descanso; cada uno perseguía al otro por el bucle actualizando lo que el otro no estaba mirando en ese momento.

Answer 2

La característica clave de todas las videoconsolas que las distinguía de los primeros PC y de prácticamente todos los ordenadores domésticos(1) era sprites de hardware .

La guía de programación de GBA enlazada 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 memoria especifica la ubicación de los sprites. Así, en lugar de tener que reescribir toda la memoria RAM de vídeo en cada fotograma, lo que requiere un montón de instrucciones, el procesador sólo tiene que actualizar la ubicación de los sprites.

El procesador de vídeo puede entonces trabajar píxel a píxel para determinar qué sprite dibujar en ese punto.

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

(1) Excepción notable: Amiga

Answer 3

"Mi pregunta es: ¿cómo consiguió un dispositivo como la GBA una tasa de fotogramas de casi 60 fps?"

Para responder sólo a la pregunta, lo hicieron con un procesador gráfico. Estoy bastante seguro de que la Game Boy utilizaba gráficos de sprites. En un nivel superior, eso significa que el procesador de gráficos se carga cosas como una imagen de un fondo, y una imagen de Mario, y una imagen de la princesa Peach, etc. Entonces el procesador principal emite órdenes como "mostrar el fondo desplazado esta cantidad en x e y, superponer la imagen de Mario #3 en esta posición x, y", etc. Así que el procesador principal no se preocupa en absoluto de dibujar cada píxel, y el procesador gráfico no se preocupa en absoluto 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.

Answer 4

La GBA tenía un procesador bastante lento. El ARM7 es muy bueno; simplemente lo hicieron funcionar lentamente y no le dieron casi ningún recurso.

Hay una razón por la que muchos juegos de Nintendo en ese momento y antes eran de desplazamiento lateral. HARDWARE. Todo se hacía en hardware. Tenías múltiples capas de fichas más uno o más sprites y el hardware hacía todo el trabajo para extraer los píxeles de esas tablas y manejar la pantalla.

Construyes el conjunto de baldosas por adelantado y luego tienes una pequeña memoria que es un mapa de baldosas. ¿Quieres que la baldosa inferior izquierda sea la baldosa 7? Pones un 7 en esa posición de memoria. ¿Quieres que la siguiente baldosa sea la 19? En el conjunto de azulejos, pones un 19 allí, y así sucesivamente para cada capa que hayas habilitado. Para el sprite, sólo tienes que establecer la dirección x/y. También puedes hacer el escalado y la rotación configurando algunos registros y el hardware se encarga del resto.

El modo 7, si no recuerdo mal, era un modo de píxeles, pero era como una tarjeta de vídeo tradicional en la que metes bytes que cubren el color de un píxel y el hardware se encarga del refresco del vídeo. Creo que podías hacer ping pong o al menos cuando tenías un nuevo fotograma podías voltearlos, pero no recuerdo bien. De nuevo, el procesador estaba bastante underclocked para esa época y no tenía demasiados recursos rápidos. Así que mientras algunos juegos eran modo 7, muchos eran side-scrollers basados en baldosas...

Si quieres una solución que tenga una alta tasa de fotogramas, tienes que diseñar esa solución. No puedes tomar cualquier pantalla vieja que encuentres y hablar con ella vía SPI o I²C o algo así. Poner al menos un framebuffer delante, idealmente dos, y tener control de filas y columnas si es posible sobre esa pantalla.

Varias de las pantallas que sospecho que estás comprando tienen un controlador con el que realmente estás hablando. Si quieres un rendimiento tipo GBA/consola, crea/implementa el controlador. O compras/construyes con una GPU/chip de vídeo/bloque lógico, y utilizas HDMI u otra interfaz común en un monitor de serie.

El hecho de que una bicicleta tenga neumáticos, cadena y marchas no significa que pueda ir tan rápido como una moto. Hay que diseñar el sistema para que satisfaga sus necesidades de rendimiento, de punta a punta. Puedes poner esa rueda de bicicleta en esa moto, pero no tendrá el rendimiento deseado; todos los componentes tienen que formar parte del diseño global.

Asteroides también funcionaba así; sólo necesitaba un 6502. Los gráficos vectoriales se hacían con una lógica separada; el 6502 enviaba una pequeña cadena de datos al controlador de gráficos vectoriales, que utilizaba una ROM y esos datos para hacer el trazado xy del rayo y z, on/off... Algunos standups tenían procesadores separados para manejar el audio y el video por separado del procesador que calculaba el juego. Por supuesto, hoy en día el vídeo es manejado por algunos cientos, si no miles, de procesadores que están separados del procesador principal...

Answer 5

¿cómo pudo un dispositivo como la GBA alcanzar una tasa de fotogramas de casi 60 fps?

Hardware.

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

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

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

Pero no importa la cpu, golpear con bits la interfaz de la pantalla va a ser una mierda.

Creo que la Atari 2600 utilizaba el golpeo de bits de la CPU para enviar la imagen al televisor. Eso es un poco obsoleto.