(español abajo)
Popeye has an unusual sprite generator. The CPU writes the sprite information (which tile, which colour palette and where in screen) in RAM. Once per frame a DMA circuit triggers and copies that region of RAM into a separate buffer. However, there is not enough time to read the buffer completely once written so the number of sprites is limited not by memory but by time.
During the rest of the frame, the contents of the buffer are scanned and compared with a screen line counter that runs slightly ahead of the actual screen output. If it is found that the sprite's Y coordinate will be visible in the coming line then the sprite information will be copied to a secondary buffer. There are two of these secondary buffers, and each one is used alternatively. When one is used to copy the data of a sprite, the other one is being read. The buffers are selected depending on the line. One is written during odd lines and read during even lines and the other operates in a complementary way. This part of the architecture is similar to other games.
The strange thing comes next. Popeye does not use a line buffer to draw the sprites in the right screen position. Rather, Popeye's sprite generator produces the output directly at the right horizontal position. This is done in two steps: first, the secondary buffers are stored with the X coordinate as the memory address (with an 8-pixel resolution), then there is a counter (chip 5E in the schematics) that synchronizes the sprite image within an 8-pixel range.
This circuit is not able to overlap sprites nicely. The circuit can only draw one sprite at a time so if two sprites are very close to each other, only one will be drawn. The sprite generators of the CAPCOM games I have so far released solved this problem by drawing all sprites in a line into a special 1-line RAM memory. This was done one line ahead of the actual output. The 1-line RAM was dumped to the screen on the next line so it was possible to have nice overlapping among sprites.
Popeye's sprite generator is certainly a step forward in 2D game hardware that sets some of the features (DMA, secondary buffers) that will be common for all future 2D video games.
Español
Los objetos de Popeye funcionan de una manera muy singular. La CPU escribe la información en la RAM (posición en pantalla, código del dibujo y color). Una vez por marco se activa un circuito de acceso directo a memoria (DMA) que copia esa RAM a un búfer. Pero el búfer es tan grande que aun copiado, luego no llega a leerse por completo.
Durante el resto del marco, el búfer se va leyendo y la coordenada Y se compara con un contador que va ligeramente adelantado respecto de la actual línea de salida. Si la comparación resulta en que el objeto ha de pintarse, se copian los datos de ese objeto a otro búfer secundario. Hay dos de estos búferes. Para cada línea hay siempre un búfer activo para escritura y otro para lectura. Y se van intercambiando de papel línea a línea. Este esquema de búfer primario y dos secundarios es muy común.
Lo raro viene a la hora de pintar los objetos en pantalla. Popeye no utiliza más búferes sino que desde aquí lanza la imagen ya al mezclador de color -donde se mezcla con el fondo y los caracteres. Usa dos trucos para saber en qué momento pintar el objeto:
1. El búfer secundario se lee con la posición horizontal de la imagen, con una resolución de 8 píxeles
2. Para cada bloque de 8 píxeles hay un contador (chip 5E del diagrama) que identifica en qué momento empezar a pintarlo
Este circuito no es capaz de solapar los objetos correctamente en pantalla. Sólo puede pintar un objeto a la vez así que si están cerca tendrá que pintar o uno u otro y el solape quedará abrupto. En los otros juegos de CAPCOM que he hecho, esto se soluciona con otro búfer más donde se pintan todos los objetos con una línea de adelanto y se pueden solapar correctamente.
El generador de objetos de Popeye es un paso adelante en los juegos 2D y tiene características que serán compartidas por todos los juegos posteriores.
Jo Tomiyori
2019-07-06 05:03:36 +0000 UTCScralings
2019-07-03 21:41:52 +0000 UTC