Hilo de detalles y curiosidades de N64

@SuperPadLand puedes probar con el que recomiendan el video https://wermi.neocities.org/emuguide/gliden64_link/, o usar alguno de los mencionado en la wiki https://emulation.gametechwiki.com/index.php/Nintendo_64_emulators, yo usaba el mupen64plus, pero con el tiempo me empezó a dar problemas, ya que pedía muchos recursos, y mi notebook no daba para mas .

doblete escribió:@SuperPadLand puedes probar con el que recomiendan el video https://wermi.neocities.org/emuguide/gliden64_link/, o usar alguno de los mencionado en la wiki https://emulation.gametechwiki.com/index.php/Nintendo_64_emulators, yo usaba el mupen64plus, pero con el tiempo me empezó a dar problemas, ya que pedía muchos recursos, y mi notebook no daba para mas .

El mupen con el plugin gráfico glide anda en casi cualquier equipo. Mi notebook tendrá 13 años y funciona bien, incluso a 2x de resolución.

Otra cosa muy diferente es con los plugins que recomendaron unos posts más atrás (que son mucho más precisos visualmente).

Parece que son todas las versiones desde Project 64 1.7 hacia atrás, yo usaba la 1.7 cuando tenía todo el entorno configurado, que soporta bastante mejor plugins modernos, desde que instalé Win10 ya solo uso la consola (sin tocar el slot de SD del Everdrive que tengo roto), a ver que tal sale la de Analogue.

Tenía por ahí los instaladores de PJ64 2.0, 2.1 y 2.3 que me los tacho de adware/malware Windows, aún no sé porqué guardaba eso y no los ficheros en versión portable

Tiny3D , nueva libreria 3D con su propio Ucode para usar junto a LibDragon, basada en Open GL 1.1.,con un rendimiento entre F3D y F3DEX2/3 pero más cercano al segundo, aún tienen que hacer más pruebas y mejoras para ver hasta donde llega de rendimiento.
https://github.com/HailToDodongo/tiny3d/


Salud.

Estupenda noticia, un empujoncito más para que haya más homebrew en la scene de la N64.

Me encontré con esto y me pareció interesante:

https://n64squid.com/

Dejo una muy interesante entrevista a Julian Eggebrecht, cofundador de Factor 5 que versa principalmente sobre la etapa N64: la transición de las 2D a las 3D, el primer contacto con los prototipos de la consola, SW: Rogue Squadron, SW Battle for Naboo, Indiana Jones and the Infernal Machine, y alguna sorpresa más...

RiGaL escribió:Dejo una muy interesante entrevista a Julian Eggebrecht, cofundador de Factor 5 que versa principalmente sobre la etapa N64: la transición de las 2D a las 3D, el primer contacto con los prototipos de la consola, SW: Rogue Squadron, SW Battle for Naboo, Indiana Jones and the Infernal Machine, y alguna sorpresa más...

Está bastante bien, pero lo del sonido que dice a la hora de preferir el cartucho no sé bien a que se refiere, si es a tener música dinámica, eso está soportado por PS1 y es la principal razón de porque muchos juegos usaron MIDI en lugar música CD porque con lo primero podían hacer música adaptativa a lo que pasara en la pantalla, con la música CD tienes que reproducir el soundtrack linealmente. Según el tipo de juego se usaba uno u otro.

No recuerdo ya juegos que usasen para poner varios ejemplos, pero Soul Reaver sí lo hace, según la zona que visites cambian, cuando aparecen enemigos también, cuando los liquidas también. Según google también la usa Busby 3D, Syphon Filter, FFVII y Crash Team Racing. Aunque si la usa FFVII, seguramente también la use FFVIII y FFIX.

Supongo que se refiere a que con un cartucho es más fácil cargar nuevos samples de música al vuelo.

riffraff escribió:Supongo que se refiere a que con un cartucho es más fácil cargar nuevos samples de música al vuelo.

En MIDI es testimonial, toda la música de FFVII ocupa 784KB y PS1 tiene 512KB de memoria de sonido más el buffer del CD que creo que eran 32KB. Más los 2MB de memoria principal. Me parece raro que sea eso.

@SuperPadLand Si dices esta parte:

It’s a common sentiment that cartridges were one of the Nintendo 64’s weaknesses. We really didn‘t like the loading times and error rates of CDs in the early days. Sure, you had more memory and if you had linear music, it made that very easy. But in the case of the music, we always loved to create very interactive, changing and cross-fading music. That was not possible on the PlayStation, and the memory constraints of cartridges were easily overcome if the team was technologically proficient

Con la música no linear se refiere a interactiva, cambiando según el momendo de la acción o fundiendose de una a otra. Supongo que la parte que no es posible en PS1 es la de fundir, y puede que también los cambios rápidos aunque con música en formato XA se podía hacer cambios con ciertas limitaciones. Pero lo más importante es que se tenía que seguir leyendo de CD que necesitaba de tiempos de acceso largos para reproducir los archivos, y eso en 2x de velocidad sigue siendo un tiempo largo y dificulta mucho lo que querian hacer en Factor5, y eso si el CD estaba perfecto y sin rayones que dificultaran la lectura.

Así que sí, me parece que los tiros van por la velocidad de acceso y de lectura del cartucho, tremendamente superiores al del CD.

Recupero este quote de otro hilo:
hilo_hardware-de-n64-revolucionario-o-catastrofe_2486704

celgadis_84 escribió:Bump Mapping Demo

Blog explain it

Creía que me había guardado ese .mp4, porque la verdad es que en movimiento impresiona (bump mapping + ambient occlusion en tiempo real, recuerda mucho a lo que es el doom 3, ¡y en una nintendo 64!). No parece que en el artículo se proporcione, y google no encuentra nada.

Atención a este vídeo de Kaze Emanuar que asegura que fue un error que la N64 sea de 64bits:



Así por encima, el cálculo en 64bits supone algunas operaciones más que en 32bits en ciertas condiciones, y encima los compiladores podían ir saltando de modos de 32 a 64 bits cuando les daba la gana, provocando código extra y desoptimizando el código.
Ciertamente 32bits es precisión de sobras para un juego 3D de 1996, pero el marketing es el marketing y era muy difícil vender que la nueva consola era más potente con un chip equivalente al de PS1, por mucho que tuviese soporte de coma flotante que la de Sony no tenía en sus gráficos.

Aparte que Nintendo 64 mola más que Nintendo 32.

El chip gráfico usa comandos de 64bits, si el bus de la consola fuera de 64bit igual la cosa hubiera sido distinta, por lo menos con llamadas a bajo nivel.

Aún así, en la libdragon cambie variables sueltas por variables unificadas de 64bit para cada comando, dividiendo los bits altos/bajos antes de mandarlo al ringbuffer y hubo aumento de rendimiento, mínimo, pero no afecto negativamente en tests que todo lo que hacen es llamar a esas funciones para dibujar en pantalla, supongo que también importa un compilador del 2016.. a uno con 20 años menos.

Es algo que comenta en el vídeo, que el SM64 apenas usa ese tipo de variables en todo el código, salvo contadas ocasiones relacionadas con la libultra, la cual si las usa, para temas internos.

En un juego enteros de 64bit puede que no tenga demasiado sentido, yo usaría el tipo de variable que mejor encaje en su propósito, se va a guardar en el Controller pak? Variables de 8bit, todos esos juegos con medidor de vida que llegan hasta "250" como los Turok, están usando variables de 8bit y no dejan que lleguen a 255 (como hace los Resident Evil) por ser un detalle "feo", es el mejor tipo de variable cuando quieres garantizar que ocupe poco, para cosas como coordenadas obviamente no debe usarse.

@EMaDeLoC pero podía haberse inventado un blast processing, por ejemplo hacer todo de 32bits normal y que el bus fuera de 64 Creo que no fue solo por el marketing porque eso se maquilla rápido, vease que Sony hizo lo mismo con su PS1 frente a N64 siendo inferior. Creo que Nintendo realmente quiso hacer una máquina claramente superior en todo a la competencia y no salió como esperaba tanto por falta de experiencia real en el 3D como por el señoro puño de hierro pidiendo milagros a cuatro céntimos.

Conker64 escribió:El chip gráfico usa comandos de 64bits, si el bus de la consola fuera de 64bit igual la cosa hubiera sido distinta, por lo menos con llamadas a bajo nivel.

¿Como de distinta?.

Algún día serán legítimos los rediseños para la escena. Ver como hubiera rendido una n64 totalmente equilibrada...

@SuperPadLand Me lo creería... si no fuese porque el bus que une CPU y RCP es de 32bits, y que era la CPU de 64bits más barata de la época (o al menos de las más baratas).
Que es un buen procesador con buen rendimiento para su precio, pero buscaban más decir que la consola tenía una CPU de 64bits, que usar realmente un procesador de 64bits.

Tenéis idea si el SH4 de Dreamcast de 64 bits y el EE de PS2 de 128 bits, utiliza código de más de 32bits que no sean cosas internas de bajo nivel?

Salud.

Señor Ventura escribió:¿Como de distinta?.

Algún día serán legítimos los rediseños para la escena. Ver como hubiera rendido una n64 totalmente equilibrada...

Pues que empezarías a eliminar los distintos cuellos de botella de la consola, aunque puestos a invertir yo lo haría en mejorar la latencia o ancho de banda de la RAM, o una mejor distribución al estilo GC.

La forma normal de enviar los comandos al RDP es usando el RSP que está en el mismo chip, así que ese problema del bus existiría solo en modo RDP->RAM o cuando la CPU necesita enviar ciertas cosas a RAM, ciertos listados al RSP o directamente al RDP.

Otra cosa es que gracias al bus permitiera enviar o recibir más datos, sería una inversión para mejorar varios fps sobre cientos creo yo, tal como se comenta en el vídeo, la CPU de N64 tiene potencia de sobra en la mayoría de casos y suele quedarse sin hacer nada.

dirtymagic escribió:Tenéis idea si el SH4 de Dreamcast de 64 bits y el EE de PS2 de 128 bits, utiliza código de más de 32bits que no sean cosas internas de bajo nivel?

Salud.

Dice Sexy Motherfucker que

el SH-4 de Dreamcast es un micro de 32 bits y el de PS2 de 64 bits, ambos con buses de 64.

@SuperPadLand
Sí acabo de mirar y el SH4 es 32 bits, aunque juraría que en su época los datos que daba SEGA era de que era de 64 bits aunque a saber si se referían al bus, del EE sólo he visto que es de 128 bits, pero suponiendo que sea de 64, ¿los utiliza en código general?

Salud.

dirtymagic escribió:@SuperPadLand
Sí acabo de mirar y el SH4 es 32 bits, aunque juraría que en su época los datos que daba SEGA era de que era de 64 bits aunque a saber si se referían al bus, del EE sólo he visto que es de 128 bits, pero suponiendo que sea de 64, ¿los utiliza en código general?

Salud.

https://en.wikipedia.org/wiki/Emotion_Engine#CPU_core

operated on 128-bit wide groups of either 32-bit, 16-bit, or 8-bit integers in single instruction, multiple data (SIMD) fashion

CPU de 32 bits.

https://en.wikipedia.org/wiki/Emotion_E ... l_data_bus

handled by a 128-bit wide internal data bus

Bus interno de 128 bits.