Las características de programación de la Nintendo 64 describen los elementos del software de escritura para la consola de juegos Nintendo 64 (N64).
Historia
La Nintendo 64 fue lanzada en 1996. En ese momento, The Economist describió el sistema como "terriblemente complejo". [1] Se dijo que las dificultades eran una combinación de supervisión por parte de los diseñadores de hardware, limitaciones en los gráficos 3D, límites tecnológicos de esa época y problemas de fabricación.
Cuando la Nintendo 64 llegó al final de su ciclo de vida, el jefe de desarrollo de hardware Genyo Takeda se refirió a sus desafíos de programación utilizando la palabra hansei (en japonés :反省"arrepentimiento reflexivo"). Takeda dijo: "Cuando creamos Nintendo 64, pensamos que era lógico que si quieres hacer juegos avanzados, técnicamente se vuelve más difícil. Estábamos equivocados. Ahora entendemos que lo que importa es la velocidad de crucero, no el destello momentáneo de pico energía." [2]
Memoria
La consola utiliza Rambus DRAM de gran ancho de banda pero de alta latencia . [3] Está alojado desde el Coprocesador de realidad (RCP) que tiene una interconexión interna entre el Procesador de señal de realidad, el Procesador de pantalla de realidad y las interfaces IO (incluido el microprocesador).
Hay un espacio de direcciones físicas en el que se asignan la mayoría de los recursos, incluido el Game Pak, la instrucción RSP y el almacenamiento local de datos [se necesita desambiguación ] , pero ni el almacenamiento local de textura RDP ni la memoria caché de la CPU. Las interfaces RSP, RDP e IO tienen cada una su propio motor DMA, programable mediante registros que se exponen a través del espacio de direcciones físicas. El RSP puede direccionar solo su almacenamiento local y puede programar su motor DMA. El motor RDP DMA maneja búferes de comando (las llamadas listas de visualización); el RDP tiene una interfaz de memoria adicional para acceder a búferes de video y datos, capaz de obtener directamente del almacenamiento local de datos RSP a través de una ruta de datos separada.
La CPU R4300 está conectada al RCP a través de la interfaz del microprocesador y puede realizar E / S programadas a través de su caché y su interfaz de memoria.
Procesador de pantalla de realidad
El procesador Reality Display es un rasterizador y sombreador de canalización fija, con búfer Z, que genera un búfer de fotogramas para que la interfaz de video escanee hacia la pantalla.
Caché de texturas
La caché de texturas tenía un tamaño de 4 KB . Su pequeño tamaño llevó a los desarrolladores a estirar pequeñas texturas en un espacio comparativamente más grande. El filtrado bilineal de la consola solo los difumina. Cuando se usa mipmapping , los requisitos de ancho de textura y el almacenamiento adicional para los niveles de mipmap limitan el nivel más grande de mipmap a 2 KB. Hacia el final del ciclo de mercado de la Nintendo 64, algunos desarrolladores precalcularon sus texturas utilizando texturas de varias capas y pequeñas piezas de textura que estaban fuertemente sujetadas, para simular texturas más grandes. Los ejemplos de esta solución se encuentran en Rare 's Perfect Dark , Banjo-Tooie , Bad Fur Day de Conker , y en la de Factor 5 Indiana Jones y la máquina infernal . [4] Algunos juegos con una estética poco realista usan sombreado Gouraud de color liso en lugar de texturizar ciertas superficies (por ejemplo, Super Mario 64 ). [5]
La gran fortaleza fue el cartucho N64. Usamos el cartucho casi como una RAM normal y estamos transmitiendo todos los datos de nivel, texturas, animaciones, música, sonido e incluso código de programa mientras se ejecuta el juego. Con el tamaño final de los niveles y la cantidad de texturas, la RAM del N64 nunca habría sido lo suficientemente remota como para adaptarse a cualquier nivel individual. Así que la tecnología de cartuchos realmente nos salvó el día.
- Factor 5, llevar Indy a N64, IGN [4]
Tasa de relleno
Muchos juegos de Nintendo 64 tienen una velocidad de relleno limitada, no una geometría limitada. Por ejemplo, el almacenamiento en búfer Z cuando está habilitado es una parte significativa del acceso a la memoria, de lo contrario, es necesario para las texturas y el búfer de fotogramas. La optimización es posible presionando esta función en el RSP y la CPU utilizando un microcódigo personalizado. [6] [4] Se puede encontrar una optimización significativa del rendimiento utilizando un microcódigo apropiado para cada juego. La clasificación de polígono por segundo de la Nintendo 64 es de aproximadamente 160.000 con las funciones de hardware habilitadas. [7] Algunos de los juegos de Nintendo 64 más intensos en polígonos incluyen World Driver Championship , Turok 2: Seeds of Evil e Indiana Jones and the Infernal Machine . [4]
Procesador de señales de realidad
El Reality Signal Processor (RSP) acepta microcódigo , [8] a través del cual, un desarrollador puede acceder a diferentes operaciones, crear nuevos efectos y optimizar la velocidad o la calidad. El RSP es un procesador RISC, menos capaz que la CPU, pero con un motor vectorial de 16 bits de 8 vías. El uso eficaz de este motor se rige por el microcódigo, que define una pequeña secuencia de instrucciones para cada instrucción compleja. Mientras promocionaba la función de microcódigos personalizados, Nintendo inicialmente se negó a compartir información sobre cómo usar las herramientas de microcódigo relacionadas. Esto se debió al temor de que fuera copiado por sus competidores. Sin embargo, durante los últimos años de la consola, Nintendo compartió la información del microcódigo con algunos desarrolladores. Las herramientas de código oficial de Nintendo son básicas, sin depurador y con poca documentación.
El microcódigo predeterminado de SGI para Nintendo 64 se llama "Fast3D", y algunos desarrolladores afirmaron que estaba mal perfilado para su uso en juegos. Aunque genera más de 100.000 polígonos de alta precisión por segundo, este microcódigo está optimizado más para la precisión que para la velocidad, y el rendimiento se ve afectado. El microcódigo "Turbo3D" de Nintendo permite entre 500 000 y 600 000 polígonos de precisión normal por segundo. Sin embargo, debido a la degradación gráfica, Nintendo desalentó oficialmente su uso. Empresas como Factor 5 , [4] Boss Game Studios y Rare pudieron escribir un microcódigo personalizado que supuestamente ejecuta sus motores de juego mejor que el microcódigo estándar de SGI .
Uno de los mejores ejemplos de microcódigo personalizado es el puerto N64 de Factor 5 del juego de PC Indiana Jones and the Infernal Machine . El equipo de Factor 5 apuntó al modo de alta resolución de 640 × 480 [9] debido a su nitidez visual. Se dijo que la máquina funcionaba a sus límites mientras funcionaba a 640 × 480. El búfer Z no se pudo usar porque solo consumió la tasa de relleno de textura ya restringida. Para evitar la caché de textura de 4 KB, los programadores crearon herramientas y formatos de textura personalizados. Cada textura se analizó y se ajustó al mejor formato de textura en cuanto a rendimiento y calidad. Aprovecharon el cartucho como fuente de transmisión de texturas para exprimir la mayor cantidad de detalles posible en cada entorno y evitar las limitaciones de RAM. Escribieron un microcódigo para iluminación en tiempo real, porque el microcódigo suministrado por SGI no estaba optimizado para esta tarea y porque querían tener más iluminación que la versión para PC. El microcódigo de Factor 5 permite una iluminación en tiempo real casi ilimitada y aumenta significativamente el recuento de polígonos. Al final, se dice que la versión N64 tiene más funciones que la versión para PC y se considera uno de los juegos más avanzados de la unidad. [4]
Factor 5 volvió a utilizar un microcódigo personalizado con juegos como Star Wars: Rogue Squadron y Star Wars: Episodio I: Battle for Naboo . En Star Wars: Rogue Squadron , el equipo modificó el microcódigo de un motor de paisaje para crear mundos alienígenas. Para Star Wars: Battle for Naboo , usaron lo que aprendieron de Rogue Squadron e hicieron que el juego funcionara a 640 × 480, y también implementaron mejoras para las partículas y el motor de paisaje. Battle for Naboo tiene una gran distancia de dibujo y grandes cantidades de nieve y lluvia, incluso en modo de alta resolución. [10]
Ver también
- Especificaciones técnicas de Nintendo 64
Referencias
- ^ "Nintendo despierta". The Economist, 3 de agosto de 1996: 55-. ABI / INFORM Global; Biblioteca de investigación de ProQuest. Web. 24 de mayo de 2012.
- ^ Croal, N'Gai; Kawaguchi, Masato; Saltzman, Marc. "Es Hip To Be Square". Newsweek 136.10 (2000): 53. MasterFILE Premier. Web. 23 de julio de 2013.
- ^ "Diferencia entre RDRAM y DDR" . Consultado el 15 de enero de 2009 .
- ^ a b c d e f "Llevando Indy a N64" . IGN. 2000-11-09 . Consultado el 24 de septiembre de 2013 .
- ^ "Super Mario Galaxy" . Consultado el 11 de enero de 2009 .
- ^ "Eliminación de superficies ocultas" (PDF) . Archivado desde el original (PDF) el 4 de marzo de 2009 . Consultado el 24 de abril de 2014 .
- ^ Próxima generación , número 24 (diciembre de 1996), página 74
- ^ "Nintendo 64" . Archivado desde el original el 10 de julio de 2007 . Consultado el 14 de enero de 2009 .
- ^ "Indiana Jones y la máquina infernal" . IGN. 12 de diciembre de 2000 . Consultado el 24 de septiembre de 2013 .
- ^ "Entrevista: luchando contra la N64 (Naboo)" . IGN64. 2000-11-10 . Consultado el 27 de marzo de 2008 .