N64 y las 2DLa consola no tenía un hardware dedicado para las 2D, apostaron por las 3D en un momento de cambio con un mercado en expansión, que no tuviera un engine 2D para manejo automatizado de scroll / sprites no quiere decir que no tuviera un micro código para 2D.
El micro código es muy básico, toma un polígono plano y lo texturiza con un bitmap, no hay más, lo hace usando la cache de texturas que esta limitada a 4KB (el gran error de la consola), sin embargo en un mundo 2D no es necesario usar mip mapping (podemos usar los 4KB enteros), ni filtro de texturas, ni correcciones de perspectiva.
Entonces como se genera un scroll ?
Un scroll no es más que un conjunto de tiles (8x8, 16x16, 32x32, 64x64, etc), cada tile es un bitmap del mismo tamaño en una posición del scroll, en este caso un polígono, veamos un ejemplo en
Yoshis Story :
Esto es el fondo de una fase (muy sencilla hay fases más complejas), es fácil ver que están usando tiles de 64x64x8bits = 4KB y que muchos de ellos se estan repitiendo (ahorro de memoria en el cartucho, que es la principal finalidad de un tile, contra más pequeño sea el tile más probabilidad de repetición y más ahorro, aunque en este caso, más gasto de polígonos), este es un mapa de 7x22 tiles.
Luego tenemos la parte que va encima, no solo del anterior scroll, sino de Yoshi también, un mapa de 8x24, a diferencia de consolas antiguas como Megadrive o Snes no existe un limite de planos en pantalla, es totalmente dependiente de lo que quiera hacer el programador.
Y combinadas, ahora la cosa ya va tomando forma.
La cámara corresponde a la resolución de pantalla, que el scroll sea más grande que la pantalla es lo que permite el movimiento.
Ahora solo nos faltan los sprites, para la consola tanto da tiles como sprites, son todo polígonos, en este caso Yoshi esta formado por varios para conseguir buena animación usando poco espacio en el cartucho.
Con la suma del OSD y ya el resto de elementos del escenario (la imagen un poco mierder sacada de un video)
Al ser polígonos se les puede aplicar efectos especiales, aparte de zoom, rotación, semitransparencias, paletas (colores indexados), etc o efectos como este usando un framebuffer auxiliar (se ve hasta como hace la copia antes de usar el efecto) :
--
Por otro lado tenemos ventajas como el uso del cartucho, una memoria unificada de gran capacidad, una cpu rápida para mover el script de cada elemento en pantalla o incluso pintar directamente en el framebuffer, pero un micro código muy básico y la total responsabilidad del programador de hacer el engine 2D en cualquiera de sus posibilidades, o bien pintando polígonos o mediante otros métodos, esto es un punto negro a la hora de querer portar un juego 2D, además del target de mercado al que apuntaba la consola.
Si Yoshi Story era un ejemplo básico de como hacer 2D en la consola, esto en el 2:10 sería algo bastante más sofisticado, con el uso de primitivas gráficas y muchos objetos en pantalla.
Suscripción
Nueva réplica
Buscar en el mensaje
