Hilo de detalles y curiosidades de N64

1, 2, 3, 4, 5, 6175
Razer7 está baneado por "saltarse un ban con un clon"
Increíble hilo, mi consola favorita de niño! Recuerdo que por la época se decía que era una consola muy enfocada al 3d y que no podía mover gran cosa en 2d, por eso apenas había juegos en 2d para la consola.
Sorprende ver esto, que fuese realmente buena en 3d. Pero como de buena era comparada con psx y saturn?
Waldo64
V1, Rotate, V2
1.055 mensajes
desde mar 2010
en 39°53'21.76"N 4°16'19.3E
Me han sorprendido mucho los datos sobre el coste de la consola, y de los cartuchos, visto así no me extraña lo "barata" que era la consola, y lo carísimos que eran los juegos comparándolos con los juegos en formato CD de la competencia.

Sigue así @BMBx64 me lo estoy pasando muy bien con tus posts!!!
excelente hilo, lei gran parte de las curiosidades, por aca existia la leyenda urbana de que si se te arruinaba la ranura de cartuchos de la consola, podias conectar cartuchos a la ranura inferior {la del disk drive}, aparte recuerdo que en las cajas de N64 las imagenes de mariokart tenian items inexistentes como una pluma y la bombas eran de colores, y en una revista salia Kamek en lugar de Donkey Kong, a ver si alguien sabe mas sobre eso
kassanmoor escribió:excelente hilo, lei gran parte de las curiosidades, por aca existia la leyenda urbana de que si se te arruinaba la ranura de cartuchos de la consola, podias conectar cartuchos a la ranura inferior {la del disk drive}, aparte recuerdo que en las cajas de N64 las imagenes de mariokart tenian items inexistentes como una pluma y la bombas eran de colores, y en una revista salia Kamek en lugar de Donkey Kong, a ver si alguien sabe mas sobre eso


La beta del Mario Kart 64 o Mario Kart R.
Acá hay algunas imágenes y algo más de información.
MF16
Adicto
340 mensajes
desde jun 2016
Waldo64 escribió:Me han sorprendido mucho los datos sobre el coste de la consola, y de los cartuchos, visto así no me extraña lo "barata" que era la consola, y lo carísimos que eran los juegos comparándolos con los juegos en formato CD de la competencia.

Sigue así @BMBx64 me lo estoy pasando muy bien con tus posts!!!


Nintendo fue una marca cara. El problema fue que las third partys se escaparon de su sometimiento, y perdio el apoyo. Los cartuchos de Snes con chips tambien eran mas caros en su dia. La Play, igualmente triunfo en gran parte por la pirateria.
Aracnoid
MegaAdicto!!!
1.349 mensajes
desde may 2013
en Transilvania
Muy buen hilo, estoy disfrutando de lo lindo!!

Saludos y gracias al autor
Bueno pues ya he alcanzado los 60fps con la libdragon [jaja], resulta que SÍ funciona por defecto a 60fps, pero se limpiaba el buffer de pantalla por software, lo cual es muy lento, entre eso y que el frameskip es muy poco tolerante, a la que no puede a 60 exactos baja a 30 de golpe.

He empezado a optimizar un poco y ya he conseguido poner 8 scroll parallax de 16bits a 60fps (tileados cíclicos de 32x32), pero podría poner más sin bajar el rendimiento, dado que varía si usas textura única o vas cargando unas cuantas he montado el engine 2D para soportar layers infinitos, lo cual es un alivio viniendo de las 2 capas de Megadrive, el gif marea un poco.
Imagen

HARDWARE (PARTE 1)
Ahora que ya sabemos lo que Nintendo se gastó en la consola vamos a ver que lleva por dentro y como funcionaba.

FUNCIONAMIENTO
El centro de operaciones de la consola es el RCP, la CPU no tiene DMA.
Imagen

Una muestra del funcionamiento de la consola, todos los pasos que realiza desde coger la información del cartucho hasta sacar la imagen de video (frame)

Video
Imagen

Audio
Imagen

Nintendo explica como sacarle partido a la consola, la memoria tiene una latencia MUY alta (~640 ns) y un ancho de banda cercano a 562.5 MB/s, por otro lado tenemos una cache de texturas de solo 4KB, la cual hay que renovar continuamente con nuevas texturas, lo ideal es ir pintando todas las texturas que podamos antes de cargar la siguiente y aprovechar la CPU mientras el RDP está ocupado.
Imagen

En muchos casos hay juegos que mantenían el uso del RCP al 99%, pero la CPU estaba siendo desaprovechada, el rendimiento de la maquina no solo dependía de los micro códigos que es una pequeña porción de proceso, sino también de la estructura del programa, por otro lado se abusaba del Z-buffer lo cual limitaba todavía más el fillrate.

- Boss Studios en Top Gear Rally usaba la CPU para procesar el audio, motivo por el cual el juego iba tan fluido y también la explicación del porque los emuladores siempre han dado problemas de audio con este juego.

- El equipo de Mortal Kombat 4 dedicó 8 meses a la versión de N64 del juego, en lugar de portar el código sin optimizaciones, por eso consiguieron 60fps estables.

Desde el lanzamiento de la consola se estuvo trabajando con los micro códigos Fast3D que estaban optimizados para estaciones de trabajo, en algunos cálculos se usaba demasiada precisión lo cual era bastante lento para juegos, hay un micro código para gráficos 2D/3D y otro para sonido, hubo diferentes evoluciones de los mismos que fueron mejorando el rendimiento, además de micro códigos personalizados por Rare, Factor 5 o Boss Studios, Nintendo era reacia a dejar que otras compañías tocaran sus librerías a bajo nivel o incluso que se pudieran desactivar ciertos efectos gráficos.

Un programador de Boss Studios da más detalles de la consola
Usar Z-buffer limitaba el fillrate de la consola, por eso juegos como World Driver Championship (uno de los juegos que más polígonos mueve de la consola lo lleva desactivado con una gestión manual), el equipo tomó el riesgo de desactivarlo sin tener la certeza de que Nintendo lo aprobara, además detalla otro tipo de información igual de interesante.


Anyone know the actual fillrate of the N64? I couldn't find it.

- Wouldn't be of much use, the theoretical numbers were much higher than what you'd see in practice since it was bandwidth limited for the most part. Plus you have to take into account things like stalls while loading the texture into the cache which the PS1 never had to deal with.
Turning off Z made a considerable difference, World Driver runs without a Z buffer for this reason, but it was a significant risk when we made that decision, because it was unclear if Nintendo would bounce a title for excessive Z fighting.

And the only Nintendo supplied uCode that made it practical to omit the ZBuffer didn't come until very late and was feature incomplete.

At a hardware level you build command lists in memory and DMA them to the local memory on the RSP, the RSP runs arbitrary code on the command list and eventually you output rendering primitives to the RDP. Most uCode writes this back out to memory into a circular buffer for the RDP to read (increasing the load on main memory), although it was technically possible for the RDP to read directly from RSP memory RAM was so restricted, the RDP tended to starve.

Reordering is certainly not as simple as on PS1, but you could run sets of static display lists in arbitrary orders pretty easilly.

I think most people used the Zbuffer because it was there.


Los juegos de Boss Studios usaban un tracker para las melodias, también explica como efectivamente Top Gear Rally usaba la CPU para procesar el sonido, pero en World Driver lo movieron de nuevo al RCP al ver que no era el verdadero cuello de botella que estaban teniendo.

It's actually an Amiga style tracker, channels are left or right, I can't remember how many channels we supported off the top of my head. N64 really didn't have good audio.

Audio like our later titles was a tracker, because that's what our sound guy (Barry Leech at the time) wanted given the very significant constraints. At the time the Nintendo libraries used the RSP for the mixing, but we measured a significant performance penalty for this, so I wrote a mixer on the main CPU, which balanced load a bit better. For WDC we moved the mixing back to the RSP because we had access to the uCode and it wasn't really the bottleneck.


Detalles de como surgio el primer Top Gear Rally de N64 (los siguientes no los programo Boss Studios) y también habla de sus físicas una de las cosas que más gustó del juego.

TGR happened because we were located just up the road from Kemco's US office. They were looking for a dev to do a Top Gear racing game on Nintendos upcoming platform, and several of us wanted to do a racing title.

The prerendered sequence we did back then was largely to convince Nintendo to get devkits, it wasn't a common sales tactic in those day, but since it's become common practice.

The physics engine went in very late in TGR, There were actually two developed and the first prooved to be unusable. I wrote the second one to dig us out of a dev hole. In terms of what's modelled it's similar in principle to the WDC one, the tire model is simpler and it has some bonus bugs in it. The WDC one is also about 10x faster (which gives you how an idea of how much implementation can change performance) mostly due to improvements in the collsion representation.

The Snow tracks came about because an artist volunteered to do it in a meeting with Kemco. Everyone loves the Jungle in the Snow...

The paintshop was an idea that had been thrown around internally, and I always fought against (I lost) because it hurt the graphics quality of the cars significantly.


MEMORIA UNIFICADA
Imagen
A diferencia del resto de consolas de la generación, N64 no tenía memoria dedicada para gráficos o sonidos, era todo un bloque de memoria donde se debía almacenar toda la información.

Sabemos que la consola tiene 4MB u 8MB con expansión, pero entonces como se repartía la memoria?

Imagen

- El frame buffer es de tamaño y color variable, si un juego funciona a 320x240 y 16bits de color nos ocuparía un total de 300KB (double buffer), cabe destacar que N64 puede cambiar al vuelo la resolución del juego, generalmente cuando se usa expansion pak mueve el framebuffer a los bancos de memoria 2 o 3 que son los 4MB extra de la expansión (los juegos que solo aumentan resolución con el expansion pak apenas hacen uso de la memoria extra, trabajan con los 4MB de stock para asegurar la compatibilidad sin expansión).

300KB de 4MB suenan realmente a poco, pero en consolas con VRAM dedicada como PSX este simple paso nos estaría consumiendo un 30% de la memoria para gráficos, pues solo tiene 1MB (15bits de representación de color).

- El sonido, como se verá en una entrevista a continuación solía consumir entre 512KB y 1MB, aunque a diferencia del frame buffer que es un tamaño requerido, el buffer de sonido podría ser variable según las necesidades del programa, en este caso N64 requiere memoria adicional sobre PSX o Saturn pues tiene que trabajar con samples para generar las melodías, en lugar de leer directamente del CD.

- Las texturas solían ocupar 4KB (o 2KB con mip mapping activado), así pues tener 128 texturas de 64x64 solo nos ocuparía 512KB, N64 tenía un debugger que permitía hacer un listado visualizado de todas las disponibles en memoria, por si quedaban dudas PSX tiene una cache de texturas de 2KB, pero también podía usar la VRAM a costa de penalización en el rendimiento, en Resident Evil 1,2,3 se usan texturas más grandes aprovechando que los escenarios son prerrenderizados.

- Buffers adicionales, pueden haber otros buffers de pantallas para efectos o sombras por ejemplo, son de tipo variable y dependen del tamaño y la profundidad de color, también habia buffers a nivel interno como el Vertex y el Z-buffer.

- El resto de la memoria RAM va dedicada al programa, listado de visualización / audio y una parte reservada al SO de N64, que hacia algunas operaciones internas (algunas a 64bits, pero lo común eran instrucciones de 32bits)

- El micro código se cargaba en 4KB adicionales en el RCP (distintos a TMEM), cabe destacar que tanto texturas, como sonidos, como partes del programa podían cargarse en streaming desde del cartucho, algo que hizo Factor 5 en Indiana Jones.

Desventajas :
Al ser memoria unificada cuando aparece un problema es más difícil de trazar de donde proviene, cualquier desliz o pise de memoria en el programa podría corromper datos sensibles de audio o vídeo y provocar un cuelgue aleatorio después, muchos fallos no se manifiestan en el momento del error sino cuando surge la excepción. (en DK64 fue imposible descubrir de donde venía uno de los fallos).

SONIDO
Se conoce vagamente que la consola puede reproducir entre 1 a 100 canales en 48khz/16bit/estéreo, al no disponer de un chip de sonido dedicado la reproducción de sonidos va a cargo del combo CPU-RCP, por lo que puede ser totalmente flexible según las necesidades del momento.

Neil Voss compositor de Tetrisphere arroja más luz al asunto en una entrevista en IGN :

- Sabiendo que cada canal consume CPU usaban generalmente 16 canales de sonido, coincide con las especificaciones comunes.
Q: Considering the fact that every voice costs processor time, how do you go about creating a song? Do you start with as many voices as possible and scale back, or do you limit the number of voices from the get-go?

Voss:

I prefer to shelve the processing resources. Voice-wise I usually make things work within 16 physical channels to eliminate the unknowns of voice stealing. ROM/RAM resources-wise I will start with the samples at a higher fidelity and then work them down from there
.


- Como se comentaba antes, la música requiere RAM adicional, en contraste PSX tiene 512KB de sonido dedicado, aunque N64 puede acceder fácilmente al cartucho para actualizar los samples (música dinámica como la que utiliza Banjo Kazooie)
Q: What's a good, average number of voices for music and effects?

Voss:

16 for music, 8-16 for sound effects, mixed at 44.1 Khz. RAM-wise somewhere around 512K-1MB for music/sound. I would say soundtracks are in a range of at least 10-25% of the experience of a game, psychologically speaking. So for resources in general, developers should mirror those numbers in how much space, processing, and budget they look at for the soundtrack. In games where the soundtrack is a more key element, there is the added benefit that if the soundtrack is strong enough it could stand on its own as an album, which could reciprocate some of its development cost.


- El micro código de audio también era programable
Q: H2O basically created brand-new sound drivers for Tetrisphere. How powerful are they compared to the original SGI drivers?

Voss:

In retrospect they were close to the same, but allowed me to use a much better and more applicable editing environment. I sequenced the audio/animations/music using a tool called 'Fast Tracker 2' on the PC. This is an event-based music sequencer with everything internalized. It is very cryptic, but if you can handle that, it is a very viable alternative to a lofty MIDI sequencer. We converted that to a proprietary format for playback on the N64, which was calibrated to the N64's low-level audio functions. The replayer allowed me to avoid using AdPCM and use 8-bit samples (about 90% of Tetrisphere's samples are 8-bit). Then we added a simple compression which took about 40% out of all the samples' sizes. The whole sample bank was around 2.75 megs -- all music and sound samples -- with about 1/2 meg of audio pattern data. As an interesting sidenote I did not use any effects-bus -- built in reverb, chorus, delay, effects -- because we were unable to get it going in time along with the custom player. All the effects are hand-programmed delays and choruses within the music.

Since then I have worked with a programmer (Ian Luck) to develop a custom converter which translates a number of "tracker" formats perfectly to Standard MIDI files, along with variable options for calibration of playback to different environments, and "re-wiring" of MIDI controllers to control specific nonstandard effects or events.


- El cartucho, ese enemigo del sonido, aunque la consola fuera muy capaz de generar sonido en alta calidad en los juegos se veían forzados a reducir la calidad del sonido a incluso cosas como usar samples para voces a 16khz o 8bit, o incluso compresiones más salvajes como 8khz.

En una entrevista a Graeme Norgate (Goldeneye 007) da detalles sobre cuanto espacio tuvieron en el cartucho para música y sonidos FX (es un cartucho de 12MB)

In the end, I had 700k for music data and instrument samples, and about the same for sound effects… basically, all the data could have fit onto a 3.5inch floppy disk….so it was a, let’s say, a creative challenge cramming everything in.


- N64 era capaz de crear todo tipo de efectos, reverb, efectos especiales como el efecto de estar bajo el agua en el Zelda OOT, incluso Dolby Sorround o ya terminando, temas tan magistrales como este :
https://www.youtube.com/watch?v=G3dQLs7n79U

EXPANSION PAK
Imagen
El Expansion Pak no es necesario para que los juegos tengan mayor resolución, se puede alcanzar 640x480x32bits sin expansión, lo que hace es simplemente añadir 4MB más de memoria total, en el apartado memoria unificada ya se ha explicado que hacían con los juegos que eran compatibles pero no exclusivos.

- Uno de los pocos juegos que usa 640x480 de framebuffer real es Virtual Chess 64 y no usa expansión.

Se sabe que la expansión es necesaria para jugar algunos juegos, en otros incluyen más contenido, en otros nuevas opciones gráficas, pero que hay de los juegos que no fueron preparados para el Expansion pak?

La consola entiende la RAM como 4 bancos de trabajo para una suma total de 8MB, algunos bloques reservados que se cargan en memoria podrían cambiar de ubicación, como los del SO.
Imagen

1) En Zelda OOT evita que la consola se cuelgue en la cueva Dodongo's Cavern, por la parte donde aparecen los dragones verdes que lanzan fuego por la boca, es un bug muy desconocido que provoca un desborde de memoria cuando lanzamos en frente de ellos Bombchus de forma continua.

El juego incluye un modo debug incluso en su versión comercial, cuando se cuelga se rellena una linea amarilla, se trata de una recopilación de datos, para lanzar el debug hay que usar un comando :
Imagen
L + R + Z
Control pad UP + C-DOWN
C-UP + Control pad DOWN
Control pad LEFT + C-LEFT
C-RIGHT + Control pad RIGHT
A + B + Start


Con la expansión, el juego sigue (o puede llegar a seguir, se trata de un bug grave de carácter aleatorio desde que se provoca) pero anula la capacidad de poder usar objetos, ojo con usar el gancho o Link se quedará congelado, si salimos de esa sala y accedemos a otras el juego se volverá completamente loco, omitiendo texturas, colisiones con paredes, etc

Si salimos de la mazmorra volverá a su estado normal, pues hace un vacío completo de memoria.

Es un fallo que también se puede replicar en el Zelda OOT de disco de Gamecube, pero no en emulador, el cual puede producir un crash en el render y dejar de funcionar.

2) Goldeneye 007, las probabilidades de que el juego se congele son menores, ej. colocando y explotando todas las minas en un mismo sitio, algo que solo es posible usando el cheat de munición infinita.

3) Donkey Kong 64, este ya es un caso conocido, tuvieron que usar la expansión y incluirla con el cartucho porque el juego tenía un bug y se colgaba aleatoriamente (estarían pisando memoria reservada?), es un fallo que incluso puede estar presente en algunos módulos de expansión no oficiales, por lo que se recomienda comprar el oficial.
BMBx64 escribió:3) Donkey Kong 64, este ya es un caso conocido, tuvieron que usar la expansión y incluirla con el cartucho porque el juego tenía un bug y se colgaba aleatoriamente (estarían pisando memoria reservada?), es un fallo que incluso puede estar presente en algunos módulos de expansión no oficiales, por lo que se recomienda comprar el oficial.


Manda narices.
lord_azareus
MegaAdicto!!!
675 mensajes
desde jun 2007
en Alicante, España
Editado 1 vez. Última: 6/06/2016 - 20:51:51 por lord_azareus.
Grandísimo hilo, muchas gracias @BMBx64.

BMBx64 escribió:3) Donkey Kong 64, este ya es un caso conocido, tuvieron que usar la expansión y incluirla con el cartucho porque el juego tenía un bug y se colgaba aleatoriamente (estarían pisando memoria reservada?), es un fallo que incluso puede estar presente en algunos módulos de expansión no oficiales, por lo que se recomienda comprar el oficial.


Además hicieron la promoción que si ya tenías Expansion Pack (como era mi caso) podías cambiarlo por un mando. Así me hice con uno verde xD.
@BMBx64 esto lo sabras, que hace esactamente el PIF? a parte de ser el CIC seleccionando la región.

Lo digo poruqe en el grafico donde se meciona pone PIF CONTROLLER, que mas controla?
1, 2, 3, 4, 5, 6175