Hilo de detalles y curiosidades de N64

Hmmm. Recientemente marshallh me confirmaba que el reloj del RCP y la CPU se derivaba del bus de video, que es diferente en cada region, pero en ese hilo, en el que tambien participo el, llegan a la conclusion de que las frecuencias de la CPU y RCP se derivan de la RDRAM.

Una cosa esta clara, y es que la RDRAM y el bus de video (y audio) van cada uno por su cuenta, con su propio clockgen y su propio cristal. Lo que ya vuelve a quedar hundido en el misterio es de cual de los dos se deriva la frecuencia del RCP y CPU...
Hace unas semanas pensaba que lo tenia ya establecido y ahora ya no lo se...

@radorn No entiendo el motivo de la confusión. Según tengo entendido, de los dos cristales osciladores, solo uno cambia la frecuencia según la región. Lo cual es lógico ya que así es más fácil programar un juego al no tener que cambiar la parte más interna a cada región. ¿O es que hay otras frecuencias que varian de una región a otra?
Si el que hizo el diagrama no se equivocó ni cometió ningún error, la frecuencia del RCP y CPU depende del chip MX8330, que es el que esta generando la frecuencia de la RAM, y a su vez depende del cristal X2. Aunque si que hay una omisión en el diagrama y es el multiplicador 1.5x de reloj entre el RCP y la CPU.
Le he echado un ojo rápido al datasheet del MX8330 y menciona las diferencias entre PAL y NTSC, pero la frecuencia de cristal no corresponde en ningún caso a los 14.7MHz del X2. ¿Es posible que venga del error de leer esa parte del datsheet, que a pesar de lo que parece no necesariamente ha de configurarse a una región?

@EMaDeLoC
Detalles, detalles!
En toda N64 hay 2 cristales, y, dependiendo del modelo, 2 clockgen MX8330 en las placas mas antiguas o 1 clockgen MX8350 en las placas mas modernas. Los PDFs de las especificaciones de ambos están por ahi, con las frecuencias exactas de entrada y de salida y las opciones de multiplicador distintas. De un cristal se derivan los 250Mhz de la RDRAM y de otro los ~50Mhz del bus de video y la referencia de la portadora de color. Este segundo cristal es de 4X la frecuencia de la portadora de color (los frecuencias exactas en Wikipedia, que en los PDFs están truncadas a 6 decimales, o en un post mio de hace unas semanas).

Hay documentos oficiales sobre el esquema de frecuencias de la N64 contradictorios unos con otros.

Los documentos mas antiguos especifican que se derivan todas las frecuencias del sistema de un unico cristal de 4X la frecuencia de color que alimenta a un unico MX8330. Este clockgen MX8330 deriva, mediante multiplicadores configurables, el reloj de la RDRAM y del bus AV, y, mediante divisor fijo /4, la portadora de color.
Con este primer arreglo, todos los componentes del sistema estaban sincronizados, pero cada region funciona a frecuencias diferentes.
Creo que ninguna N64 comercializada está construida de esta manera, y que ese diseño solo se usó en prototipos.

En algun momento posterior a ese documento, se decidió que la RDRAM necesitaba un reloj exacto de 250MHz en todas las regiones, y la solucion a la que llegaron fue poner un segundo MX8330 con un cristal que diese exactamente 250MHz despues del multiplicador.
Mas tarde sacaron un nuevo clockgen, MX8350, que toma los dos cristales y genera todas las frecuencias necesarias.

Con este segundo arreglo, el bus de video y el bus RDRAM tienen frecuencias que no son derivadas de la misma fuente. Lo que no queda claro es de cual de estas dos fuentes se deriva la frecuencia de la logica principal del sistema: RDP, CPU y demas...

Inicialmente parecería logico que fuese la RDRAM la que diese la referencia al RCP y este a la CPU, pero marshallh me ha dicho este mismo año que en realidad es del bus de video de donde se toma la referencia para el RCP y la CPU, y que la diferencia entre el RCP y la RDRAM se soluciona con un FIFO.
Sin embargo, en ese hilo de assemblergames el propio marshallh no parecia objetar al hecho de que el RDP derivase de la RDRAM.

Total, que hay 2 referencias de frecuencia para la logica del sistema: Una para la RDRAM y otra para el bus de video (y audio). El misterio que queda es cual de las dos es la referencia que usa el RCP, y, a traves de el, el resto del sistema.
Hagan sus apuestas.

Como ya mencioné durante la retahila de megaposts que hicimos hace poco, hay juegos que sufren diferencias cuando son ejecutados en una consola de region diferente, diferencias que van mas allá de la frecuencia de la salida de video: Escenas animadas donde audio y animacion se desincronizan, pruebas temporizadas que van demasiado rapido o demasiado lento... hasta tuve un caso raro donde ocurría un bug importante que me impedía avanzar en el juego, no dejando que cargase la siguiente fase.

@radorn @EMaDeLoC según tengo entendido Nintendo 64 es un sistema cuya separación regional la marcan los cartuchos, mientras que el hardware es gemelo en todos sitios salvo por temas de voltaje, salida de vídeo en según qué modelos, etc. Si la frecuencia del bus realmente cambiase según la región, ¿no debería haber algún tipo de bug o pérdida de rendimiento al emplear roms NTSC con un flashcart en una consola PAL por ejemplo?.

Edito, no había leído esto:

hay juegos que sufren diferencias cuando son ejecutados en una consola de region diferente, diferencias que van mas allá de la frecuencia de la salida de video: Escenas animadas donde audio y animacion se desincronizan, pruebas temporizadas que van demasiado rapido o demasiado lento... hasta tuve un caso raro donde ocurría un bug importante que me impedía avanzar en el juego, no dejando que cargase la siguiente fase.

Si esto es cierto, a nivel personal me interesaría saber si en sistemas PAL la diferencia de frecuencia es para peor o mejor.

@Sexy MotherFucker Entiendo que los muros de información de hace unas semanas son un tanto... densos y dispersos, pero esas cosas se comentaron. De todas formas, resumiré un poco aqui.

Hay 2 capas en el sistema "anticopia" de la N64.
Primero esta chip de seguridad. En los cartuchos va el CIC, y que se comunica con el chip PIF de la consola, que se encarga de inicializar la consola. El CIC puede ser variante NTSC o PAL (o MPAL, para Brasil, y puede que una para la placa arcade Aleck64, y quizá alguna cosa mas). En la consola está el chip PIF, que es el encargado de arrancar y configurar la consola, entre otras tareas, y es el que se comunica con el CIC del cartucho. Si la region no coincide, el PIF bloquea la consola.
Además de eso, hay un numero de tipos de PIF diferentes, con las siguientes equivalencias

PAL ----- NTSC
7101 --- 6102 --- el CIC mas comun, utilizado por los primeros juegos y todas las 3rd parties
7102 --- 6101 --- solo usado en StarFox 64 / Lylat Wars
7103 --- 6103 --- utilizado por juegos de segunda y tercera generacion de Rare y Nintendo
7105 --- 6105 --- utilizado por juegos como los Zeldas, PD, DK64, CBFD... tiene funciones extra de seguridad explotadas por RARE en JFG y BT, que necesitaron ser parcheados para poder funcionar con boot-emulators.
7106 --- 6106 --- utilizado por algunos pocos juegos, como Yoshi's Story, creo.

Si, falta el X104, y el 1 y el 2 están al reves en NTSC, no es un error tipografico.

En la cabecera de la ROM hay un codigo de carga que tiene que coincidir con el CIC para que el proceso funcione, y, ademas, algunas ROMs incluyeron algun truco de seguridad mas (especialmente RARE) para molestar a los pira... usuarios de copiones de entonces y las tecnicas "anti-DRM" de entonces. Además, El primer 1MB de la ROM (excepto la cabecera) tiene que dar un par de sumas de comprobacion especificas almacenadas en la cabecera de la ROM.

Todos esos elementos y comprobaciones son necesarios para que la N64 se digne a ejecutar tu ROM.
Una vez ejecutada, puede haber otras comprobaciones a la carta y habilidad de los programadores de turno.

Una comprobacion que se hizo popular despues de las primeras remesas de juegos fue comprobar el Os_Tv_Type, que es el nombre de variable que libultra (el SO de N64, la libreria de desarrollo oficial) le da a un byte que el proceso de inicializacion del PIF almacena en RAM antes de de permitir la ejecucion de la ROM. Este byte se pone a 00 si el PIF/consola es PAL, 01 para NTSC y 02 para MPAL. Algunos juegos, como enseñé en el video que grabé, comprueban este byte, si si no les gusta lo que ven, te dicen alguna bordez, como que te compres otra consola porque esa no les vale. O una pantalla en negro sin mas... al gusto del programador.
Los bootloaders incluidos en los menus de los cartuchos de ROMs actuales simplemente "spoof"ean ese valor para hacerlo coincidir con la ROM. (detallé esto unos posts atrás, con una lista de codigos de pais en las cabezeras ROMs y su equivalencia a PAL, NTSC o MPAL). Por ejemplo, si la ROM tiene una S (de Spain) como idenfiticador de region, el menu del 64drive, como parte del proceso de carga de la ROM, reescribe el valor Os_Tv_Type a 00 (PAL), antes de dar paso a la ejecucion de la ROM, para que cuando arranque no proteste si se encuentra un 01 porque la consola es NTSC. De la misma forma, si la ROM tiene una E (de English, la ID de region que Nintendo escogió para USA), el menú cambiará el Os_Tv_Type a 01 antes de ejecutar la ROM, para tratar de hacer pasar tu consola PAL por una NTSC.
Tambien puedes desactivar el spoofing y ver que pasa si el Os_Tv_Type de la consola no coincide con la ROM, y ver esos bonitos avisos de "tu consola no mola". O las pantallas negras... O las ROMs que se la suda y carga igual, e quizá funcione todo perfecto o quizá no del todo, o quizá ocurran otras cosas buenas o malas porque los programadores hicieron cosas interesantes y pasaron de las normas de Nintendo... hay casos...
Hay cosas creativas, pero son raras.

Sobre tu pregunta del "voltage"... no se quien te diría eso, pero, el voltaje solo es diferente en el enchufe de la pared. El voltaje DC que una PSU europea da a la consola es el mismo que el de una PSU yanki o japo. La cuestion es que si enchufas una PSU yanki o japo, que requieren 100-120V, a un enchufe de 200-240 V de España, la PSU se quema, y quiza la N64 tambien. Tambien pueden sentarles mal la diferencia de frecuencia de AC, que son las mismas que en NTSC y PAL respectivamente.
Pero si compras una consola NTSC y le pones la PSU de una consola PAL y la enchufas en España, todo va perfecto. Lo que tiene que coincidir es la PSU con la corriente AC del enchufe de la pared de tu casa.

Obviamente la salida de video es diferente entre consolas NTSC y PAL (por cierto, la consola NTSC es igual en Japon y en USA, excepto por las indentaciones del cartucho y la bandeja del receptaculo, para evitar que encaje. Además de eso, la señal de video de ambas, incluida la de USA, es NTSC-J, la variante NTSC de japon que tiene un nivel de negro ligeramente distinto al estandar NTSC original de USA).

La cuestion de las velocidades es lo que despista. la frecuencia del RCP es la que determina la velocidad general del sistema, porque de el se deriva la CPU y otras cosas. Y, yo, por lo menos, ya no se si la velocidad del RCP se deriva de la de la RDRAM o del bus de video. lo que está claro es que el video y la RDRAM no están sincronizadas entre si, ya que sus relojes se derivan de cristales de referencia distintos, y uno de ellos es diferente en cada region.

Sea como sea, esto puede afectar a los juegos si los ejecutas en consolas de region diferente a la que esperan.

Ejemplos:

Turok 3 : Las escenas cinematicas sufren desincronizacion entre la animacion y el sonido cuando cargas una ROM en la consola equivocada. Con una conmbinacion el audio va acumulando retraso hasta que al final de la escena hay una diferencia brutal, y con la combinacion inversa, el audio va demasiado rapido quedandose la escena sin sonido cara el final. No recuerdo cual era cual, pero creo que quizá el sonido adelanta cuando usas consola PAL y ROM NTSC, y atrasa si es consola NTSC con ROM PAL.

Donkey Kong 64: El reloj de las pruebas temporizadas se ve afectado por las diferencias de reloj. En una combinacion el reloj va mas rapido de lo que deberia y en otra mas lento. Supongo que si la prueba tiene un tiempo asignado lo suficientemente ajustado, en una de las combinaciones de ROM y consola, quizá se vuelva imposible porque el reloj se acabará antes de que sea fisicamente posible acabar la prueba. No tengo datos reales sobre esto, solo teoreticos, igual la diferencia no es tan grande como para dar problemas, pero existir existe.

Puede haber otros desajustes, probablemente minimos en general.

Personalemente me encontre con el que probablemente sea el error mas raro debido a cargar ROMs de la region equivocada. Ya lo comenté con anterioridad pero lo repito para la ocasion:
South Park, el juego de tiros en primera persona de Acclaim, reciclando el motor de Turok 2:
Jugué a la ROM NTSC en mi consola PAL. Llegué a una fase en la que el pueblo esta lleno de gente se ha convertido en zombies/mutantes o algo asi. La ultima fase del episodio tiene un jefe final delante de la biblioteca del pueblo, un bichejo gigantesco supermutado asqueros. Cuando llegas al recinto las puertas se cierran detrás de ti y ya solo puedes enfrentarte al jefe.
Me lo cargué 3 veces, y las 3 veces, despues de matarlo, me mostraban una escena donde los 4 crios comentaban la jugada y se aliviaban de acabar con la invasion zombiemutante, y, acto seguido me devolvian al recinto del jefe, sin nada mas que ahcer que dar vueltas y gastar municion, sin salida ninguna posible. Busqué y busqué como loco hasta que decidi cargar el juego en la consola NTSC. Volví a cargarme al jefe y una vez acabó la escena animada, efectivamente, el juego me llevó, como es debido, a la pantalla de puntuacion y guardar partida.
Conclusion: Mi consola PAL, a efectos de entorno, gracias al cartucho flash, el bootloader con spoofing, etc, era una consola NTSC... pero, de alguna manera, la diferencia de frecuencias (sean del componente que sea, que eso aun es un misterio para mi) desató un "bug" raro que impedia que, en esa fase en concreto, cargase la pantalla de puntuacion para poder continuar con el juego, y, en vez de eso, me devolvió a la fase en la que estaba, sin posibilidad de salir.
Cual sea la causa exacta de este comportamiento ya no tengo ni dea.

Respondiendo a tu ultima pregunta, sobre "cual es mejor"... bueno... mejor es que concuerden en genero y numero... digo, que concuerde la ROM y la consola xD
Ahora bien, habitualmente las ROMs NTSC son mejores porque no tienen barras negras o escalado de imagen (hay un puñado de excepciones que tambien comenté anteriormente), y los errores debidos a correr ROMs NTSC en consola PAL, como el que comento, no parecen algo habitual, ni hay miles de usuarios quejandose por ello, asi que..., en general, bien.
Algunas ROMs PAL tienen ventajas: La mas obvia los idiomas (aunque, personalmente, juego siempre en ingles...). Luego tambien que algunos juegos, al salir despues, tienen algunos bugs menos, o que , en las versiones PAL de ciertos juegos que ya comenté de desarrolladores britanicos, se preocuparon de implementar 288p real, sin escalado. GE, PD, DKR y 40Winks...

En fin, en general es seguro usar ROMs NTSC en consola PAL. Es hasta recomendable. Pero pueden darse y se dan cosas raras a veces...

Finalmente, a nivel tecnico, el reloj del bus de video digital entre el RCP y el DAC es diferente entre regiones, siendo ligeramente mas rapido en la consola PAL que en la NTSC. Cómo y cuánto afecta eso al rendimiento de la consola, o los bugs de software por juego "de importacion" que eso pueda causar ya son cuestiones mas complicadas, principalmente porque no parece que tengamos claro si la velocidad del RCP y la CPU se derivan de el, o si se derivan del reloj fijo de la RDRAM que es igual en todas las regiones. Yo, desde luego, en este momento no se la respuesta. Creía tenerla hace unas semanas, pero ya no...

@radorn muchas gracias por la información.

Pero me has hecho cogerle asco y desprecio a mi Nintendo 64 PAL, soy así de maniático.

Gracias de nuevo, me tocará venderla en el mercadillo.

@Sexy MotherFucker Are you on your special days, Allyson?

@radorn no, me viene desde adolescente, cuando la Dreamcast me enseñó la diferencia entre 50 y 60 hz, o como cuando me di cuenta que la Megadrive PAL ralentiza la música de ciertos juegos; desde entonces no tolero downgrade alguno al producto original.

Yo hasta tu penúltimo post era feliz con mi Everdrive 64 pensando que en mi N64 PAL las roms NTSC se ejecutaban a la perfección, ahora vas y me jodes la vida demostrando que eso no es necesariamente cierto, lo cual hace que tenga que mandar al carajo mi consola.

Si ya lo decía el sabio Recap de Postback: las adapactiones PAL de consolas japonesas son ABOMINACIONES.

Gracias por devolverme a mis orígenes talibanes en estos temas, en algún momento me ablandé y perdí el norte.

@Sexy MotherFucker
Es un problema de perspectiva.
Como Europa no es el lugar de origen de los fabricantes de hardware, el formato PAL es conversion y raramente version original cuando se trata de software para consolas... Incluso en empresas como RARE, la version inicial siempre era NTSC... y luego se hacia la conversion, con mayor o menor exito.

Hay juegos "PAL-perfect", con 288p y tal. No te deshagas de la consola, consiguete una NTSC como extra. Solo tienes que comprar la consola. El adaptador electrico, los mandos y hasta el Expansion Pak puedes usar los que ya tienes. Cable AV si necesitarás, porque en regiones PAL desde SNES a GC (y quiza tambien Wii y WiiU), Nintendo decidió putear y hacerlos diferentes, trasladando cuatro tonterias del interior de la consola al capuchon del conector. Si usas cables AV europeos con la consola NTSC la imagen se verá un tanto oscura de mas. Puede ser jugable, dependiendo de la TV en cuestión, pero será mas oscuro.
Luego está el tema de la compatibilidad de los cartuchos por culpa del CIC. El nuevo 64drive tiene un CIC "clonado" universal y vale para ambas. El modelo "antiguo" (el que tengo yo), no y tengo que usar mi conector-T casero.
Del Everdrive64 no se si los modelos nuevos usan CIC universal... ni que modelo tienes tu...

Para rematar: En el caso de que el RCP y CPU deriven sus frecuencias de bus de video y no de la rdram, la consola pal sería ligeramente mas rapida que la ntsc. no se si eso te consuela.

radorn escribió:. No te deshagas de la consola, consiguete una NTSC como extra. Solo tienes que comprar la consola. El adaptador electrico, los mandos y hasta el Expansion Pak puedes usar los que ya tienes. Cable AV si necesitarás, porque en regiones PAL desde SNES a GC (y quiza tambien Wii y WiiU), Nintendo decidió putear y hacerlos diferentes, trasladando cuatro tonterias del interior de la consola al capuchon del conector. Si usas cables AV europeos con la consola NTSC la imagen se verá un tanto oscura de mas. Puede ser jugable, dependiendo de la TV en cuestión, pero será mas oscuro.

Bien visto

Además ahora que lo pienso sin la sangre subida a la cabeza (me ha enfadado de verdad lo que has dicho) tengo una bonita carcasa como esta puesta en la mía:



Y no es plan de deshacerse de ella, sobre todo teniendo en cuenta que Majora's es de largo mi Zelda favorito, y posiblemente mi juego favorito en toda la historia.

Para rematar: En el caso de que el RCP y CPU deriven sus frecuencias de bus de video y no de la rdram, la consola pal sería ligeramente mas rapida que la ntsc. no se si eso te consuela.

Dependería de si eso desvirtúa o mejora el rendimiento de los juegos; estaría bien cuando se aclare el tema al 100% hacer un proyecto de enumerar diferencias de una misma rom entre unos modelos y otros.

Sexy MotherFucker escribió:Bien visto

Yo es lo que hice allá por 2002, si no recuerdo mal. N64 NTSC "pelada" y Conker's BFD de eBay por 25-30 euros con envio. Son los que se vieron en el video.

Sexy MotherFucker escribió:Dependería de si eso desvirtúa o mejora el rendimiento de los juegos; estaría bien cuando se aclare el tema al 100% hacer un proyecto de enumerar diferencias de una misma rom entre unos modelos y otros.

Eso es un dolor de cabeza por el que hace años intente idear una base de datos en libreoffice detallando mil aspectos diferentes de las roms, tanto intrinsecos, como de software como de ejecucion en distintos entornos.
y llegue a la conclusion de que estaba mordiendo mas de lo que podía masticar. y,aun con la base de datos lista, como proyecto colaborativo sería dificil tener suficiente gente dedicada y con eel equipo y entrenamiento necesarios para identificar y documentar todo lo que tengo en mente. Y para uno solo, tardaría años xD

@radorn Madre mía, que follón con las frecuencias...
Bueno, yo me decanto a que derivan de la frecuencia de la RDRAM. Lo primero que me viene a la cabeza es por lógica, pues es más fácil por tema de programación entre regiones tener la RDRAM fija y luego hacer las pequeñas modificaciones necesarias para el video de cada región.
Pero la lógica no tiene cabida aquí...
Según las pruebas que hicieron en ese hilo de AssemblerGames, si variaban el reloj de X1 la señal de video quedaba desincronizada de la TV, pero no tenía artefactos. Es decir, el VI seguía sincronizando el framebuffer con el DAC de video sin problemas, pero la imagen no la soporta el TV y no se ve.
En cambio si variaban el reloj X2, el del RDRAM, la velocidad de juego aumenta y el framebuffer se desincroniza mostrando artefactos horribles en la pantalla.
Por eso creo que el reloj del RCP deriva del RDRAM y no del bus de video, pues si fuese de este último la velocidad del juego aumentaría. Y de hecho, creo que el X2 no tendría sentido que estuviese pues si ya sacas el reloj del RCP de un lado, no necesitas cristales extra y complicar la circuitería.
Ahora bien, eso es con la prueba que han hecho en una consola NTSC sin saber que revisión es. Para demostrar esta teoría habría que repetir el experimento en consolas PAL y otras revisiones. Así se despejaría esa duda de cual es la referencia.
Lo que es interesante es ver que el framebuffer se sincroniza con el DAC al margen de la velocidad del reloj de video, por lo que la transmisión la rige el RCP, y es cuando el RCP esta overclockeado cuando el framebuffer se transmite con artefactos.

@Sexy MotherFucker pillate una consola japo. En ebay puedes pillar alguna por menos de 25€ envío incluido. Yo compré una de los primeros modelos y tiene el mod RGB puesto. Ah, y el everdrive64 es multiregión, solo hay que cambiarlo con un interruptor escondido accesible desde la ranura SD.

Yo os leo y no me entero de nada supongo que sera todo electronica

HYBRID HEAVEN
Es de esos juegos raros que te encuentras dentro del catálogo de la consola, no está mal la mezcla de géneros, el sistema de combate es interesante, incluso emocionante, la historia es una fumada, empezando por la intro con el presidente dando una conferencia y nuestro protagonista viéndolo desnudo en el sofá.


Por favor vístete, que lo tienes a un palmo de tu habitación, en la intro simplemente cambian la cámara a distintas salas en el espacio tridimensional.


..Siempre me pregunto que tipo de detalles añaden dónde no se ve.


Efectivamente, nada, ni el pomo de la puerta.


Así que bueno después de ver la fumada inicial donde no te explican nada, empezamos el juego, se requieren 57 notas del Controller pak, que deben ser cerca de 14KB de los tacaños 32KB de la memoria, como pueden ocupar tanto las partidas? Oh vaya, si el juego te genera 2 slots de guardado para que el programador no tenga que gestionarlos por separado, ahora tiene algo más de sentido.

Lo primero que llama la atención al empezar a jugar son los controles, es decir, el personaje hace lo que quiere, gira desplazándose para volver al sentido contrario, te imaginas qué gracia corriendo cerca de un barranco?


Las acciones son lentas y todo resulta bastante mecánico, para poner una llave tiene que centrarse en el medio de la puerta, ya has desbloqueado la puerta? Pondrá la llave cada vez que pase de nuevo, por otro lado tenemos a Lara Croft saltando en un intento de tocar el techo.


Los detalles aplicados en la pared son polígonos pegados encima, en consola desde cierta distancia y ángulo hay defectos, pero ésto es algo habitual, quizás no al nivel de usarlo en paredes enteras.


En su momento lo llamaron el "MGS" de N64, aunque la poca relación la he visto en este gif.


El modo exploración del juego consiste en ir avanzando por salas infestadas de robots con sensores, podemos usar una pistola para destruirlos, pero si salimos de la sala y volvemos a entrar se regeneran, las explosiones se ven por encima del personaje en consola, quizás se olvidaron Z?


Ah sí, los robots mina, vas a odiar a estos robots.


Antes de seguir, algunos detalles técnicos.

La resolución normal es de 288x224.


El modo wide screen 576x300.


Y el modo hi-res 576x448.


Hay problemas de fillrate, porque el juego renderiza grandes superficies que no debería (a continuación) así que el único modo recomendable es el normal, no hay diferencias de resolución en PAL o NTSC, lo cual era de esperar al no ser desarrolladores europeos.

Nos encontramos en la zona superior del puente, pero la madre del cordero, hacía falta tener el sector entero generado?


El juego derrocha recursos, meten un modelado enorme de un sector del nivel que se renueva en ciertas puertas (oscurecen a negro), sueltan una cámara que navega por él y dejan que la consola gestione qué aparece dentro y fuera del campo de visión, por ejemplo en esa sala tenemos suerte y lo único que vamos a ver de frente es esto:


Pero en otros casos estoy andando hacia la sala de guardado y el juego va a ¿12fps?.


Ah amigo, que detrás de esa pared hay una sala circular enorme que no puede descartar.


Yo creo que el diseño de niveles está simplificado para manejarse de forma sencilla pero poco óptima, las paredes y suelos aunque se ven limpios son texturas que se repiten hasta rellenar la superficie, la resolución de las texturas suele ser bastante discreta, sin usar la máxima capacidad.

32x32 la textura de la imagen de arriba. (se invierte horizontalmente en 1 de cada 2 pasos)


Cambiando de tema, completarlo me ha tomado 22 horas y 32 minutos, aunque eso no es del todo cierto, es de esos juegos que si los dejas en pausa el tiempo sigue sumando, una partida normal puede durar 12 horas.


194 SS rank? No es que sea un maquina jugando, el que hizo el sistema de rankings es un poco como Zeno Sama y se alegra de ver 4 hostias seguidas, eso es, hacer un combo y tener un SS garantizado independientemente de lo mal que lo hagamos en el resto.

El sistema de combate del juego es tan cruel como la vida misma, aprendemos a base de hostias, tal cual, podemos aprender algunas técnicas y movimientos que los enemigos realicen sobre nosotros.

Tenemos unos puntos de acción para realizar ataques, cuando la barra está llena nuestro ataque será más poderoso, una vez avanzamos desbloqueamos diferentes puntos de carga que permiten realizar combos, la cuestión es que los enemigos puede cargar entre 3 y 5 veces más rápido que nosotros.

Y éste de dónde ha salido, Majoras Mask? Otro de los problemas del juego es la cámara, se pelea con las paredes, en lugar de dar prioridad a la visibilidad del combate.


Los movimientos en los combates mejoran considerablemente, se nota que es la base del juego, las peleas hay que entenderlas como un tablero donde cuenta nuestra posición y orientación, no es lo mismo estar de frente que de espaldas y el estado del movimiento que estamos realizando, si inician un ataque cuando nosotros estábamos apunto de agarrar, hay un 99% de probabilidades que de un cebollazo nos manden al suelo.

Las animaciones no usan un esqueleto, sino un conjunto de polígonos pegados entre sí, los cuales sirven para identificar distintas zonas del cuerpo, el sistema de combate usa daño localizado, si nos dañan la pierna izquierda por ejemplo, no podremos realizar ataques con esa pierna, el polycount, Diaz tiene 731 polígonos en ésta extracción, es probable que algunos enemigos tengan más, pero los NPC humanos no deberían ser muy distintos.


Sirve de algo subir de nivel? Durante el juego encontraremos generadores de enemigos, cerca de capsulas de guardado que nos regeneran la vida, así que parece ideal ponerse a pelear para subir de nivel, mejorar la fortaleza del cuerpo y aprender nuevas técnicas, pero lo cierto es que no, hay auto nivel siguiendo cierta lógica.

Así que me voy a la fase 4, estando en nivel 1 y me cargo al agente Smith de 1 patada.. el cual puede darte bastante quebraderos de cabeza en nivel 15, porqué? La vida de los enemigos se asimila a la que nosotros tengamos hasta cierto margen, si su capacidad de subir vida es hasta 800, nuestra patada no subirá a esos niveles de daño, sino más cerca de 180-200, con lo cual los combates son más largos y los enemigos con más opciones ya que atacan con mayor velocidad y ojo a los que disparan desde lejos.


Esto tiene pinta de doler no? .. Venga hombre!


En el juego hay material debug, aunque yo solo he usado el selector de nivel.

Otros detalles:
- El enemigo del cuerno que se hace invisible me parece el enemigo estandar más difícil.
- El Dr Bross creo que es el jefe más duro.

Como siempre, un placer leer otro de tus análisis técnicos de juegos de N64.

Saludos BMBx64!!!

Gran post @BMBx64, ya echaba en falta una dosis de detalles técnicos de la consola.
¿Sabes los polígonos por segundo del juego, así a ojo? Tengo la teoría de que de media de los juegos, sin mucho alarde técnico, ronda los 60k pol/s.

A mi el Hybrid Heaven me gustó más por su temática y ambientación que por lo técnico, en modo low-res va bien; pero tampoco es una virguería y en modo hi-res preguntas por ahí si te va a 12fps, pero hay algún frametest por internet comparando ambos modos y el juego muchas veces no aguanta ni los 10fps y tenía caídas a 5-6fps. Está bien saber que el motivo no es porque la consola no pudiera moverlo mejor sino porque decidieron renderizar zonas enteras a lo bruto.

Lo de compararlo con MGS sí que nunca lo entendí. Uno es de acción-sigilo y el otro es un ¿rpg raro?

Calculinho escribió:Lo de compararlo con MGS sí que nunca lo entendí. Uno es de acción-sigilo y el otro es un ¿rpg raro?

Supongo que la comparación nace de que ambos son juegos de Konami, aunque no tengan nada que ver uno con el otro, una comparación mas acertada seria con WinBack.

@Calculinho el verdadero "Metal Gear" de Nintendo 64:

Edit: @Oystein Aarseth se me adelantó xD




Hubo hasta una versión para la Ps2:



@BMBx64 ya se te echaba de menos

Yo vengo a hablarte de mi libro como siempre:

288x224

Esto entiendo que es área de dibujado dentro de un marco de 320x224/40 ¿no?.

Calculinho escribió:A mi el Hybrid Heaven me gustó más por su temática y ambientación que por lo técnico, en modo low-res va bien; pero tampoco es una virguería y en modo hi-res preguntas por ahí si te va a 12fps, pero hay algún frametest por internet comparando ambos modos y el juego muchas veces no aguanta ni los 10fps y tenía caídas a 5-6fps. Está bien saber que el motivo no es porque la consola no pudiera moverlo mejor sino porque decidieron renderizar zonas enteras a lo bruto.

Por desgracia es algo común en muchos juegos thirds de N64, la falta de optimización para aprovechar mejor el sistema. También se suma como dijo @BMBx64 una vez, la falta de práctica y pericia en la programación en 3D de aquellos años.

@Falkiño bueno, lo de Konami creo que fue que se la sudó completamente porque el Castlevania en hi-res también va como el culo. Y no estoy seguro, pero creo que algún ISS también iba mal en hi-res.

@Sexy MotherFucker @Oystein Aarseth se parece más a MGS que el Hybrid desde luego, pero tampoco creáis que es una comparativa acertada. Pero bueno, en esa época se comparó con MGS casi cualquier cosa que lo protagonizase un hombre occidental blanco con pistola (Syphon Filter sería otro ejemplo).

Me he olvidado de la música que va cambiando según las salas, con temas de misterio o de batalla como éste que están muy bien.
https://www.youtube.com/watch?v=fF5QpR0H7Dg

EMaDeLoC escribió:¿Sabes los polígonos por segundo del juego, así a ojo? Tengo la teoría de que de media de los juegos, sin mucho alarde técnico, ronda los 60k pol/s.

El mayor polycount podría tenerlo en las secuencias de vídeo donde se juntan 4 o 5 NPCs a la vez mirando hacia alguna pared que no de con ningún sector, si todos fueran del detalle de Diaz serían unos 3000-4000 por frame a unos 20-30fps

Las batallas son 1 VS 1, hubiera estado interesante combates contra varios enemigos a la vez.

Sexy MotherFucker escribió:Esto entiendo que es área de dibujado dentro de un marco de 320x224/40 ¿no?.

Sí, borre el margen negro al subir la captura

--
Winback también está interesante, tengo por ahí una partida empezada

@BMBx64 ya te termino de preguntar, que sabes que soy muy maniático con estos temas xD: 320x224 el Framebuffer, ¿o 240?.

@Calculinho yo le tengo muchas ganas al Operation Winback. Seguramente estará a 3 euros o menos en Cash Converter para la Ps2, pero lo suyo es experimentarlo en su versión primigenia para N64 antes.

@Sexy MotherFucker el de PS2 no lo he probado, el de N64 me gustó aunque al ver que había versión vitaminada para hardware mayor me lo reservé para cuando toque ese fullset (año 2080 aprox).

Calculinho escribió:lo reservé para cuando toque ese fullset (año 2080 aprox).

xDD

Con decirte que sin aspirar al fullset, yo estimo que me queda por lo menos todavía una década de uso de PlayStation 2, y tuve mi primera allá por el 2003.

BMBx64 escribió:

EMaDeLoC escribió:¿Sabes los polígonos por segundo del juego, así a ojo? Tengo la teoría de que de media de los juegos, sin mucho alarde técnico, ronda los 60k pol/s.

El mayor polycount podría tenerlo en las secuencias de vídeo donde se juntan 4 o 5 NPCs a la vez mirando hacia alguna pared que no de con ningún sector, si todos fueran del detalle de Diaz serían unos 3000-4000 por frame a unos 20-30fps.

Eso en "polígonos por segundo" a cúanto equivale ¿?

¿Cómo se hace la cuenta ya que estamos?.

Sexy MotherFucker escribió:

Calculinho escribió:lo reservé para cuando toque ese fullset (año 2080 aprox).

xDD

Con decirte que sin aspirar al fullset, yo estimo que me queda por lo menos todavía una década de uso de PlayStation 2, y tuve mi primera allá por el 2003.

BMBx64 escribió:

EMaDeLoC escribió:¿Sabes los polígonos por segundo del juego, así a ojo? Tengo la teoría de que de media de los juegos, sin mucho alarde técnico, ronda los 60k pol/s.

El mayor polycount podría tenerlo en las secuencias de vídeo donde se juntan 4 o 5 NPCs a la vez mirando hacia alguna pared que no de con ningún sector, si todos fueran del detalle de Diaz serían unos 3000-4000 por frame a unos 20-30fps.

Eso en "polígonos por segundo" a cúanto equivale ¿?

¿Cómo se hace la cuenta ya que estamos?.

Pues depende de los fps ,pero serían aprox 80.000-90.000 pol/seg, y se calcula multiplicando los poligonos por frame con los "Frame Per Second" que renderiza y de hay sale los poligonos por segundo.

Salud.

OFFTOPIC ON

Calculinho escribió:OFFTOPIC ON

Lo del frame per second me ha recordado a que ayer mirando revistas viejas, en una del análisis del Quake III de PS2 el analista se lució diciendo que esto. Y he buscado en internet por si era una expresión o algo que desconocía, pero tiene pinta que fue un gazapo guapo o alguien que no tenía ni la más mínima idea de inglés



Siento el offtopic, pero es que me hizo mucha gracia y acabo de recordarlo ahora con los comentarios.

El redactor tiene Inglés nivel nativo,xD

Salud.

Sexy MotherFucker escribió:Hubo hasta una versión para la Ps2:

Y secuela también.


@Calculinho @dirtymagic
Tsk tsk... que no teneis ni idea.
No es que se le de mal el inglés, si no que es tan bueno jugando que tiene que usar "frags per second" para poder contar a la cantidad de contrincantes que liquida durante las partidas...
...
...
...

radorn escribió:

Sexy MotherFucker escribió:Hubo hasta una versión para la Ps2:

Y secuela también.


@Calculinho @dirtymagic
Tsk tsk... que no teneis ni idea.
No es que se le de mal el inglés, si no que es tan bueno jugando que tiene que usar "frags per second" para poder contar a la cantidad de contrincantes que liquida durante las partidas...
...
...
...

Salud.

@BMBx64 Acabo de ver tu análisis del Hybrid Heaven y me motivo a terminarlo ya que lo deje inconcluso pero al continuarlo me di cuenta que lo deje en el último punto de guardado para la batalla final que por cierto si dura bastante.

El juego tiene muchas cinemáticas en donde se ve muy bien gráficamente lastima que no se vea así en la parte jugable, a mi me gusto que los personajes mostrarán gestos aunque sea solo con texturas se ven bien parpadean y muestran gestos faciales, a diferencia de MGS donde los personajes apenas tienen rostro, la historia si es muy extraña con algo de propaganda a los United states jaja.

De haber sabido que la fuerza de los enemigos se asimila a la del jugador no hubiera subido de nivel peleando con el mismo enemigo de algunas zonas xD , y lo que más odie fueron los robots de combate que caminan lento, en si no es un mal juego y al terminarlo se puede guardar el ending (que me pareció bueno) en una fila del controller pak para verlo las veces que quiera y se desbloquea el nivel difícil.

En fin otro juego que termino del catalogo, creo que es un juego que cualquier seguidor del 64 debe probar, eso si difícilmente lo volvería a rejugar.

BMBx64 escribió:El Dr Bross creo que es el jefe más duro.

En su epoca, yo alquilé este juego 2 o 3 veces, y no fuí capaz de pasar de ese cabronazo.

Lo cual me lleva a la siguiente pregunta, porque en cierto punto me puse a hacer "grinding" de forma intensiva.

BMBx64 escribió:Sirve de algo subir de nivel? Durante el juego encontraremos generadores de enemigos, cerca de capsulas de guardado que nos regeneran la vida, así que parece ideal ponerse a pelear para subir de nivel, mejorar la fortaleza del cuerpo y aprender nuevas técnicas, pero lo cierto es que no, hay auto nivel siguiendo cierta lógica.

Así que me voy a la fase 4, estando en nivel 1 y me cargo al agente Smith de 1 patada.. el cual puede darte bastante quebraderos de cabeza en nivel 15, porqué? La vida de los enemigos se asimila a la que nosotros tengamos hasta cierto margen, si su capacidad de subir vida es hasta 800, nuestra patada no subirá a esos niveles de daño, sino más cerca de 180-200, con lo cual los combates son más largos y los enemigos con más opciones ya que atacan con mayor velocidad y ojo a los que disparan desde lejos.

No acabo de entender lo que dices aquí: "La vida de los enemigos se asimila a la que nosotros tengamos" ... ¿que?
¿Que significa eso exactamente? y ¿significa eso que hacer grinding es contraproducente?

radorn escribió:

BMBx64 escribió:No acabo de entender lo que dices aquí: "La vida de los enemigos se asimila a la que nosotros tengamos" ... ¿que?
¿Que significa eso exactamente? y ¿significa eso que hacer grinding es contraproducente?

Quiere decir que los enemigos suben de vida conforme subes de nivel, y paradójicamente ser más difícil derrotarlos cuanto más nivel tenga tu personaje.

@EMaDeLoC
Parece eso, pero la manera en que está formulado me confunde.

Sexy MotherFucker escribió:320x224 el Framebuffer, ¿o 240?..

224

radorn escribió:En su epoca, yo alquilé este juego 2 o 3 veces, y no fuí capaz de pasar de ese cabronazo.

Lo cual me lleva a la siguiente pregunta, porque en cierto punto me puse a hacer "grinding" de forma intensiva.

Yo me lo cargué disparándole con todas las pistolas de veneno que conseguí , le obligaba a desperdiciar sus puntos en curarse del veneno (aunque es temporal) y en lanzarse pócimas a si mismo, mientras le iba dando patadas simples de 1 barra, por si fuera poco viene con velocidad mejorada, fuerza mejorada y defensa mejorada, que es lo primero que me lanzaba a mí al empezar.

Además de lejos dispara con la pistola de hielo (ilimitada?), que te puede hacer 700 de daño (con 1600 de vida) y dejarte en el suelo congelado durante 6 o 7 segundos, donde con suerte te deja levantarte, por supuesto si intentas hacerle un combo de cerca él también tiene capacidad de hacer eso y como te enganche bien, igual te quita 1400.

Es el enemigo "perfecto", ni de lejos, ni de cerca.

Ah sí, luego hay el objeto ring eraser, que se carga al enemigo tal cual pero no lo probé con el boss, para llegar a él, hay secuencias antes, durante y después, con una batalla anterior corriendo durante 10 min de sus bestias.

radorn escribió:No acabo de entender lo que dices aquí: "La vida de los enemigos se asimila a la que nosotros tengamos" ... ¿que?
¿Que significa eso exactamente? y ¿significa eso que hacer grinding es contraproducente?

Si puede suponer una ventaja con el hombre de negro del gif, pero es que el juego está programado para ir introduciendo nuevos enemigos y estos ya vienen regulados con nuevos stats, va todo muy guiado.

Supongamos:

Nivel 1

Personaje:
Vida 100
Fuerza patada 150

Hombre de negro:
Vida 100
Fuerza patada 150
Disparo 60

Viendo estos stats, de 1 patada te cargas al enemigo, pero ojo, de una patada te mata él a tí también, obviamente en nivel 1 no llegamos al mundo 4, así que esto sería un caso extremo.

Nivel 15

Personaje:
Vida 850
Fuerza patada 180

Hombre de negro:
Vida 800
Fuerza patada 180
Disparo 45 (ya no quita tanto)

Aquí necesitas pegar 5 patadas para eliminarlo y él lo mismo a tí, necesitas más tiempo de batalla y el enemigo recarga mucho más rápido, así que probablemente de lejos te estará acribillando a disparos con la pistola y de cerca te expones a que te tumbe en el suelo.

Nivel 25?

Lo siento, no llegamos a nivel 25, los generadores de enemigos lanzan entre 5 y 10 rondas, luego ya no generan más, así que igual se nos deja llegar al nivel 18 en esa parte del juego, con unos 150 puntos más de vida con respecto a ese enemigo en concreto.

Puede que sea más fácil derrotarlo en niveles más bajos que dándole su máximo de vida, todo depende de como enfoquemos el combate, yo en todo caso habiendo visto el sistema no esquivaría las batallas, pero no haría ni una de más.

@john D9
A mi tampoco me parece un juego para repetir una vez completado

@BMBx64 OK, aclarado, gracias

Mis recuerdos del juego son un poco borrosos en cuanto a los detalles. Primeramente porque de aquella, aunque iba por delante de mi clase en dominio del inglés, aun lo estaba aprendiendo (que lo aprendí principalmente jugando a la N64 porque no traducían casi ningún juego xD), y esto causaba que el argumento se me escapase. No siempre entendía muy bien que coño pasaba porque el argumento es bastante paja mental, como señalaste antes.

Recuerdo el mecanismo de moverse en tiempo real y pararse para ataques y defensas y tal... pero de los objetos que usabas, los que equipabas y tal ya no me acuerdo... Solo ahora que has mencionado lo de las pistolas me acuerdo de algo.

Hybrid Heaven en modo panorámico y Hi-res se ve de fábula... en foto xDD. Luego tiene que moverse y es el horror, una pena

Hola a todos.

Podríamos debatir si el expansión pak fue buena idea?

Ya que cuando un juego tenia hi-res empeoraban los frames

En teoría la N64 no necesita el expansión pak para subir la resolución,sólo hay que ver que el juego con mayor resolución de pantalla es el Virtual Chess 64 con 640x480 , simplemente que lo " fácil " era usarlo para tener un framebuffer mayor sin sacrificar texturas,modelos ect...,para mi su forma idónea de uso es como simplemente un pozo de memoria más grande,como hace LoZ : Majora´s Mask o PD en modo low res.

Salud.

@radorn sigo sopesando la idea de hacerme con una N64 NTSC, así que vamos a repasar una cosa:

Ahora bien, habitualmente las ROMs NTSC son mejores porque no tienen barras negras o escalado de imagen (hay un puñado de excepciones que tambien comenté anteriormente), y los errores debidos a correr ROMs NTSC en consola PAL, como el que comento, no parecen algo habitual, ni hay miles de usuarios quejandose por ello, asi que..., en general, bien.

Más allá de los posibles bugs comentados debido a la diferencia de frecuencia con los cristales; cuando en mi N64 PAL estoy utilizando una rom NTSC, entiendo que la juego a su velocidad/frecuencia de vídeo original, ¿no?. O sea; Super Mario 64 aparte de no tener bandas es más rápido que cuando jugaba con el cartucho PAL me da la sensación a mí.

Es que esto es lo que más me preocupa, y me metiste una psicosis obsesiva del 15 el otro día con el rollo de las frecuencias.

@Sexy MotherFucker , yo quiero mirar también como está el tema de cuál es la mejor opción a la hora de jugar a la N64 en hardware real. Tengo una Pal de cuando era niño.

Con las conclusiones que saques, podrías compartirlas, puede ser una muy buena guía de compra para la N64.
Después de jugar a la MS y MD a 60hz y sin franjas, no quiero dar un paso atrás.

Un saludo.

aranya escribió:Después de jugar a la MS y MD a 60hz y sin franjas, no quiero dar un paso atrás.

Te felicito por tu decisión. Tarde o temprano todo el mundo acaba viendo la luz en ese asunto.

@jeisonpsp Que el hi-res empeorase la tasa de frames no es por culpa del expansion pak, sino un efecto de las limitaciones del RCP y el ancho de memoria. El mismo Virtual Chess que se ha mencionado tiene una tasa de frames regular y eso que no es una maravilla gráfica (tampoco es lo primordial en un juego de ajederez).
El Majora's Mask no habria sido posible sin el expansion pak, que se usa para mantener todos esos eventos cronológicos de los NPC actualizados además de cargar más datos de animaciones, texturas, etc y dejar el acceso al cartucho a otros datos.
Volviendo al hi-res, por lo que he ido averiguando con los análisis de BMBx64, el problema esta en el fill-rate del RCP que es bastante limitado. La consola es capaz de 640x480, pero no a framerates aceptables y requiere de bastante optimización, y además en casos concretos (creo que algún juego de basket). Muchos programadores tiraban de trucos simples como reducir el framebuffer hasta que la tasa de fps fuese aceptable, más barato y rápido que optimizar escenarios o lineas de código. Por cada linea horizontal menos a 320x240 se mejora el rendimiento en 1'5%, al menos en la teoría.

Y ya centrandose en el memory pak, fue la solución a un problema de desarrollo de la consola: la memoria ROM de los cartuchos era cara y para ser competitivos no pensaban en usar más de 16MB. La idea era sacar el 64DD en poco tiempo con los discos de 64MB, pero para ejecutarse decentemente necesitaban 8MB de RAM en la consola. SGi se ciñó en el diseño del RCP a la RAMBUS, que era muy cara, y le vendió la moto a Nintendo de que iba a seguir así de cara y que lo mejor era crear una expansión en la consola para reducir costes. ¿Qué pasó? Al año cayeron los precios de la RAM y Nintendo se encontró fabricando una consola con un puerto de expansión más caro que meter toda la memoria directamente. Y sin fecha para sacar el expansion pak los desarrolladores siguieron programando para 4MB.
Si los 8MB hubieran estado desde el principio los programadores habrian estado dedicandole más tiempo sacandole partido a la memoria extra y muchos juegos que ya lucen bien, se habría visto mejor.

Y ya que he mencionado el 64DD, para cuando pensaban sacarlo el precio de las ROM habia bajado tanto que los cartuchos de 24 y 32MB ya eran asequibles (64DD salió en diciembre del 99 y Ocarina of Time, el primer juego de 32MB, en noviembre del 98) y los desarrolladores preferian usar los cartuchos que tener que acostumbrarse al modo de programar el 64DD (acceso por bloques grandes, imposibilidad de streaming, velocidad lenta...), teniendo pocas ventajas como precio, capacidad y espacio de guardado disponible. Vamos, que por hacer caso a SGi con el precio de la RAM, el lanzamiento del 64DD se vió muy perjudicado y el retraso en sacarlo fue la muerte definitiva.

Vaya, a lo tonto he hecho un resumen de la historia de la consola...
Bueno, seguro que los gurús del hilo me corregiran o ampliaran muchas cosas de las que he dicho.

@Sexy MotherFucker Yo creo que el tema es si le sacarás partido real o no. Es verdad que SM64 va a 30fps en NTSC, por lo que en PAL baja a 25 por el tema de sincronía con el video. Lo mismo ocurre con F-Zero X, 60fps en uno, 50 en Europa.
Pero siendo sinceros, juegos que vayan a más de 25fps la mayoría del tiempo solo hay un puñado, por lo que juegos donde vayas a notar una diferencia real de velocidad, pocos. Si acaso es verdad que al ir el NTSC más rápido que PAL, se rasque un fps suelto en alguna parte.
Espero tranquilizarte con esto porque sé que casi te da un pronto y mandas la N64 a la basura...
Pero ahora me ha entrado la curiosidad y quiero comprobar unas cosas de la salida RGB de la consola, como si es posible la compatibilidad de un juego de 60Hz en una consola y una TV CRT PAL. Si tengo un rato lo miro este finde y lo cuento por aquí.

@EMaDeLoC yo sin ser tan fan de la consola como algunos de vosotros, sí que la jugué mucho en la época porque se la regalaron a mi hermana, y concretamente a Super Mario 64 le di bastante caña. Hace unos años, cuando me hice con un Everdrive 64, la primera rom que me descargué fué la de SM64 NTSC-U, y noté que aparte de jugarse sin las odiosas bandas negras el juego va más fluído; por eso @radorn me dejó todo esquizoide el otro día con el rollo de las frecuencias de los cristales y los bugs del Turok.

Y sí, ya estoy más relajado, descuida

No tengo ningún afán de coleccionar N64, los únicos juegos que me hacen sentir algo al insertar el cartucho original ya los tengo; Ocarina of Time & Majora's Mask, ambos PAL con su caja original (si bien tengo cierta curiosidad por cómo mejoran el rendimiento sus contraparte NTSC), por lo tanto en el caso de que me hiciese con una consola extranjera sería única y exclusivamente si ahora @radorn me dice que la mayor velocidad que experimenté en Super Mario 64 fué un sueño de Resines.

Si optase por una N64 japonesa, valoraría el hacerme con un cartucho-resto del Super Mario 64 compatible con el rumble-pack, al cual además le arreglaron ciertos bugs anti-speed runners:

Volviendo al hi-res, por lo que he ido averiguando con los análisis de BMBx64, el problema esta en el fill-rate del RCP que es bastante limitado.

Pues A TOMAR POR CULO el z-buffer y lo que haga falta.

En serio, parecéis demasiado interesados en ver rendir a la N64 tan sólo un 15-20% más con las nuevas librerías actuales; esto según BMBx64 es que los juegos se muevan con un poly-count leeevemente superior como para darse mucha cuenta, con todos los efectos activados, mejor calidad en el rango RGB, y manteniendo frame-rates decentes de 25-30 fps.

A mí en cambio me parece mucho más estimulante ver a la N64 rendir un 60% más de lo que vimos en los 90 a base de quitarle capas de pintura, y todo lo que ocupe espacio de más en memoria, colapse el ancho de banda, etc. Quiero ver un Tekken 3 nivel System 12, o la cosa más aproximada que se pueda a Daytona USA; quiero ver hasta donde llega Nintendo 64 jugando con las mismas reglas que PlayStation, y cúanta ventaja le saca en su propia liga.

@jeisonpsp Como ya te han dicho otros, la alta resolucion no tiene nada que ver con el expansion pak, aunque las revistas y el marketing de la epoca se empeñase en dar esa impresion. El EP solo es mas RAM, y la consola es perfectamente capaz de renderizar en "hi-rez" sin el. Que normalmente muchos juegos requieran el EP para permitir la alta resolucion es por que las imagenes renderizadas tienen que almacenarse en RAM antes de salir por la pantalla, y una imagen mas grande, obviamente, requiere mas espacio... espacio que normalmente cunde mas emplearlo en otras cosas, como texturas, modelos, codigo, datos dinamicos...

Dato curioso: La salida de video de N64 limita la longitud de una linea a 640pixels tanto en NTSC como en PAL, y la altura a 480 y 576 lineas respectivamente. Sin embargo, creo que el tamaño maximo del framebuffer puede ser mayor. Se que la pantalla del menu principal de GoldenEye (con las carpetas de dossier representando las partidas) funciona a 240p y 288p en NTSC y PAL, pero el framebuffer es mucho mayor. No recuerdo la cifra, pero creo que la puse en algun post anterior. Es posible que se pueda renderizar a un framebuffer mayor de 640, pero la salida de video no da para mas, y probablemente el VI se quede sin ancho de banda para leer y escupir una imagen mas grande al DAC si abusas mucho.

@EMaDeLoC Nunca habia oido eso de que la RDRAM era cara y por eso limitaron a 4 MB la RAM de serie. Yo precisamente habia leido que uno de las ventajas de la RDRAM era gran rendimiento (si, bueno...) a bajo coste y por eso la usaron. No se si hubiese sido mejor o no tener los 8MB desde el principio. NIntendo pretendia que el EP fuese parte del ecosistema del 64DD. Al margen de lo cara o barata que fuera la RDRAM realmente, poner menos siempre es mas barato que poner mas, y cuando produces algo en masa, cualquier recorte supone millones y millones de dolares de ahorro. Nintendo64 en realidad es un sistema low-cost (los cartuchos no, claro xD). Incluso ignorando el lector de CD de PS1 y SAT, comparando las placas, queda claro que la N64 tiene que ser mucho mas barata de producir por el simple hecho de que hay muchos menos componentes, especialmente ICs

N64: primera revision de placa NUS-CPU-01 - 12 ICs
https://upload.wikimedia.org/wikipedia/ ... 1_F_01.jpg

PS1: modelo original SCPH-100x - 18 ICs
http://www.the-liberator.net/site-files ... eboard.JPG

SAT: no se que modelo es - 24 ICs
https://upload.wikimedia.org/wikipedia/ ... rboard.jpg

@Sexy MotherFucker
Respecto al aspecto de los juegos PAL: Como ya sabemos, como las consolas de exito de los 90 eran todas japonesas, los juegos se desarrollaban con NTSC en mente y luego se hacia la conversion a PAL.
En sistemas anteriores, especialmente de 16bit, las barras negras eran inevitables. Pero en N64 hay 3 opciones habituales:
- La clasica: Imagen comprimida con barras negras.
- La ideal: Renderizar nativamente 288p. He localizado literalmente 4 juegos PAL que lo hacen: GE, PD, DKR, y la beta de 40Winks. Este tipo de conversion requiere hacer cambios bastnte profundos en el codigo del juego, por eso casi nadie lo hizo.
- El apaño facil: Renderizar a 240p como la version NTSC original y estirar/re-escalar hasta 288p en el VI. Lo hacen muchos juegos de segunda generacion en adelante. Añade borrosidad.

Hay excepciones raras. Algunas ya las comenté anteriormente, como la version Japonesa del primer Goemon, que renderiza a 240p y reescala a 480i con el VI... no sabemos bien para que, porque la version USA no lo hace. La version PAL reescala a 288p, como es habitual. O Body Harvest, que tanto en PAL como en NTSC renderiza por debajo de 240p y reescala a pantalla completa.
Añado a la lista 2 rarezas mas que acabo de recordar:
-Automobili Lamborghini (un juego mas bien mediocre), renderiza a 240p en ambas versiones, y, en PAL, reescala a 288p, pero, al contrario que el resto de juegos, que utilizan un algoritmo de reescalado adecuado, este simplemente repite una linea cada 5, obteniendo 6, (288-240=48 --> 240/48=5 -- 288/48=6). "point resampling"/"nearest neighbour"
-Lylat Wars version PAL Australiana: El juego lleva barras negras (240p encajados en 288p), pero mantiene el ratio de aspecto reduciendo el viewport en el eje vertical, de forma que, en vez de comprimir la imagen, la recorta. Es el unico juego que he visto que hace esto.

Respecto a la velocidad: Como aun no tenemos claro si la velocidad del RCP y la CPU depende de la RDRAM o el bus de video, ni tampoco sabemos que referencia usa cada juego para calcular el paso del tiempo, no se decirte realmente si los juegos NTSC en consola PAL van exactamente a la misma velocidad que en NTSC. Una cosa que si puedo decirte es que la salida de video que un juego NTSC produce al correr en consola PAL si es mayor que en NTSC, por la sencilla razon de que los modos de video del VI se especifican diciendole al VI cada cuantos pixels del bus de video tiene que meter los pulsos de sincronizacion vertical y horizontal (y donde tiene que encajar los datos de imagen en cada linea, claro). El bus de video NTSC es ligeramente mas lento que el PAL a causa de las frecuencias de la portadora de color. Hace unas semanas puse unos calculos que hice al respecto y me sale que, usando los modos de video de los juegos NTSC en una consola PAL, el refresco vertical pasa de ~60Hz a ~61.2-61.3Hz . No es una diferencia que vayas a notar, y, como ya he dicho, ni siqueira es seguro que el ritmo del juego esté ligado a la velocidad del VI.
hilo_hilo-de-detalles-y-curiosidades-de-n64_2171497_s1120#p1745841885

Lo de los bugs... primeramente no recuerdo ninguno en un Turok, si no en South Park. Y luego la cuestion teorica de las pruebas temporizadas en DK64 que quizá se vean afectadas por la diferencia del hardware, pero nunca he comprobado nada de esto.

Respecto a tu pregunta especifica sobre SM64: No, no lo soñaste. Mario 64 va mas lento en la version PAL. Zelda tambien. Y, como esos dos, otros muchos juegos.
El tema de las conversiones es muy complicado. Hay muchas variables que estan directamente en manos de los programadores, especialmente en un sistema "moderno" como N64, donde no hay tantos aspectos fijos, atados al hardware, si no que son programables y dependen de si los programadores quieren (o les dejan) hacer las conversiones bien o no.
Barras negras, resolucion, escalado, ritmo/velocidad de juego, ratio de aspecto... todo esta en manos del proceso de conversion y cada juego es de su padre y de su madre.

En general no vas a sufrir ninguna perdida por jugar juegos NTSC en la consola PAL. La diferencia de velocidad, si la hay en algun juego, no va a ser grande. Puede hacer algun bug ocasional, especialmente en juegos mal programados, pero hoy en dia hay mucho cartucho flash por ahi, y no parece que se oigan muchas quejas al respecto, asi que no debe haber ningun problema notorio.

Como dijiste en su momento, a mi tambien me gustaría hacer un estudio pormenorizado sobre el resultado de correr juegos en hardware no nativo (ademas de otras muchas cosas), pero hacer eso bien va a ser muy dificil.
Por ahora, ten la tranquilidad de que no vas a tener grandes problemas por jugar NTSC en PAL y si vas a tener el beneficio de 240p nativo y 60Hz (bueno 61.poco)

@Sexy MotherFucker Yo acabo de hacer una comparación rápida del SM64 NTSC y PAL en una consola PAL y el primero parece ir más rápido, no solo en framerate, también en velocidad de juego. Hay una comparativa y efectivamente van a distinta velocidad. Por lo visto el tiempo lo miden por refresco de pantalla y no por un registro de la CPU específico para eso.
https://www.youtube.com/watch?v=uyhcY1EMrwY
Igual así acabo de destranquilizarte...
Hazle más caso a radorn, que entiende más de las salida de video de la N64.

Sexy MotherFucker escribió:Pues A TOMAR POR CULO el z-buffer y lo que haga falta.

A ver, tómate la pastilla y relaja tu hate por el z-buffer.
Es verdad que el Z supone una carga para el RCP, pero más carga es el cache de texturas y el ancho de banda de la memoria.
Jugando con las mismas reglas que la PSX posiblemente el rendimiento de los juegos sea algo mejor, pero no mucho más. El ya tan mencionado World Driver Championship tenía un Z-buffer personalizado y llega a los 100Kpol/s a 30fps. Quizá sin Z de ninguna clase pueda llegar a 150K, pero como la memoria de gráficos y del resto de componentes es la misma, entre alta latencia y ancho de banda el rendimiento toca techo.
Otro ejemplo es un juego de helicópteros que puso BMBx64 por aquí donde se desactivaba el filtrado de texturas y no había mejora de rendimiento. Para exprimir bien la N64 hay que coordinar bien CPU-RCP-memoria. Si eso ya está al límite, por muchas capas de pintura que quites no verás diferencias. Esos famosos medio millón de polígonos de la librería Turbo3D me apuesto a que son polígonos sin textura y sin intervención de la CPU, quitándose justamente los dos cuellos de botella de la máquina.
A mi también me gustaría ver un Daytona USA en la N64, pero hay que ser realistas y a base de quitar cosas el Daytona se acercaría más al Virutal Racing que a la versión AM2 o Saturn.
Una mejora de rendimiento del 15% te parecerá poco pero solo con eso hablamos de que el Zelda pasaría de 20fps a casi 25, y la imagen se haría mucho más agradable.
A ver si con suerte se finalizan esas librerías, se puede acceder a las microinstrucciones del RCP y la scene empieza a ofrecernos cosas chulas.
Quien sabe, quizá un Daytona USA 64.

@radorn Estaba escribiendo esto y he visto tu respuesta.
Yo personalmente me decanto a que la velocidad del RCP el cristal X2 (o la memoria desde tu punto de vista) y que las diferencias entre regiones de juegos se debe a la forma en que cada programador mide el tiempo. Si no me equivoco, la velocidad del RCP es la misma en todas las regiones y la diferencia esta en el DAC de video, y quizá algunos programadores prefirieran medir el tiempo por cada fin de frame del DAC que por un registro de la CPU que se incrementa a la mitad de reloj de la CPU (46.875MHz). Es normal porque es más fácil hacer cálculos contando 60 que 46 millones. Luego ya después de terminar el juego depende de cada desarrollador como adaptar las regiones. Si no las tienes en la cabeza desde el principio, te costará mucho y harás una chapuza como el SM64. Si ya lo tienes planificado, problemas 0 como en muchos otros juegos.

El 64DD debía estar ya en concepto cuando perfilaron la consola y por tanto también los 8MB de memoria. Teniendo en cuenta el coste de poner el slot del EP, el molde de la consola, fabricar los termination pak... Si Nintendo hubiese predecido como toca (como ya apuntaba el mercado de entonces) una bajada en los precios de la RDRAM, habría instalado los 8MB directamente por un poquito más del coste (no mucho) al principio para un año después ahorrarse mucho dinero al bajar la RAM y fabricar una consola mucho más barata. Es cierto lo que dices que un cambio mínimo te puede costar millones en la fabricación en masa, pero a poco que bajaran los chips RDRAM de 4MB seguro que ya salían más baratos que un slot + termination pak.
Tenerlos al principio habría hecho que los desarrolladores jugaran más con ese extra de memoria: mapas más grandes, descompresiones de datos más radicales... En vez de preocuparse si se iba a tener una clientela potencial menor al haber menos usuarios con el EP.

@EMaDeLoC
Una curiosidad!
Has comentado que con las nuevas librería se le puede sacar entre un 40-60 % más de rendimiento por poder ver cosas estilo Tekken 3 o Daytona..

Quien ha creado estás librerías?
Están desarrollando cosas interesantes?

Gracias!

@EMaDeLoC Lo del asunto del coste de la RAM y el 64DD tiene otra implicacion.
Si que es cierto que el 64DD ya estaba en los planes durante el desarrollo de la consola. Pero incluso entonces, no creo que contasen con vender tantos 64DDs como N64s, si no mas bien que sería solo una fraccion de los usuarios los que decidiesen pagar casi el equivalente a una segunda N64 por el lector de discos magneticos. Desde esa perspectiva, si creo que les compensaba ahorrarse los 4MB de RDRAM extra y para reducir el precio por consola y aumentar su margen de beneficios. No creo que el coste de la RDRAM bajase tanto como para ser comparable al precio del conector.

aranya escribió:@Sexy MotherFucker , yo quiero mirar también como está el tema de cuál es la mejor opción a la hora de jugar a la N64 en hardware real. Tengo una Pal de cuando era niño.

Con las conclusiones que saques, podrías compartirlas, puede ser una muy buena guía de compra para la N64.
Después de jugar a la MS y MD a 60hz y sin franjas, no quiero dar un paso atrás.

Un saludo.

Cualquier consola por RCA+flashcard chino+CRT+un gamepad nuevo o con el joystick restaurado. Esto último es casi más importante que jugar a 50 o 60hz.

-RCA porque los mods para mejorar la imagen son caros y usando CRT tampoco son tan necesarios.
-Flashcard Chino porque puedes jugar al catálogo PAL a 50hz o al NTSC a 60hz, pero de todas formas en N64 tampoco te confíes hay juegos que tienen mejor framerate en PAL que en NTSC.
-Lo del joystick porque hay juegos donde la precisión y la velocidad de respuesta en los movimientos del mismo pueden convertir un buen juego en una verdadera tortura en la que desearías poder usar la cruceta.

Calculinho escribió:

aranya escribió:@Sexy MotherFucker , yo quiero mirar también como está el tema de cuál es la mejor opción a la hora de jugar a la N64 en hardware real. Tengo una Pal de cuando era niño.

Con las conclusiones que saques, podrías compartirlas, puede ser una muy buena guía de compra para la N64.
Después de jugar a la MS y MD a 60hz y sin franjas, no quiero dar un paso atrás.

Un saludo.

-RCA porque los mods para mejorar la imagen son caros y usando CRT tampoco son tan necesarios.

Pero recomiéndale un S-Video por lo menos, que no necesita de mod.