Hilo de detalles y curiosidades de N64

Muy buen hilo, me suscribo soy una gran fan de N64 es mi consola favorita, cuando tenga un ratillo ya posteo algo sobre ella

Tremendo post, de lujo.

Que gran trabajo de recopilación de curiosidades, no conocía todas estas cosas del GoldenEye. Además muy bien mostrado con todos esos gif y vídeos, felicidades por la currada .

Me suscribo, es mi consola preferida xD.
Mi objetivo es llegar, algún día, a tener el fullset PAL de la consola, aunque está claro que con juegos como Snowboard Kids 2 o Starcraft 64 va a estar complicado.
Aunque con paciencia se pueden ir pillando casi todos los juegos a precios más o menos asumibles, acabo de conseguir el International Superstar Soccer 2000 a 21 euretes en una puja en ebay, normalmente no bajan de 60 si es la versión multi 4 (la otra versión es FRA/ITA y suele ser más barata).
Además en mi blog he escrito hace relativamente poco artículos sobre Castlevania 64 y Bajo Tooie, vamos que es la consola que más activo me mantien en lo retro.

Gracias por crear este hilo por aqui. Lo vi en otra pagina, pero queria verlo por aqui tambien

Sobre la caida del framerate, recuerdo cuando jugabamos de 4 y explotaban muchas bombas al mismo tiempo, se ponia lento, pero algo que no nos preocupaba en ese entonces.

Me gustan estos detalles tecnicos de las consolas viejas.
Estoy suscribiendome al hilo para seguir sus detalles.

Bienvenido, BMBx64. Un placer ver que has decidido abrir uno de tus hilos en este foro.
Conoces un montón de curiosidades de Nintendo 64 y otras consolas retro, además de que lo documentas todo con un detalle casi enfermizo, jeje. Estoy seguro de que los usuarios de clásicas de EOL van a disfrutar muchísimo con tus aportes.

GoldenEye da para un hilo propio porque el juego fue muy rompedor en su época y hay una gran comunidad de fans que llevan ya casi veinte años destripándolo. Cómo pasa el tiempo.

Algunos apuntes más:
-Al igual que Natalya cambia el discurso cuando sale del ascensor según tu nivel de vida, la conversación entre 006 y Bond al final de Facility también cambia por el mismo motivo.
-La cubierta de Frigate debe de ser el punto del juego donde más bajan los frames. Otros puntos muy problemáticos son cuando se ve la presa al completo en el primer nivel, el nivel de Cradle cuando en pantalla hay algo más que una pasarela y cielo (el nivel está cargado completamente en todo momento) y las salas con columnas del principio de Egypt (que debe de ser la parte del escenario con más carga poligonal de todo el juego).
-Algunos niveles multijugador no se podían jugar a 4 jugadores como Archives, Bunker y Caverns. Incluso Egypt está limitada a dos jugadores (para ser uno de los últimos desbloqueables del juego y un mapa tan grande, sabe a poco). Esto es debido a que no había memoria suficiente para hacerlos funcionar a 4 jugadores, o mejor dicho: los programadores administraron la memoria de esa forma. con la ayuda del editor pude cambiar la gestión de memoria y hacer Archives, Bunker y Caverns jugables a 4 jugadores sin ningún problema aparente (en mis primeras pruebas el juego se colgaba si había mucha acción, pero fui toqueteando la memoria hasta conseguir que no se colgara más). Con Egypt no lo probé porque en esos momentos lo había sustituido por un mapa de los míos.

Saludos.

Geniales aportes sobre este gran juegazo, un motivo entre tantos para tener en su época una n64 y poder disfrutarlo, hoy en día ya no es lo mismo como aquella sensación de antaño sinceramente.
Goldeneye sin duda fué un antes y un después en los shooters, otro título glorioso de la ahora moribunda RARE.

Genial, seguimos pues, a ver que más cosillas van saliendo
Me alegro de verte Sogun no sabía que estuvieras por aquí también

WAVERACE 64

El agua, ese agua
El wireframe es realmente complejo cuando las aguas están movidas, para el que le pille por sorpresa, son las lineas que unen los vértices.


Así que he probado poniendo un set de aguas calmadas desde el menú.


Cuando el agua está calmada se produce un movimiento continuo sin variaciones si no hay eventos que las alteren, se puede ver como el bucle del gif se repite sin saltos.


El agua viene a ser una especie de tablero a base de polígonos, la superficie que rellena es siempre la misma y es de carácter infinito (delimitada solo por el tiempo que estamos fuera de los margenes del escenario), terrenos como islas o playas se ponen por encima, además del baile de polígonos se utiliza iluminación para dar forma a las olas, los colores y las semitransparencias completan el set.

Aquí podemos ver el molde tridimensional de agua que "persigue" al jugador, la gran superficie que se ve por encima corresponde a la capa espacial de cielo.


Las colisiones se hacen con la base poligonal, la jetski sigue el angulo adecuado y el personaje hace el resto con las animaciones, existen excepciones, en los saltos especialmente si inclinamos el joystick podremos meternos dentro de esa superficie para salir después, lo cual nos permite pasar por debajo de un puente en este mismo nivel.

Una curiosidad, el agua no baja en Southern Island, son los polígonos de la isla los que disimuladamente suben.


Existen evento de olas donde se producen las mismas, en este caso para saltar la rampa.


Uno de los escenarios más bellos del juego, desde cerca no puede apreciarse porque quedan muy oscuros, pero desde lejos se ve que los reflejos del lago son en realidad polígonos con la textura invertida.


Los carteles y la publicidad
Los logos de Kawasaki y Jetski salían hasta en la portada del juego.


Cuando lanzaron la versión de la tienda virtual de Wii el contrato ya había expirado, que mejor que hacerle una publicidad muy conveniente a Wii y NDS.



Shindou Edition
La revisión japonesa tiene cambios en muchas de las canciones, pero hay una muy modificada que parece casi distinta:
https://www.youtube.com/watch?v=gpx3S5Yp2iE

La original:
https://www.youtube.com/watch?v=sXVUlu620Mk

Además cambian muchos FX, añade un modo fantasma donde el guía es un delfín y accede al Controller Pak al entrar a los menus.

La guinda es la compatibilidad con el Rumble Pak, al igual que pasa con la reedición de Super Mario 64.


Además de Kawasaki tiene publicidad de Fanta, en otras versiones se cambia la publicidad por un logo de N64:


SUPER SMASH BROS

Debug y hitbox
Smash esconde en la versión comercial varios menús de debug y se puede activar un modo hitbox con códigos gameshark.

- Debug de juego
Nos permite probar todas las modalidades, en diferentes escenarios, seleccionando tiempo y con distintos personajes a la vez, pulsando los botones amarillos podremos testear las animaciones del personaje que tenemos seleccionado en ese momento, dentro de los personajes podemos elegirlos todos, incluso las replicas poligonales o Master Hand.


- Debug de sistema
Este vendría a ser el menú que se utiliza para testear el contenido del juego una vez se encuentra en el cartucho, diferentes CIC de protección de copia, música y sonidos FX, luego incluye test de periféricos y controles, niveles de intensidad del rumble pak, pulsación de botones y calibrado de joystick (son bastante conservadores al usar rango 80 como máximo valor para el joystick)


- Cajas de colisión
Como buen juego de peleas que se precie se utilizan cajas de colisión invisibles para representar la zona de impacto del jugador, como vemos en las imágenes es necesario ignorar detalles, sería un error hacer que la espada de Link tuviera cajas de colisión o la gorra de Mario, el sistema de combate distingue entre 4 colores, la amarilla es la zona que puede ser golpeada y la que da cuerpo al jugador para el choque con paredes o elementos.


La roja corresponde al ataque, las cajas se vuelven relativamente grandes para enfatizar el rango del ataque y equilibrar un poco las diferencias de altura entre luchadores.


Cuando varios personajes atacan a la vez y colisionan se produce un empate, a destacar que en ese instante se pierde el ataque, si un tercer jugador estaba cerca no recibiría daños y podría tomar ventaja en ese instante.


El color azul muestra invencibilidad, cuando nos levantamos del suelo o nos agarramos a una cornisa seremos invencibles temporalmente a los ataques, inexplicablemente al cubrirse no cambia el color de la caja, así pues el escudo altera el comportamiento de las mismas, cuando esquivamos quedamos descubiertos en el final de la animación, es un método bastante común para no spamear ese movimiento.


Como es de esperar los ataques atraviesan al jugador en ese estado.


Por último queda el color verde para cuando el jugador sale del escenario y aparece de nuevo, recibe impactos pero no daños.


Media
Recordemos ese vídeo comercial tan majo donde se daban todos de palos.
https://www.youtube.com/watch?v=K783SDTBKmg

Geometría
Modelados muy discretos, podría intuirse que va a 60fps y aunque en emulación demuestra 60fps, en consola todo parece indicar 30fps, es probable que se deba a que pueden jugar 4 personajes simultáneos.


Para tener algo como referencia, aquí podemos ver el modelado en Super Mario 64.


Aunque cuando la cámara se aleja se aplican diferentes niveles de detalle sobre los modelados (LOD), reduciendo significativamente el número de polígonos.

@BMBx64 Super Interesante y currado, ya me he suscrito al hilo. Felicidades!!!

Buen hilo, me apunto!

WAVE RACE 64

- Al diseñar el juego se planteó la posibilidad de usar lanchas futuristas en vez de motos acuáticas, e imprimirle mayor velocidad a las carreras. Se descartó para evitar parecidos con el posterior "F-Zero X".
- Fué versionado para Gameboy y tuvo en “Wave Race: Blue Storm“ de Gamecube su secuela espiritual.

BEETLE ADVENTURE RACING

- En Australia el juego se rebautizó como “HSV Adventure Racing“, sustituyendo el Beetle de Volkswagen por coches de la marca HSV.
- La música del juego la compuso el canadiense Phil Western, que trabajó con Bryan Adams, Rob Halford o Metallica.

Precioso hilo, @BMBx64!! Me ha encantado la explicación detallada del Waveracer.

Deseando ver más!!!

Perfecto

En esta ocasión quería revisar Turok 1, 2 y Jet Force Gemini, pues considero que tienen cosas originales que aportar, sobretodo en temas de IA.

TUROK
Bueno bueno, se lo está pensando, yo con un hueso de arma y el indio este con el lanzamisiles apuntándome.. en realidad algunos enemigos tienen áreas delimitadas por donde moverse, los enemigos de tipo humano no podrían pasar sobre superficies de distinta altura, a veces hay zonas que tampoco pueden cruzar y se dan media vuelta, aunque no exista ningún limite virtual, este enemigo es de tipo ataque cuerpo a cuerpo y está fuera de mi rango, así que solo le queda resignarse.


Las animaciones están trabajadas, tiene aceleración, inclinación, transición suave entre unas y otras, algo bastante sofisticado para la época, en el gif de arriba podemos ver como el enemigo nos trata de mirar a la cara, como al darse la vuelta se planta ligeramente y hace el giro o aquí en este gif como se plegan para desviarse y dificultar nuestro acierto.


Hay una entrevista con David Dinstbier donde se habla del desarrollo del juego.

Esta clase de enemigos dispara desde lejos y al acercarse golpea cuerpo a cuerpo, hay otra variante que son enemigos en posiciones fijas que solo disparan o lanzan granadas, es fácil de perderlos de vista si los dejamos atrás, cuando toma la cuesta hacia abajo coge la inclinación de la misma, eso es un detalle interesante pues muchos juegos no lo hacen.


Hay otros enemigos como cucarachas capaces de escalar paredes, los enemigos saltarínes pueden bucear en el agua además de saltar superficies, algo bastante curioso es que los dinosaurios y los humanos pueden trabajar juntos, pero si pierden nuestro target se atacarán entre ellos y dejaran de prestarnos atención durante su pelea.


Esta particularidad no es nueva, ya la tenían juegos como Quake, de hecho si miramos la entrevista de arriba se citan varios juegos de ID, por otro lado comentan que un escenario completo de Turok puede ser de entre 250000 y 300000 polígonos, dado que N64 renderiza unos 4000 por frame es bastante normal la niebla, Quake serían unos 10000 polígonos de media por escenario.

David: I was given a book, and in it the authors were talking about the original Doom on the PC, and that each level was composed of about 3,000 polygons, and that each level in Quake was composed of about 10,000. An average level in Turok runs between 250,000 and 300,000 polygons. That's a lot of mass, a lot of polygons.

Si revisamos las geometrías de los niveles de Quake efectivamente se mueven en cifras aproximadas, uno al azar, los datos arriba a la derecha.


Por cierto el hub donde elegir nivel de dificultad fue eliminado del port a N64 además de sufrir inexplicables recortes en los niveles, en esta imagen de debug podemos ver que Quake en PC renderiza unos 378 polígonos en esta escena, los enemigos son unos 200-300 polígonos, así que las limitaciones deberían ser más por falta de optimización o espacio.


TUROK 2
Volviendo a Turok y su secuela hay muchos cambios, una cosa no mencionada es que las colisiones en Turok 1 no son a nivel poligonal, existe una caja mucho más grande que hace un poco de auto aim, ayuda al jugador a acertar con más facilidad, otra cosa es que las colisiones no están localizadas, puedes disparar a cualquier parte y que el enemigo se desangre del cuello, en Turok 2 añadieron colisión a precisión poligonal, al igual que Goldeneye con algunas reacciones independientes según donde disparamos, ahora también reaccionan ante los disparos, ojo a la voltereta hacia atrás del enemigo de la izquierda.


Como me iba a olvidar del cerebral bore? Ese arma que causa pánico con solo verla, así es, no hace falta ni disparar con ella, pero si los enemigos se nos ponen demasiado cerca no dudarán en atacar.


Jugando al pilla pilla, otra de las novedades añadidas en Turok 2 es la capacidad de cubrirse detrás de otros objetos, generalmente cajas para que puedan hacerlo.


Geometría
Turok 2 tiene uno de los modelados 3D más complejos que dio la consola, el protagonista son cerca de 3000 polígonos.


La chica anda cerca de los 2900.


Ambos aparecen a la vez en la intro del juego junto a un portal que mueve gran cantidad de polígonos para las ondulaciones, la tasa va limitada a 15fps, como todas las intros, no la parte ingame que es variable a 30.


Para encontrar algo similar en la generación 32/64bits hay que irse a la demo técnica del dinosaurio de PSX, 2724 polígonos, 30fps, aunque únicamente eso en pantalla.


Vídeo en movimiento:
https://www.youtube.com/watch?v=YCtZIlolG6w

Música
Para el port que se hizo a PC hubo cambios en la música, algunos temas parecen sonar mejor (sin compresión), mientras que otros parecen sonar mejor en N64, como si hubieran sido más revisados después de componer las canciones, aquí tenemos River of souls en PC:
https://www.youtube.com/watch?v=R5TMypZAGSM

JET FORCE GEMINI
Aquí hay algo más sofisticado, los enemigos en lugar de buscar puntos fijos son capaces de esconderse detrás de cualquier pared del decorado.

Además se coordinan entre ellos, creando formaciones, algunas de tipo triangular, en este gif, 2 enemigos están en mis extremos disparando y cubriéndose en la pared, mientras que un tercero ataca desde el centro superior.


Parece que aún no le ha quedado claro si he muerto o no, Floyd totalmente pasivo ante la situación.


Aquí igual pensaron que sería demasiado injusto que al intentar subir el ascensor nos chafara perdiendo una vida. Vela es de goma.


Una de las diversiones más macabras (además de recolectar cabezas) es acabar con los Tribals, generalmente dan saltos de alegría.. hasta que les disparamos, si el resto ven lo que hemos hecho dejarán de estar contentos, miraran hacia el suelo, se secarán las lágrimas y poco más, aunque a simple vista no lo parezca el daño es localizado como en Goldeneye y reaccionan según donde disparamos.


Una de las reacciones más graciosas pasan usando el láser (OUOUOUOOIOIU) o como empiezan a correr si disparamos con el lanzallamas.


A veces los enemigos no se dan cuenta de nuestra presencia, a este lo acabo de asustar.


Un momento que era eso que le estaba lanzando?


Efectivamente no se trata de un ítem, es un arma que se incluye en el repertorio y sirve para cosas tan interesantes como.. alimentar a los peces! Podemos tirar comida a los enemigos también y ver como se miran entre ellos, como luego miran atentamente la comida rebotar como diciendo que me estas contando.

Puede servir para despistarlos o para hacer explotar minas de proximidad, si de casualidad les da pero poco más.

En realidad no lo he vencido y me está pidiendo clemencia, este nivel tiene un fallo que deja anclados a los enemigos, pero si que es cierto que a veces podrán soltar el arma y rendirse con las manos en alto, heredado nuevamente de Goldeneye pero totalmente aleatorio en este caso, también podremos volarles el arma y que se dediquen a correr y lanzarnos granadas.


Debug y curiosidades
En la versión comercial se dejaron un código de debug, si pulsamos esta combinación en la pantalla de inicio donde salen los protagonistas corriendo se abre un cuadro a la derecha :

C-Left, C-Right, C-Up, C-Down, R, L, L, R, C-Up, R, C-Down, R, L, C-Right

La información corresponde a :
- Nombre de la escena, el juego entiende un menú, una intro o una fase como diferentes escenas
- Coordenadas del protagonista: X, Y, Z
- Free 0: Corresponde a la memoria libre principal, omitiendo la de los objetos
- Free 1: Memoria para objetos
- Free 2: Sin uso

De que sirve esto? Tan solo para chafardear, en algún momento dado los betatesters usaron este menú, cuando está activado si se produce un crash nos aparece un menú para trazarlo.


En internet la información para provocar uno es escasa o confusa, porque el juego no tiene fallos conocidos, así que una de las formas es toquetear el cartucho hasta que salte, incluso en esa imagen del code dump se puede leer TLB LOAD, el crash es probable que haga referencia a un fallo por no leer bien la información del cartucho.

Si accedemos a opciones en el menú principal nos sale cerca de 1500KB libres (solo se usan 4MB de RAM en total).


Escenarios pequeños como las tumbas del cementerio siguen dejando mucha memoria libre.


La memoria reservada para objetos es de aproximadamente 100KB pero siempre suele estar en uso, incluso en los menús así que los valores serán siempre menores, objetos como gemas, monedas, cajas de munición suelen ocupar 512 bytes, disparar al cielo con el triple cohete puede acumular 16KB, 12KB con la ametralladora, no hay armas que consuman más ram.

Objects out of ram(1) !!

Ese texto se puede encontrar abriendo la rom con un editor, aunque parece más bien un aviso, de la misma forma aparece un texto que hace referencia a un modo alta resolución que no fue añadido.

El juego tiene muchas curiosidades como un circuito de Diddy Kong Racing que se desbloquea al completar las maquinas arcade de la discoteca, no es de extrañar este detalle cuando parte del equipo también trabajo en el juego anterior.
https://www.youtube.com/watch?v=kLvq3Py2uu0

Y por si fuera poco, lo volvieron a usar en Mickey Speedway (también de Rare) en algunos mapas escondidos en la rom, la gracia es que también usaron el circuito del palacio Mizar de Jet Force Gemini.
https://www.youtube.com/watch?v=xnBOzPy5LbY

También hay canciones ocultas dentro de la rom que no fueron usadas en la versión final, esta es una de ellas (pero hay más):
https://www.youtube.com/watch?v=AcIMNuMeurw

Wireframes y geometría
Algunos wireframes son monstruosos comparado con lo que mueven otros juegos, aunque podrían haber conseguido más rendimiento global descartando diferentes segmentos.


Water ruins usa una geometría más típica, polígonos mucho más grandes, el cielo es tridimensional, cubre y rota sobre el escenario, es seguramente uno de los escenarios más bellos que dio la consola.


Los personajes son de rango 500pol (Vela en este caso), cuando consiguen los propulsores aumenta algo más su cifra.


Por cierto el juego de luces de spacestation era espectacular, que mal rollo me daba esta fase


Para colmo había una puerta redundante, en general toda la última sala de la estación espacial se puede saltar, quizás querían hacer un nivel más largo y se quedaron sin tiempo o espacio?


Video de una beta de Jet Force Gemini
https://www.youtube.com/watch?v=r5BeTXpYJrw

El video tiene ya años, pero muy pocas visitas para ser una fuente original, así que creo que puede ser interesante, hasta el compositor Graeme Norgate se pasa a preguntar de donde habían sacado esto.

Como es de aproximadamente una hora resumo un poco en puntos interesantes (casi todo es música nueva) :
00:16 - Presentación del menú y la música totalmente distintas.
00:35 - Personajes SD, aunque se pueden elegir mediante trucos en la versión final parecen ligeramente diferentes.
00:54 - Se trata de una versión del E3 de 99, el 11 de octubre se lanzo el juego, en muy corto periodo de tiempo rehicieron gran parte de la OST (Robin Beanland).
01:14 - El framerate en la beta parece bastante mejor que en el juego final, quizás corría en devkits ? A la música le dieron un toque cañero y desenfadado.
06:51 - Diferente música en Ichor, por momentos recuerda a Blastcorps.
17:08 - Niveles sin finalizar, vuelves al principio en ciertas zonas, pasa en otros tramos del video, pero por mencionarlo 1 vez.
17:15 - La música del nivel acuático suena en el menú de pausa, por lo visto lo tenían bastante incompleto aún.
18:12 - Diferente música para el aterrizaje de la nave.
21:30 - Más música electrónica feliz.
25:17 - Water ruins.. la música aquí recuerda a Goldeneye (Graeme Norgate), pero como la final ninguna.
31:23 - La música de Goldwood es la misma, no así la de las cuevas.
36:49 - Juno usa un traje rojo bastante diferente, debe ser su actualización de traje por la mitad del juego, nueva música.
51:22 - Y ahora la música se da un aire a Diddy Kong Racing.

Impresionantes todos los datos que nos aportas, apenas conocía alguno. Está muy interesante este hilo espero muchos posts tuyos, la N64 es mi consola favorita, gracias @BMBx64 por compartirlo .

Qué currazo colega

Me encanta el hilo, todo documentado y totalmente parcial, enhorabuena.
Permanezco atento a novedades.

Si queréis comentar cualquier cosa de los juegos no hay problema, así damos algo más de vidilla al hilo

BEETLE ADVENTURE RACING
El juego tiene un increíble modo debug que se activa con código gameshark, es tan extenso que permite hacer de todo, probar pistas, volar sobre ellas, comprobar partes del hardware como monitorizar todo tipo de valores, incluso viene con editores de serie para testear animaciones, vehículos, modelados o efectos.

Podemos navegar por los escenarios con las coordenadas en pantalla.


Vaya.. Need for speed, parece que en principio iba a ser el NFS de N64 luego cambiaron de idea, aquí podemos ver información de vértices, triángulos, carga de trabajo de la cpu, etc. El número de polígonos en escena encaja con las cifras medias que suelen verse en los juegos de la época, entre 2000 y 4000 polígonos por frame.


El visor de vehículos nos permite cambiar todo tipo de parámetros, hasta el tipo de reflejos que tiene el coche, el color o las animaciones, ruedas, suspensión..


Un visor de IA de los contrincantes para probar las pistas vistas desde arriba, la linea representa el recorrido útil y puede extenderse, aparece en varios colores para asegurarse de que esté siempre visible sin importar el fondo, el tamaño de la misma aumenta en las rectas y se reduce en las curvas, probablemente son indicaciones de donde puede acelerar más o menos el coche, con cierto margen de desviación de la posición idónea de trayecto y búsqueda del centro en caso de salirse o estamparse.


También hay todo tipo de modos gráficos pero no todos funcionan, capacidad para desactivar antialiasing, filtro de texturas en bilinear, trilinear o desactivado, alterar gamma o eliminar el dithering, quizás el más sorprendente sea el de recorte poligonal en vista aérea, con un radio rojo de pantalla que determina la visión y amplitud de la cámara, va cargando zonas poligonales si están en el punto de mira de la cámara, va descargando las que no son necesarias, pues aunque no se renderizan en la escena final si que consumen cálculo si están presentes.


El debug es tan extenso que no queda más que dejar unas cuantas capturas más de todo lo que contiene, lastima que texture view rompa la consola y no se pueda acceder.





STAR WARS: SHADOWS OF EMPIRE
Tiene un debug mode que se activa con la nariz, así es, usa una combinación única para sacar el cheat que equivale al Debug mode, primero hay que crear un archivo que se llame "_Wampa__Stompa", el "_" equivale a un espacio, hay que jugar en dificultad media, o no funcionara.

Ahora viene lo bueno, cuando entremos en el juego hay que pausar la partida.

En el menú de pausa hay que presionar y mantener :
Los 4 C amarillos, L, R, Z, Izquierda en el DPAD



Si nos fijamos en la posición de las manos para pulsar todo eso veremos que están bastante ocupadas, ahora queda lo mejor, mientras está todo eso pulsado hay que girar el joystick hacia la izquierda 5 segundos, hasta escuchar un TIC del menú, ahora derecha otros 5 segundos, ahora izquierda, ahora derecha y ahora izquierda, escuchando TIC en cada paso, la nariz o la boca pueden servir para mover la palanca (o unas manos muy hábiles, no las mías).

(Las siguientes imágenes están sacadas de hardware original para asegurar que todos los datos sean correctos)

Vale, ya estamos en el cheat que tiene esto de especial? Las primeras versiones del juego no solo traen selección de nivel, vidas o invencibilidad, también opciones de depuración aunque bastante más limitadas que otras que se han visto como el escandaloso Beetle.


Permite activar y desactivar Antialiasing, el como de útil resulta el AA en un juego que corre a 320x240.. yo personalmente lo prefiero desactivado, además hay una ganancia de 2fps, también se puede activar o desactivar el dithering, también lo prefiero desactivado. (gif con y sin AA)


Se puede jugar sin texturas, sin iluminación.. todas estas opciones incrementan rendimiento.


Se pueden ver datos en pantalla como las coordenadas o el framerate, los HZ son la cifra equivalente en este caso, un dato a tener en cuenta, el juego no corre a 30fps, intenta hacerlo a 60fps, especialmente en las fases de vuelo podrá ponerse a.unos 50fps, aunque la oscilación es tan dispar como la cifra mínima que parece ser 12fps, podemos culpar de ello a las primeras librerías de Fast 3D.


El menú permite cambiar la niebla, el color, la forma, la distancia o incluso desactivarla del todo, como vemos el famoso truco de usar niebla más cercana para ganar rendimiento tiene resultados en el framerate, cuando baja hasta 12 salta un mensaje en pantalla "turtle" o demasiado lento donde el juego pasa a ser poco jugable y tosco.


Con Aspect ratio se puede adaptar el formato al tipo de pantalla, se pueden poner cifras dispares para ensanchar o estrechar demasiado.


Como curiosidad una imagen bien configurada para 16:9 nos consumiría más recursos al hacer aparecer más elementos en pantalla y viceversa, se puede ganar rendimiento aplastando la imagen.


Otras opciones destacábles son el teletransporte, poder controlar enemigos, cambiar la altura de salto o incluso la gravedad.

Curiosidades flash y truquillos de títulos variados.

SHADOWMAN
Esto es un set de texturas del juego, bastante habitual de lo que veremos en la consola pues la TMEM de 4KB dentro del RCP limita el tamaño de las mismas, sin embargo iremos viendo ejemplos ingeniosos a lo largo del hilo con texturas de tamaño y profundidad superior, en este caso:
Tiles de escenarios de 64x64 y 16 colores indexados, algunos símbolos y demás a 32x32.


Ahora viene lo bueno, según Nintendo Acción algunas texturas de Shadowman estaban basadas en escaneos de enfermedades de la piel.

BLAST CORPS

La versión 1.0 que fue lanzada en USA tiene un peculiar exploit, cuando aparcamos un coche pegado a un edificio no podemos salir con el jugador a pie, hasta ahí bien, pero resulta que si empezamos a pulsar el botón Z repetidamente termina por explotar el edificio, incluso aquellos que requieren TNT para destruirse.

Puede que se tratara de una especie de truquillo en tiempo de desarrollo para no quedarse atrapado y que luego no eliminaron o bien una mala decisión que corrigieron muy rápidamente a juzgar por la fechas.

La versión Japonesa ya viene con esto corregido, también tocaron los tiempos del time attack, para la Europea se añadieron los cambios anteriores además de un selector de idioma.

Música
Una de las canciones es un remix del boss de Donkey Kong Land..
https://www.youtube.com/watch?v=_Wx3NbM-KrI

QQQQUAKE
Hay un menú debug que se activa escribiendo un password, si tenemos controller pak hay que entrar en LOAD y luego cancelar la carga para que nos aparezca el menú, escribiendo QQQQ QQQQ QQQQ QQQQ nos saldrá un mensaje de password incorrecto, presionamos B, vamos a opciones y allí está, aunque más que debug resulta ser una herramienta para betatesters, selección de nivel, todas las armas e invencibilidad.


Existe una opción que permite eliminar el antialiasing sin necesidad de ningún truco a diferencia del resto de juegos comentados, eso va a gustos pero creo que mejora la definición de todo el conjunto, la foto tomada directamente de mi tele LED, consola con RGB mod, sin filtro.


MISCHIEF MAKERS
En la pantalla de Press Start hay que pulsar y mantener a la vez (L+A+C-IZQ+C-DER+START), podemos acceder a un sound test, o bien ir directamente a youtube y escuchar el album oficial remasterizado


DUKE NUKEM 64
Hay gran cantidad de material desechado o ligeramente modificado, en N64 no se olvidaron de vestir a la chica antes de meterla en el huevo.


Original en pc.

Vaya currada de hilo!

JacintoCinete escribió:Buen hilo, me apunto!
WAVE RACE 64

- Al diseñar el juego se planteó la posibilidad de usar lanchas futuristas en vez de motos acuáticas, e imprimirle mayor velocidad a las carreras. Se descartó para evitar parecidos con el posterior "F-Zero X".
- Fué versionado para Gameboy y tuvo en “Wave Race: Blue Storm“ de Gamecube su secuela espiritual.

En realidad el Wave Race de GameBoy es de 1992 y fue lanzado en Europa años más tarde tras ver el tremendo éxito de la secuela en 64 bits. enlace a la wikipedia

Aquí un vídeo de ese primerizo Wave Race 64 con lanchas futuristas y unos circuitos que nada tienen que ver con la versión final. La verdad es que uno se pregunta si no se trata de desarrollos distintos, porque es que ni el agua es parecida. Es como si hubieran rehecho el juego de cero.

Del Wave Race 64 siempre me llamó la atención que no tiene secuencia de créditos. Ni siquiera en el manual viene nada. Leí cuando salió que Miyamoto estaba implicado en el desarrollo y sé que la música es de Kazumi Totaka porque es de los pocos juegos donde aún están buscando su famosa canción.

Sogun escribió:

JacintoCinete escribió:Buen hilo, me apunto!
WAVE RACE 64

- Al diseñar el juego se planteó la posibilidad de usar lanchas futuristas en vez de motos acuáticas, e imprimirle mayor velocidad a las carreras. Se descartó para evitar parecidos con el posterior "F-Zero X".
- Fué versionado para Gameboy y tuvo en “Wave Race: Blue Storm“ de Gamecube su secuela espiritual.

En realidad el Wave Race de GameBoy es de 1992 y fue lanzado en Europa años más tarde tras ver el tremendo éxito de la secuela en 64 bits. enlace a la wikipedia

Aquí un vídeo de ese primerizo Wave Race 64 con lanchas futuristas y unos circuitos que nada tienen que ver con la versión final. La verdad es que uno se pregunta si no se trata de desarrollos distintos, porque es que ni el agua es parecida. Es como si hubieran rehecho el juego de cero.

Del Wave Race 64 siempre me llamó la atención que no tiene secuencia de créditos. Ni siquiera en el manual viene nada. Leí cuando salió que Miyamoto estaba implicado en el desarrollo y sé que la música es de Kazumi Totaka porque es de los pocos juegos donde aún están buscando su famosa canción.

Curioso, no lo sabía, y ese video ni lo había visto, jeje. Gracias!

Por cierto @BMBx64 , vaya currada de hilo!

TUTORIAL: COMPILAR Y USAR LIBDRAGON EN WINDOWS
Bueno pues vamos con algo nuevo, las roms generadas no funcionarán en la mayoría de emuladores (los que solo miran libultra), funcionará en emuladores a bajo nivel como MESS o CEN64 y en hardware original.

Primero mencionar que no he dado con ni un solo tutorial que explique bien los pasos, siempre pasa algo que no deja compilar el entorno.

Esto ha sido probado en Windows 7 x64 y Windows XP x86.

DESCARGA
He creado un rar con un set de recursos necesarios:
- Viene la libdragon con algún makefile arreglado, pues da fallo al compilar mksprite, viene un ejemplo que he montado que saldrá al final del hilo, para poder poner una imagen en pantalla sin demasiadas dificultades.
- Viene la versión x86 de cygwin (aconsejable), el entorno de trabajo que usaremos.
- Viene notepad++ (versión portable) un editor de texto, es necesario usar un editor que respete el salto de lineas de un código, NO usar el de Windows, ni wordpad ni nada de eso.

Se puede descargar de aquí

INSTALAR CYGWIN
Descomprimimos N64kit.rar en una carpeta, dentro encontraremos "setup-x86.exe", lo ejecutamos.

Pasos:
1) Elegimos C:\cygwin como ruta, sin complicarnos.
2) Direct connection, se bajaran los paquetes automáticamente de internet (cygwin.netbet.org me fue bastante rápido)
3) Paso sumamente importante, elegimos que paquetes se instalan con cygwin, encontraremos algo parecido a este menú:


En el buscador de arriba a la izquierda buscamos los siguientes paquetes, desplegamos menús, los marcamos tal y como sale en la imagen, solo queremos los binarios, no el "src":

gcc-core
gcc-g++
libmpc-devel
libpng-devel
wget
texinfo
make

* Son cerca de 400MB de descarga, antes de instalarlo se quejará de que falta libusb, damos aceptar y listo.
4) Dejamos que la instalación cree icono en el escritorio.
5) Copiamos la carpeta libdragon que viene en N64kit.rar en "C:\cygwin\usr\local"

COMPILAR ENTORNO
1) Ejecutamos Cygwin terminal, el nuevo icono que hay en el escritorio como administrador (click derecho), durante todo el tutorial no saldremos NUNCA del terminal, minimizar como mucho, nunca cerrar.
2) Nos saldrá una ventana parecida a la consola de comandos de msdos, lo que vamos a hacer es desplazarnos a la carpeta que hemos copiado de libdragon, crear una carpeta temporal y copiar el archivo build, con los siguientes comandos, pulsamos enter en cada uno:

cd ..
cd ..
cd usr
cd local
cd libdragon
cd temp
./build

El último es el importante, en un ordenador medianamente rápido puede tirarse 2 horas compilando, lo dejamos hacer.

He incluido en el zip los archivos que busca build en los repositorios: binutils-2.25, gcc-5.1.0, newlib-2.2.0, para acelerar el proceso.

3) Cuando termine volverá a salir el cursor y podremos escribir, nos fijamos si hay algún texto de error en pantalla, si no lo hay seguimos, escribimos:

cd ..
export N64_INST=/usr/local
make
make install
make tools
make tools-install

* Con esto ya habremos compilado libdragon y todas sus herramientas, nos fijamos que no haya errores, si por algún caso fallamos en alguno de los pasos hay que situarse siempre en usr/local/libdragon para compilar alguno de los pasos anteriores.

COMPILAR LIBMIKMOD
He añadido dentro de la carpeta libdragon/temp la librería libmikmod lista para compilar, no sirve de nada instalar la que viene con cygwin pues es una personalizada, he tenido que corregir el makefile como no, vamos al terminal y escribimos:

cd temp
cd libmikmod
make
make install
cd ..
cd ..

Con esto ya podremos compilar ejemplos que lleven música, volvemos a la raíz de libdragon.

COMPILAR EJEMPLO

1) Ahora lo siguiente es desplazarse a la carpeta de ejemplos y compilar alguno, escribimos:

cd examples
cd bmb
cd filesystem
$N64_INST/bin/mksprite 32 conker.png conker.sprite

Esto coge una imagen PNG y la transforma en un sprite compatible de N64, para situarnos en la carpeta, podemos llegar a través del explorador de windows en :
C:\cygwin\usr\local\libdragon\examples\bmb\filesystem

Podemos cambiar la imagen por cualquier otra en formato en PNG si lo preferimos, si todo fue bien habrá creado conker.sprite en la carpeta.

2) Ahora lo siguiente es compilar el ejemplo, escribimos:

cd ..
make

Y... después de tanta historia habrá compilado algo?


Si lo hemos hecho bien, en la carpeta (C:\cygwin\usr\local\libdragon\examples\bmb\) aparecerán los siguientes archivos, el que nos interesa es bmb.v64, lo copiamos a la SD del Everdrive 64 y listo.


APUNTES
- Si queremos trastear con el código es el fichero bmb.c, lo abrimos con Notepad++ (N64kit.rar)
- Los ficheros bmb.bin, bmb.elf, bmb.o, bmb.v64, spritemap.dfs se crean con el make, podemos borrarlos, si actualizamos algún sprite de la carpeta filesystem es OBLIGATORIO eliminar el archivo .dfs o no se actualizará al compilarlo, esos archivos están de cache para acelerar compilación.
- Es de vital importancia recordar:
export N64_INST=/usr/local
Lo tendremos que escribir antes de compilar un ejemplo si hemos cerrado el terminal.
- Cada vez que cerremos el terminal tendremos que ir de nuevo a la ruta (usr/local/libdragon)

cd ..
cd ..
cd usr
cd local
cd libdragon
cd examples

Es imprescindible aprender como se navega por los archivos con el terminal, si queremos ver que contiene la carpeta actual escribimos "dir" en el terminal.
- En este enlace hay descripción de todas las funciones de libdragon

RESULTADOS
Bueno por fin, pedazo de tostonazo no? Con razón ni dios programa nada de homebrew en N64

El test bmb es simplemente una imagen que se puede mover por la pantalla usando el joystick analógico, el código que he implementado para sacar los fps es muy experimental, se basa en la teoría de que cada ciclo de código es un frame renderizado y que el clock de sistema es independiente, puede que no sea exacto, pero todo parece indicar que libdragon por defecto funciona a 30fps y hay que modificar algún valor para cambiarlo.


Se pueden usar sprites por hardware o por software (que todo lo haga la cpu), obviamente por software es MUY lento, si los hacemos por software no hay limite de tamaño, puedes coger una imagen de 1MB y la N64 hará lo que pueda para representarla, si usamos los sprites por hardware estamos limitados a los 4KB de la TMEM.

En este otro ejemplo he usado el modo 640x480x32bits, lo máximo que da la consola, he cargado una imagen a lo bestia de 640x480 y 32bits de casi 1MB (de los 8MB totales con expansión), el rendimiento es de... 3fps, como es de esperar, creo que para modos por software lo ideal sería usar 320x240 y 16bits.


LIMPIEZA
Una vez funcione todo correctamente podemos borrar la carpeta temp de C:\cygwin\usr\local\libdragon, ya no nos hará falta y ocupa más de 2GB.

Seguiré experimentado a ver si puedo hacer alguna tech demo maja o algo

Esto ya me gusta mas

A mi lo que mas me apetece es zambullirme en toda la historia del proceso de la N64, sus especificaciones originales, el funcionamiento del hardware final...

Gran trabajo, sigue así

BMBx64 escribió:TUTORIAL: COMPILAR Y USAR LIBDRAGON EN WINDOWS
Bueno pues vamos con algo nuevo, esto solo tiene sentido para el que tenga un copión o flashcart y quiera trastear con la consola, las roms generadas no funcionarán en la mayoría de emuladores (los que solo miran libultra), funcionará en emuladores a bajo nivel como MESS o CEN64.

Fixed.

Este hilo es genial.
Me asombra realmente la diferencia gráfica de un juego a otro de esta consola. Hay juegos con pésimos gráficos, poca carga poligonal y con un framerate completamente errático. Mientras que otros son todo lo contrario.

El otro día estuve justamente probando el San Francisco Rush y me resultó imposible jugarlo. Sin embargo su secuela es espectacular técnicamente hablando. Si uno lo ve distraído podría pasar por un juego de Dreamcast.

No se si tiene mucho que ver con el hilo, pero me llamó mucho la atención y quería mencionarlo

He actualizado el tutorial de libdragon añadiendo info de la libmikmod, ahora se puede reproducir música en los ejemplos, he actualizado el zip añadiendo otras cosas para facilitar la instalación.

La consola es una buena bestia para las 2D, es una lastima que apenas se explotara, por software puede renderizar más de 128 sprites sin bajar de fps en modo 320x240x16bits.


Por hardware de momento he conseguido este rendimiento con la libdragon, sin optimizar nada, los 2048 sprites son de 16x32 a 16bits.


Cuando termine con los tests miraré de hacer algo funcional, una demo un juego o algo y ya subiré el ejemplo.

MÁS CURIOSIDADES

Controller Pak
La tarjeta de memoria siempre ha dado la sensación de llenarse enseguida, pero cual era su capacidad real ?


Tenía solo 32KB de memoria SRAM alimentada por un modelo de batería no recargable, la capacidad esta repartida por páginas, 128 páginas x 256 bytes = 32KB, solo 123 accesibles, el resto se usan por el sistema de paginación, índice de tabla, etc.

Podían almacenarse un total de 16 juegos y el código para gestionar las partidas tenía que inyectarse en el propio juego, generalmente no llegaba a llenarse la lista, muchos juegos pedían las 123 páginas para guardarse, otros como Gex Enter the Gecko usaban 1 sola, donde solo guardaba el password que también podía introducirse manualmente.

Habían memorias no oficiales con más capacidad, aunque usaban un interruptor que alternaba 4 bancos de memoria siguiendo ese esquema.

Rumble Pak
Curiosidades que igual sepas o no de este accesorio.


1) Funciona con 2 pilas AAA porque la consola no podría dar suficiente energía a los 4 mandos con rumble simultáneamente.
2) En las tiendas llegaron a hacer un mod donde se alimentaba del mando con tal de que no robaran el accesorio (o se quedara sin pilas), en la actualidad existen tutoriales para hacer el mod, teóricamente la consola puede con 2 mandos a la vez.
3) Según la libdragon (SDK) y el manual de programación oficial de N64 el rumble solo tiene 3 funciones básicas :
rumble_init
rumble_start
rumble_stop
Hay que usar intervalos de tiempo para darle forma y textura al tipo de vibración, se entiende que si dejamos el rumble iniciado en cada frame llegara a su máxima velocidad de vibración en muy corto periodo de tiempo y que si lo apagamos y encendemos en un cálculo constante podríamos mantener un nivel de vibración estable ajustado.

Emuladores
Existen varios emuladores funcionales en N64, uno dentro de Excite bike 64 (el Excite Bike original de NES) otro de Gameboy en Pokemon Stadium 1/2 bastante más avanzado porque se pueden jugar los Pokemon Rojo / Azul o incluso Amarillo de GBC, mediante el Transfer pak pasa la información completa del cartucho al emulador para hacer funcionar el juego, la cuestión es que han encontrado la manera de inyectar otros juegos para hacerlos funcionar.
https://www.youtube.com/watch?v=cB9jr4lOOvw


CHOPPER ATTACK
Este juego tiene el siguiente truco en la pantalla de presentación (Press Start): Matener Z mientras pulsamos en el DPAD: Derecha, Izquierda, Arriba, Abajo, A, B, Start, si lo hacemos bien tras pulsar start nos saldrá esto.


Exacto, texture mode estaba mirando, funciona? Sí, que es? Elimina el filtrado de texturas, así que se ven pixels como bloques, en este caso no mejora el rendimiento del juego, el cual es muy bueno el 99% del tiempo, pero siempre me hace recordar que Nintendo pudo haber usado un menú genérico en sus juegos para elegir este tipo de detalles, captura en consola.


Y en emulador ? Pues va a ser que también funciona, aquí he podido hacer un cara a cara de los beneficios de usar filtrado de texturas, recordemos que el emborronamiento del que tanto se habla no viene de los filtros, sino más bien de la salida de vídeo de la consola.


TOP GEAR RALLY
Resulta que hubo un target render para mostrar que intenciones tenían con el juego, aunque obviamente se quedaron lejos del mismo, escenarios completamente distintos, mucha más carga gráfica en el target o la música que terminó siendo estilo tracker de amiga (música solo por canales izquierdos o derechos).
https://www.youtube.com/watch?v=NKkEk6k6wu4

Aún así TGR fue un juego genial en su momento, los escenarios lejos de ser los típicos túneles (hola v-rally) eran terrenos abiertos, con rutas alternativas, con detalles poligonales como casas, piedras, carteles, hasta podías salirte del escenario y hacer una escapada a la playa con detalles como el efecto majo en el agua.


Cada rueda tiene física individual, eso permite todo tipo de rebotes, derrapes y posicionamiento sobre el terreno, el porcentaje de todas estas variables se puede alterar eligiendo diferentes neumáticos, volante o suspensión, el coche reacciona continuamente y de forma diferente a cada terreno, eso junto a los 30 fps estables hacen una conducción variada y bastante divertida, los choques son alocados, en la primera cuesta que hay en el nivel de la jungla.. vaya pues me he ido a tomar viento!


Uno de los puntos más flojos del juego son los 5 circuitos que tiene, un fallo común en los juegos de la época, no importa que se puedan correr invertidos con diferentes cambios climáticos, eran muy pocos.

Otra cosa es el nivel de detalle de los vehículos que se vio perjudicado por la herramienta de dibujo del juego, tal como dice uno de sus programadores:

Asset creation was more of an issue with the restriction than the limitation itself. I really hated how we had to make the cars look in Top Gear Rally, because we allowed the users to edit the textures they had to have a very simple mapping which precluded us from making them look much better than they did.

Si miramos el editor de dibujo es bastante simple pero funcional, consta solo de 16 colores como suma total, no hay más, los detalles originales ya vienen con esa limitación, las texturas están agrandadas, en este caso aunque parezca de 128x128 la unidad mínima del píxel es de 4x4 por lo que realmente sería de 32x32 en este caso, todo ello fueron decisiones para reducir el espacio para guardar nuestros garabatos en el cartucho/tarjeta, quizás el zoom en las texturas para facilitar el trabajo de edición.


Música
El menú más mola con la música Europea / Japonesa
https://www.youtube.com/watch?v=Z_y1Vd6QUmU

Un vistazo a como suena la americana
https://www.youtube.com/watch?v=7MwVGunH45k

GEX 64
Es tan port de PSX que conserva hasta las salas de guardado originales, con su botón delete pulsando cuadrado y todo.


Para acceder a estas salas hay que usar el código de gameshark de levitar y tener mucha paciencia para encontrarlas, entre la niebla que deja escasa visibilidad, que están perdidas por el aire (al menos quitaron las plataformas que llevan a ellas) y que el juego tiene limites.. tras muchos intentos alguien logró llegar a una de las salas, en esta no aparecen los botones.
https://www.youtube.com/watch?v=o5nI8W_W8Tk

EARTHWORM JIM 3D
Tiene un menú de depuración para enseñar cosas como los fps, un momento, una muestra del porqué no hay que fiarse de lo que digan algunos emuladores.


El contador de fps, marca lo que dice el emulador y no lo que debería el juego, si hacemos correr el contador de fps en consola el juego apunta a 30/31 fps, pero rara vez lo consigue, oscila entre 15 y 30 sin frameskip, es decir, se pondrá a cámara lenta cuando no consiga la velocidad objetivo.

Existe otro menú de información que marca el número de canales de sonido activos (no cuenta música) y pone información de objetos o incluso de polígonos por frame, canales activos he llegado a ver hasta 8 pero es probable que se usen más, el juego logra mantenerse a 30fps mientras el contador de polígonos esté por debajo de 900, no está rindiendo a mucho más de 30K pol/s, es uno de los rendimientos más bajos que he visto en la consola junto a los títulos de Infogrames.


Mismo lugar y posición en consola, venga va, podemos dar por buenas las cifras de polígonos que arroja el emulador.

Me uno! hilo gigante

Un placer ver tus posts @BMBx64 . Mira que es mi consola favorita, pero siempre me pareció una estafa el Controller Pak, 5.000 pesetas que costaba por 32KB de memoria, puff.

Muy curioso que el Rumble Pak fuese a pilas porque la consola no podía dar suficiente corriente a los cuatro mandos, yo en su época le adapté un trasformador genérico de Game Boy Pocket para usarlo en el Rumble, jajaja.

Una pena que no se explotase más a fondo la N64 para juegos 2D con sprites, sorprende que fuese tan buena en ello como has mostrado.

Al Top Gear Rally le di bastante, me gustaban los escenarios abiertos y el detalle de las ruedas, como comentas en tu post; estaba muy currado eso. En cuanto al Gex64, me ha matado que fuera un port directo de PSX, mira que dejarse hasta los iconos de los mandos de SONY .

Muchas gracias mbm!!! Mira que no he probado casi juegos de la N64 (por ahora) pero muy interesante el post

Me apunto el hilo, y espero a nuevas actualizaciones, por lo que te invito a dejes tu vida profesional, familiar y personal para dedicar mas tiempo a este foro y al hilo en particular bajo pena de tener que jugar al superman 64 durante un año consecutivo

La verdad es que esta bastante interesante el hilo en general y me interesa bastante el tema.

Cuando queráis empezamos con los detalles técnicos de la consola, de momento solo están siendo juegos, curiosidades y pequeñas cosillas.

Hay una beta del Superman 64 para máxima tortura

MÁS CURIOSIADES

Porqué esta pelota en el cable ?
Se trata de un requerimiento de la Unión Europea con respecto a las interferencias electrónicas, una especie de anillo de ferrita, hay 3 diferentes encapsulados, este es el común de Nintendo, más tarde se vendieron mandos sin él o quizás fueron importados?


El botón reset

No corta la alimentación de la consola, se trata de un botón que lanza una llamada a un reinicio por software, cuando la consola se bloquea completamente es imposible hacer reset, hay que apagarla.

1) El botón puede hundirse y estropearse, es un fallo bastante más común de lo que parece.
2) Existen juegos con apagados personalizados antes del reset, en Turok 1 suena una bestia al pulsar el botón, otros usan persianas que se cierran o diferentes fundidos.

Costes de producción
Una tabla comparativa con los costes por componente en el año 1997, se trata de cifras orientativas (cuando se refieren a subsistema de audio imagino que se trata del VDC-NUS o a componentes que conformen el conjunto del DAC), como podemos ver en Nintendo apuntaban hacia una maquina low cost (recordemos el precio en que se lanzaron PSX o Saturn), cabe destacar que hubo toda una serie de recortes de última hora como la salida RGB, algunas especificaciones y retrasos de la consola (la CPU inicialmente iba a funcionar a 105Mhz, lo cual significa que el RCP lo haría a 70Mhz, en lugar de 93,75 y 62,5 respectivamente).

En el caso del software se puede ver el precio de los cartuchos y sobretodo los elevados royalties como un punto negativo a la hora de apostar por N64.


Haciendo un cartucho transparente
He visto por ahí un post donde enseñan imágenes de como se hace un cartucho de N64 en un molde, dándole color, etc me ha parecido interesante, imágenes cortesía de McFish.

Tenemos el molde por un lado del cartucho, luego por el otro, se limpian y recortan los restos, se usa una especie de embudo para rellenar los orificios más pequeños, con la forma final de la carcasa se empieza a pulir, se le da color..








En su forma digievolucionada


Y estas piezas de metal?
Sirven para facilitar el encaje del cartucho en la ranura de slots de la consola.


Hay algunos cartuchos como el Everdrive que pueden venir sin esos metales, hay que tener cuidado porque se pueden dañar las patas del slot que se ve en esta imagen, como levantándolas de su sitio.

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?

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.

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.

Muy buen hilo, estoy disfrutando de lo lindo!!

Saludos y gracias al autor

Bueno pues ya he alcanzado los 60fps con la libdragon , 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.


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.


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


Audio


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.


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

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?



- 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

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.


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 :

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.

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?

@BMBx64 por casualidad, tu no sabrás como rescatar las partidas guardadas de los cartuchos para poderlas jugar en el emulador (no quiero volver a pasarme todo el Zelda OOT)

Saludos y a seguir con este fantástico hilo!

DiGiCharatFan escribió:@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?

En ese bus tienes SI(serial interface) y PI(peripheral interface), se usa SI para enviar instrucciones directamente a la RAM de PIF, puede leer / detectar mandos y los periféricos como la memoria o el rumble, también controla el botón de reset y como bien dices lee la protección de los cartuchos, se retorna un resultado que rellena los registros de SI para usarlos después.

Aracnoid escribió:@BMBx64 por casualidad, tu no sabrás como rescatar las partidas guardadas de los cartuchos para poderlas jugar en el emulador (no quiero volver a pasarme todo el Zelda OOT)

Saludos y a seguir con este fantástico hilo!

Cartucho original o flash? Aún así el Zelda OOT tiene bastantes cheats para situarte casi donde quieras.
--

GEOMETRÍA
Existe un plugin (lemD3D8) que en modo debug permite hacer un dumpeo de la escena poligonal presente, su único problema es que hace a su vez de render gráfico, la compatibilidad con los juegos y los detalles están limitados a ese plugin concreto, si bien existen herramientas que sacan los modelados del DirectX, pero este sirve para generar escenas globales.

Si se quiere saber la cantidad exacta que se renderiza por frame es necesario tener en cuenta el descarte de polígonos que quedan tapados, eso varía de un juego a otro, de un micro código a otro, los personajes mostraran más polígonos estando de cara que de espalda, pues muchos se concentran en el rostro y otros detalles frontales.

El plugin no saca solo la información de la cámara, sino toda la geometría cargada en ese momento, incluso la que no vemos, esta es la fase del desierto de Mario 64, como se ve el juego es muy simple en ese aspecto, todo ese mapa no llega a 2000 polígonos, el protagonista de Turok 2 contiene más, como se vio páginas atrás.


En Goldeneye utilizan cerca de 460 polígonos por soldado (en esta escena he eliminado todo salvo el soldado).


Aunque lógicamente no todos van armados con el mismo rifle (o llevan sombrero), así que lo he separado del modelado, 52 triángulos, se puede deducir por tanto cuanta geometría mueve un NPC cuando va desarmado.


Lo óptimo son unos 3000-3500 polígonos por frame, como podemos imaginar aquí se esta triplicando esa cifra y la consola sufre, no solo por geometría, el código de colisión, IA y física de tanto soldado a la vez.


Ahora Perfect Dark, la cámara esta situada un poco más arriba del brazo, existe el modelado del brazo al completo, el arma y la mano, además del puntero láser, tanto en el arma como en el cuerpo del enemigo.


Ya solo la mano y el arma son 527 polígonos.


Hay mejora en los enemigos, en Perfect Dark los modelados tienen más polígonos, una mejor distribución en el cuerpo y en la cara, los soldados usan 200 polígonos más que en Goldeneye.


Los resultados de Fighters Destiny 2 son un poco decepcionantes, en escena completa el juego mueve unos 2000-2200 polígonos, los escenarios constan de unos 50-100 polígonos, si interpretamos el framerate y la escena nos salen unos 60-66K, hay juegos por encima de ese rango.


Si descartamos el escenario y el otro jugador vemos que los personajes apuntan a un modelado de rango 900 pol, eso es sin contar la sombra, la cual consume 108 polígonos en este caso, si sumamos 2 luchadores de 1000 tendríamos esos 2000, con ese poco margen de detalle para escenarios o partículas que no suceden en esa captura de render.


En Mace por ejemplo hay más detalle en los escenarios, desde este angulo que he cogido el escenario parece un estudio de grabación , cerca de 2000 polígonos solo para el escenario.


Y los personajes tienen una geometría similar, 1019 en este caso, que sigue estando en el rango de los 1000, aunque el bajo framerate hace que sea mejor elección el estilo de Fighters Destiny (y probablemente entra en juego la manera en la que esta escrita el código), la cuestión es que hay geometrías muy superiores en juegos de otros géneros, sin Namco sacándole jugo a la consola es difícil imaginar que podría haber salido de exprimirla un poco más en este género en concreto.


Ahora un vistazo a Fighting Force, según las cifras extraídas del Fighting Force de PSX que supuestamente es la misma geometría serían 3024 pol/frame (en PSX se pueden saber cifras exactas de renderizado).


He borrado todo excepto 2 personajes, la chica tiene 600 polígonos, parece que el juego mueve ese rango para los personajes e igual o algo menor para los enemigos.


Ahora veamos el despilfarro del suelo, 770 polígonos, sabemos que la consola puede usar polígonos muy grandes gracias a la corrección de perspectiva, o incluso Saturn hace una especie de modo7 o plano abatido en muchos juegos donde el suelo es simplemente una superficie plana para no renderizar esa cantidad innecesaria (como en la beta de este juego).


Un vistazo al campo de Fifa 99, resulta interesante ver que faltan jugadores o incluso la portería, en ese momento la cámara estaba picada enfocando a una pequeña región del campo, es de imaginar que los objetos dinámicos como jugadores los recoloca fácilmente en el campo cuando sea necesario.


Y que hay de los jugadores? 320 polígonos aprox. al menos con este tipo de rostro, peinado, etc, si nos fijamos en su sombra no están haciendo el método de FD2 o Mace, sino que están usando un buffer interno para representarla.


Conker son 1200 polígonos, en el LOD más cercano (el de la intro)


Conker justo antes de entrar a la taberna, la geometría a nivel global de escenario sería 6 veces superior a Super Mario 64, esto es sin descarte poligonal, habría que deducirle cerca del 30%


548 polígonos el prota de Misión Imposible.


Los modelados de Pokemon Stadium 2 son bastante normales en geometría, pero están muy bien hechos con esa cantidad, Steelix son 714 polígonos.


Los renders los estoy sacando o bien en wireframe o en flat shading para que se vean las caras, aunque en los juegos están usando sombreado goraud que quedan más redonditos, además de mejor iluminación y color.


Por cierto los wires engañan bastante si no se sabe la tasa de frames, en Mortal Kombat 4 los escenarios son más complejos que Fighters Destiny, con columnas o estructuras simples, todo eso sería bajo si no fuera porque el juego va a 60fps, como curiosidad la sombra es la misma para todos los personajes.

Aracnoid escribió:@BMBx64 por casualidad, tu no sabrás como rescatar las partidas guardadas de los cartuchos para poderlas jugar en el emulador (no quiero volver a pasarme todo el Zelda OOT)

Saludos y a seguir con este fantástico hilo!

BMBx64 escribió:Cartucho original o flash? Aún así el Zelda OOT tiene bastantes cheats para situarte casi donde quieras.

Cartucho original, el tema seria copiar la partida del cartucho original y meterla para jugarla en emulador y/o en flashcard.

¿Como se pondrian esos cheats tanto en emulador como en flashcard?

(Buenísimo el último post)

Saludos y gracias

Aracnoid escribió:Cartucho original, el tema seria copiar la partida del cartucho original y meterla para jugarla en emulador y/o en flashcard.

¿Como se pondrian esos cheats tanto en emulador como en flashcard?

Te pongo la opción más fácil, en el emulador PJ64 cuando cargues Zelda OOT te vas a sistema/cheats y debería salirte una lista, en "have" eliges el inventario y el juego te deja progresar según las cosas que vayas añadiendo, si lo editas bien puedes dejarlo bastante parecido a la partida que tengas en el cartucho.


--

LIBULTRA Y MICRO CÓDIGOS
Dentro del RCP hay el RSP para cálculos y otras instrucciones, con 4KB para código personalizado y el RDP, el rasterizador.

Para crear una escena 3D hay toda una serie de pasos para asegurar un buen rendimiento.

Scissoring box
El rasterizador elimina las porciones que quedan fuera de esta caja, esto puede usarse como pantalla, como el típico mapa o radar en una región de la pantalla,etc

Reject box

Es otra caja del tamaño relativo a la pantalla, se puede elegir de proporción 1 a 6.

Lo que hace es rechazar los polígonos que salen de esa segunda caja, con que sea 1 solo vértice todo el polígono entero será descartado antes de ser renderizado, esto choca con la idea de querer usar polígonos muy grandes para grandes superficies (algo que se puede ver en el render de Super Mario 64), sin embargo los escenarios se configuran en modo clipping y no llegan a salir de la pantalla pues se subdividen, viene después explicado.

Cabe destacar que estas cajas solo determinan coordenadas X/Y, para Z existe otra variable de profundidad.

Jet Force Gemini tiene un buen ejemplo en la pantalla de selección de personaje, la cámara gira alrededor de los personajes, decidieron que lo mejor para componer la escena era un ratio de 6:1.


Zelda Majoras Mask usa 2:1, si nos fijamos en el lado izquierdo la función de rechazo ya se ha comido unos cuantos triángulos que eran paredes rectangulares, por otro lado la máxima geometría que puede mover el juego sin tener caídas de rendimiento parecen ser 4000/pol frame, como nota el juego se ahorra el algoritmo de frameskip cuando funciona a 20fps y en los primeros frames de caída.


3D Clipping
Consiste en recortar un polígono subdividiendolo en 2, el margen de maniobra es el espacio muerto entre la caja de recorte de la pantalla y la de rechazo, es decir si un triangulo está mitad dentro de la pantalla la parte que queda fuera de la pantalla es eliminada tras ser subdividida, esa es la idea, que el rasterizador no pierda tiempo.

Sin embargo todo esto consume recursos y hasta la propia Nintendo lo desaconseja para uso global.

3D clipping is expensive and should be avoided. Methods employed by the host application which can reduce the amount of geometry that gets clipped are a good idea. Crude visibility determination algorithms, geometric level-of-detail, and careful scene construction can help improve clipping performance dramatically.

The clipping algorithm is sensitive to large numbers and overflows.

Es de suponer que juegos donde usen polígonos pequeños para formar el escenario usen un ratio de descarte algo más grande pero eviten clipping como Fighting Force (porque muchos polígonos serían subdivididos en muchos más, lo cual también aumenta el polycount a nivel interno) y juegos como Castlevania 64 que usa pocos pero gigantescos le saquen más partido a esto con el clipping.


Back-Face Polygon Culling
Es lo que permite establecer que caras están delante y cuales detrás con respecto a la posición de la cámara, permite descartar polígonos que queden detrás de un modelado.

Veamos un ejemplo, que es todo este desastre de lineas? Efectivamente vuelve a ser Conker.


El wire es esta escena (con framerate incluido)


Vamos a darnos una vuelta por el buffer enviado a DirectX.. como se puede ver al modelado de Conker lo han troceado cuando mira en primera persona pero eso es parte del proceso de rechazo fuera de pantalla, dando una vuelta se puede ver que hay algunas caras descartadas de la geometría que pintan, recordemos que esta rutina es efectiva para los polígonos que tienen un set "back-face" el cual es dinámico, si damos la vuelta al objeto ya no será la parte de atrás sino la de delante, todo esto necesita de cálculo.


Ahora sabiendo que el clipping requiere mucho cálculo que recomienda Nintendo? Como ya se comento lo que trata la geometría son los micro códigos, cuando se habla de Fast 3D o F3DEX es una serie de micro códigos, luego hay unos cuantos especializados para distintas tareas que hay que cargarlos de forma secuencial.

Because microcode loading increases overhead, discretion in loading is recommended to obtain good performance. For practical purposes, this means intermittently switching between the microcode types used for rendering. As an example, a clip-capable microcode such as F3DLX would be used for rendering landscapes and fast microcode such as F3DLX.Rej used for rendering characters. As with previous releases, switching between F3DEX and L3DEX when rendering lines can be done without CPU involvement.

F3DLX tiene todas las funciones de clipping y culling, se aconseja para escenarios, que son los que usan polígonos grandes y superficies donde hay que rellenar muchos pixels, para realizar las funciones también necesita recopilar información previo paso y realizar muchos cálculos de la proyección de la escena.

F3DLX.Rej para personajes, este código es mucho más liviano pues lo único que contempla es el rechazo de polígonos al salir de la pantalla y no se hace clipping, haciendo G_CULL_BACK aumenta el rendimiento especialmente cuando se acercan objetos a la pantalla pues no se renderiza la parte que no se ve del polígono, G_CULL_FRONT sirve para eliminar las caras que queden demasiado cerca de la cámara, es indispensable eliminar no solo porque taparían toda la imagen sino porque es drástica la caída de rendimiento de cualquier elemento que se acerque demasiado a la cámara, parece que los emuladores no hacen G_CULL_BACK en muchos casos o no queda demasiado claro al sacar las extracciones poligonales, en los emuladores de PSX si que se hace el descarte de caras y las cifras de escena son más exactas.

Otros datos a tener en cuenta extraídos del SDK.

Triangle Rejecting Process
- Triangles which are entirely inside the rejecting rectangle are drawn.
- Triangles which stretch from inside the rejecting rectangle to outside, or those that are entirely outside the rectangle, are rejected.
- The rejecting box is 2-6 times the size of the screen rectangle. By default, the rejecting box is 2 times the size of the screen rectangle. The range can be changed using g*SPClipRatio. Values from FRUSTRATIO_2 to FRUSTRATIO_6 can be specified. In the Z direction (the depth direction of the screen), rejection is performed according to the Far plane. No rejection is performed according to the Near plane.
Please see "Rejection Processing" below, for additional information.
- Because of reject processing, a large triangle may not be rendered if one of its vertices falls outside the screen, even though it should appear in the screen.
- Reject processing with F3DLX.Rej and F3DLP.Rej can allow faster processing of “2 Triangles” commands. When making DL, it is advantageous to use g*SP2Triangles, if possible.
- The gspF3DLX.Rej.o version provides texture perspective correction, while gspF3DLP.Rej.o version does not. F3DLP.Rej is slightly faster than F3DLX.Rej.
- Both F3DLX.Rej and F3DLP.Rej do not support G_CULL_BOTH.

Un ejemplo de como el número de personajes afecta a la geometría sería Tony Hawk 3, al ser un solo protagonista invierte mucho cálculo en la geometría del escenario.


Test
Con toda esta teoría vamos a probar un test de ejemplo que viene en el SDK, imágenes extraídas de hardware original.

En el test se pueden elegir diferentes figuras geométricas como cubos o triángulos.


La barra de abajo corresponde a los recursos usados de los diferentes componentes, agrandar un objeto más de la cuenta consume mucho más de lo esperado.


Este menú corresponde al color combiner, se pueden aplicar colores o texturas a una superficie y otro tipo de combinaciones, el consumo aumenta al poner todo este texto en pantalla, quizás esta siendo renderizado por software?


Una buena configuración permite este tipo de efectos.


Este es el menú del RSP, aplicar goraud shading le sale gratuito a la consola según este test.


Una iluminación básica aumenta algo la carga de recursos, ahora hay que imaginar que pasa en juegos como Forsaken 64.


Veamos Forsaken 64 en acción


También combina los colores de todas las fuentes y saca tonos intermedios.

IGN: Forsaken 64, set for an April 98 release, looks great. Running at 60fps (frames per second) in single-player mode and a smooth 30fps with up to four people playing, it's also fast.

The Nintendo 64 version of the game will feature exclusive new levels and weapons as well as more sophisticated AI (artificial intelligence) than its PC predecessor.

En realidad el juego corre a 30fps en N64, en PC servia como benchmark para las tarjetas gráficas de la época.


Con G_CULL_BACK desactivado (lo que descarta polígonos que quedan detrás o tapados) el consumo se dispara, es de imaginar que los juegos deberían tener este set activado, aunque este micro código es realmente antiguo.


Con el Z-buffer desactivado hay un ligero aumento de rendimiento pero se producen errores de prioridad en los modelados, habría que hacer un listado manual como en World Driver Championship, no es de extrañar que la mayoría de compañías no se calentaran la cabeza y tiraran de esto aún perdiendo fillrate.


2Cycle permite hacer efectos interesantes como los reflejos del agua en Zelda OOT, permite combinar 2 texturas, solo aumenta la carga de proceso del RDP, no del RSP.




En el menú de VI (Video) tenemos diferentes apartados uno de ellos son correcciones de gama, algo que esta presente en algunos juegos de la consola, activarlo o desactivarlo no supone ningún tipo de cambio de rendimiento y un filtro para el dithering que evita que se vea el tramado de pixels, en este caso activarlo si consume recursos, ahora no recuerdo pero creo que hay juegos que permiten activar o desactivar esto en las opciones.






Optimizaciones para objetos que están parcialmente fuera de la pantalla (Scissoring box, mencionado arriba).

Impresionantes tus post, de verdad

Tienes alguna curiosidad que comentar del Diddy Kong Racing? Yo flipé en su dia con él, lo considero bastante mejor que Mario Kart 64, muchos mas circuitos, un modo historia genial con jefes y todo, varios vehiculos, etc

El juego iba fatal de frames en muchos momentos, sabes si con expansión pack iba mejor? Habría alguna posibilidad de jugarlo en algun emulador con unos 30fps estables?

Sí, todos los juegos de Rare tienen cantidad de material curioso dentro de los juegos, se nota que estaban en una etapa muy creativa, el Diddy Kong Racing tiene niveles de test que hasta luego aparecen en Jet Force Gemini, ya miraré de hacer algo más visual.

He seguido añadiendo cosas con la libdragon, el rumble es muy fácil de usar, próximamente OGG lo cual sería un lujo si no consume demasiada cpu.

Me ha dado por revisar cual es el rendimiento de PSX en 2D para ver que tal voy, pues al igual que N64 o bien acepta rectángulos o polígonos planos, el primer caso es mucho más rápido pero no se pueden rotar los sprites.

He comparado un test real de N64 con las especificaciones dadas sobre sprites de PSX, con el siguiente resultado:
PSX: Sprite 16x16 Textura 16bits - 667*60fps
N64: Sprite 16x16 Textura 16bits - 1520*60fps

A falta de compararla con Saturn es una buena bestia en 2D, para no dar demasiado la brasa con detalles técnicos vamos con unas cuantas betas y juegos no lanzados.

BETAS Y PROTOTIPOS

Dinosaur Planet
No hay mucho que comentar teniendo casi una hora de vídeo, tras ser cancelado se le hizo un lavado de cara y acabó apareciendo en Gamecube como Star Fox Adventures.
https://www.youtube.com/watch?v=cOVBRJToVDY

Eternal Darkness
No lucía nada mal en N64.
https://www.youtube.com/watch?v=LWeXnBH8Ohs

También fue cancelado en N64 para acabar saliendo en Cube.


Los personajes quedaron bastante puntiagudos y había cierta sensación de port, aunque las cifras de polígonos entran en el rango de lo que sería la generación 128bits, existe una entrevista con Silicon Knights (que ahora no encuentro) donde comentaron que aprendieron a colocar mejor los polígonos para Twin Snakes, en Eternal Darkness podrían haber hecho los modelados usando menos recursos, se especifico que la protagonista principal tenía más de 4000 polígonos, efectivamente revisando el modelo las cifras eran correctas.


Una muestra de Alex Roivas en N64 con la misma pose, las animaciones no eran muy diferentes.


El juego iba a correr a 640x480*, igual que en Cube, sin embargo a 30fps en lugar de 60, en un cartucho de 32 o muy probablemente 64MB, existen incongruencias con los escenarios, no queda claro si iban a ser en tiempo real o prerenderizados, en muchos casos parecen demasiado complejos para correr en la consola, en una entrevista de IGN del año 2000 se puede leer lo siguiente:

Unlike Resident Evil 2 for Nintendo 64, though, Eternal Darkness runs on a fully 3D engine, enabling complete freedom of movement and, because backgrounds aren't pre-rendered, a totally scalable camera system. What this means for the player is 3D environments that are totally interactive and look beautiful.

Con otro texto que le sigue después

The game utilizes a rock-solid 3D engine that outputs pre-rendered-quality visuals -- and by this we mean extraordinarily detailed textures and polygon models -- but with full freedom of movement and interactivity with the environments.

Si repasamos los vídeos es cierto que hay escenas con movimiento 3D.
https://www.youtube.com/watch?v=koBEIdTuaIQ

Aunque las partes jugables de la beta muestran cámaras estáticas en prácticamente todos los vídeos, con momentos donde la cámara rota (min 1, podría ser precalculado o FMV sobre el escenario?), si bien esta demo es del 99 y la entrevista del 2000, podrían haber cambiado mucho las cosas de una versión a otra o podrían referirse a partes prerenderizadas montadas sobre una base 3D como REmake (para proyectar luces y sombras).
https://www.youtube.com/watch?v=7WIDWoefpAc

Resident Evil Zero
No me lo digas.. otro juego trasladado de N64 a Gamecube, aquí podemos verlo en vídeo presentado en una feria.
https://www.youtube.com/watch?v=-Sb9J8BFma4

Twelve Tales Conker 64
Antes de que el juego se convirtiera en la aventura para adultos que conocemos, no es el clásico vídeo de las cintas promocionales, sino de 30 min (13:16, suena la canción de Jet Force Gemini), cabe destacar lo fluido que se mueve.
https://www.youtube.com/watch?v=M6ceNFV2yz4

Wildwaters Extreme Kayak
Juego cancelado de Looking Glass Studios, aunque algunos detalles lucen bien el juego se ve que estaba bastante incompleto en ese punto.
https://www.youtube.com/watch?v=IpTegSY4HY8

Mini racers
Mismo equipo encargado del juego anterior, este luce en un estado mucho más avanzado, no pudo lanzarse por la caída de la compañía en la bancarrota.
https://www.youtube.com/watch?v=qfjMKoJwc-0

Tamiya Racing 64
Es un prototipo antes de convertirse en "Mini racers".
https://www.youtube.com/watch?v=qggeXAHWcHk

Glover 2
Otro juego cancelado por perdidas de la compañía, especial atención al dialogo del Furby en el 1:45, samples de la gallina del Zelda OOT, cuescos y más.
https://www.youtube.com/watch?v=uV1QfIu8-Sg

Dragon Sword
Casualmente de la misma gente que hizo Glover 64, tiene bastantes bugs aunque es jugable, el vídeo esta grabado de un emulador, pero no hay mucho donde coger en youtube.

En el estado de la beta el juego consiste en ir avanzando y cargarse los totems que van apareciendo, si no nos cargamos los totems irá creando enemigos infinitos además de una barrera que no se puede pasar (algo que no se ve en el emulador), aunque no queda claro la forma en que hay que cargárselos, a veces con varios golpes, a veces parece que toman muchos más, igual hay que golpearlos cuando crean enemigos o cuando se activan ciertos interruptores, en el segundo nivel hubo un totem que por mucho que le golpeara nunca se rompía, si por cualquier motivo mueres, cuando vuelve a salir el jugador se volverá incontrolable, si volvemos al menú y empezamos partida seguirá siendo incontrolable, hay que tener la suerte de hacerlo todo en una sola vida y de alguna forma cuidadosa para que los totems se vayan rompiendo sin problemas.

https://www.youtube.com/watch?v=fh8uKt-LGtU

En el 0:37 del vídeo anterior se ve el protagonista de pie sin moverse, en realidad ahí iba una intro, que es la que se ve en este vídeo, hay algunos cambios para que hubiera 2 jugadores atados en lugar de uno, es probable que en el estado de la beta no llegaran a finalizarlo.
https://www.youtube.com/watch?v=gaVKFPFzQJE

Tommy Thunder
Por lo visto no fue ni anunciado, se presenta en un estado muy beta, no hay sonido pero podemos escuchar el ruido dependiendo de los colores de la pantalla a causa de un mal cable.
https://www.youtube.com/watch?v=xC9uJovJujk

40 Winks y ODT
Estaban bastante avanzados en su desarrollo, es más casi completos, se puede encontrar la beta de los mismos, aunque también existen las versiones completas de PSX donde si se lanzaron.

https://www.youtube.com/watch?v=O_5rY5r5bd8

https://www.youtube.com/watch?v=Yyv2knrGTu8

Riqa
Fue un juego presentado en el E3 del 99 desarrollado por Bits Studios, fue cancelado porque avanzaba más lento de lo esperado y la consola ya estaba llegando a su fin de ciclo, el juego parece que tiene un ligero auto apuntado y se usan los C amarillos para desplazarse lateralmente a la vez que corre, lo cual da un aspecto raro a las animaciones de la protagonista que recuerda a Lara Croft, parece que en ese estado de desarrollo ya se movía muy fluido.
https://www.youtube.com/watch?v=5_B-wh4vApw

Jungle Emperor: Kimba
También cancelado, tenía unas interesantes animaciones para el agua.

@BMBx64
Me gustaria ver un analisis de The Legend of Zelda: Majora's Mask.
Porque a nivel de poligonos se nota tanta diferencia con su antecesor. En especial, la nariz.

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.

Curioso, se supone que las direcciones reservadas deben venir especificadas en la documentación. ¿Documentación incompleta o desistieron de revisar miles de líneas de código?

1985a escribió:@BMBx64
Me gustaria ver un analisis de The Legend of Zelda: Majora's Mask.
Porque a nivel de poligonos se nota tanta diferencia con su antecesor. En especial, la nariz.

Ya veo.

AxelStone escribió:Curioso, se supone que las direcciones reservadas deben venir especificadas en la documentación. ¿Documentación incompleta o desistieron de revisar miles de líneas de código?

Bueno.. lo de las direcciones reservadas es solo una teoría, es cierto que siempre hubo falta de documentación, especialmente del RCP a bajo nivel, a Rare le costó pasta el tema del Expansion pak en DK64 para no querer revisar el código de arriba a abajo.

Muchas cosas que hay en este hilo tienen alguna explicación o cita original en alguna parte (2:40):
https://www.youtube.com/watch?v=VgtAXCaSlpk

In a recent Director's Commentary video for Conker's Bad Fur Day (embedded below, at 2:40), Chris Marlow, one of the game's programmers, let slip some behind-the-scenes details that reveal the true reason for the Expansion Pak's inclusion with Donkey Kong 64. According to Chris, there was a glitch in the game that caused it to "randomly crash...in the 4 meg only version," which apparently didn't occur with the Expansion Pak installed. Unable to track down the cause, Rare was forced to include the memory expansion for free "which cost [Rare] a fortune." Though as fellow Rare colleague Chris Seaver pointed out in that same video, it actually worked out in Perfect Dark's favor (released the following year), as that game "definitely needed it" in order to run most of its modes, which helped avoid most customers from having to purchase the accessory separately.

Ah, de otro juego que me gustaria ver un analisis, es de Conker's Bad Fur Day. Que tiene de especial el efecto del cañon o la bazuka, que en emuladores, cuesta trabajo emular correctamente????