HU6270
Este es el nombre
del procesador gráfico de la PC Engine, uno de los dos chips de video.
El Hu6270 también llamado VDC “Video Display
Controller”.
Contrariamente a la cpu, este está basado en una arquitectura 16 bits y dispone de todos los elementos para ofrecer una excelente construcción
gráfica. Está conectado a una cantidad
importante de memoria de vídeo que le han reservado, 64 kb, mucho más que cualquier
consola contemporánea. La Super Nintendo, aparecida tres años más tarde, dispone
de la misma cantidad de memoria de vídeo, 64kb. Cuando esta consola centra su estructura en un 80% en este apartado exclusivamente, descompensando
gravemente otros apartados técnicos, como ya se ha explicado largo y tendido.
El Hu6270 gestiona
los decorados y los sprites (los elementos móviles de un videojuego en dos
dimensiones).
Disponer de solo
un scroll significa que, de base, la PC Engine
no puede ofrecer un desplazamiento paralelo, es decir, un desplazamiento
de la decoración a varios niveles de velocidad con el fin de dar la ilusión de
profundidad (como el decorado visto a través de una ventana de un tren, por
ejemplo). Para resumirlo, varios scrolles.
Esta técnica ha
sido puesta en práctica muchas veces por
la Mega Drive y la Super Nintendo que disponen respectivamente de tres y cinco
planos. En el caso de la PC Engine: SI, un solo plano de decoración está
disponible, pero hay una enorme lista de juegos que usan más de uno, dos, tres
o cinco, incluso efectos de profundad enormes como los usados en Dead Moon,
Spprigan Mark 2, Pc Denjin Super Air Zonk. Y juegos con varios scrolles a
diferentes velocidades, hay directamente cientos. ¿Cómo puede ser posible esto?
En realidad, la PC
Engine se apoya en la experiencia de Hudson con las consolas de 8 bits para crear este tipo de scrolls no generados por el propio chip y Hudson es de las
pioneras en saber programar y crear todos estos efectos en Famicom, por lo
tanto sabían perfectamente que no tenerlos por hardware no supondría el más
mínimo problema, como así fue y se ve, como digo en cientos de juegos de Pc
Engine. Se usan dos procesos para crear esos scrolles por programación: los
“raster effects” y el cambio dinámico de los mosaicos (o trozos/partes de gráficos, les llamaremos así para abreviar), esto último muy usado en
Famicom.
Los mosaicos son
motivos que, una vez puestos en conjunto, forman la decoración/fondos del juego. Esta
construcción rompe la imagen en bloques
de 8x8 píxeles. Es aquí cuando interviene la importante cantidad de memoria de
vídeo presente en la PC Engine. Estos 64 Kb proporcionan entre otros, numerosos
mosaicos algunos de ellos fijos y otros animados. Como se intuye de manera
clara Hudson tenía clarísimo donde la estructura debía ser más potente, para
soportar toda la evolución de la máquina.
Pc Engine simula
un scrolling a la manera de un efecto
óptico, alternando rápidamente motivos ligeramente modificados para dar la ilusión de un decorado con varias
profundidades. Esta técnica casi no consume recursos.
Y una cosa
sumamente graciosa: menos Out Run todos los juegos adaptados de arcade de
“scaling” suelen ser bastante superiores técnicamente, siendo arcades de la
propia Sega, en Pc Engine que en MD, lo que cual sin lugar a dudas indica que
Hudson tenía razón.
Directamente esto
se debe a la falta en Sega del más mínimo interés o mino en la creación de su
Megadrive.
Mutilar
brutalmente una de tus placas usadas en arcades en 1986 no creo que sea la
mejor manera de crear algo serio, pero eso es mi opinión, de retales nunca sale
nada bueno.
Juegos como Thunderblade
de Md son un claro ejemplo que puede ver cualquiera de dejadez, mala
programación y el poco interés de la propia Sega en respetar SUS juegos arcade
en SU propia creación, MD. Cuando teniendo varios scrolles por hardware hacer
todos estos juegos hubiera sido “en teoría” sumamente sencillo. Que salgan los
juegos scaling de Sega en una consola con un Hardware totalmente diferente al
arcade y con un solo scroll, mejores, es realmente como diríamos “dejar con el
culo al aire a MD y sobre todo a Sega” y en los primeros tiempos de vida de las
dos máquinas. Así le fue a MD en Japón.
El otro proceso,
los “raster effects” consisten en contar las líneas trazadas en la pantalla y
cambiar su velocidad del desplazamiento. Este proceso de animación ha sido
utilizado en Famicom por Hudson antes de la PC-Engine.
Una de las particularidades
del VDC de la PC Engine es su panel de resoluciones. La consola es capaz,
gracias al VCE (Video Color Encoder) de mostrar una imagen comprendida entre
256X224 y 565X242 píxels. Ojo al contrario que todas las otras consolas, este
chip no funciona con resoluciones fijas, va de esa resolución a la otra
pudiendo usar la que quiera, cuando quiera.
Eso hace que
algunos juegos tengan una resolución por ejemplo en una foto de inicio y otra
durante el juego, similar a lo que hace un Sharp X68000. Digamos que es flexible
y variable según que se necesite. Ojo ni era fácil de hacer ni lo podía hacer cualquiera,
pero allí esta y Hudson nos proporciona el ejemplo más bestia.
¿Que es el zoom del
Ryoko No Ken/ Art of Fighting? Básicamente un cambio de resolución en caliente instantáneo,
cuando la Super con todo su chip gráfico no es capaz de conseguir, ni un zoom
ni un tamaño ni una fluidez similar.
Pc Engine Ryoko No
Ken sencillamente es una demostración de técnica, programación, flexibilidad y potencia de uso de cosas
que Super y MD no tienen y son incapaces de hacer. Que sencillamente las deja
en el más absoluto de los ridículos.
En materia de sprites, el VDC usado de forma clásica. Es capaz de mostrar un máximo de 64 elementos móviles simultáneamente teniendo en cuenta sus colisiones completas. La talla de los sprites varía entre 16X16 a 32X64 lo que es adecuado para mostrar los elementos móviles de gran tamaño.
Sin embargo lo que
cuenta para los sprites son la cantidad mostrable en una línea. Cosa
importantísima que nadie tiene en cuenta cuando habla de ellos.
Como digo se usan
los números fáciles como publicidad engañosa para niños (y YouTubers que muchos
de ellos su edad mental no pasa de 4 años) y se olvida que es fácil entender
cosas con números explicados de verdad y no según me interese.
Para la PC Engine
este número se sitúa entre 10 y 16 según la resolución, la Mega Drive 20 no
tengo claro si con las colisiones o no y la Super Nintendo, 32 (esta última esos
números sin colisiones. Si las activas se reducen esos números de sprites
dramáticamente y cuanto más completas sean las colisiones más problemas tiene
la consola para mover esos sprites y más problemas de tirones y slow-down veremos en la consola).
La Super tenía una
automatización tal que muchos procesos gráficos no pasaban por la cpu, esa fue
la causa de tener una cpu tan sumamente pobre y lenta. Sencillamente no
necesitaban a la cpu o eso creían los de Ricoh (si, Nintendo siempre encarga a
terceros, ellos no diseñan nada, piden, y un tercero les fabrica) Pero a la que querían
pasar a juegos que aprovecharan el chip gráfico para algo más que colorines, scalings, rotaciones o chorradas, la cpu les ponía en enormes problemas.
Era más fácil hacer juegos vacíos de enemigos que pelearse con la cpu.
Sencillamente para que se entienda: Super puede poner muchísima cosa móvil en pantalla, pero si activas colisiones estas son controladas por la CPU y esta no puede con ello. Sencillamente se limitó la cantidad de estos sprites con colisiones de forma expresa, para evitar el bloqueo total de la cpu de la consola. Como vemos en cientos y cientos de juegos con solo algunas cosas en pantalla que puedan digamos colisionar, esto hace que la cpu se sature completamente y sea incapaz, por su deficiente estructura de mover eso.
Un ejemplo,
Akumajo Dracula primera fase: dos esqueletos con una vela, el juego casi se
para. Sencillamente se usan unas colisiones completas y la cpu no llega y se
satura. Los juegos ágiles sencillamente usan muchos trucos de programación para
“Superar” ese defecto, por desgracia aunque estos sean los mejores se quedan
en unos cuantos contadísimos quizás unos más o menos 60 de 1500 y del resto un
% enorme sufre de problemas enormes para mostrar cosas en pantalla o
sencillamente juegas con pantallas prácticamente vacías. Juegos como Spprigan Powered o Cotton son un ejemplo muy dramático de esto.
Aunque la Pc Engine no innova en este punto ofrece una gestión robusta y confortable de los sprites, donde se puede constatar en más de cien juegos de Shoot’em Up, donde en la mayoría de veces no sufren de ningún defecto de animación, mientras que la Super sufre continuamente slow down por su carencia en temas de gestión de sprites y su lentísima cpu.
¿El llamado scroll
que es? Algo básicamente que nadie te va explicar
Se utiliza una
pantalla virtual que el jugador no ve. La consola lo usa para actualizar el
resto del nivel y desplazar una “cámara”
que es lo que ve el jugador.
Un desplazamiento del escenario a varios niveles de velocidad.
El VDC de la PC Engine se
inspira de este proceso de visualización. Actualiza su decoración en una
pantalla virtual con ayuda de la BAT (la
Block Attribute Table), que es un espacio de memoria asimilable a un
cuadro o una tabla de materias (índice)
en el que son inscritos los emplazamientos de las diferentes partes de
la memoria, de sus colores respectivos y del lugar dónde deben estar emplazadas en la pantalla.
Sencillamente la consola
avanza más la pantalla de lo que tú ves para que no tengas saltos ni
cortes como si pasaba en Pc88, 98, MSX…
El VDC lee esta tabla de izquierda a derecha y de arriba a abajo y luego construye una decoración en la pantalla virtual según el sentido de los desplazamientos del jugador. Contrariamente a la NES, la talla de esta pantalla virtual es muy flexible en Pc Engine, no es solo un “scroll”, como vemos este tema que tanto se simplifica o ignora también tiene su complicación.
Su sola limitación es la
de la memoria de vídeo. Por ejemplo, el BAT puede representar una pantalla de
1024x512 píxels dónde solo una porción de 336x224 es visible. La tabla BAT es
una de las funcionalidades clave del VDC
ya que es la base de la construcción gráfica y de la flexibilidad el Hu6270. En
efecto, este espacio de memoria puede ser cambiado en cualquier momento,
configurado de la manera que quiera el grafista o el programador.
Flexibilidad es la clave para poder hacer cosas diferentes y lo que hace que cientos de juegos de Pc Engine se vean de una manera u otra. Mientras que esa falta total de flexibilidad en Super y ese automatismo que tiene en su estructura crea que todos sus juegos sean clones en su aspecto.
Algo parecido pasa en MD, pero no tan exagerado como en Super, donde realmente todos sus juegos se ven exactamente igual.
Numerosos efectos gráficos como los cambios de mosaicos para efectuar los scrollings paralelos lo hace la BAT, dentro de la que podemos intercambiar fichas para dar la ilusión de una animación a diferente velocidad.
La BAT puede ser
igualmente desviada para permitir a la PC Engine reproducir vídeo
(flexibilidad), cosa que no es menor en una consola con una CPU de 8 bits y un lector CD-Rom donde la tasa de transferencia
no supera los 150 kb por segundo.
Por ejemplo en el
Gulliver Boy, uno de los raros títulos que utiliza Hu-vídeo en PC Engine, las
secuencias están organizadas en la pantalla en 24x14 partes siendo un vídeo de 192x112 píxels (1 título= 8
píxels) a diez imágenes por segundo por 256 colores.
Para que la PC Engine
pueda reproducir este vídeo, este está codificado en el formato gráfico del VDC y constituido de “partes o trozos”
guardados en los 64 kb reservados para la parte gráfica.
Estas “partes o trozos” que
son el puzzle del vídeo se
vuelven a unir y montar ordenadamente gracias a la BAT.
Como hemos visto, el BAT
es una tabla (índice) que permite al VDC
conocer la “parte o trozo” que busca en la memoria del vídeo, la manera de
colorearlo y su emplazamiento en la pantalla. En el caso del Gulliver Boy,
la BAT está compuesta de dos índices que alternan entre dos emplazamientos de
memoria de VDC que son independientes. El primero representa la imagen mostrada
y el segundo la imagen a seguir.
Una vez la primera imagen es mostrada, su emplazamiento de memoria es cogido por la siguiente que ella misma
deja lugar a la imagen siguiente cargada por el CD-ROM. La BAT se actualiza constantemente para reconstruir y colorear estas imágenes.
Es por la ordenación o
intermediación de éste índice que los
vídeos son mostrados. En otros términos, la BAT permite reproducir de forma
lógica el funcionamiento de una memoria “doble búfer”. Otras consolas como la Neo Geo hacen lo
contrario. En ellas se subdivide los
vídeos en partes y se reconstruye la imagen sin necesitar de usar la memoria de
vídeo. Pero esto pide un acceso directo inmediato al soporte de guardado que un cartucho puede asumir pero no un
CD-Rom. Sin la BAT, la PC Engine no podría sin duda tener éxito en lo que a
reproducción de vídeo se refiere o incluso simular los scrollings en varios
planos con ayuda del cambio dinámico del mosaico. Pero Hudson sabia muchísimo
lo que hacía cuando creo este chip y como se ve su prioridad no fueros los
números publicitarios, sino una flexibilidad total, además adecuada y de paso totalmente
optimizada para el uso del Cd-ROM.
El VDC es un procesador
gráfico relativamente flexible y fácil de tener todo a mano. Ofrece todo lo que un
grafista de la época pueda necesitar y crear. Con un poco de ingenio, usando
la BAT o los efectos raster puedes hacer de todo.
Dicho esto el VDC no
maneja el color. Para hacer esto dispone de un compañero: el HU6270 También la gran idea de dividir toda
esta parte y toda la parte de codificación de color en dos chips
