Nintendo Sixty Fooour!

En el anterior artículo, explicamos las características un poco la historia de PlayStation, describiendo también un poco su arquitectura. En este artículo, vamos a hablar un poco sobre la historia y la tecnología detrás de Nintendo 64, la primera gran consola 3D de Nintendo.

Silicon Graphics ayudó a los efectos especiales de Terminator 2.

Al mismo tiempo que SONY preparaba su consola, Silicon Graphics, una de las compañías pioneras en los gráficos generados por ordenador y conocidos tanto por sus estaciones de trabajo como por su implicación en el mundo del cine, buscaban nuevos usos de su tecnología en otros mercados, y viendo como tanto SEGA como Namco habían realizado colaboraciones con compañías americanas para sus sistemas arcades, se percataron que el mundo del videojuego era el lugar perfecto para poder expandirse. Para ello, la compañía crea un chip gráfico al que llamarían reality engine que podría tener la potencia necesaria para manejar gráficos tridimensionales a un bajo coste. El primer intento lo realizan con SEGA América, donde se concuerdan al parecer una serie de reuniones pero finalmente no llegan a buen puerto, debido en parte a la negativa de SEGA Japón de crear una consola con ese chip. El que era entonces el presidente de SEGA América, viendo la negativa por parte de SEGA Japón, se disculpa con los chicos de Silicon graphics y les dice que en Seattle, la ciudad donde se encontraban, “existe otra compañía de videojuegos que empieza por N y pueden querer el chip gráfico”. Es así, como Silicon Graphics visita Nintendo y está, encantada de lo que ve, realiza el acuerdo de crear juntos su consola de nueva generación. Comienza project Reality.

Demo técnica de Horizon Zero Dawn, donde la parte no visible no se tiene en cuenta para la imagen final. Nintendo 64 aplicaba el algoritmo Z-Buffering para realizar lo mismo

El chip que creó SGI para Nintendo 64 fue una variación del reality engine que llamaron Reality coprocessor. Este contenía en su interior dos procesadores, Uno es el llamado RDP o Reality Display Processor, que se encargaba, como el GTE de PlayStation (coprocesador geométrico que explicamos en el anterior artículo), de renderizar la imagen final a partir de la posición de todos los polígonos y la cámara, aunque, el chip RDP contenía una serie de añadidos que el chip GTE no tenía y lo hacían más avanzado, añadidos como antialiasing (que se utilizan para eliminar los llamados dientes de sierra), Z-Buffering (que es una manera para calcular qué polígono es visible en la escena y por tanto si hay que pintarlo o no en la imagen final), texture mapping y filtro tri-linear para corregir la perspectiva de la escena cuando se dibuja la escena. El otro chip es el llamado Reality Signal Processor o RSP, un procesador de propósito general modificado para poder ejecutar operaciones en paralelo (las cuales resultaban esenciales para el cálculo de geometría 3D).

Aunque todo el mundo recuerde Nintendo 64 por las 3D, también existieron juegos 2D. Bangai-o o Yoshi’s Story son 2 ejemplos de ello.

El RSP, era el encargado de calcular los efectos y toda la geometría de la escena, dejando a la cpu principal para otras tareas y para ello, lo que hacía, era ejecutar un código programable propio llamado microcódigo. Este especificaba cómo debía calcular todos esos efectos de luz y geometría y como era programable, hacía posible que los desarrolladores tuvieran libertad a la hora de como poder calcular la geometría y crear efectos. Sillicon Graphics y Nintendo facilitaron además 3 conjuntos de microcódigos para que los creadores de videojuegos pudiesen utilizarlo y no tuviesen que preocuparse de ese proceso. Uno era el llamado FAST3D, que calculaba la geometría de la escena (recordemos que calcular la geometría es realizar el cálculo de todas las traslaciones y rotaciones de cada polígono que hay que hacer para crear la imagen) con una gran precisión, otro modo era el TURBO3D que este permitía calcular la escena con muchos más polígonos en pantalla que FAST3D pero con una menor precisión, por último existía el modo sprite2D para realizar cálculos sobre sprites, pudiendo realizar operaciones de escalado y rotaciones.  El RSP además era el encargado del sonido. 

Las ventajas sobre esta arquitectura son claras. Cómo hemos visto a lo largo de las consolas con capacidad 3D, estos utilizaban la CPU principal para realizar los cálculos geométricos y posteriormente utilizaban unos chips que realizaban una tarea específica para el renderizado. PlayStation, por ejemplo, tenía el coprocesador GTE (tecnología curiosamente también licenciada por Silicon Graphics) para renderizar los triángulos o Saturn, utilizaba la unión de los dos chips gráficos donde uno se encargaba de dibujar los fondos y otro los sprites, generando así la imagen final. Nintendo 64 por contra, gracias a este chip podría delegar esa tarea al coprocesador y dejar la CPU para en tareas como IA o lógica del videojuego. Además, Nintendo 64 estaba llena de ideas novedosas que ahora son un estándar en el mundo de las consolas. Por ejemplo, la idea de memoria unificada, donde Nintendo 64 contenía 4MB de memoria que era compartida tanto por el procesador principal como por el Reality Coprocessor.

Nintendo y Silicon Graphics preveían que el desarrollo de la consola les iba a llevar 2 años, pudiendo lanzarla para mediados del 95. Pero nada más comenzar la joint venture comenzaron los problemas. El primero vino a través del propio chip reality coprocessor, ya que este presentaba muchos errores de cálculo y necesitó retoques hasta el final de desarrollo de la consola (es más, el chip nunca consiguió las capacidades que quisieron los creadores). Por parte de Nintendo, el principal problema vino a través de la imposición del precio, y es que la compañía de Kyoto se negaba en rotundo a crear un producto que costase más de 25000 yenes de producir, lo que hacía que diseñar una arquitectura tan revolucionaria a ese precio fuese una tarea titánica.

Uno de los “milagros” de Nintendo 64 fue el port de Resident Evil 2, donde los chicos de Angel Studios (que posteriormente crearían Red Dead Redemption) lograron meter el juego en un cartucho de 512 Megabits (64 Mega Bytes).

Es por ello, que la consola peca de tener unas decisiones de arquitectura muy cuestionables que sin duda, hacían que todas esta revolución, quedase sólo sobre el papel. La mayor lacra que arrastraba Nintendo 64 era su latencia de la memoria con la CPU. Como hemos dicho previamente, la consola tenía 4 megas de RAM unificada conectada al Reality Coprocessor. Esto de por si no es un problema, ya hemos dicho que la memoria unificada fue una decisión novedosa y seguida por muchas compañías posteriormente, pero el problema viene, a no existir un camino directo entre la memoria principal y la CPU. Esto hacía (unido a las propiedades del tipo de memoria elegida, RAMBUS, pero que no entraremos en detalle), que se tardase muchísimo el tomar instrucciones desde la memoria hasta la CPU y esto provocaba lo que llamamos un cuello de botella. Un cuello de botella es cuando un proceso en una producción en cadena es más lenta que otras y hace por tanto que la producción global se ralentice. En el caso del videojuego, mientras la CPU no termina de calcular la IA o la lógica del videojuego, el Reality coprocessor no puede generar la imagen final, haciendo que muchos juegos, en vez de funcionar a 30 imágenes por segundo, funcionasen a 20 o incluso 15 imágenes por segundo. Otro de los grandes fallos es la selección del medio de almacenamiento, y es que Nintendo 64 optaron por seguir con el cartucho en vez de utilizar CD-ROM. La decisión fue tomada tanto por coste, ya que añadir una unidad CD-ROM haría subir bastante el precio final, como por combatir la piratería, ya que sin CD-ROMS, sería mucho más difícil ejecutar copias. Pero, la audiencia ya había visto las bondades del CD, y esto hacía parecer a la consola de Nintendo como una consola desfasada desde el día uno.

Estación de trabajo Onyx eran utilizados como devkits de Nintendo 64. Su precio alcanzaba los 100.000 dólares la unidad.

Además, los desarrolladores tenían una serie de impedimentos draconianos para poder crear juegos en Nintendo 64. Primero, los juegos sólo podían ser desarrollados con estaciones de trabajo de Silicon Graphics, estas estaciones de trabajo, eran ordenadores con unos especificaciones muy especiales que costaban miles de dólares de la época (el modelo Indy, el más barato, costaba alrededor de 5000 dólares), haciendo que el desarrollo en la consola fuese bastante caro para estudios pequeños o medianos. Además, las herramientas de desarrollo eran insuficientes y Nintendo impidió a los desarrolladores no tocar el microcódigo del RSP hasta finales de la vida de la consola, haciendo sólo posible que pudiesen utilizar el modo FAST3D para vender sus videojuegos. Esto era debido a que este modo gráfico era el que mejores resultados visuales daba y por tanto hacía que hubiere una brecha de calidad entre Nintendo 64 y sus competidoras, pero a costa de mostrar menos polígonos por segundo. Para muchos desarrolladores, esto limitaba mucho la creación del videojuego.

Nintendo 64 salió en junio de 1996 con 3 juegos de salida y casi dos años de retraso. Pero pese a todos sus problemas y contra todo pronóstico, hubo un juego que revolucionó el mercado de las consolas, Super Mario 64. Este juego, demostró finalmente las bondades de la dimensión extra, y podemos decir que puso el punto de inicio del 3D tanto en jugabilidad (gracias en parte al mando, que incorporaba el stick analógico), como en cámara y por supuesto diseño de niveles. Con el tiempo, veríamos también como se le sacaba partido a la consola con juegos  como F-ZERO X, la segunda parte del aclamadísimo F-ZERO, que era capaz de mostrar 30 naves a 60 imágenes por segundo. A mediados de la vida útil de la consola además, Nintendo lanzó un periférico llamado expansion pack que añadía 4 megas más de memoria principal a la consola (llegando a los 8 Megas) y hacía que varios juegos se viesen en una mayor resolución. Este periférico sin embargo, no arreglaba el fallo de latencia de la consola, que era el verdadero problema de la consola. Hay un caso curioso, Donkey Kong 64 de Rare, que a escasas semanas del lanzamiento descubrieron un bug que hacía que la pantalla se congelase y hacía injugable el juego. Este bug aparecía de manera aleatoria por lo que era difícil de solucionar, pero sólo se producía en consolas sin el expansion pack insertado. RARE, sin tiempo para arreglarlo, obligó el uso del expansion pack para poder jugar al juego. A finales de la vida útil de la consola, Nintendo abriría la veda sobre la utilización de microcódigo que no fuese FAST3D y compañías como RARE, FACTOR 5 o BOSS Games, especializados en juegos de coches, finalmente crearían su propio conjunto de microcódigo para sus juegos, añadiendo así ciertas capacidades extra a Nintendo 64. 

Una vez explicados la quinta generación, hablaremos del 3D en el PC, dando una pequeña introducción sobre la programación gráfica sobre juegos previos a la era de las tarjetas gráficas, y el cambio radical que supuso dichas tarjetas.