La complejidad de desarrollar para Nintendo 64
Publicado por: Adrián Ruiz
Nintendo 64 llegó por fin al mercado en 1996 después de dejarle el paso a PSX, una joven competidora que prometía facilitarle el trabajo a los desarrolladores de videojuegos.
Y lo cierto es que en su día N64 fue la consola más potente de la generación: contaba con corrección de perspectiva, un sistema de 32 y 64 bits, mapeo de texturas, búfer de datos, interpolación trilineal,, carga rápida de texturas, antialiasing… Era casi como tener una consola de nueva generación.
Salvo por la caché.
Pesar reflexivo
Nintendo 64 ha contado con juegos históricamente grandes, tales como ‘Ocarina of Time‘, ‘Super Mario 64’, ‘GoldenEye 007’, ‘Banjo-Kazooie’… Pero el salto del 2D al 3D no fue un camino de rosas, y presentaba muchas dificultades.
Primero estaba el problema de la caché de texturas, esta caché era de apenas unos 4Kb de tamaño. Su reducido tamaño llevó a los desarrolladores a estirar pequeñas texturas sobre un espacio relativamente grande. Si la textura era demasiado grande, tenía que dividirse en trozos, ¿la solución? Reducir la resolución de los píxeles.
Por otro lados estaba los problemas de RAM. Nintendo 64 fue una de las primeras consolas en usar memoria unificada. Esta memoria se compartía con todos los procesadores para que los desarrolladores pudieran valorar cuánta memoria necesitarían para cada tarea sin sufrir limitaciones de hardware. Con una capacidad para transferir 500Mb de datos por segundo, la RAM de Nintendo 64 ridiculizaba a sus competidores. Pero esa cantidad de memoria no tardaría en quedarse corta.
Por último estaba la tasa de relleno. Nintendo 64 contaba con una capacidad aproximada de hasta 160.000 polígonos por segundo, pero muchos de sus juegos tuvieron una tasa bastante limitada. Algunos desarrolladores tuvieron que sortear esta limitación a través de códigos propios, y dieron lugar a algunos de los juegos más exigentes que ha tenido la consola, como ‘World Driver Championship’, ‘Turok 2’ e ‘Indiana Jones y la Máquina Infernal’.
La solución
Por un lado Nintendo ya anticipó el problema con la RAM y última hora añadieron a la consola un slot vacío donde irían módulos de RAM extraíbles. La consola venía de serie con el Jumper Pak aunque su utilidad era meramente cubrir el hueco vacío; sería el Expansion Pak, que llegó 3 años después, el que otorgaría a la consola el doble de RAM. Este módulo solo fue obligatorio en dos juegos (‘Donkey Kong 64’ y ‘Majora’s Mask’), mientras que otros como ‘Perfect Dark’ tenían zonas inaccesibles sin la RAM extra.
Por otro lado estaba el microcrodigo oculto. Para arreglar los cuellos de botella de la consola sus desarrolladores crearon un microcódigo progamable que ayudaba al hardware a la hora de comprimir/descomprimir datos. Pero Nintendo nunca liberó este código a terceros, razón por la que se apreciaba una diferencia de calidad enorme entre first-party’s y thirds. En su lugar los desarrolladores se las ingeniaron para modificar sus propias versiones del microcódigo.
Para el final del ciclo de vida, Genyo Takeda, antiguo jefe de desarrollo de hardware de Nintendo, se refirió al proceso de desarrollo de Nintendo 64 utilizando la palabra “hansei” (反省), que en japonés quiere decir “pesar reflexivo”, en un intento de reconocer sus equivocaciones y reflexionar sobre qué pudieron hacer mal.
“Cuando desarrollamos Nintendo 64, pensamos que era lógico que si se quiere hacer juegos más avanzados, se hace técnicamente más difícil. Estábamos equivocados. Ahora entendemos que es la velocidad de crucero que importa, no el flash momentáneo de pico de potencia.”
Genyo Takeda
Si te ha gustado el artículo síguenos para no perderte nuestras publicaciones: