Hilo de detalles y curiosidades de N64

Pues yo hace casi 2 años pululando por una tienda de segunda mano, encontré un volante de N64, un V3. Lo compré, lo probé a nivel funcional y lo limpié porque tenia bastante roña. Realmente no he jugado a nada con el porque no tengo un entorno donde usarlo comodamente.
Por lo visto hay dos o puede que tres versiones del V3, a juzgar por el texto de las cajas. Parece haber una normal, sin ningun tipo de vibracion, y una o dos versiones mas; una con simple vibracion y otra con force-feedback (resistencia al movimiento).
Parece que yo tengo la de vibracion, porque dice "tremor". No recuerdo si vibraba o no cuando lo probé.



@Zardoz2000 Para usar mandos de GC en N64 está esto https://www.raphnet-tech.com/products/g ... /index.php
Personalmente el mando de GC no me convence nada para jugar a juegos de N64, y no se si te sale a cuenta, pero si tienes ese empeño, puedes comprar uno y hacernos un analisis.
Lo que no se es si es compatible con volantes. En la lista de compatibilidad no se mencionan volantes ni a favor ni en contra. Supongo que si el volante en cuestion se comporta como mando, puede que funcione. Si usa otro protocolo, ya no...
Desde luego, en N64, a no ser el teclado del 64DD y el microfono de Pikachu, creo que no hay mandos con protocolos especiales, si no que todos funcionan, a nivel electronico, como el mando estandar. Pero eso no soluciona nada con respecto a GC, claro.

Gracias a todos. Dios proveerá y seguro que encuentro algo asequible por ahí y más si ya sé lo que comprar. Últimamente me estoy haciendo con más artículos en los sitios más insospechados y cada vez me estoy dando cuenta de la utilidad de tener un amplio stock de cosas (mandos, memorias etc) por si las necesitase.

No me voy a gastar 20 euros en un mando de una Xbox clásica sin nisiquiera poseerla pero si la viese en la caja de artículos de 1-2 euros de un rastro me haría con una sin duda. Por poner un ejemplo poco antes de tener la 360 tuve la oportunidad de comprar juegos de Xbox a 1,5 euros (el primer Halo etc) y pasé. Después me arrepentí porque me compré la 360 y no pude aprovechar su retrocompatibilidad.

cegador escribió:El otro día me pillé en wallapop esto por 8 euros (con caja, plásticos, instrucciones y como nuevo) y tengo ganas de darle caña:

Al final me he comprado un adaptador de corriente chinorri y era eso lo que fallaba.

Respecto al volante, funcionan todos los botones y es jugable... pero los pedales no. Me explico:

El pedal de acelerar es como si pulsaras arriba en el analógico.
El pedal de frenar es como si pulsaras abajo en el analógico.

¡Ningún juego de los que he probado tiene la opción de configurar los controles de esa manera! Todos traen varias configuraciones pero predeterminadas... no puedes poner lo que tú quieras.

Menudo fracaso los que crearon el volante este

cegador escribió:Respecto al volante, funcionan todos los botones y es jugable... pero los pedales no. Me explico:

El pedal de acelerar es como si pulsaras arriba en el analógico.
El pedal de frenar es como si pulsaras abajo en el analógico.

¡Ningún juego de los que he probado tiene la opción de configurar los controles de esa manera! Todos traen varias configuraciones pero predeterminadas... no puedes poner lo que tú quieras.

Menudo fracaso los que crearon el volante este

¡Joder, que inútiles! Programaron el modo de N64 igual que el de PS1 sin preocuparles que eso no funciona en ningun juego de ese sistema ¡Vaya chapuza y vaya timo!

Que ya de paso, ese invento que nacio en PS1 de poner el acelerador y el freno en lados opuestos de un mismo eje, de manera que lo que aprietas en uno cancela al otro, no me gusta un pelo.
O sea, ya se que en el mundo real no debes pisar el freno mientras sigues acelerando. Ellos asumen que en un videojuego tampoco vas a hacer eso, pero... un videojuego, especialmente si no es de simulacion pura, puede hacer eso. No se aplica la misma logica lo mismo para nada. Pero bajo su modelo de control, pisar el freno y el acelerador a fondo al mismo tiempo es como no pisar ninguno de los dos, y pisar mucho el acelerador y un poco el freno es como pisar el acelerador pero no tan a fondo... ¡Bravo!

Yo tengo un volante multisitema de ThrustMaster/Gullemot (como el tuyo en ese sentido), un volante con licencia Ferrari que encontré muy barato nuevo. Compatible con PS1 y PS2 por conector clasico; PS3 y PC por USB; GC y Wii por conector de GC.
Aparte de que tiene una deadzone brutal que dificulta hasta la practica imposibilidad cualquier movimiento de precision, tambien tiene lo de los pedales a analogico, claro que, en GC, los mapean a los deslizadores laterales, lo cual es muy adecuado, dado que son independientes el uno del otro.
Tiene funciones de remapeo, pero no estoy muy seguro de cuantos problemas se pueden solucionar de esa manera.

cegador escribió:Lo comenté meses atrás en el hilo:

La consola se me reinicia a los pocos segundos y seguramente es el adaptador a corriente. He buscado en tiendas físicas pero nada Lo que he encontrado es en aliexpress a 7 euros y en amazon se pone a 12-15€ con el envío...

Son copias chinas y no sé cómo andarán de calidad... en las fotos las conexiones tienen mala pinta los acabados:



Como toda la calidad sea así, da muy mal rollo.

Al lío:

¿alguien de Barcelona podría prestarme su adaptador para asegurarme que el fallo está ahí?

Cuando me venga el mío chino lo probaré en la mía. Para más señas me compré a la vez el transformador y cable video para ver si funciona así que en un par de semanas te digo.

@Zardoz2000 Al final me compré uno en amazon, (es chinorri igual) pero la calidad del plástico se ve mejor que la de las fotos. Funciona correctamente.

A ver cuánto dura.

Conker64 escribió:Ya estoy por aquí, necesitaba un descanso

Creo que ahora si podré dedicar más tiempo a los aportes, pero solo me centraré en el hilo de MD y en éste.

PD: Me gusta el nuevo nick

Ya creíamos que no te íbamos a volver a ver, nos has pegado un buen susto.

Que no vuelva a pasar

@Conker64 te echábamos en falta camarada

@EMaDeLoC mira quien ha vuelto.

@Conker64 Bienvenido de vuelta, se te echaba de menos

Zardoz2000 escribió:Gracias a todos. Dios proveerá y seguro que encuentro algo asequible por ahí y más si ya sé lo que comprar. Últimamente me estoy haciendo con más artículos en los sitios más insospechados y cada vez me estoy dando cuenta de la utilidad de tener un amplio stock de cosas (mandos, memorias etc) por si las necesitase.

No me voy a gastar 20 euros en un mando de una Xbox clásica sin nisiquiera poseerla pero si la viese en la caja de artículos de 1-2 euros de un rastro me haría con una sin duda. Por poner un ejemplo poco antes de tener la 360 tuve la oportunidad de comprar juegos de Xbox a 1,5 euros (el primer Halo etc) y pasé. Después me arrepentí porque me compré la 360 y no pude aprovechar su retrocompatibilidad.

Haces bien, yo me di cuenta de eso mismo hace unos 3-4 años y desde entonces tengo todo redundante: de varias consolas tengo varias fuentes de alimentación oficiales, tengo de todas los cables de vídeo varias veces (tipo 3 cables de compuesto, 2 RGB, 2 componentes etc) y siempre tengo varios mandos, de N64 tengo 6, de GC tengo 7, de SNES tengo 5... por si acaso Lo mismo para Wii.
Siempre es bueno que en cosa de cables, accesorios etc. tengas unos cuantos, no tienes que tener 20, pero si usa tarjetas de memoria pues ten 3 o 4, por ejemplo, cargadores/fuentes ten siempre al menos una de respaldo por si muere la que estás usando etc.


Un saludo

Conker64 escribió:Ya estoy por aquí, necesitaba un descanso

Creo que ahora si podré dedicar más tiempo a los aportes, pero solo me centraré en el hilo de MD y en éste.

PD: Me gusta el nuevo nick

Rebienvenido.
El nuevo nick es más fácil de recordar que el anterior. Siempre tenía que mirarlo antes de escribir nada cuando te mencionaba porque temía dejarme alguna letra o colar alguna donde no debía, jeje.

@Conker64 bienvenido crack

De momento no podré aportar mucho hasta que pueda poner imágenes, pero tengo que ponerme al día en algunas cosas, el nick sí, llevaba tiempo con ganas de cambiármelo

@Conker64 Ahora es cuando nos cuentas cómo te emborrachaste, te perdiste, te corriste mil aventuras intentando volver a casa, perdiste a tu novia en el espacio y te hicieron rey contra tu voluntad.

¡SPOILERS!

ejem... que digo que bienvenido, y vaya susto diste, macho.

Bienvenido @Conquer64, se te echaba en falta por aquí, al fin y al cabo es tu hilo!

Lol ojalá tuviera historias que contar

No sé si se puso hasta ahora pero dejo la música de los trailers promocionales VHS del Zelda, en descarga.

A ver probando vídeos.. vale, parece que sí, Vigilante 8 es un título interesante y se mueve muy suavecito, aunque está sacado por RCA se aprecia que no texturiza las montañas del fondo, usa color goraud, con lo que consigue un poco más de fillrate disponible.

Vamos hace como los Spyro de PSX y no me acuerdo del nombre de un juego protagonizado por Bugs Bunny también de PSX.
¿Y es posible que lo use también el Star Wars : Battle of Naboo en los exteriores pero no con tanta cercanía?

Salud.

@Conker64 Ya tenía fichadas esas dos, que llevan tiempo localizadas por "la comunidad internacional", y alguna mas, y otras que aun no he colgado. Debería hacerlo y mejorar un poco el hilo, que está bastante cochambroso tal como está actualmente:
hilo_musica-de-los-vhs-promocionales_2274330
Tengo la idea de ponerlos en descarga tambien, a modo de "album" o algo xD, pero tambien quiero ponerlos en video con algun fondo un poco vistoso para ver el interés que tienen y satisfacerme de ello...

Respecto a Vigilante 8, es un port de PSX, y la verdad es que se nota una vez que eres consciente de ello.
@dirtymagic Eso que dices del Spyro, aunque yo no he jugado a el, es muy acertado. Sin quitarle merito, la verdad es que es una formula muy de PS1. La primera vez que jugue a un V8, en alquiler y sin saber que provenía de PS1, sin quitar que me impresionó lo definido de los graficos, si que me llamó la atencion esa extraña distancia... de detalle (mas que distancia de dibujado). No es algo que se vea mucho en otros juegos de N64 y en mi opinion se debe sencillamente a que proviene de PS1.

@dirtymagic
Sí, como dice radorn es una técnica que no suele emplearse demasiado en N64, en Battle of Naboo según veo también la usan.

Las superficies afectadas por la niebla deben usar 2CYCLE, así que bueno todo lo que sea ahorrar un poco de fillrate es bueno, luego es de esperar que no hagan aparecer las texturas de golpe, sino que empiecen con alpha a 0 y gradualmente suban los 32 niveles de transparencia hasta sólido según distancia.

Es bueno ver un port de PSX donde conservan parte de sus optimizaciones, dejo de paso un texto que escribí hace tiempo de como funciona el fillrate en N64 y en PSX:

FILLRATE

PSX


SPRTx son sprites, donde x se refiere a la profundidad de color 4bit, 8bit, 15bit.

POLY_F3: son triángulos flat (3 puntos), POLY_F4: son rectángulos flat (4 puntos), flat es un único color para todo el polígono.

POLY_GT3: triángulo con sombreado goraud texturizado, se entiende.

Bien, PSX maneja 2D a 2 pixels por ciclo, los planos de scroll los puedes hacer con tiles y luego tienes a los sprites para el resto, con un pico teórico de 66 Mp/s.

No dice nada de sprites con zoom, con rotación, con semitransparencia ya vemos que tarda el doble del poly seleccionado.

El pico teórico es suponiendo que tienes el sprite en cache, PSX tiene 2KB de cache de texturas, ahí lo metes ahí lo dejas, es decir, si puede con 1000 sprites, va a poder con el mismo sprite 1000 veces, no quiere decir que vaya a poder con 1000 sprites distintos, porque tendrás que recargar la cache con cada nuevo, consumiendo ese preciado ancho de banda, eso también va para 3D, a mayor cambio de texturas peor rendimiento.

Una de las ventajas es la gestión automática, una página de textura donde puedes definir de cuantas piezas está formada y se puede usar en 1 sola superficie, en el caso de N64 se tiene que hacer de forma manual usando UV mapping con la función load block del RDP, creo que solo hay demos de ejemplo y no recuerdo si hay algún caso comercial.

N64
La consola tiene 4 modos: FILL, COPY, 1CYCLE, 2CYCLE.

FILL es el equivalente a POLY_F4/3, te pinta un rectángulo o un triángulo de 1 solo color, pero en N64 ésto solo suele usarse para limpiar el buffer de pantalla, porque FILL no usa Z-Buffer y no hay muchos motores con display lists, lo hace a 4 pixels por ciclo, lo cual daría un pico teórico de 250 Mp/s

COPY es el equivalente a SPRTx/Tile, te pinta un rectángulo con textura, con capacidades limitadas, puedes voltear vertical y horizontalmente el sprite, puedes incluso hacerle zoom verticalmente, pero eso es todo, COPY funciona a 4 pixels por ciclo igual que FILL, con lo que su pico teórico sería de 250 Mp/s.

Pero la realidad es que ninguno de esos datos se cumple, con FILL conseguí un rendimiento de 140 Mp/s en el último test, cerca de 100 Mp/s para COPY, pero esa es la grandeza de ir programando, poco a poco los resultados son mejores, pero nunca van a llegar a los teóricos.

Que quieres hacer un zoom 2X al sprite?

Tenemos que irnos a 1CYCLE, éste modo es especial porque prácticamente te da casi toda la funcionalidad de la maquina, filtrado de texturas, corrección de perspectiva, tintado RGB, máscaras, hasta semitransparencias cuasi gratuitas si comparamos lo que le cuestan a PSX, a 1 pixel por ciclo: 62.5 Mp/s.

Para rotar un sprite eso sí, hay que componerlo de 2 triángulos, como era de esperar va a ser más rápido poner 1000 sprites normales, que 1000 sprites rotando, pero eso pasa en todas las maquinas.

2CYCLE ya lo conocéis, pero es necesario activarlo para superficies afectadas por la niebla, trilinear, algunos efectos y superficies con 2 texturas claro.

En 2D no hay que lidiar con Z-buffer así que hay mucho más ancho de banda disponible.

El Z-Buffer es de 16bits, lo cual quiere decir que los objetos tienen de 0 a 65535 posiciones, pero en lugar de rellenarse con información de color se rellena con información Z, cuando N64 pinta una superficie si ésta lleva Z-Buffer se escribe 2 veces, una sobre el framebuffer obviamente, ahí escupe el color, la segunda comprueba si Z es superior en la nueva superficie para cada pixel.

Ahora ya no tenemos un fillrate de 62.5, sino de la mitad, 31 aprox., bien, éste es el motivo por el que no hay que usar Z-Buffer en todo, solo en algunas superficies, explosiones semitransparentes a pantalla completa? No por favor, no uses Z.

Por la forma en la que el RCP lee la memoria conviene tener el framebuffer y el zbuffer en distintos bancos de memoria, como en el EPAK, aumenta el rendimiento.

@radorn
Anda, llevaba tiempo buscando ésta, como la encontraste?

Conker64 escribió:Ya estoy por aquí, necesitaba un descanso

Creo que ahora si podré dedicar más tiempo a los aportes, pero solo me centraré en el hilo de MD y en éste.

PD: Me gusta el nuevo nick

Bienvenido de nuevo.

@radorn ¡He encontrado un juego compatible con los pedales del volante! ¡Se puede configurar!

El juego es "California Speed", de MIDWAY:



Se deja jugar, pero poco más. No es muy emocionante aunque con el volante aumenta la dificultad exponencialmente.

Sigo a la búsqueda de más juegos de coches con controles configurables.

@Conker64 Bienvenido a casa

Uf, que mono tenía de datos técnicos de la consola...

Conker64 escribió:PSX

POLY_F3, POLY_F4, SPRTx, TILE primitives: 2 pixel/cycle - 66 Megapixels/second.

POLY_G3, POLY_GT3 (texture is on cache!) 1 pixel/cycle - 33 Megapixel/second.

When semitransparency is used, the raw speed is halved, for example a POLY_G3 abr id 0.5 pixel/cycle - 16 Megapixels/second.

LoadImage transfers with 33 Mhz*4 bytes per sec, so it can attain speeds up to 132 MBytes/sec. However, when the CPU accesses the main bus, it stops the LoadImage!. (So stay on I and D cache!).

Conker64 escribió:Ahora ya no tenemos un fillrate de 62.5, sino de la mitad, 31 aprox., bien, éste es el motivo por el que no hay que usar Z-Buffer en todo, solo en algunas superficies, explosiones semitransparentes a pantalla completa? No por favor, no uses Z.

Bueno, no te ofendas pero a efectos prácticos esos datos no son nada válidos.
No es que sean falsos, lo que pasa es que los benchmarks de las compañías son en inmejorables condiciones. Según leí por ahí, en PSX los datos es con un triángulo de tamaño medio en mitad de la pantalla, y en N64 creo que pone el manual de desarrollo que es en base a un rectángulo grande, en ambos casos usando solo una textura.

En la práctica en PSX tomando de ejemplo Motorhead a 60fps y 320x240 de resolución, son 4'6Mpx/s, pero tiene bastante niebla ese juego y posiblemente ahorre fillrate de alguna parte. Aparte a 60fps solo puedes tener dos contrincantes lo que significa que la PSX se queda corta de CPU.
En N64 tomando Ocarina of Time NTSC a 20fps y 320x237 de resolución, salen 1'5Mpx/s, pero es un juego con un uso intensivo de 2CYCLE así que debería ser 3Mpx/s. F-Zero a 60fps y 296x208 nos saca casi 3'7Mpx/s. Curiosamente World Driver Championship se queda en los 2Mpx/s y pico. Son cifras más bajas que en PSX, pero considerando el cuello de botella de la memoria no son tan malas.

Obviamente esto es en pleno in-game con las consolas haciendo otras tareas. Si solo tuvieran que dedicarse a la tarea de dibujado el fillrate debería ser más alto.

Y ahora dos preguntillas:
Por lo que cuentas, el modo 2CYCLE y el z-buffer se puede activar por polígono y no en toda la pantalla. Creía que o lo activabas para todo o no lo activabas. ¿O lo he entendido mal?
¿No se usa el z-buffer para la niebla? ¿Seguro que se usa 2CYCLE? Pensaba que la niebla se hacía con solo 1CYCLE y apoyandose en el z-bufer para modificar el color del pixel.

Como curiosidad, la forma en la que Majora's Mask usa el z-buffer para generar el efecto de la Lente de la Verdad (Lens of Truth):


http://gliden64.blogspot.com/2016/12/depth-buffer-emulation-ii.html

Traducido toscamente por mí:
Copia de buffer de profundidad. 'The Legend of Zelda - Majora's Mask' usa varios trucos de frame buffer. Un truco esta relacionado con la Lente de la Verdad (Lens of Truth). Cuando esta activada, muestra objetos ocultos. ¿Cómo funciona? Primero, la mayoría de los objetos visibles se renderizan de forma normal. Cuando todo esta listo, el juego copia el buffer de profundidad a otro sitio. El nuevo buffer de 16bits de color es situado y el buffer de profundidad es renderizado en el como una textura, usando el comando BgCopy. Entonces el juego renderiza el rectángulo texturizado a pantalla completa con la textura de la Lente. Ese rectángulo tiene una profundidad mínima, así que todo el buffer de profundidad debería rellenarse con MIN_Z. Sin embargo, el círculo de la lente tiene alfa cero, así que todos sus píxeles son descartados por comparación alfa y el buffer de profundidad dentro de la Lente queda intacto. Ahora el juego renderiza los objetos "ocultos". Estos objetos descartados por profundidad se comparan fuera del círculo de la Lente. Por cierto, cualquier textura "bonita" de la Lente en paquetes de texturas rompe la funcionalidad de la Lente: el círculo de la Lente debe llenarse con transparencia. Cuando se completa el renderizado de los objetos "ocultos", el juego copia el bufer de profundidad desde el bufer temporal al bufer de profundidad (por defecto), que restarua su estado en el momento antes del dibujado de la textura de la Lente. Ahora el resto de la geometría, la cual debería estar sobre la Lente, puede renderizarse. Por ejemplo, los copos de nieve (show es un gazapo).

Es un poco galimatías, pero viene a decir que se usa el Z-buffer para crear el efecto de la lente y los objetos invisibles del Majora's Mask.

@EMaDeLoC
Claro, son datos teóricos:

FILL teórico 250MP/s
TEST FILL - 140MP/s
COPY teórico 250MP/s
TEST COPY - 100MP/s

Estos tests son "a lo máximo que alcance" sin hacer nada más, aunque el enfoque que les dí fue desbloquear el framerate lo cual no es del todo preciso, es decir no es lo mismo que el programa corra a 1000 fps y de ahí calcules el fillrate, que hacerlo correr a 60fps pintando X pantallas a la vez, el segundo son muchos menos ciclos.

En la práctica en PSX tomando de ejemplo Motorhead a 60fps y 320x240 de resolución, son 4'6Mpx/s, pero tiene bastante niebla ese juego y posiblemente ahorre fillrate de alguna parte. Aparte a 60fps solo puedes tener dos contrincantes lo que significa que la PSX se queda corta de CPU.
En N64 tomando Ocarina of Time NTSC a 20fps y 320x237 de resolución, salen 1'5Mpx/s, pero es un juego con un uso intensivo de 2CYCLE así que debería ser 3Mpx/s. F-Zero a 60fps y 296x208 nos saca casi 3'7Mpx/s. Curiosamente World Driver Championship se queda en los 2Mpx/s y pico. Son cifras más bajas que en PSX, pero considerando el cuello de botella de la memoria no son tan malas.

Como sacaste esa info?

Es muy difícil que un juego pinte 1 sola pantalla por frame en 3D, en PSX suelen usar pequeños bloques para componer el escenario, en N64 los motores para manejar todo a lo bruto aún estaban muy verdes y se pintaban superficies enteras que quedaban tapadas por otras.

Para saber cuanto han pintado hay que calcular todas las superficies que existan en pantalla, ej. aquí se lía parda, ves todas esas antorchas con luz? Cuando te acercas todas esas luces se hacen gigantes a la vez, 1 sola superficie de luz según distancia podría ser del tamaño de casi 1 pantalla.
https://i.imgur.com/alACLH7.jpg

Por lo que cuentas, el modo 2CYCLE y el z-buffer se puede activar por polígono y no en toda la pantalla. Creía que o lo activabas para todo o no lo activabas. ¿O lo he entendido mal?

Tienes que reservar un hueco de memoria para el Z-Buffer, que equivale al tamaño de pantalla, es decir ocupa lo mismo que el framebuffer, esa memoria la dejas permanente, luego por superficie decides en que modo trabaja el RDP, si usas Z-Buffer le pasas el puntero de memoria del buffer, ahí la consola compara y pinta Z, si no lo usas pues nada, no le pasas el puntero y no añades z-buffer en set other modes para esa superficie.

Si pintas con Z activado es como si pintaras 2 veces, una el color, otra la info de Z, por eso el fillrate se divide.

¿No se usa el z-buffer para la niebla? ¿Seguro que se usa 2CYCLE? Pensaba que la niebla se hacía con solo 1CYCLE y apoyandose en el z-bufer para modificar el color del pixel.

Sí, es conveniente, si quieres usar el comando fog nativo de la consola la mayoría de superficies requieren 2CYCLE, hay alguna excepción donde puedes usar 1CYCLE, pero nada te impide crearte tu propio algoritmo para niebla, como en PSX, el Z-Buffer es para que atraviesen la niebla, de lo contrario solo pueden verse por delante o por detrás.

@Conker64 Me leeré lo del fillrate, que me interesa bastante.

Respondiendo a tu pregunta sobre la musica del trailer de N64:



@cegador ¡Excelente! Sigue sin gustarme lo de tener freno y acelerador en un mismo eje, pero es bueno que haya juegos donde puedas usar esa característica, sin duda. Tengo que ver si my V3 tambien puede configurarse así y que tal chuta.
Si Californa Speed va, deberías probar los 3 juegos de la saga RUSH (San Francisco RUSH, RUSH 2 Extreme Racing USA, y San Francisco RUSH 2049), y posiblemente los Cruis'n (USA, World, Exotica) y el Off-Road Challenge, que es como un Cruis'n pero con todoterrenos y pistas de tierra y tal.

De hecho, permiteme hacer una lista



Y mientras escribía esto (y hablaba por telefono y rebuscaba varias cosas ), @Conker64 y @EMaDeLoC habeis añadido mas cosas... ¡que falta de consideración!

Conker64 escribió:Como sacaste esa info?

La de PSX es resolución estandar, no creo que el Motorhead vaya a menos resolución y su framerate es muy estable.
Las resoluciones de N64 son las que aportaste al principio del hilo.
Luego he multiplicado los píxeles de resolución por los fps. Se que es un cálculo muy tosco pero acumulando datos se hace una media. Pero si me dices que PSX lo hace por bloques, la N64 pinta de más y que "pintar" el Z-buffer cuenta como pixel, se pueden tirar mis cálculos a la basura.

Entiendo por lo que explicas que el fillrate son los píxeles pintados de cada polígono, y se incluyen tanto los visibles como los que no.
Me he liado bastante con el concepto de fillrate.

@radorn Uoohh

Pedazo de lista te has currado, me lo has puesto fácil

Los Cruis'in que he probado no te dejaba modificar los controles.

Algunos de los que me has recomendado también los probé y nada.

Ya iré comentando mis avances.

@radorn
Vaya historias , me miraré el hilo

@EMaDeLoC
Creo que en esa generación sería normal ver entre 3-6 pantallas por frame (sumando superficies hasta contar pantallas), dependiendo del tipo juego, del momento, etc

@cegador
Esa lista es basicamente cómo tengo organizada mi carpeta de juegos de carreras en la SD del "ROMtucho", con un par de modificaciones para revertir un par de manías personales a algo mas "estandar", y, aparte, la de "combate vehicular", y luego los extras.

He puesto todos, aunque algunos ya se de memoria que no va a ser posible y otros calculo que tampoco, pero bueno, así me aseguro de no dejarme ninguno por el camino.

¿Has descartado ya todos los RUSH? No se el 1 y el 2, pero el 2049 creo que tenía muchas posibilidaddes de configuracion y me suena de que si podría ponerse el stick para eso... o quizá era para el control de planeo... hmmm he recordado eso mientras escribia y me temo que la respuesta es que tampoco va a valer para pedales analogicos

@Conker64 Tal como está el hilo en este momento, la verdad es que no hay demasiado que ver. Tengo que preparar los materiales que he recopilado y pedir que lo desarchiven para actualizarlo como es debido.
Incluso debería contar mis "secretos" para encontrar estas cosas a ver si mas gente se anima a rebuscar.

Alguna tienda online donde pueda encontrar el Expansion Pack sin que me sangre la billetera?

cuervoxx escribió:Alguna tienda online donde pueda encontrar el Expansion Pack sin que me sangre la billetera?

Eso es mas para el hilo general, creo yo hilo_hilo-oficial-nintendo-64_2275957

OPTIMIZANDO EN TEXTURAS

Los juegos de nintendo 64 como sabeis usa texturas de multiplos de 2 en ocarina of Time que es donde hablo no hay excepción

En especifico (aunque es poco lo que hay ) el juego utiliza de 4 tipos

1ºTextura normal 32x32,64x32(bien usado) 32x16, 8x16 etc hasta 64
Para ahorrar en el funcionamiento del juego, a la hora de trabajar si usamos siempre texturas tal cual de las mediciones arriba (en RGB) la consola se quedaria un poco seca

2ºTextura indexada: este usa para texturas de poca carga pero abarcan un gran espacio por ejemplo los suelos de hyrule ya que son verde y amarillo (quitando la multitextura) y tambien para alpha

3ºTextura escala de grises: este se usan de dos maneras .
1 para hacer telarañas y texturas que requieran solamente estos dos colores
2º para añadir algo de profundidad a las texturas mediante la multitextura

4ºColores Hexadecimales:
¡Comandante nos quedamos sin espacio!,¿Que?,Dejad al profesional
La siguiente manera es hacer que los ropajes y ciertos lugares no fueran texturas sino colores simplemente con vertices coloreados

Las tunicas de link son colores hexadecimales, la de los ciudadanos

Tambien hay texturas animadas como lo es las gotas de agua en los agujeros

En majora mask lo mejoraron algo y añadieron SFX(efecto de sonido)

Posiblmente esto se haya repetido

Por cierto @Conker64 bienvenido devuelta colega

Cómo queréis que se enfoque el hilo? Más aportes de juegos y curiosidades para que la lectura sea menos espesa? Intercalar con datos técnicos? Ej. primera página del hilo vs las que fueron saliendo tras la libdragon.


Dato:
Tengo datos de rendimiento oficiales que creo que aún no se han dado, benchmarks específicos, no datos teóricos, pero esperaré a tener imágenes para ilustrarlos correctamente.

Novedad:
Están empezando a reemplazar uCodes dentro de algunos juegos, el objetivo es mejorar el rendimiento, el primero para variar es Super Mario 64, ya iba el 95% del tiempo a 30fps, la cosa sería ver si mejora en Jolly Roger Bay por ejemplo, me tienen que pasar aún la rom pero la cosa pinta bien.

Conker64 escribió:Novedad:
Están empezando a reemplazar uCodes dentro de algunos juegos, el objetivo es mejorar el rendimiento, el primero para variar es Super Mario 64, ya iba el 95% del tiempo a 30fps, la cosa sería ver si mejora en Jolly Roger Bay por ejemplo, me tienen que pasar aún la rom pero la cosa pinta bien.

¡Ostia puta! ¿Donde se cuece eso?

Conker64 escribió:Cómo queréis que se enfoque el hilo?

Yo voto que... si a todo. Por mi, lo que mas te motive a ti. xD
Una ayuda inestimable la mia, lo sé.

@Conker64 +100
A todo.

Conker64 escribió:Tengo datos de rendimiento oficiales que creo que aún no se han dado, benchmarks específicos, no datos teóricos, pero esperaré a tener imágenes para ilustrarlos correctamente.

@Conker64
Cualquier cosa que puedas aportar va a ser alucinante igualmente así que no te cortes.

Me intriga lo último que has comentado de los uCodes. Nunca me había planteado que eso fuese posible. Creía que el juego se diseñaba con el microcódigo como base y que para utilizar otro distinto habría que rehacer el juego de cero. ¿Significa esto que se podrían crear nuevos microcódigos y "transformar" los juegos comerciales? Necesito roms jugables.

@Sogun Los microcodigos del RCP son realmente programas de muy bajo nivel (mas bajo que ensamblador normal, a nivel de la microarquitectura especifica, de ahi el nombre) que la CPU envia a una cache cache especial del RCP (o RDP y RDP especificamente) y desde ahí se ejecutan, procesando los displaylists que se le indiquen. Mientras el microcodigo modificado siga aceptando los displaylists o audiolists que el motor del juego que se ejecuta en la CPU produce, puedes cambiarlo, claro que si. Que no se haya hecho hasta ahora responde a la complejidad de la tarea y otras circunstancias de la scene.
Yo ya habia fantaseado con estas cosas hace bastante tiempo. De hecho, viejas historias repetidas por internet durante años afirman que, durante desarrollos oficiales, muchos desarrolladores inicialmente usaban microcodigos mas ligeros, sin tanta "calidad" (menos filtrados y menos precision, basicamente, acercando los resultados a los de PS1 y SAT), pero que Nintendo no permitia esos microcodigos en las versiones finales, así que luego había que aplicar el microcodigo "bueno" y optimizar ahí. A estas alturas no se cuanto de verdad habrá en esto.
La cuestion es que a nivel de scene, debido, me imagino, a la falta de mas recursos (tiempo y "haqueros" interesados, en otras palabras), hackear los microcodigos estaba lejos de ser una prioridad y siempre tuvieron un aura de algo inalcanzable.
Ahora que hay mas librerias de programacion y gente dedicandose a hackear el hardware a bajo nivel, es "natural" que empiece a haber gente metiendose con los microcodigos, "la ultima frontera" de N64.

Estoy emocionado como un colegiala en un concierto de Justin Bieber, o el mariquita quien esté de moda ahora

@Conker64 si te pasan ROMs de prueba o hay algun sitio publico donde ver estas cosas, por favor, rulalas. Yo estoy desconectado de la scene desde hace mucho tiempo por lamentables circunstancias personales.

@radorn
Pues me lo han comentado en el IRC de N64, que hacía como 1 mes que no entraba.. a ver si alguno se estira y me manda alguna rom para probar

Lo de los benchmarks oficiales va a estar interesante:
- Se desvelan cambios en el clock del RCP antes de ser la maquina lanzada
- Datos exactos de sprites y fillrate
- Datos exactos de polígonos y cual fue el tamaño para las mediciones
- Datos exactos en sonido

He comparado con mis tests y encajan los resultados.

@Sogun
Hay un programa que pasa el Fast 3D del SM64 a F3DEX y del Banjo, pero sirven más bien para hacer modelados compatibles y cosas similares, lo nuevo que están haciendo según me comentaron es para aumentar el rendimiento.

Hablando de microcodigos, tambien me comentó marshallh hace meses que hay alguien trabajando en un emulador de SNES para N64 que utiliza microcódigo en el RCP para emular la PPU. Había algo en un repositorio en github, pero ahora no lo encuentro. De todas formas no había nada realmente jugoso que echarse a la boca, mas que un ejemplo de ROM que mostraba una imagen en pantalla, cuya gracia está en que se supone que se está mostrando a traves de esa emulacion de la PPU, procesando las baldosas/celdillas/tiles. Era una imagen generica de un paisaje playero tropical o algo así...

EDITO: Encontrelo https://github.com/PeterLemon/N64/tree/master/EMU parece que hay alguna ROM en los subdirectorios. Yo solo recuerdo haber probado una en su momento. Curiosos, rebuscad.

Conker64 escribió:[beer]

Cómo queréis que se enfoque el hilo?

No le haría ascos a leer algún debate de quienes conoceis el hardware de la n64, sobre cuales son las espectativas de su futuro rendimiento.

Con eso de los cambios en el clock del rcp me he quedado con la intriga de a que se refiere.

@radorn
El github de Krom

@Señor Ventura
Qué tipo de espectativas? Con respecto a los juegos?

Conker64 escribió: @Señor Ventura
Qué tipo de espectativas? Con respecto a los juegos?

Si, tus impresiones personales con respecto a lo que está por venir. Como referencia a los demás nos serviría de mucho, desde el punto de vista de que no estamos al tanto de los avances de algo tan privado como esta scene.

Yo aventuro a pensar que debido a la paranoia de Nintendo de abaratar costes, el RCP iría más rápido, posiblemente a los mismos Hz que la CPU, pero el exceso de calentamiento a la larga conllevaría el usar una disipación de calor más potente y cara o inclusivo a pasar a la disipación activa (ventilador), lo que disparaba el coste. Con la bajada de 30MHz respecto a la CPU se sacrificaba mucho rendimiento pero la disipación se quedaba en un simple taco de aluminio ultrabarato.
Puede que me equivoque, pero teniendo en cuenta que los Pentium solo necesitan disipación pasiva pequeña y la RAM del expansión pak también poca disipación, la mayor fuente del calor sea el RCP, algo lógico al procesar más cosas.

EMaDeLoC escribió:Yo aventuro a pensar que debido a la paranoia de Nintendo de abaratar costes, el RCP iría más rápido, posiblemente a los mismos Hz que la CPU, pero el exceso de calentamiento a la larga conllevaría el usar una disipación de calor más potente y cara o inclusivo a pasar a la disipación activa (ventilador), lo que disparaba el coste. Con la bajada de 30MHz respecto a la CPU se sacrificaba mucho rendimiento pero la disipación se quedaba en un simple taco de aluminio ultrabarato.
Puede que me equivoque, pero teniendo en cuenta que los Pentium solo necesitan disipación pasiva pequeña y la RAM del expansión pak también poca disipación, la mayor fuente del calor sea el RCP, algo lógico al procesar más cosas.

¿Entonces es cierto?, ¿la N64 puede funcionar con el RCP a mas frecuencia?.

Señor Ventura escribió:

EMaDeLoC escribió:Yo aventuro a pensar que debido a la paranoia de Nintendo de abaratar costes, el RCP iría más rápido, posiblemente a los mismos Hz que la CPU, pero el exceso de calentamiento a la larga conllevaría el usar una disipación de calor más potente y cara o inclusivo a pasar a la disipación activa (ventilador), lo que disparaba el coste. Con la bajada de 30MHz respecto a la CPU se sacrificaba mucho rendimiento pero la disipación se quedaba en un simple taco de aluminio ultrabarato.
Puede que me equivoque, pero teniendo en cuenta que los Pentium solo necesitan disipación pasiva pequeña y la RAM del expansión pak también poca disipación, la mayor fuente del calor sea el RCP, algo lógico al procesar más cosas.

¿Entonces es cierto?, ¿la N64 puede funcionar con el RCP a mas frecuencia?.

Probablemente, pero te cargas la compatibilidad con los juegos actuales, que dependen, en muchos aspectos interrelacionados, de las frecuencias originales.
Incluso el OC de la CPU mediante cambio de multiplicador (1x, 1.5X, 2X, 3X) pone muchos juegos como si fueran una escena de persecucion de jamonas de Benny Hill.
Si aceleras el RCP probablemente te cargues la sincronizacion de video, provoques una gran inestabilidad, o directamente casque el software.
Probablemente se podría hacer OC a muchas cosas de N64, pero solo valdría para software nuevo especifico para esas nuevas frecuencias o reconvertido (una tarea manual juego por juego)

@Señor Ventura
En 2D superior a Neogeo, ej. los Metal Slug podría correrlos a 60fps sin caídas, eso lo puede hacer una sola persona desde su casa, incluso con la actual libdragon, con expansión mucho mejor.

En 3D por lo pronto, muchos de los juegos comerciales que rascaban, creo que podrían ir a 30fps más estables con un poco de optimización.

No sé si se llegarán a ver cosas potentes porque hace falta un equipo y tiempo, si alguien decidiera hacer un kickstarter con presupuesto en N64 sí, ya solo con la evolución que han sufrido los engines 3D se notarían mejoras en los juegos.

En datos brutos el RSP podría calcular mucho más rápido la geometría y dejarle más tiempo al RDP para pintar más, la CPU también funciona mucho mejor al compilar con GCC 8.x.

No me estoy enterando exactamente bien de lo que se habla ¿Vamos a poder jugar a 30fps en hardware real varios juegos? o ¿Para jugar a 30fps dichos juegos hay que hacer un OC al RCP?

Señor Ventura escribió:¿Entonces es cierto?, ¿la N64 puede funcionar con el RCP a mas frecuencia?.

A ver, te has confundido de terminos y yo no me he explicado bien.
Cuando Conker64 hablaba de los cambios de reloj del RCP antes de lanzarse la máquina yo he supuesto que se tratan de cambios mientras se desarrollaba el hardware y hacian los ajustes necesarios entre algo que funcionase bien y se ajustara a los costes de fabricación tan limitados por Nintendo. Teniendo en cuenta que la diferencia de 1.5x entre reloj de CPU y RCP no tiene mucho sentido, ya que has de meter otro multiplicador de reloj, ajustar circuiteria para que funcionen a frecuencias distintas, etc mi teoria es que el calentamiento del RCP era un problema serio que o bien se solventaba mejorando mucho la disipación, o bajando la velocidad hasta un nivel adecuado entre ahorro y rendimiento.
Aún cuando se hubiesen decidido por mejorar la disipación igual el tener una consola cara, ruidosa y emitiendo calor cual radiador en invierno no les parecía un buen punto de favor a Nintendo.
El caso es que no es lo mismo las especificaciones de reloj antes de dar por finalizado el hardware, que hacerle overclock posterior ya que en este último caso te cargas las especificaciones originales que usaban los desarrolladores para realizar los juegos, y por tanto podían producirse bugs.

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...

Calculinho escribió:No me estoy enterando exactamente bien de lo que se habla ¿Vamos a poder jugar a 30fps en hardware real varios juegos? o ¿Para jugar a 30fps dichos juegos hay que hacer un OC al RCP?

Se habla de hackear algunos juegos para cambiarles los microcódigos por otros más ligeros u optimizados y mejore su rendimiento. El OC no sería necesario, es un tema aparte.

@EMaDeLoC mi flashcard is ready