Hilo de detalles y curiosidades de N64

Quería saber cómo estaba hecho el fuego de Turok 2 ya que me parecía el mejor efecto que se puede encontrar sobre este elemento en este sistema.



Se trata de texturas de 64x64 8 bits IA (Intensity Alpha) -> 4 bits en escala de grises y 4 bits de canal alfa -> 16 tonos de color y 16 grados de transparencia. Por lo que he podido capturar y reorganizar, son un total de 20 cuadros de animación y por eso el movimiento es tan fluido. Si tenemos en cuenta que el juego intenta funcionar a 30 fps pero que la mayor parte del tiempo está funcionando por debajo (y el siguiente escalón ya son 20 fps) prácticamente es inmejorable. Son 80 kB de texturas dedicados al fuego (y hay otra animación para una llamarada más pequeña pero que usa el mismo tamaño de texturas y me parece que incluso más cuadros de animación).

Esto de tener 16 grados de transparencia y poder asignarlos por cada píxel independientemente del color es un curro tremendo pero realmente es la forma ideal de hacer el efecto de fuego. Un 10 para Acclaim por ser tan ambiciosos y lograr un resultado soberbio. A continuación dejo los gifs del canal de color y del canal alfa por separado y más lentos para que se puedan apreciar bien. En el canal alfa cuanto más cercano a blanco es el píxel es más opaco y cuando es más oscuro tiene mayor grado de transparencia.




Para quien quiera saber más sobre los distintos formatos de texturas con los que trabaja Nintendo 64 hay un artículo muy detallado, aunque en inglés:
https://n64squid.com/homebrew/n64-sdk/t ... e-formats/

Sogun escribió:Quería saber cómo estaba hecho el fuego de Turok 2 ya que me parecía el mejor efecto que se puede encontrar sobre este elemento en este sistema.



Se trata de texturas de 64x64 8 bits IA (Intensity Alpha) -> 4 bits en escala de grises y 4 bits de canal alfa -> 16 tonos de color y 16 grados de transparencia. Por lo que he podido capturar y reorganizar, son un total de 20 cuadros de animación y por eso el movimiento es tan fluido. Si tenemos en cuenta que el juego intenta funcionar a 30 fps pero que la mayor parte del tiempo está funcionando por debajo (y el siguiente escalón ya son 20 fps) prácticamente es inmejorable. Son 80 kB de texturas dedicados al fuego (y hay otra animación para una llamarada más pequeña pero que usa el mismo tamaño de texturas y me parece que incluso más cuadros de animación).

Esto de tener 16 grados de transparencia y poder asignarlos por cada píxel independientemente del color es un curro tremendo pero realmente es la forma ideal de hacer el efecto de fuego. Un 10 para Acclaim por ser tan ambiciosos y lograr un resultado soberbio. A continuación dejo los gifs del canal de color y del canal alfa por separado y más lentos para que se puedan apreciar bien. En el canal alfa cuanto más cercano a blanco es el píxel es más opaco y cuando es más oscuro tiene mayor grado de transparencia.




Para quien quiera saber más sobre los distintos formatos de texturas con los que trabaja Nintendo 64 hay un artículo muy detallado, aunque en inglés:
https://n64squid.com/homebrew/n64-sdk/t ... e-formats/

¿Con que programa se podría diseñar esas texturas y en que formato, por cierto que programa usas tú para crear las texturas?.

A mi con Gimp, las texturas de 64X32X8 en BMP, me pesan siempre un poco más de 2KB,cuándo no debería ser así,¿puede ser por el formato BMP que añade algo de información incrustada?.

Salud.

Sogun escribió:Son 80 kB de texturas dedicados al fuego (y hay otra animación para una llamarada más pequeña pero que usa el mismo tamaño de texturas y me parece que incluso más cuadros de animación).

El cartucho del Turok 2 ya era de 32MB, contaban con bastante espacio para texturas.
De hecho la ROM USA tiene 33KB libres, mientras que la ROM PAL tiene asombrosamente 320KB libres.
¿Mejora de compresión? ¿Optimización de espacio? ¿Material sobrante de la versión USA quitado en la PAL?

Sogun escribió:Puede que incluso demasiadas capas de semitransparencia afectara al rendimiento.

En algún sitio vi explicado el bug, de qué formato de textura estaba puesto y cúal pusieron por error, y ambos son con alpha, así que no parece que fuera a haber gran diferencia por ahí. De hecho, el tipo de textura erróneo que pusieron era RGB+A, mientras que el formato correcto es I+A (I de Intensity, o sea, escala de gris). Si acaso, yo diría que RGB+A requeriría mas proceso. Lo que no acabo de entender es cómo interpretar datos IA como RGBA da ese resultado tan curioso, todo en negro, y sin haber colores por ningun lado.

Sogun escribió:Esto de tener 16 grados de transparencia y poder asignarlos por cada píxel independientemente del color es un curro tremendo pero realmente es la forma ideal de hacer el efecto de fuego.

Hombre, o me imagino que tendrían un software, comprado o desarrollado por ellos mismos, capaz de renderizar tanto los canales RGB como el alpha. No creo que lo fuesen a mano aplicando alfa a cada fotograma.
De hecho, no creo que esa textura tan compleja la dibujasen a mano, Parece mas bien una animación algorítmica capturada. No lo digo como si fuese darle a un botón y listo, si lo que pretendías era decir que fueron pixel a pixel manualmente poniendo el alpha, creo que te equivocas.

dirtymagic escribió:A mi con Gimp, las texturas de 64X32X8 en BMP, me pesan siempre un poco más de 2KB,cuándo no debería ser así,¿puede ser por el formato BMP que añade algo de información incrustada?.

Si, BMP contiene un cabecero con la información de las dimensiones y el formato de pixel, entre otras cosas.
La alternativa sería un formato en bruto o "RAW" (crudo) que obligaría al programa que lee los datos a saber de antemano esos aspectos. Las texturas en la TMEM pueden ir en RAW porque el displaylist ya le dice al RDP cual es el formato y dimensiones.

EMaDeLoC escribió:El cartucho del Turok 2 ya era de 32MB, contaban con bastante espacio para texturas.
De hecho la ROM USA tiene 33KB libres, mientras que la ROM PAL tiene asombrosamente 320KB libres.
¿Mejora de compresión? ¿Optimización de espacio? ¿Material sobrante de la versión USA quitado en la PAL?

El primero probablemente no, el segundo y el tercero son posibles, y yo añadiría también la posibilidad de que retirasen el sistema de depuración/debug. Claro que eso podría considerarse también como "material sobrante"

radorn escribió:

Sogun escribió:Puede que incluso demasiadas capas de semitransparencia afectara al rendimiento.

En algún sitio vi explicado el bug, de qué formato de textura estaba puesto y cúal pusieron por error, y ambos son con alpha, así que no parece que fuera a haber gran diferencia por ahí. De hecho, el tipo de textura erróneo que pusieron era RGB+A, mientras que el formato correcto es I+A (I de Intensity, o sea, escala de gris). Si acaso, yo diría que RGB+A requeriría mas proceso. Lo que no acabo de entender es cómo interpretar datos IA como RGBA da ese resultado tan curioso, todo en negro, y sin haber colores por ningun lado.

Según la descripción del error, la textura esta en formato IA de 16bits, mientras que en el código se dice que la textura es RGBA de 16bits.
Ambos formatos usan 16 bits por pixel, pero en IA los 8 primeros bits son la intensidad (o luminosidad) y los otros 8 son el nivel de transparencia (256 niveles, ahí es nada).
En el formato RGBA, el color se almacena en formato 555: 5 colores por bit. El decimosexto bit es el alfa, que en este caso es o el pixel se ve, o no se ve.
Por las fotos, la textura de humo es un simple cuadro negro (intensidad cero) con diversos niveles de transparencia para dar forma de nube. Como el valor de la transparencia varía, el último bit de cada pixel también varia, y al interpretarse como formato RGBA, el pixel desaparece según si el valor de transparencia es un número par (bit 16 = 0 = transparente total) o impar (bit 16 = 1 = dibujalo).
Lo raro es que no salga tonalidades de azul en el humo, al coincidir los 5 bits del azul del formato RGBA en los 8 bits de intensidad alfa. Quizá por un casual se hagan los píxeles transparentes justo cuando se quedan teñidos de azul.

¿Es posible encontrar el archivo tal cual de la textura, en el formato original de la consola? Nada de BMP, JPG ni otras mierdas...

EMaDeLoC escribió:¿Es posible encontrar el archivo tal cual de la textura, en el formato original de la consola? Nada de BMP, JPG ni otras mierdas...

La consola en sí no tiene un formato como tal para texturas, todo lo que hace es leer un array de 8 bits (primeros y segundos 4bit para texturas de 16 colores), de 16bits, etc en una posición de memoria que le indicas al llamar al comando, hacen falta otros parámetros para ese y varios comandos más que tienes que llamar, así que es tarea de si la librería tiene alguna macro y formato reconocido que ya hace todos esos pasos por ti o si los haces a mano o implementas en un motor.

También puedes crear al vuelo, de hecho la textura dentro de un cartucho podría ser perfectamente un bmp y que se convierta en tiempo de carga, un png, un tileset o spritesheet gigante con multiples texturas, etc, aunque yo al menos creaba las texturas con el array que necesita la consola.

Igual se sale un poco de lo que preguntabas, pero no está de más comentarlo..

Dejo una imagen chula del otro hilo de N64 en vandal

@Conker64 ¿Que juego es el de la plataforma de arriba, el que parece que se parapeta detrás de un contenedor a lo metal gear solid?

Señor Ventura escribió:@Conker64 ¿Que juego es el de la plataforma de arriba, el que parece que se parapeta detrás de un contenedor a lo metal gear solid?

Winback.

Conker64 escribió:

EMaDeLoC escribió:¿Es posible encontrar el archivo tal cual de la textura, en el formato original de la consola? Nada de BMP, JPG ni otras mierdas...

La consola en sí no tiene un formato como tal para texturas, todo lo que hace es leer un array de 8 bits (primeros y segundos 4bit para texturas de 16 colores), de 16bits, etc en una posición de memoria que le indicas al llamar al comando, hacen falta otros parámetros para ese y varios comandos más que tienes que llamar, así que es tarea de si la librería tiene alguna macro y formato reconocido que ya hace todos esos pasos por ti o si los haces a mano o implementas en un motor.

También puedes crear al vuelo, de hecho la textura dentro de un cartucho podría ser perfectamente un bmp y que se convierta en tiempo de carga, un png, un tileset o spritesheet gigante con multiples texturas, etc, aunque yo al menos creaba las texturas con el array que necesita la consola.

¿Entonces se podría hacer algo parecido a como funciona Soul Reaver de PSX, que es una textura grande y a partir de ella corta las texturas al tamaño de cache?, porque simplificaría mucho el tema de texturizar con texturas con más resolución y troceadas para caber en la caché.

salud.

@dirtymagic
Claro, lo primero es lo más fácil, enviar un bloque a cache.

Si te refieres a pintar más de 1 textura en 1 superficie tendrías que usar UV mapping, creo que no era nada común de ver.

Imagino que es un código que tendría que cocinar el programador escribiendo directamente para el RDP (que establece toda la información y coordenadas de textura)

Conker64 escribió:

EMaDeLoC escribió:¿Es posible encontrar el archivo tal cual de la textura, en el formato original de la consola? Nada de BMP, JPG ni otras mierdas...

La consola en sí no tiene un formato como tal para texturas, todo lo que hace es leer un array de 8 bits (primeros y segundos 4bit para texturas de 16 colores), de 16bits, etc en una posición de memoria que le indicas al llamar al comando, hacen falta otros parámetros para ese y varios comandos más que tienes que llamar, así que es tarea de si la librería tiene alguna macro y formato reconocido que ya hace todos esos pasos por ti o si los haces a mano o implementas en un motor.

Bueno, pues entonces a ver si alguien puede pasar el array o decirme la posición de memoria de la ROM donde se encuentra, y ya me apañaría yo...

Conker64 escribió:Igual se sale un poco de lo que preguntabas, pero no está de más comentarlo..

Se sale bastante...

Señor Ventura escribió:@Conker64 ¿Que juego es el de la plataforma de arriba, el que parece que se parapeta detrás de un contenedor a lo metal gear solid?

Operation Winback, injustamente maltratado por la crítica de la época porque lo pusieron como el MGS de N64, está bastante bien. Salió con mejoras gráficas para PS2 y tuvo una secuela llamada Winback 2 (PS2, Xbox) ya en tiempos de 360.

@SuperPadLand hmmm... yo el Winback me lo pasé recientemente y la verdad es que es muy repetitivo, muy rígido, frustrántemente coregrafiado en muchas ocasiones, y a veces se hace incomprensible qué es lo que se supone que debes hacer. Los escenarios no están mal, y tiene sus puntos positivos, pero, la verdad es que se me hizo mediocre.

EMaDeLoC escribió:Bueno, pues entonces a ver si alguien puede pasar el array o decirme la posición de memoria de la ROM donde se encuentra, y ya me apañaría yo...

Me parece que en el Mario casi todos los datos van comprimidos en la ROM en un formato llamado mio0. Creo que tendrás que acudir a la scene de hackeo del juego para sacar la textura.

De todas formas, una búsqueda rapida me ha dado esto https://hack64.net/wiki/doku.php?id=sup ... memory_map

EDITO: En SMWcentral, que parece ser uno de los centros de hackeo de M64, curiosamente, he bajado un pack de texuras de SM64 claramente sacadas mediante la técnica de volcado de los emuladores para los texture packs esos.
He encontrado la que creo que es la textura del humo, y eso me ha aclarado muchas cosas:



La textura original verdaderamente contiene valores de intensidad que dibujan una nube de humo, y, además, un canal alpha.
El caso es que al interpretarse los valores de intensidad como si fueran RGB, lo esperable era que se vieran colores, y no un punteado negro, que era lo que a mi me extrañaba. Y, efectivamente, eso es lo que muestra la textura decodificada a RGB24 para el texture pack que bajé.
La razon de que se vea negro en el juego, imagino, debe ser que luego aplicaron coloreado en el polígono donde va la textura, reduciendolo todo a negro.

radorn escribió:La razon de que se vea negro en el juego, imagino, debe ser que luego aplicaron coloreado en el polígono donde va la textura, reduciendolo todo a negro.

Tienes razón, no había caido en el coloreado del polígono. Debe ser negro ya que se pensaba usar una textura IA y el color debía ser negro o el humo se vería de otro color, o quizá blanco. Eso anularía cualquier color producido por el formato RGBA.

@radorn con injustamente maltratado no me refería a que fuera una obra maestra, sino a que en su época lo ponían como el MGS de los que tenían una N64 entonces y claro, la decepción fue mayúscula. Pero le pasó lo mismo al Syphon Filter que en la propia PS1 lo ponían como MGS de Sony para su consola o algo así. Al final MGS sólo había uno y redondo, SF a mi me gustó muchó; pero no es MGS y Winback le pasa lo mismo; tiene sus puntos fuertes; pero la mayoría sin muy mejorables. A mi modo de ver y sino recuerdo mal, me gustaba mucho la idea de las "coberturas" que aunque no terminan de funcionar bien del todo al final son un paso previo de lo que después se usó mucho en juegos de acción en tercera persona en la siguiente generación y que todavía siguen usándose hoy en día. La IA la recuerda "rara", no me atrevo a decir mala porque este es un hilo técnico e igual es muy compleja; pero a mi me daba la sensación de que me veían por sus santos cojones aunque no me moviera apenas para que hubiera acción sí o sí.

Pero vamos a lo que iba, MGS fue un 10 y algo único en esa generación; SF y Winback eran cosas diferentes con algún elemento en común; pero juegos de 6-8. El Winback tiene un valor añadido en N64 porque dentro de su propio catálogo no tiene una amplia competencia y si buscabas algo "adulto" con trama y de tiroteos en tercera persona no había mucho más porque los intentos de Duke Nukem a TPS en esta generación, para mi, fueron todos bastante mediocres tanto en PSX como N64.

El tema de Winback es que fue el primer shooter en tercera persona con coberturas de la historia, predecesor de Kill·Switch, básicamente el juego que inspiró Gears of War (en palabras de Cliff Bleszinski). El salto que hubo entre simplemente mirar desde la cobertura (Metal Gear Solid) y todo el sistema de apuntado desde la cobertura fue gigantesco. Kill·Switch refinó bastante la fórmula pero Winback lo inventó todo. Que no está nada mal para una empresa, Omega Force, que acabó dedicándose al musou toda la vida.

Sí que es un pelín ortopédico en ocasiones pero se juega bien. Lo único que no me gusta es que para obtener el final bueno tienes que ir a pijo sacao, es muy Mizzurna Falls.

N64 SP: LaN64 portátil más compacta del mundo con hardware real (y ranura para cartuchos)

cegador escribió:N64 SP: LaN64 portátil más compacta del mundo con hardware real (y ranura para cartuchos)

Brutalísimo.

Hilo del foro donde cuenta el desarrollo (no cuenta mucho, pero hay fotillos).
https://bitbuilt.net/forums/index.php?threads/gmans-mgc64-thing.3117/

@EMaDeLoC Me sobra la entrada de cartucho, podrían aprovechar el espacio para meter más batería (comenta que sólo dura 2 horas actualmente).

Pero igualmente increíble.

@cegador Aún mejor, podría haber montado el slot a la misma altura que la placa y al borde de la consola, sobresaliendo el cartucho como hacian los de Gameboy en la autentica SP. Así la consola sería aún más pequeña.
Si hubiera optado por una batería plana podría tener más capacidad. De todas formas una de 4000mAh no es moco de pavo.
Alternativas aparte, es un gran mod.

Vídeo con entrevistas a los encargados del remake de Doom64, habla mucho del original comenta las técnicas y trucos usados en su momento y lo compara con el Doom de PSX y otros. Muy recomendable:

Hola!
Si al expansión pak les hubieran montado memorias rápidas con poco lag, se hubiera notado mucho el rendimiento o el cuello lo seguiría tendiendo?

ziu escribió:Hola!
Si al expansión pak les hubieran montado memorias rápidas con poco lag, se hubiera notado mucho el rendimiento o el cuello lo seguiría tendiendo?

lo seguiría teniendo, para que hubiera mejora, la propia RAM de la consola debería ser mejor, no solo la de la expansion.

ziu escribió:Hola!
Si al expansión pak les hubieran montado memorias rápidas con poco lag, se hubiera notado mucho el rendimiento o el cuello lo seguiría tendiendo?

Aparte de lo que te ha dicho el compi, las RDRAM montadas en la consola ya eran de las más rápidas del mercado. La única forma de mejorar el rendimiento era variando la arquitectura, como ampliando el bus de memoria a 18bits o asignando memorias y procesadores dedicados como tenía PS1, por ejemplo un procesador de audio con su propia memoria y un chip dedicado al framebuffer. La arquitectura de la N64 es de muy bajo coste de producción, y en ese termino el rendimiento es bastante bueno. Hablamos de una consola que salió casi al mismo tiempo que la 3Dfx Voodoo 1 que también venía con 4MB de RAM y dos procesadores.
Habría sido mucho más interesante que con el 64DD ya tan previsto como para implementar el expansion pak, directamente la hubieran sacado con 8MB de RAM. Así los desarrolladores habrían jugado desde el principio con más memoria disponible y veriamos cosas más interesantes. Puedo incluso que con un Mario 64 a 480i.
Pero son elucubraciones.

EMaDeLoC escribió:

ziu escribió:Hola!
Si al expansión pak les hubieran montado memorias rápidas con poco lag, se hubiera notado mucho el rendimiento o el cuello lo seguiría tendiendo?

Aparte de lo que te ha dicho el compi, las RDRAM montadas en la consola ya eran de las más rápidas del mercado. La única forma de mejorar el rendimiento era variando la arquitectura, como ampliando el bus de memoria a 18bits o asignando memorias y procesadores dedicados como tenía PS1, por ejemplo un procesador de audio con su propia memoria y un chip dedicado al framebuffer. La arquitectura de la N64 es de muy bajo coste de producción, y en ese termino el rendimiento es bastante bueno. Hablamos de una consola que salió casi al mismo tiempo que la 3Dfx Voodoo 1 que también venía con 4MB de RAM y dos procesadores.
Habría sido mucho más interesante que con el 64DD ya tan previsto como para implementar el expansion pak, directamente la hubieran sacado con 8MB de RAM. Así los desarrolladores habrían jugado desde el principio con más memoria disponible y veriamos cosas más interesantes. Puedo incluso que con un Mario 64 a 480i.
Pero son elucubraciones.

Ok, es que tenia entendido que al estar la memoria unifcada, habia mucho lag y cuello de botella, creia que la causa eran memorias lentas , y que el bus era rapido. Esto que de la RDRAM era la mas rapida del mercado lo desconocia.

Igualmente no creo que hubiera aumentado mucho los costes si hubieran hecho buses independientes u asignado por ejempo 2MEGAS CPU 1,5 MEGAS VIDEO y 0,5 MEGAS AUDIO por ejemplo, pero bueno, quizas no se esperaban estos problemas a la hora de programar,

@ziu El pico teórico de la RAM de la consola es de 500MB/s, que para la época está muy bien (en la PS1 es de 131MB/s). El problema es que ese pico solo se alcanza durante la transmisión de los datos, no incluye el acceso a memoria, que es lo que se conoce como latencia. La latencia de la RAM de la N64 es de 28 nanosegundos, casi lo mismo que la EDO RAM montada en la Voodoo que era de 30 nanosegundos. Pero mientras esta última va a 100MHz, la de N64 alcanzaba los 250 y además a doble canal, lo que la convertía de facto en 500MHz.
La diferencia de rendimiento es que mientras que ves en la Voodoo un montón de chips separados y conectados cada uno a un procesador, permitiendo el trabajo en paralelo y nulos cuellos de botella con el framebuffer, en la N64 todo pasa por un único bus de 9bits: texturas, modelos 3D, sonido, música, código, framebuffer, etc. Debido a los múltiples accesos y a los ciclos de lectura/escritura no llegará a los 500MB/s, pero la RAM de la N64 debe ser de las memorias más estresadas jamás instalada en una consola y se acerca bastante a su pico teórico a todas horas.

En cuanto a los costes, imagina que por ejemplo añades algo (un bus más ancho, una memoria dedicada, etc) y te cuesta 2$ dólares más por consola. No parece mucho, pero si tienes que hacer una tirada de 500.000 consolas, que es lo que vendió la N64 en la primera semana en Japón, esos 2$ se transforman en un millón. Un millón que has dejado de ganar en una semana de ventas por algo que posiblemente no mejore significativamente el rendimiento.

En el caso de PS1 sí se hizo así porque Sony fabrica sus propios chips. Dentro de la consola, aparte de componentes pasivos y las memorias, todos los chips son de Sony, por lo que podía reducir drásticamente los costes y además no depender de hacer pedidos de miles de unidades, sino ir fabricando al ritmo que necesitase.

Para que te hagas una idea de lo ratas que son los de Nintendo, hiceron placas base específicas para Francia con salida RGB por la legislación que había allí con la conexión de vídeo, pero en cuanto vieron que no era necesario el RGB, le quitaron todos los componentes que pudieron, vendieron todas las placas y en cuanto se acabó el modelo, les vendieron a los franceses las misma consola que al resto de Europa. Se ahorraron como mucho 50 centavos por unidad quitando esos componentes.
También es reseñable la diferencia de cantidad de revisiones que tiene la consola. Es gracioso ver la cantidad de componentes que desaparecen de la primera versión a la última.

Un apunte, no digo lo de ratas de forma despectiva, porque hay que ser un genio para que juegos del nivel de DK64 o Zelda vayan tan "fluidos" en un simple bus unificado de 9bits.

@EMaDeLoC mejor un bus de 18 bits?, o dos buses de 9 bits.

Imagino que si tendría un impacto en el rendimiento... como mínimo doblar los fps, no?

@Señor Ventura Que va, ni de lejos llega a doblar fps.

A ver si lo explico bien.

El reloj de la RAM es de 250MHz. Eso significa que cada hercio o ciclo duran 4 ns (nanosegundos). La RDRAM es capaz de mandar dos bytes en cada pulso de reloj, así que si multiplicamos 2 bytes por 250MHz nos salen los famosos 500MB/s (en realidad son 562MB/s porque son 9 bits, pero para hacerlo más sencillo todo, lo explico con bytes).
Ahora imaginemos que pedimos 4 bytes, que es el paquete de datos más pequeño que le podemos pedir a la RDRAM. La cuenta rápida nos dice que tardaríamos un ciclo por cada 2 bytes, y que un ciclo son 4 ns, entonces tardaríamos en recibir los datos 8 ns (4 bytes / 2 * 4 ns).
Pero en realidad es mucho más complejo. Para solicitar 4 bytes, primero hemos de hacer la petición a memoria (activar las líneas del bus) y mantenerla 12ns, luego esperar 28ns (latencia) y entonces recibimos los datos. Es decir, 12ns de peticíon + 28ns de latencia + 8ns de datos = 48ns. Eso nos daría 83MB/s, lejísimos de los 500MB/s.
Si la memoria fuese la misma pero con el doble de ancho de bus, es decir, 2 bytes, la transmisión de datos duraría 4ns, pero todo lo demás seguiría tardando lo mismo, así que al final serían 44ns. Lo que nos da 90MB/s. Es decir, prácticamente lo mismo.
Si lo miramos con el paquete de datos más grande que se puede pedir, que son 256bytes, a un byte de ancho de banda son 552ns de tiempo, 463MB/s, y dos bytes de ancho de banda 296ns de tiempo, 864MB/s. Es casi casi el doble.
Esto nos da a entender que cuantos más datos leamos de una vez más alto será el ancho de banda efectivo, pues habremos estado más tiempo recibiendo los datos, que esperando a la memoria.
Lo que ocurre es que rara vez habrá que pedir 256bytes seguidos, los paquetes tendrán tamaños variables, especialmente al escribir en memoria las líneas de distinto tamaño que formen los polígonos.
Usando una hoja de cálculo he mirado la eficiencia de los tamaños de los paquetes. Cuando superan los 80 bytes superamos también los 400MB/s. A partir de 32 bytes tenemos 300MB/s, pero cuando baja de ahí se ronda los 200MB/s. En resumen, hacer movimientos de menos de 32 bytes sale muy caro en rendimiento.
Si doblamos el ancho de banda, obtenemos una mejora, pero no es tan grande como doblar rendimiento. Por ejemplo a los 80 bytes son 660MMB/s y a los 32 bytes son 444MB/s. Un 65% de mejora en el primero, un 48% el segundo.
Así a priori doblar el ancho del bus parece que nos dé una mejora tal que podríamos tener 30fps estables y aún quedaría margen para aumentar carga poligonal. Pero el doble de fps queda lejos.
Sin embargo como he dicho se aprovecha mejor el ancho de banda en ambos casos con paquetes mayores de 32 bytes. Tendría que mirar más a fondo pero paquetes de más de 32 bytes serán comunes al cargar texturas o sonidos, en cambio al cargar polígonos, código o variables de programa bajaremos de los 32 bytes con seguridad. Luego al pintar las líneas horizontales de los triángulos en el framebuffer, el tamaño será muy variable, yendo desde el mínimo al máximo de velocidad con frecuencia. Hay que recordar que al pintar un pixel se comprueba el buffer Z y son paquetes pequeños lo que se está moviendo por ahí (aunque estoy muy verde en lo que se refiere a como comprueba el RCP el buffer Z).
En resumen, doblar el ancho del bus nos daría una mejora del 50% aproximadamente. Pero hay que tener en cuenta que doblar el ancho de bus implica más cosas, como aumentar el tamaño del RCP, que ya es un puto monstruo, para hacer sitio al bus extra; poner dos chips en paralelo en la placa, que ya saldría bastante caro; hacer el slot del expansion pak más grande, lo cual también aumenta de precio... ¿He comentado ya lo rata que es Nintendo?

Espero no haber fundido las neuronas de mucha gente con este tocho tan técnico. Ni haber metido mucho la pata...

Los datos sobre la RDRAM los he sacado de este datasheet, que en teoría es una memoria con las mismas prestaciones.

@EMaDeLoC

Gracias x la explicación tan detallada, tiene su sentido si es para ahorrar costes a la larga a costa de perder algo de rendimiento...

Veo la Saturn por ejemplo y es todos lo contrario CPUs por un tubo, x eso dicen q fue la ruina es costes para sega..

Y si le quitaron un montón de chips entre el primer modelo de N64 y el último, ¿Se nota un empeoramiento auido-visual?

@ziu La mayoría de las cosas que quitaron es por simpliciar la producción, abaratandola. Por ejemplo, pasaron de dos chips de RAM a uno solo, unificaron chips de vídeo y audio, cosas así.
Que yo sepa hay modelos concretos sin salida S-video. No sé si empeoró la calidad del video compuesto o del audio al tomar esas medidas.

Cómo emular la N64 en PC y configurarlo a 4K usando retroarch:



Lo voy a probar estos días, a ver qué tal.

ziu escribió:@EMaDeLoC

Gracias x la explicación tan detallada, tiene su sentido si es para ahorrar costes a la larga a costa de perder algo de rendimiento...

Veo la Saturn por ejemplo y es todos lo contrario CPUs por un tubo, x eso dicen q fue la ruina es costes para sega..

Y si le quitaron un montón de chips entre el primer modelo de N64 y el último, ¿Se nota un empeoramiento auido-visual?

No hay empeoramiento, al revés: las últimas N64 (las de colores o Funtastic) vendidas sobre el 2000 al 2002 tienen mejor salida de vídeo compuesto que las anteriores, y el S-Video es igual en ambas. Aunque hay algunos modelos Funtastic que incluso perdieron la opción del S-Video. Pero en compuesto son mejores a las grises oscuras normales.

Observa esta comparativa:


Ambas son N64 PAL usando compuesto. A la izquierda las grises oscuras, a la derecha las de colores o Funtastic, si te fijas la imagen es más nítida, aunque según el título se aprecia solo en los detalles, como el Mario Kart 64 donde se nota en cosas como la fuente de las letras por ejemplo, que se ven mejor.

Tienes discusiones sobre el tema e incluso números de serie y tal, en estos dos foros:

https://www.tapatalk.com/groups/nintend ... t2744.html

http://forums.modretro.com/index.php?th ... uest.1417/


Un saludo

@Falkiño

Que cambio,
Lo que influte las salidas de video,

Mario64 Odyssey ya descargable (sólo para emulador):

cegador escribió:Imágenes del prototipo del mando de N64:

https://twitter.com/shanebattye/status/ ... 7030618112

En este video hacen una comparativa entre el prototipo y un mando normal.



Lo usa también con prototipos como el Mario 64 o el Viewpoint 2064.

Edit: MVG dedica un vídeo a lo complicado que era desarrollar en N64:



Comete un fallo garrafal a partir del minuto 6. Dice que Turok 2 lee las texturas del cartucho en vez la TMEM o la RAM para superar el límite de los 4KB. Creo que los asiduos al hilo sabemos cuanto de incorrecto es eso.
Otro fallo es decir que el problema de la memoria era la latencia, cuando en realidad es el bus y la sobrecarga de trabajo (en un post anterior lo explico en detalle).
Son dos cosas que ya he comentado en los comentarios del vídeo.
Invoco a @Conker64, que es quien tiene más experiencia tocando código, a ver si encuentra más fallos en el vídeo con los que indignarnos.
Aunque me parece que aparte de lo mencionado esta todo bastante bien.

EMaDeLoC escribió:Edit: MVG dedica un vídeo a lo complicado que era desarrollar en N64:

Comete un fallo garrafal a partir del minuto 6. Dice que Turok 2 lee las texturas del cartucho en vez la TMEM o la RAM para superar el límite de los 4KB. Creo que los asiduos al hilo sabemos cuanto de incorrecto es eso.
Otro fallo es decir que el problema de la memoria era la latencia, cuando en realidad es el bus y la sobrecarga de trabajo (en un post anterior lo explico en detalle).
Son dos cosas que ya he comentado en los comentarios del vídeo.
Invoco a @Conker64, que es quien tiene más experiencia tocando código, a ver si encuentra más fallos en el vídeo con los que indignarnos.
Aunque me parece que aparte de lo mencionado esta todo bastante bien.

Creo que se lía un poco al comentar la CPU, habla todo el rato de instrucciones y éstas vienen fijas en el chip, N64 puede hacer operaciones con datos de 32bit y 64bit, tanto en enteros como en coma flotante (float/double), creo que así quedaría más claro.

El 5 stage pipeline también creo que confunde un poco, aunque ya se lo están diciendo en los comentarios.

Tampoco comenta que las operaciones con datos en la CPU (los 8KB de data) si van a ser utilizados directamente por el RDP hay que pasarlos primero a la RDRAM, es un proceso manual, de lo contrario lee información no actualizada, si haces que a cada operación se haga writeback a la RAM te puedes cargar bastante el rendimiento, es solo cuando sea necesario.

Lo de las texturas suena raro, si son de 16 colores pueden ser de 64x64 sin mayor secreto.

Menciona el framebuffer de 32bits, pero por rendimiento es un modo poco útil.

Hay más cosas pero vaya de las pocas que menciona en el vídeo, para incrementar fillrate hay muchos truquillos, el más obvio es no usar z-buffer (World Driver..) o usar COPY en lugar de CYCLE1 o usar texturas alargadas horizontalmente o no usarlas, goraud es más rápido y así..

En el vídeo patina muchísimo cuando dice que el World Driver Championship funciona a 60 fps a 640x480 de resolución (min 9:30).
Siendo un juego de los más avanzados técnicamente de la consola y de los de mejor rendimiento me parece que está limitado a 30 fps. No recuerdo un pico de suavidad extrema como a veces daban PilotWings 64 o GoldenEye (juegos con framerate desbloqueado). En cuanto a la resolución es muy normalito y no llega ni por asomo a lo que dice ni siquiera en modo hi-res. Creo que ya se pusieron números. También menciona que para lograr ese rendimiento hubo que desactivar cosas como por ejemplo el mipmapping cuando en el propio vídeo se ven texturas con el filtro activado (se habrá confundido con el z-buffer que sí se eliminó).
Luego añade que el Perfect Dark tiene un rendimiento pobre por las limitaciones que se les impuso a Rare (supongo que se refiere a que no usaran micro-código propio) cuando lo que ocurre con este juego es que tiene una geometría y unos efectos de frame-buffer y transparencias muy tochos. Realmente a resolución normal y en espacios cerrados sin un ejército de enemigos en pantalla el juego funciona muy bien.

Supongo que lo que dice de que hacia el final de la vida de la consola los desarrolladores almacenaban texturas sin comprimir en el cartucho y las procesaban directamente desde ahí sin pasar por la caché para superar la limitación de los 4 kB aunque fuese un método más lento es algo totalmente incorrecto. Los ejemplos que aparecen en el vídeo con texturas de Turok 2 pasan por la caché de 4 kB sin problemas (de hecho en esos casos concretos de texturas de 64x64 a 16 colores se emplean 2 kB para la información de la textura y los otros 2kB para la paleta de la textura como ya hemos explicado en este hilo muchas veces).
He investigado muchísimos juegos de N64 que tenían texturas aparentemente más grandes de lo que permitía la caché y siempre se trata de una imagen partida en trozos más pequeños para que pudiera manejarlos la caché.
Creo que se hace un lío con el streaming de texturas de Factor 5 para el juego de Indiana Jones en el que afirmaban que el límite de la cantidad de memoria RAM ya no era un problema porque con ese método la memoria efectiva era la de todo el cartucho.

Yo tenía entendido que cuando se va a renderizar un escenario toda la información (geometría y texturas) se carga en la RAM y después las texturas pasaban a la caché para aplicarles todos los efectos antes de mostrarlas en pantalla. Por eso en los niveles de GoldenEye puedes asignar la cantidad de memoria que se asignará a las texturas y si te quedas corto empiezan a corromperse.
A ver si alguien puede arrojar un poco más de luz en esto.

----------------

En otro orden de cosas, este fin de semana estuve experimentando con un método para simular Fur shading. Se ve y funciona de escándalo en emulador, pero me temo que el hardware original se queda corto de resolución para que se aprecie algo (de rendimiento no funciona muy allá pero pensaba que se arrastraría más ).

Dejo enlace al parche que debe aplicarse a la rom de Goldenye, imagen comparativa y una explicación en el secreto.

@Sogun Entonces a ver si lo entiendo.
Has puesto 3 capas
La 1 la imagen base (0 transparencia) la 2º un 50 y la tercera 75% supongo que la ultima es para la vista lejania cuand miras un arbusto o algo las puntas.
¿me equivoco?

La verdad es que MVG no está muy fino últimamente.

Flash-Original escribió:@Sogun Entonces a ver si lo entiendo.
Has puesto 3 capas
La 1 la imagen base (0 transparencia) la 2º un 50 y la tercera 75% supongo que la ultima es para la vista lejania cuand miras un arbusto o algo las puntas.
¿me equivoco?

Mi idea inicial era ir haciendo cada capa más transparente según se alejaba de la capa base como tú dices. En el caso de tres capas de semitransparencia pensaba hacer 75%, 50%, 25% de opacidad pero no quedaba bien. La última capa apenas se distinguía y era como si no estuviese ahí. Hay que tener en cuenta que las texturas en escala de grises cuando las haces transparentes (Intensity Alpha) ya incluyen un grado de transparencia según el color del píxel. Entonces los píxeles blancos tenían una opacidad del 25% pero los píxeles más oscuros tenían mucho menos. Lo mismo con las otras capas. Realmente el conjunto era mucho más transparente de lo que pretendía. En texturas con paleta de colores sí que sería necesario aplicar distintos grados de semitransparencia a cada capa, pero todavía no he hecho ningún test.

Así que en este caso ninguna capa tiene semitransparencia de más añadida por mí. Los píxeles blancos son opacos al 100% y los grises tienen más o menos transparencia dependiendo de lo oscuros que son.

Yo me pregunto si se podría programar un microcódigo capaz de usar la TMEM como caché transparente igual que en PS1, quitando así la limitación de tamaño de textura. Claro que para eso también habría que crear formatos de textura capaces de funcionar de esa manera, que no se si permitirían el uso de mip-maps, y, desde luego, el rendimiento se vería afectado en el momento que se accediese a una parte de la textura no cacheada, igual que sucede en PS1. Pero bueno, esos problemas ya dependerían de un buen diseño de modelos y texturas para minimizar la incidencia de dichas situaciones y su impacto en el rendimiento.

Por otro lado, sería cojonudo que alguien encontrase una forma de hacerle OC al RCP, que es el componente mas castigado del sistema. La CPU en general, con sus 93.75 MHz, va bastante holgada, pero puede que ahogada por el acceso a la memoria unificada a través del RCP...

Un antiguo desarrollador de Earthworm Jim 3D ha comentado en el vídeo algunas cosas interesantes.

"N64 was the first console I developed for. I wrote a lot of the game engine (rendering and character control) for Earthworm Jim 3D (I know it was not a particularly good game - I'm so very, VERY sorry). I have fond memories of using the hardware - and don't remember it being particularly bothersome. It was a struggle early on with the documentation, but once I got a basic textured triangle on the screen, in my memory it went smoothly (from a technical point of view). But it was a long time ago, and I wouldn't say we really pushed it. I hadn't programmed any 16-bit consoles, so perhaps it helped not having that baggage. And the display lists felt familiar from having worked with DirectX (DX3? DX5??) albeit the N64 had a more OpenGL like syntax. I definitely remember fill rate and textures sizes being an issue. Pretty sure we kept everything 32x32 or lower.


We started the game quite early on in the lifecycle of the console, but the project lurched in a few different directions, so by the time it was released the engine was older than other titles that were hitting the market at the same time. The chap who worked on the camera and collision had more issues - I remember the collision, in particular, was difficult to optimise - and the camera was hamstrung by the fact development of the levels and the camera happened in parallel - the camera should have been nailed down first - but that was a project management thing, and nothing to do with the hardware. The big positive I remember was the speed of the CPU and the fact it had a built-in FPU. We did a lot of prototyping on PC and converting that code to the N64 was easy. I do remember the Partner64 debugging system being unreliable - both the hardware and software were temperamental. That slowed things down, especially during debugging phases.


All in all, I really enjoyed developing for the N64, and really like the fact it has a great catalogue of games, even if the one I worked on isn't "

Menciona el Partner64, un cartucho de desarrollo, como que era poco fiable y les retrasó su desarrollo.

gelon escribió:La verdad es que MVG no está muy fino últimamente.

Tiene experiencia y conocimientos en la scene, especialmente en la primera Xbox, pero se nota mucho que en la N64 no tiene ni idea y que no contrasta adecuadamente algunos datos cuando se documenta.

@radorn No creo que la TMEM pueda usarse como dices. Si se pudiera ya se habría hecho con los fondos de algunos juegos en vez de usar los modos COPY o FILL. Aparte, teniendo en cuenta el rendimiento de la TMEM, debe ser muchísimo más rápida que la RAM para leer los 4 píxeles necesarios al aplicar el filtro bilinear.
Lo del overclock ya lo comenté por aquí que alguien conectó un ultrahdmi propio y ajustó los relojes de todo y consiguió como un 10% más de rendimiento, pero también iba más rápido el juego, lo cual no es ideal.
Creo que daría mucho mejor resultado hacer como en WDC y crear displaylist de forma manual y optima para eliminar el cuello de botella añadido del z-buffer con la RAM. WDC demuestra que el renderizado de polígonos no es el problema, sino la memoria unificada y el ancho del bus enano.

yo no suelo poner mas de 50% variando el caso ya que como tu dices no se notan en consola como maximo 60% ya que no se nota

@EMaDeLoC Pues no tengo ni idea de si lo de modificar el comportamiento de la TMEM como caché transparente mediante microcódigo es posible o no. Puede que no, como dices tu, pero bueno. El razonamiento de que si fuera posible ya se habría hecho tampoco me parece algo grabado en piedra, dada la reticencia de Nintendo a permitir este tipo de acceso de bajo nivel.

Respecto a lo del overclock aquel, lo que yo me pregunto es si overclockeó el bus de video o el bus de RDRAM.
En ambos casos, imagino haría falta código específico para la nuevas velocidades.

De todo lo que decís, lo que extraigo es que por culpa del bus el WDC no puede hacer uso de un z-buffer que podría ahorrar muchos polígonos que haber podido poner donde hicieran falta, y aumentar así la carga gráfica.

Una lástima.


...peeero, la scene ha avanzado hasta donde muchos no alcanzamos a ver con nuestros profanos ojos... así que vamos a jugar un rato.

Si tuvierais que hacer un port del daytona usa, ¿de donde recortariais, y como sería vuestra visión de como debería ser el juego?, ¿que decisiones tomariais?.

Y lo mas importante, contando con conseguir la optimizacion ideal, y según vuestra visión, ¿que aspecto final tendría el juego?... ¿número de polígonos?, ¿calidad de las texturas?, ¿distancia de dibujado?.

¿Os atreveis con un boceto contextual para goce y disfrute de quienes os leen, u os leen en la sombra?

Yo os voy lanzar una pregunta, a que se debe que en Mario kart 64, hay bajada de velocidad en las música, en la pantalla de la selva va acelerada, la pantalla del castillo de peach, para que carajo está el castillo??

radorn escribió:@EMaDeLoC Pues no tengo ni idea de si lo de modificar el comportamiento de la TMEM como caché transparente mediante microcódigo es posible o no. Puede que no, como dices tu, pero bueno. El razonamiento de que si fuera posible ya se habría hecho tampoco me parece algo grabado en piedra, dada la reticencia de Nintendo a permitir este tipo de acceso de bajo nivel.

No creo que se pueda no solo porque no lo hayan hecho ya, sino por los modos COPY y FILL. Además no creo que se adelante nada ya que si la textura ha de pasar por el TMEM, tendrá que partirse en cachos de 4KB y estamos en las mismas que si hubiera un mosaico de texturas.
En realidad creo que texturas más grandes son perjudiciales, porque si tienes una pared con una textura grande y solo se ve una esquina, has de cargar toda la textura grande para una sola esquina. En cambio si esta pared esta divida en 4 polígonos cada uno con su propia textura, y solo se ve uno, pues solo cargas esa textura que es 4 veces más pequeña que la grande. Y claro, cuanto más ancho de banda de RAM ahorres, mejor.

radorn escribió:Respecto a lo del overclock aquel, lo que yo me pregunto es si overclockeó el bus de video o el bus de RDRAM.
En ambos casos, imagino haría falta código específico para la nuevas velocidades.

Ay, esta memoria...

EMaDeLoC escribió:

radorn escribió:Si aceleras el RCP probablemente te cargues la sincronizacion de video, provoques una gran inestabilidad, o directamente casque el software.

Pues ya colgué antes este video, no se si lo recuerdas:

Por lo que dice la descripción, le sube el reloj del RCP un 10%. Efectivamente el video analógico casca, pero aquí ya le habian metido un FPGA que interceptaba la señal digital del RCP, y ajustandolo se acaba obteniendo imagen de forma normal por HDMI. Bueno, lo de normal es un decir...
Si es viable como mod, no lo creo porque habrá juegos que tengan una sincronización CPU-RCP muy ajustada y apareceran errores de todo tipo.

Por cierto, el tío del vídeo sigue activo en la comunidad de mods y llego a estar haciendo cosas tan impresionantes como una placa de N64 ultrareducida para hacerla portatil.

Para flipar en colores...

Por cierto, del proyecto ese de una placa reducida para la N64 parece que no tiene muchas ganas de continuarlo.

Señor Ventura escribió:De todo lo que decís, lo que extraigo es que por culpa del bus el WDC no puede hacer uso de un z-buffer que podría ahorrar muchos polígonos que haber podido poner donde hicieran falta, y aumentar así la carga gráfica.

Una lástima.

No no, el z-buffer no sirve para ahorrar polígonos, solo sirve para evitar errores de dibujado cuando el displaylist no esta en el orden perfecto o los polígonos se cruzan.



Lo que ocurre es que en la N64 el z-buffer sobrecarga el ancho de banda de la RAM y un poco el RCP. Evitando su uso podemos añadir polígonos, pero el displaylist hay que hacerlo bien con el orden concreto para evitar polígonos encima de otros como en el ejemplo de antes.

Señor Ventura escribió:...peeero, la scene ha avanzado hasta donde muchos no alcanzamos a ver con nuestros profanos ojos... así que vamos a jugar un rato.

Si tuvierais que hacer un port del daytona usa, ¿de donde recortariais, y como sería vuestra visión de como debería ser el juego?, ¿que decisiones tomariais?.

Y lo mas importante, contando con conseguir la optimizacion ideal, y según vuestra visión, ¿que aspecto final tendría el juego?... ¿número de polígonos?, ¿calidad de las texturas?, ¿distancia de dibujado?.

¿Os atreveis con un boceto contextual para goce y disfrute de quienes os leen, u os leen en la sombra?

Pues un Daytona USA como el de Sega Saturn, la versión Championship Circuit Edition, con las mejoras técnicas de la N64 y los trucos del WDC: filtrado bilineal, distancia de visionado bastante alta, niebla para camuflar el popping, texturas con corrección de perspectiva, sin z-buffer, 30fps, transparencias reales (nada de dots), etc.

Vamos, esto:


Pero con estos gráficos:

@EMaDeLoC osea que los números que arroja el wdc son básicamente el rendimiento máximo posible en cuanto a polígonos, texturas, y tasa de frames posible en n64, no?.

Si mal no recuerdo le rondaba los 150k polígonos por segundo. No se si se ha dado el dato de las cifras máximas que llegó a alcanzar cada sistema. Sería curioso.

@Señor Ventura Si escarbas en este hilo, Conker64 da cifras de N64 y PS1.
Creo que WDC llegaba a 100.000 por segundo según sus cálculos.

¿Se sabe qué pasaba con Mario Kart 64 y el framerate? Concretamente en Jungle Parkway.

Tengo recuerdos vívidos de campeonatos con amigos y que ese circuito, en puntos muy específicos, fuera un carrusel, que de pronto se disparara la velocidad del juego haciendo al kart bastante incontrolable.

Creo que había tres puntos, pero desde luego este era uno.



¿Tiene el framerate desbloqueado o qué pasaba ahí?