Hilo de detalles y curiosidades de N64

158, 59, 60, 61, 62, 63
Calculinho
MegaAdicto!!!
7.213 mensajes
desde ene 2010
en Galicia
Hoy le ha tocado el turno de nuevo a Hydro Thunder y buscando diferencias entre versiones (las cuales a nivel contenido no he encontrado por si alguien quiere aportar algo) he visto este vídeo sobre gráficos del juego en PSX-N64-DC en consola original. Los resultados son los esperados, la de PSX es la que peor luce al notarse bastante el pixelado aunque tiene pinta de funcionar fluidamente, el de N64 es bastante mejor y creo que se acerca bastante a la de DC para ser una consola menos potente.

Dicho esto a modo de introducción, me he dado cuenta de una cosa en la que gana la de PSX que me parece curiosa y es que en los saltos grandes al caer, el agua en las versiones de N64 y DC al intentar jugar con el efecto reflejo literalmente se convierte en un espejo; pero el efecto es chungo porque parece que caes al vacío sin saber cuando tocarás "suelo", en la de PSX hay reflejo, pero será por el "ensuciado" pixelado se ve donde caes. En el vídeo dejo un momento donde va mostrando una caída en las tres versiones:
https://youtu.be/F05QxlNWGGk?t=5m6s

En el resto del vídeo hay más saltos, por si queréis buscarlos.
Sogun
MegaAdicto!!!
691 mensajes
desde jul 2009
Editado 1 vez. Última: 1/10/2017 - 12:25:12 por Sogun.
Hay algo muy raro en ese vídeo.

Recordaba del Hydrothunder que es un juego que tenía un look muy PS1 en N64 por usar colores muy vivos, dientes de sierra muy evidentes y un framerate muy fluido que parece que a veces supera los 30 fps (Otro ejemplo sería el SCARS). Sin embargo en ese video se ve la versión de N64 muy apagado, y lo que es peor, es leeeeenta. Un rápido vistazo al contador de segundos nos hace ver que las partes de N64 están ralentizadas. Quizás porque realmente el juego va a más de 30 fps y al realizar el vídeo se muestran todos los frames a 30 imágenes por segundo. Otra cosa que no se aprecia en el vídeo es que seguramente la versión de Dreamcast funciona a 60 fps como rocas. Por cierto, que la versión de PS1 sufre un tearing brutal y muy molesto que, combinado con un bajo framerate, hace daño a la vista (no sé si será cosa del vídeo o es que el juego realmente es así).

He encontrado otro vídeo en el que se compara la versión de PS1 emulada en PS3, con la versión de PS2 (que según parece es igual que la de la Dremcast, aunqué quizás a menor resolución) y la de N64 y también está ralentizada. Voy a tener que jugar al juego para comprobarlo.

Dejo otro vídeo donde se ve lo que yo recuerdo, pero que al estar capado a 30 fps no se pueden apreciar las partes que digo que parece que supera esa tasa. Ya digo, jugaré un poco y editaré con las impresiones.

EDIT: Pues a mí también me va el contador de tiempo ralentizado jugando en un Everdrive PAL con la rom NTSC, me pregunto si está relacionado aunque no he tenido este problema con ningún otro juego. En emulador corre a la velocidad correcta, y funciona entre 25 y 30 fps según Glide64...
Fortunachan
Adicto
406 mensajes
desde dic 2013
Se que hay una versión de pc, pero no he podido dar videos de calidad, de lo que se, es que es mas superior que la de ps1
john D9
Novato
21 mensajes
desde jun 2017
Ya se extrañan los post informativos de @BMBx64
Sogun
MegaAdicto!!!
691 mensajes
desde jul 2009
Han liberado una beta del The World is not Enough. No conozco mucho del juego así que no sé los cambios que ha habido. En el enlace hay imágenes:

https://www.obscuregamers.com/threads/the-world-is-not-enough-twine-beta.22674/
BMBx64
Adicto
261 mensajes
desde may 2016
Editado 2 veces. Última: 11/10/2017 - 00:41:07 por BMBx64.
He estado probando la beta del TWINE [360º]

Quizás lo más interesante es el menú debug que trae, por fin se pueden desbloquear todos los niveles libremente, también tenemos contador de fps y el poder usar todas las armas, aunque no hay muchas para elegir en este build, los misiles por otra parte pueden bloquear la consola, yo creo que merece la pena tenerla, he notado bastantes cambios y eso que no me conozco demasiado el juego.
Imagen

El contador de fps es interesante, el juego corre a 30fps y generalmente lo consigue en muchas zonas salvo que el escenario sea abierto.
Imagen

El modo hi-color supone una limpieza de pantalla, a costa de 6fps de perdida de rendimiento, el juego va limitado de fillrate como la mayoría de juegos de N64, existe un modo hi-res que no sé exactamente que hace, se ve como el modo low-res pero consume los fps del hi-color, quizás solo sea alguna clase de escalado, no es de extrañar que ese invento raro lo sacaran o no me parezca recordarlo en la versión final.
Imagen

El juego usa triple buffering, no va pegando saltos tan bruscos de frame en comparación con el double buffer y en general es bastante suave, habría que averiguar si esto pasa al usar Expansion pak o sin ella, si jugamos en low-res lo más probable son cifras entre 20-30fps, en hi-color le descontamos 6fps a ese cálculo.
Imagen

Vale, este escenario quería verlo en consola, algo horrible del modo low-res es que por alguna razón usan random filter, si dejas el mando y miras la imagen verás puntos aleatorios semitransparentes por toda la pantalla, no sé que sentido tiene esto salvo que piensen que estamos cerca del pueblo de Silent Hill.
Imagen

--
He estado hablando con Krom sobre la idea que tenemos de hacer una librería libre y hay algunas novedades.

Por ejemplo ha conseguido procesar 8 triángulos por ciclo usando la VU dentro del RSP, resulta que libultra también hace uso de la VU pero no usa toda su capacidad, en el caso de libultra son 2 triángulos por ciclo y cálculo libre para otras tareas, por ejemplo Factor5 usa cálculo en la VU para sus librerías de sonido (MusyX).

El test escrito en ASM sobre los 8 triángulos por ciclo puede encontrar aquí.
https://github.com/PeterLemon/N64/tree/master/RSP/XBUS

Algo a destacar es que es un test usando XBUS, que es esto?

Para mandar comandos al RDP se puede hacer de 2 maneras, los escribes en una región de la RAM y el RDP lee de ahí, como hace ahora mismo la libdragon o el RSP se lo pasa directamente al RDP, ambos están en el mismo chip, por un bus mucho más rápido, así que este es otro terreno donde se ganará velocidad en la librería final que usemos.

Otro detalle, dado que la CPU de N64 tiene una FPU en realidad ya se podría hacer 3D con ella, saltándose completamente el RSP y pasando los cálculos directamente al RDP, aunque dado que los 3 chips pueden trabajar en paralelo estaríamos perdiendo mucho potencial.

Algo importante es que la maquina tiene potencia de cálculo de sobras, pero donde falla es en el fillrate, esta imagen es un ejemplo de lo que pasa en muchos juegos, he grabado un pequeño gif donde miro a una pared y luego giro la cámara hacia la derecha, igual no se ve muy suave en el gif, pero donde la consola sufre es mirando a la pared y no a partes más complejas del escenario.
Imagen

A partir de la palmera y brillo de sol son 30fps constantes, lo cierto es que parece que muchos engines antiguos no eliminan las zonas tapadas por polígonos más grandes, por ejemplo esa pared gigante debería evitar que se procesara lo que hay detrás, como se ve, el barco, la montaña y casi que todo el resto del nivel.
Imagen

Así que la idea sería crear engine que pintara de dentro hacia fuera, en orden de textura y que detecte cuando un polígono es lo suficientemente grande como para que valga la pena analizar toda esa zona para descartar pintado o incluso transformaciones.
Señor Ventura
MegaAdicto!!!
12.595 mensajes
desde ene 2014
BMBx64 escribió:Por ejemplo ha conseguido procesar 8 triángulos por ciclo usando la VU dentro del RSP


Pero planos, ¿no?.

¿Eso no son 4 veces mas polígonos que lo que vemos comúnmente en los juegos del catálogo?, es que si es así hablamos de muchos cientos de miles de ellos... supongo que no llegará a tanto por lo que comentas del fill rate con las texturas...
BMBx64
Adicto
261 mensajes
desde may 2016
@Señor Ventura
Según entendí trabajará con 8 a la vez indistintamente, con valores válidos para activar la corrección de perspectiva, hay pasos previos donde el RSP o la CPU trabajan en la proyección de la escena y pasos posteriores por decidir, si se encargará el z-buffer o habrá un display list manual.

Si le entregas antes la información al rasterizador mejor, pero de por sí no es una multiplicación de rendimiento, si éste hace cuello de botella solo le darás algo más de tiempo, lo suyo es crear un engine que sea lo más limpio posible enviándole superficies, le restas tiempo al RSP o la CPU, pero igual ese tiempo es mucho menor en comparación con lo que tarda el RDP cuando se le acumula la faena.
Señor Ventura
MegaAdicto!!!
12.595 mensajes
desde ene 2014
BMBx64 escribió:@Señor Ventura
Según entendí trabajará con 8 a la vez indistintamente, con valores válidos para activar la corrección de perspectiva, hay pasos previos donde el RSP o la CPU trabajan en la proyección de la escena y pasos posteriores por decidir, si se encargará el z-buffer o habrá un display list manual.

Si le entregas antes la información al rasterizador mejor, pero de por sí no es una multiplicación de rendimiento, si éste hace cuello de botella solo le darás algo más de tiempo, lo suyo es crear un engine que sea lo más limpio posible enviándole superficies, le restas tiempo al RSP o la CPU, pero igual ese tiempo es mucho menor en comparación con lo que tarda el RDP cuando se le acumula la faena.


Si, a eso me refería. Al menos de esta forma te aseguras de que el cuello de botella nunca será la geometría, y a partir de ahí ir avanzando a otras partes del hardware hasta que no sea posible optimizar mas.

Una forma de acelerar la texturización no se si sería posible en todo caso... 8 polígonos texturizados por ciclo, aunque sea sin z buffer (para ir empezando), me parecería una tremenda burrada para una máquina de esa generación. Ignoro a que equivaldría eso porque desconozco cual es la cifra total de ciclos de proceso, pero aunque no sea realista... joder que me gusta emocionarme xDD
BMBx64
Adicto
261 mensajes
desde may 2016
Editado 1 vez. Última: 20/10/2017 - 05:03:28 por BMBx64.
DITHER
Estaba haciendo una recreación día/noche y al ver el cielo he pensado que quedaría mejor con tramados.

Así que vamos a añadir nuevas funciones:
rdp_rgb_dither(num);
rdp_alpha_dither(num);

Cada una tiene 4 configuraciones dentro del chip, en el caso de RGB DITHER:
0 - Dither pensado para usar en conjunto con filtro.
1 - Dither estándar, para usar sin filtro.
2 - Dither aleatorio, agh.
3 - Desactivado.

Como no tengo pensado usar filtros vamos a ver el estándar..
Imagen

Pues.. no es lo que esperaba, trabaja sobre toda la superficie, sean del mismo color o no.
Imagen

Algo así hubiera estado genial para no tener que hacerlo manualmente:
Imagen

Vamos a revisar el random dither, pero solo aplicándolo al cielo, igual eso da sensación de viveza o algo.. oye pues el granulado no queda tan mal si se aplica selectivamente, se pueden hacer cosas vistosas.
Imagen

Al final el ciclo ha quedado más corto [idea]
Imagen

Para conseguir tonos naranjas tendría que haber usado blanco/negro, modificando tan solo la escala RGB limita al color fuente de la textura, así que en este caso la transición a tarde no hubiera funcionado demasiado bien.

Volveré a esto cuando ya exista un motor 3D, en 2D puede que muchas cosas sean distintas y el código no valga después.
158, 59, 60, 61, 62, 63