Hilo de detalles y curiosidades de N64

despues de probar el port de gba, creo que estamos a un paso de ver un port en snes !!!

Sogun escribió:
Me ha picado el gusanillo y he buscado si estaba por ahí algún escenario del primer Tomb Raider extraído en formato OBJ o FBX con sus correspondientes texturas para hacer un port rapidito al motor gráfico del GoldenEye y ver cómo funciona. Pero no encuentro nada. A ver si alguien me lo consigue y comparto lo que haga por aquí.

A lo mejor aquí encuentras algohttps://www.tombraiderforums.com/showpost.php?p=3893223&postcount=489
Salud.

Hablando de...

He visto una tabla comparativa en la que se describen también las capacidades de la placa model 2 de sega, y las de un pentium a 133mhz.

https://segaretro.org/Sega_Saturn/Hardw ... ison_table



Impresiona un poco ver que los números no sitúan a la N64 demasiado lejos de la model 2, aunque todos sabemos que es así xD

1.400.000 polígonos sin texturizar en la N64... ¿no daría para un virtua racing decente a mas de 320x240?. Claro, que eso es model 1, pero digo yo que con mas motivos todavía...

Y viendo esto sigo imaginándome un daytona usa por encima de los 360p y 250.000k polígonos por segundo a 5fps, eso si, a una distancia de dibujado decente... claro, que yo que se xD (aunque el WDC creo que manejaba 180k polígonos por segundo a 30fps con una distancia de dibujado muy lejana, aunque a una resolución mas bien estándar).

Me da a mi, que se han flipado un poco con las cifras en general de las 3 consolas .

Salud.

Señor Ventura escribió:Hablando de...

He visto una tabla comparativa en la que se describen también las capacidades de la placa model 2 de sega, y las de un pentium a 133mhz.

https://segaretro.org/Sega_Saturn/Hardw ... ison_table



Impresiona un poco ver que los números no sitúan a la N64 demasiado lejos de la model 2, aunque todos sabemos que es así xD

1.400.000 polígonos sin texturizar en la N64... ¿no daría para un virtua racing decente a mas de 320x240?. Claro, que eso es model 1, pero digo yo que con mas motivos todavía...

Y viendo esto sigo imaginándome un daytona usa por encima de los 360p y 250.000k polígonos por segundo a 5fps, eso si, a una distancia de dibujado decente... claro, que yo que se xD (aunque el WDC creo que manejaba 180k polígonos por segundo a 30fps con una distancia de dibujado muy lejana, aunque a una resolución mas bien estándar).

Según esos datos la Saturn es casi una N64, supongo que calcularon lo que procesa cada chip por separado y lo sumaron sin importar que no pueda procesarlo todo al mismo tiempo por el bus de datos compartido para todo como si en vez de trabajar en cascada funcionara en paralelo.

Señor Ventura escribió:Hablando de...

He visto una tabla comparativa en la que se describen también las capacidades de la placa model 2 de sega, y las de un pentium a 133mhz.

https://segaretro.org/Sega_Saturn/Hardw ... ison_table



Impresiona un poco ver que los números no sitúan a la N64 demasiado lejos de la model 2, aunque todos sabemos que es así xD

Las cifras no es que sean del todo incorrectas, es no están en su contexto adecuado.
En Saturn eso que entiende por transformaciones de vertices y polígonos, son sprites. La Saturn maneja muy bien los sprites, deformandolos por vertices, y de hecho el 3D son sprites simulando polígonos. Pero los vertices solo tienen dos coordenadas, los polígonos 3D de verdad tienen 3. Cuando la Saturn tiene que manejar 3D, tiene que hacerlo por software e interpretar cada vertice tridimensional como un punto bidimensional en la pantalla (o framebuffer) para deformar el sprite convenientemente. Y es en ese proceso donde el rendimiento se va al carajo.
Es decir, en resumen, los datos de la Saturn son en 2D, basicamente, mientras que los de PS1 y N64 son en 3D.

Luego normalmente todas estas cifras suelen ser máximo teóricos o en condiciones muy favorables, como por ejemplo un triángulo con la misma textura. Se calcula cuanto tarda en dibujarlo cada procesador y de ahí se saca todo, y generalmente hay muchos factores a tener en cuenta.

Señor Ventura escribió:1.400.000 polígonos sin texturizar en la N64... ¿no daría para un virtua racing decente a mas de 320x240?. Claro, que eso es model 1, pero digo yo que con mas motivos todavía...

Y viendo esto sigo imaginándome un daytona usa por encima de los 360p y 250.000k polígonos por segundo a 5fps, eso si, a una distancia de dibujado decente... claro, que yo que se xD (aunque el WDC creo que manejaba 180k polígonos por segundo a 30fps con una distancia de dibujado muy lejana, aunque a una resolución mas bien estándar).

Yo quiero ver un port del Virtua Racing en N64, porque tengo la impresión de que podría alcanzar perfectamente los 60fps. No es un juego con muchos polígonos, y seguramente si cogemos la cantidad de polígonos del F-Zero y ponemos el doble sin textura, también los mueve la consola a 60fps.
El Daytona USA 1:1 del arcade ya es fliparse, pero el Circuit Edition de Saturn tiene una cantidad de polígonos bastante buena y capaz de moverlo la N64.

@EMaDeLoC el VR yo no le veo nada raro para que N64 no pueda moverlo a 60fps a 240p, a 360 o 480p ni idea porque la consola tiende a asfixiar al usar los modos hi-res, pero aun así siendo todo polígono sin texturizar no veo porqué no ¿O me estoy perdiendo algo?

Daytona USA coincido contigo que es fliparse esperar algo cercano al arcade, pero a 240p-30fps o quitando IA rivales algo se apañaría, el mínimo ya lo tenemos con la versión de lanzamiento en Saturn el máximo es sólo calibrarlo a N64, pero como mínimo más distancia de renderizado y un framerate estable a 30fps o en su defecto a 20, pero estable.

Kaze Emanuar ha vuelto a optimizar el código de Super Mario 64 y conseguido mejorar el rendimiento un pasito más. Esta vez mejorando la detección de colisiones con las paredes. En el proceso ha solucionado varios bugs de los que se aprovechaban los speedrunners.



Hacia el final del vídeo se muestra una parte de su último hack funcionando por encima de los 40 fps y en varias ocasiones alcanzando los 60 fps. Una lástima que la captura no sea directamente suya y parece que está capada a 30 fps, por lo que no se aprecia la suavidad. El propio Kaze dice que con todos los cambios y optimizaciones el hack funciona al doble de fps que al principio (hay vídeos de cómo rendía, los recopilé en un mensaje anterior).

Siendo los escenarios del juego original bastante más sencillos, veo totalmente posible que se consigan los ansiados 60 fps. El mismo Kaze dice en los comentarios que es un proyecto que tiene en mente, pero le llevaría cientos de horas de las que ahora no dispone. No debe ser tan sencillo como aplicar sus cambios al código y recompilar, seguro que hay que hacer muchos retoques a los escenarios para que carguen a trozo o algo así.

@Sogun imagino que las físicas todas estarán calculadas en función del framerate así que si optimiza a 60fps igual se va todo a la mierda.

EMaDeLoC escribió:Yo quiero ver un port del Virtua Racing en N64, porque tengo la impresión de que podría alcanzar perfectamente los 60fps. No es un juego con muchos polígonos, y seguramente si cogemos la cantidad de polígonos del F-Zero y ponemos el doble sin textura, también los mueve la consola a 60fps.
El Daytona USA 1:1 del arcade ya es fliparse, pero el Circuit Edition de Saturn tiene una cantidad de polígonos bastante buena y capaz de moverlo la N64.

Pero el virtua racing arcade funciona a 30fps, eso igual da mas margen para subirle la resolución.

El juego original funciona a 496x384, y parece que demanda 2000 polígonos por frame, lo cual serían unos 60.000 polígonos por segundo, sin texturizar ni nada. Debería ser pan comido para una N64, digo yo, ¿no?... incluso diría que también debería serlo para una saturn, pero si comparas su port con el arcade hay una diferencia brutal, como mínimo de resolución...


Lo del daytona usa ya es otra cuestión. Mas bien no se trata de acercarse al arcade, sino de descubrir con cuanto rendimiento podría reproducirse un frame con una calidad parecida a la del juego original. De ahí que hablase de 5 frames por segundo, pero que igual ni eso, ¿eh?, ni idea.

Señor Ventura escribió:El juego original funciona a 496x384, y parece que demanda 2000 polígonos por frame, lo cual serían unos 60.000 polígonos por segundo, sin texturizar ni nada.

Sabía que era más resolución pero la cantidad de polígonos no. F-Zero X son 60.000, según las cuentas de Conker. Teniendo en cuenta la mejora de rendimiento que supone no usar texturas en los polígonos y la mejora de ancho de banda al no cargar esas texturas al TME, creo que las cuentas permitirían mejorar la cantidad de polígonos para mejorar la distancia de dibujo, que en el arcade creo que se notaba cierto popping.

EMaDeLoC escribió:

Señor Ventura escribió:El juego original funciona a 496x384, y parece que demanda 2000 polígonos por frame, lo cual serían unos 60.000 polígonos por segundo, sin texturizar ni nada.

Sabía que era más resolución pero la cantidad de polígonos no. F-Zero X son 60.000, según las cuentas de Conker. Teniendo en cuenta la mejora de rendimiento que supone no usar texturas en los polígonos y la mejora de ancho de banda al no cargar esas texturas al TME, creo que las cuentas permitirían mejorar la cantidad de polígonos para mejorar la distancia de dibujo, que en el arcade creo que se notaba cierto popping.

Eso es interesante... f-zero x funciona al doble de frames por segundo que el virtua racing, pero con una distancia de dibujado menor, y seguramente a menor resolución.

Lo cierto es que no parece un reto muy grande conseguir un virtua racing 1:1 como el del arcade en N64...

1.400.000 polígonos sin texturizar

Esas cifras no creo que puedan alcanzarse, por ejemplo en libdragon montando un ejemplo donde todo lo que hay es un bucle que pinta rectángulos flat (ojo, que son más rápidos que los triángulos)


Da las siguientes cifras en consola:
7604 - 380K (50 fps)
13261 - 398K (30 fps)

El test no es muy diferente al de los copos de nieve que hice, pero eliminando aproximadamente 50000 condiciones y otro código innecesario del bucle, que hace que suba de 356 a 380K.

Los rectángulos son de 4x4, aunque si los pongo de 8x8 sigue dando el mismo rendimiento, a 16x16 la cosa empeora, no estoy limpiando toda la pantalla, solo la parte de los contadores para que puedan actualizarse, con lo cual no se desaprovecha fillrate.

Estas cifras siempre suelen darse para este tipo de ejemplos, donde todas las superficies son de un mismo tamaño, si son mayores ya te descuadra la cosa.

De compilarlo en libn64 o libultra si la cosa fuera como en otros ejemplos se podría alcanzar entre un 20-30% de mejora, siempre que todo quede perfectamente alineado y probablemente otro porcentaje si se ejecuta en el RSP y se comunica con el RDP, en lugar de mandar los comandos a la RAM para que luego los lea el chip gráfico, luego puede haber otras cosas que se me escapen.

Usar la consola en modo fill es perfectamente válido para un juego 3D que use flat.

Para rectángulos texturizados no es muy diferente la cosa, incluso con los tests oficiales de Nintendo (mis tests coinciden en rendimiento).


Por ejemplo siendo 160K para rectángulos texturizados de 16x16 usando la misma textura, siempre que el target sean los 60fps, ya que el rendimiento no es linear y a 30 fps el desempeño es superior.

Lo cual no está nada mal, podría revisar que dan los de 4x4 y compararlos.

@Conker64 ¿Entonces es un si?, ¿496x384 de resolución, 2000 polígonos por frame, 30 frames por segundo?.

Mi impresión es que la n64 da de sobra para esto, aunque no sabría decir cuanto.

@Señor Ventura
Esos datos que dices en flat? Sí.

PD: Técnicamente debería alcanzar 500K en ese test de arriba, incluso con triángulos (de ese tamaño minúsculo), ya que fue la cifra proporcionada como pico de rendimiento del modo Turbo 3D.

Conker64 escribió:@Señor Ventura
Esos datos que dices en flat? Sí.

PD: Técnicamente debería alcanzar 500K en ese test de arriba, incluso con triángulos (de ese tamaño minúsculo), ya que fue la cifra proporcionada como pico de rendimiento del modo Turbo 3D.

¿500 mil polígonos?, pero si el arcade maneja solo 60 mil O_O

¿Como es posible que la saturn no pueda con un virtua racing a pesar de que por números no debería quedarse tan por debajo de las espectativas, y la nintendo 64 vaya tan sobrada?, ¿será que nunca se usó bien la 32 bits de sega?.

@Señor Ventura
Bueno con ese test solo conoces el pico de fillrate, un rectángulo/triángulo encima de otro en el centro de la pantalla, eso no se traslada a un juego donde cada superficie puede ser de un tamaño diferente, tienes toda la lógica del juego, toda la transformación 3D y otros factores afectando, colisiones, IA, etc.. pero los 60K ya te los hace texturizando, con Z-Buffer y el resto de efectos en algunos juegos (quizás en unos más estables que en otros), al usar fill/flat pierdes todos esos efectos, pero ganas mucho ancho de banda que da para aumentarle la resolución.

@Señor Ventura ¿de dónde sacas el polycount de Virtua Racing? Lo digo porque la Model 1 escupe unos 180.000 polígonos por segundo teóricamente, que no se a cuánto equivale por frame.

¿Como es posible que la saturn no pueda con un virtua racing a pesar de que por números no debería quedarse tan por debajo de las espectativas, y la nintendo 64 vaya tan sobrada?, ¿será que nunca se usó bien la 32 bits de sega?

La conversión del VR para Saturn es del año 1995, realizada por una compañía ajena a SEGA (Time Warner Interactive), cuando la máquina estaba pobremente documentada y los compiladores de C eran una mierda. Si a esto le sumas que en Saturn al carecer de hardware dedicado para las transformaciones (FPU/Co-Procesador de matrices) hay que hacer todos los cálculo “a mano”, en una época donde programar medio en paralelo aunque sea en tándem a través de un ensamblador para chips que no conocía ni el tato, es de suponer que ese primer Virtua Racing no aprovechaba la máquina demasiado.

Pues si la model 1, saca 180000 pol/seg @ 60 fps, son 3000 pol/frame y a @ 30 fps, 6000 pol/frame como al parecer funciona el V.R., que parece que son cuatro polígonos, pero es que todo son polígonos, hasta las rayas de la carretera o las banderas.

Salud.

Conker64 escribió:@Señor Ventura
Bueno con ese test solo conoces el pico de fillrate, un rectángulo/triángulo encima de otro en el centro de la pantalla, eso no se traslada a un juego donde cada superficie puede ser de un tamaño diferente, tienes toda la lógica del juego, toda la transformación 3D y otros factores afectando, colisiones, IA, etc.. pero los 60K ya te los hace texturizando, con Z-Buffer y el resto de efectos en algunos juegos (quizás en unos más estables que en otros), al usar fill/flat pierdes todos esos efectos, pero ganas mucho ancho de banda que da para aumentarle la resolución.

Pero digo yo, que si 60k/90k polígonos texturizados por segundo con todos los efectos es una cosa bastante estándar para los juegos de las 32 bits, sin texturizar sea todavía una carga de trabajo aún menor.

La incognita es la resolución, pero la impresión es que un modo gráfico sin texturizar permita agilizar la tarea como para subir la resolución manteniendo la tasa de cuadros por segundo (30fps).

Lo que estaría bien saber es hasta que resolución podría subir sin resentirse.

Sexy MotherFucker escribió:@Señor Ventura ¿de dónde sacas el polycount de Virtua Racing? Lo digo porque la Model 1 escupe unos 180.000 polígonos por segundo teóricamente, que no se a cuánto equivale por frame.

Pues si es a 60fps, son 3000 polígonos por frame... y si es a 30fps, pues 6000 polígonos por frame.

Los límites de la model 1 no tienen por qué ser los límites del virtua racing, ojo, pero ahora estoy leyendo que virtua racing superaba las cifras teóricas de la model 1 con 6500 polígonos por frame, lo cual son 195 mil polígonos por segundo... pues tampoco me parece muy creíble si 180k son benchmarks

Parece que 2000 poligonos por frame eran los de la competencia superando a lo que ofrecía sega, y que por eso se vió obligada a diseñar o mejorar la model 1 hasta conseguir esos 6500 (polígonos por frame).

Algo me falla aquí. Sin un análisis no hay datos para tomar ninguna fuente como válida.

dirtymagic escribió:Pues si la model 1, saca 180000 pol/seg @ 60 fps, son 3000 pol/frame y a @ 30 fps, 6000 pol/frame como al parecer funciona el V.R., que parece que son cuatro polígonos, pero es que todo son polígonos, hasta las rayas de la carretera o las banderas.

Salud.

A mi lo que me resulta raro es que 180k polígonos sean cifras no en un entorno de juego, pero que luego un juego roce los 200k. Nunca he visto un solo hardware que presentando cifras de benchmarks dedicados solo a dibujar, luego acabe superando esas cifras en un juego, que lo que hace es exigir mas que solo dibujar.

https://www.wikiwand.com/en/Virtua_Racing

Cito esto sobre los datos técnicos de F-Zero X por si os sirve. Y añado que F-Zero fue el juego con menor resolución interna que encontré al hacer capturas nativas para el top.

Sogun escribió:

Sexy MotherFucker escribió:Cifras del Daytona U.S.A de ARCADE para establecer más visualmente la comparativa:

- 300.000 polígonos por segundo.
- Mapeado de texturas com mip mapping, correción de perspectiva, y 16 bit de profundidad de color.
- 60 fps inamovibles.
- 496x384p (24 khz).
- Hasta 39 ias en carrera.
- Sonido a 48 canales PCM y 44 Khz.

Que conste que yo me conformo con 50.000 polígonos, las mismas IAs que en Saturn, 60 fps constantes, y 0 pop up.

Podemos comparar con F-Zero X que es lo más parecido
-50.000/60.000 polígonos por segundo
-Texturas con corrección de perspectiva, a 8 bits de color y sin mipmapping
-60 fps constantes
-Resolución 296x208p
-Hasta 29 IAs en carrera
-Sonido mono 16-bit PCM con un samplerate de 22,050 Hz
-Pop up/distancia de dibujo deficiente.

En base a lo que pone en la Wiki, básicamente desarrollaron la placa y el juego a la vez, tal vez las especificaciones son conservadoras y realistas al rendimiento en un juego, le pasa como a GC que ponía de rendimiento de 6-12 M pol/seg y PS2 75 Millones y luego, la GC eran datos realistas y PS2 pura fantasía para alcanzar esas cifras.

@Conker64, no consigo bajarme el CEM64 para windows, esta la web muerta, he visto que existe otro emulador hardware accuracy, Larper64,¿lo has probado, que tal va?

Salud.

Señor Ventura escribió:Pero digo yo, que si 60k/90k polígonos texturizados por segundo con todos los efectos es una cosa bastante estándar para los juegos de las 32 bits, sin texturizar sea todavía una carga de trabajo aún menor.

La incognita es la resolución, pero la impresión es que un modo gráfico sin texturizar permita agilizar la tarea como para subir la resolución manteniendo la tasa de cuadros por segundo (30fps).

Lo que estaría bien saber es hasta que resolución podría subir sin resentirse.

Con eso consigues lo de Tobal 1 de PSX, estará por ahí enterrado en algún comentario de páginas atrás, algo más de 120K y en alta resolución, claro que con truco, 2 luchadores que no se acercan demasiado a la pantalla.

En un juego de carreras las superficies son más variables y hay menos control.

@dirtymagic
Lo subiría pero los pifdata que necesitas con el emulador son archivos con copyright, el Larper64 ni lo conocía, llevo bastante desconectado

La generación 128bit tampoco pone tantos polígonos, luego analizas escenas de muchos juegos y te sale 500k, 750k, 1 o 2 millones, es entre un 10x y un 20x de la anterior generación, donde un modelado era de 600 polys ahora puede serlo de 6000, todo ello a mayor resolución, framerate, mayor resolución de las texturas, etc

--
Interesaría un análisis del Misión Imposible? En plan completo, técnico, jugabilidad, niveles, inspiración y comparación con la película, marketing de la época.. en base a como te lo vendían las revistas y los VHS..

@Conker64 cualquier cosa técnica que expliques, especialmente para mi que no entiendo de tecnicismos, interesa y mucho

SuperPadLand escribió:@Conker64 cualquier cosa técnica que expliques, especialmente para mi que no entiendo de tecnicismos, interesa y mucho

+1

Este hilo y el de curiosidades de MD son oro, de lo mejor del foro

@Conker64 no puedes pasarlo sin el PiF y ya lo buscaré por mi cuenta?
Todo lo que sea más información técnica siempre es bienvenida.

Salud.

Ok, miraré si se puede hacer una review entretenida

@dirtymagic
El emu no tiene interfaz, tira de línea de comandos y está pensado para desarrollo, si lo quieres para probar cosas en el emulador antes que en la consola te puede servir, pero para jugar es un poco incómodo, he dejado los bat que tengo montados para arrancarlo, los puedes editar para cambiar roms de otros nombres.

Las roms tienen que ser en formato z64.

Los controles no son configurables, te dejo los que tengo anotados (faltarían los C amarillos creo):


Archivos necesarios a la carpeta raíz junto con el exe, los DD puede que no sean necesarios, el pif solo el de la región que vayas a usar:


Edit: El rendimiento puede que no coincida al 100%, en algunos tests el contador de fps me da más en CEN64 y en otros en N64.

Gracias @Conker64, ya está bajado.
Tranquilo, no lo quiero para jugar, sino para probar el rendimiento del mod que estoy haciendo del Zelda OoT, que el plugin Angrylion, es preciso en los gráficos, pero el framerate, siempre lo mantiene, así que para saber si alguna parte del escenario rasca, tenía que probarlo en la N64 que tengo en otra habitación con la TV crt, es un coñazo, estar de un lado para otro con la SD,😅.
Salud.

Me he topado con dos demos muy interesantes creadas por James Lambert aka olivieryuyu que pueden descargarse aquí.

N64 Realtime Shadows

Esta demostración muestra una técnica para renderizar sombras en tiempo real en el hardware original de n64.

Funciona como una variación de volúmenes de sombras y trabaja renderizando en 3 pasos cualquier objeto sombreado y 2 pasos para el volumen de sombra.

-Primero renderiza los objetos iluminados
-Luego renderiza las superficies traseras del volumen de sombras de forma totalmente transparente, pero sigue actualizando el buffer de profundidad.
-Después redibuja todos los objetos sin iluminación superponiendo una textura (decal mode).
-A continuación dibuja las superficies frontales del volumen de sombra también totalmente transparente.
-Por último, redibuja los objetos iluminados de nuevo.

Las sombra proyectada por Suzanne (la cabeza-de-mono mascota de Blender) se renderiza fuera de pantalla en un buffer de 64x64 de 8 bits y después se proyecta sobre el suelo.

En la demo se puede rotar la cámara con el stick del mando, acercarnos y alejarnos al centro de la escena con A y B, y alternar entre varios colores de la fuente de luz con los botones Z y R. La demo renderiza en entrelazado (supongo que a 640x480) y funciona a 30 fps (ojo biónico) con la cámara alejada, pero si nos acercamos mucho empieza a rascar de lo lindo. Le cuesta dibujar muchos píxeles semitransparentes de sombra.
En los comentarios el autor menciona que existen limitaciones y que los objetos complejos sólo pueden proyectar sombras en superficies planas y las superficies planas puedes proyectar sombras en objetos complejos, pero no se podría proyectar sombras de objetos complejos en otros objetos complejos.


N64 Toonshading

La demo muestra algunos usos de renderizar en un buffer de 8 bits de color. Después se utiliza una paleta para transformar la imagen final. La técnica más útil aquí mostrada es toon shading. Para conseguir este efecto primero se renderizan los objetos 3D en un buffer de color de 8 bits. La N64 hace esto renderizando únicamente los 8 bits del canal del color rojo. El resultado es una imagen en escala de grises que no puede mostrarse por si misma. Primero es necesario convertirla a una imagen de 16 bits de color. Esto se hace asignando cada valor de gris a un color único utilizando una paleta de colores. Para conseguir el efecto de dibujo animado, los valores iluminados y ensombrecidos de cada color se colocan uno junto al otro con el color oscuro primero. Cuando un objeto tiene que renderizarse, usa este modo (SHADE - 0) * ENVIRONMENT + PRIMITIVE donde PRIMITIVE se asigna al índice del color oscuro y a ENVIRONMENT se le da el valor de 1. El hardware interpreta el valor 1 como 1/255 y el resultado final es que a la parte del modelo en sombras se le asigna el índice oscuro y la parte iluminada se le da el ínidice superior al ínidice oscuro, que es el color luminoso. Hasta 128 parejas de colores pueden almacenarse en la paleta de colores de 256 entradas.

Al igual que en la demo anterior, se puede rotar la cámara con el stick del mando, acercarnos y alejarnos al centro de la escena con A y B. Si pulsamos Z y R podemos ir alternando entre distintas paletas (esto no se muestra en el vídeo). Hay algunas paletas que no se limitan a 2 colores por objeto y se consiguen efectos muy vistosos. Esta demo también renderiza en entrelazado pero no parece tan fluida como la anterior (explicación en los comentarios del autor).
En los comentarios el autor habla de que la línea negra de contorno se consigue renderizando el objeto una segunda vez (con las normales invertidas, es algo que ya se ha visto en muchos hacks de N64) pero que el efecto toon shading no requiere de muchos recursos. Lo único malo es que quedas limitado a 256 colores en pantalla, pero con una dirección artística adecuada no sería un problema.

Creo que sería posible conseguir el mismo efecto con texturas envmap. Es algo que tengo en mi lista de cosas que probar. De este modo se podría combinar toon shading con renderizado normal y además no habría limitación de colores en pantalla.

Olivieryuyu también estaba creando su propia versión optimizada del microcódigo de Factor 5. Él ayudó a Gonetz a documentar este microcódigo y hacer estos juego compatibles con el plugin gráfico GlideN64. Escribió varios artículos en su blog, pero hace tiempo que no actualiza.

@Sogun con la último demo me imagino un Wind Waker demake

SuperPadLand escribió:@Sogun con la último demo me imagino un Wind Waker demake

Sería digno de ver, total, WW es 1 festival de texturas planas de 2BBP y 4BBP; Nintendo 64 puede con todas ellas. El rollo sería bajar de 480 a 240p, Framebuffer de 8 en lugar de 16, el polycount de millones a unos pocos cientos de miles, marcarse un target cerrado de 20-25 fps en lugar de 60, etc.

Lo veo joder, lo veo.

@Sogun buenos aportes como siempre

Al final me he animado y he probado a simular el Toonshading con mi idea, aunque los resultados no han sido como yo me esperaba. La verdad es que no sé si podría mejorarlo porque no entiendo de donde sale tanta gama de color e incluso colores que no tengo en las texturas. Creo que el culpable es el motor gráfico del GoldenEye que le añade cosillas a los envmaps.

Un experimento con texturas envmap para conseguir algo parecido al toon-shading característico de juegos como Jet Set Radio.

El modelo de Link pertenece a The Legend of Zelda Windwaker retexturizado para esta prueba en N64 (por eso los ojos y la boca están mal. También eliminé algunos polígonos de las manos que no se ven). Un versión del modelo agrandada con las superficies invertidas y texturizada en negro simula la línea de contorno, aunque este modelo no está bien posicionado y la línea de contorno no se aprecia en algunas zonas. En total el objeto tiene 5090 triángulos (como se ve al final del vídeo) ¡¡Demasiado para el hardware original!!.
No sé por qué la transparencia de la textura de la boca no aplica transparecia si se trata del mismo tipo de textura que los ojos, que sí renderizan bien.

Como se observa en el experimento, se consigue un efecto toon-shading convincente en algunos ángulos pero desde otros puntos de vista se asemeja a un goraud shading típico. También hay un toque metálico en el modelo que sospecho que es la forma en la que el motor gráfico del GoldenEye maneja los envmap. No lo he probado en el harware original.

La segunda parte del vídeo muestra el modelo en el GE Setup Editor. Las transiciones de color son mucho mejores y no hay ni rastro del efecto goraud shadin. Así era como me imaginaba que se vería en el juego. Más adelante muestro la malla poligonal y también las normales de los polígonos que se usan para renderizar los envmaps con un código de color. Los cortes bruscos de color son malos y deben corregirse manualmente, pero sólo solucionarían pequeños defectos gráficos y no los grandes problemas que tengo.

Sexy MotherFucker escribió:

SuperPadLand escribió:@Sogun con la último demo me imagino un Wind Waker demake

Sería digno de ver, total, WW es 1 festival de texturas planas de 2BBP y 4BBP; Nintendo 64 puede con todas ellas. El rollo sería bajar de 480 a 240p, Framebuffer de 8 en lugar de 16, el polycount de millones a unos pocos cientos de miles, marcarse un target cerrado de 20-25 fps en lugar de 60, etc.

Lo veo joder, lo veo.

Algo como Megaman Legends para las mazmorras y como el Phantom Hourglass para navegar -> https://youtu.be/okM-WIIVPgA?t=1325 y arreando

Nuevo vídeo de OpenLara corriendo en una Nintendo64. jnmartin84 ha bajado la resolución a 160x120 (un cuarto de la resolución habitual y más baja que el port de GameBoy Advance) para mejorar el rendimiento porque a 320x240 el juego se arrastraba. Siguen faltando todos los filtros de texturas, precisión subpíxel, antialising y cualquier tipo de sonido y música, pero al menos lo que se ve ya es reconocible. Pasito a pasito...


Del mismo autor. Parece que ha programado un compilador para crear una rom del clásico Another World y que funcione en la Nintendo 64.

@Sogun ¿y todo eso usando solo la cpu?. Veo normal que no funcione a 320x240, si es que no puede ser de otra manera.

¿Hasta donde se espera alcanzar (usando solo la cpu)?.

Está aprendiendo a manejar 3D según progresa, le va a tomar un tiempo:

I'm (re)learning a lot as I go. I haven't done any 3D stuff since an undergrad computer graphics course so long ago

Muy bien el Another World

Puto puyo N party, con voces entre escenas y ROM expandida, gracias a Zoinkity.

@doblete queria probarlo, pero no se por que me da error al parchearlo, tanto con un parcheador online como con el DeltaPatcher, el SHA-1 de la ROM es la que debe.

Hidden Palace ha publicado una versión temprana de 007: The World is not Enough. No tengo muy claro cuánto cambia, pero para empezar la primera misión es la sexta o séptima del juego final. No empieza en el banco.

@Natlus Por lo que pone, tienes que usar la última versión de xdelta, no la que viene con xdelta gui o deltapatcher.

Cuantas novedades de golpe, el Another World funciona muy bien, el Tomb Raider sí que está costando, imagino que tiene que ver con algo peculiar del hardware porque aun usando sólo la CPU esta es como 5 veces más potente que la de GBA. Una cosa a mencionar, sino me equivoco, 160x120 es la mitad de la res del original de PS1 que creo que sería el objetivo ya que a 640x480 en esta gen de consolas sólo se vieron en juegos sin texturizar o gráficamente sencillotes y nunca en mundos 3D.

Hola, vengo de un hilo del subforo "emulación" y me gustaría dejar aquí mi duda...

Algo que no puedo entender es el hecho de la dificultad de la emulación de N64... parecía que Saturn se resistiría más pero desde hace un par de años se ha conseguido emular bastante bien y en mi opinión ha pasado por la derecha la emulación de N64... Es que lo del Mario Tennis es increíble, tengo un mini PC con emus de Game Cube y Wii U y sus respectivos Mario Tennis van infinitamente mejor que el Mario Tennis de N64.

¿Puede ser por falta de medios para desarrollar los emuladores de N64? ¿Por complejidad de arquitectura? si es que le cuesta hasta a nintendo hacer una emulación decente...

No sé si ya lo único que nos queda es esperar que las FPGA sean la salvación para "emular" correctamente esta consola...

Me acuerdo cuando soñábamos que en 2018 tendríamos N64 Mini...

En fin

raspael escribió:Hola, vengo de un hilo del subforo "emulación" y me gustaría dejar aquí mi duda...

Algo que no puedo entender es el hecho de la dificultad de la emulación de N64... parecía que Saturn se resistiría más pero desde hace un par de años se ha conseguido emular bastante bien y en mi opinión ha pasado por la derecha la emulación de N64... Es que lo del Mario Tennis es increíble, tengo un mini PC con emus de Game Cube y Wii U y sus respectivos Mario Tennis van infinitamente mejor que el Mario Tennis de N64.

¿Puede ser por falta de medios para desarrollar los emuladores de N64? ¿Por complejidad de arquitectura? si es que le cuesta hasta a nintendo hacer una emulación decente...

No sé si ya lo único que nos queda es esperar que las FPGA sean la salvación para "emular" correctamente esta consola...

Me acuerdo cuando soñábamos que en 2018 tendríamos N64 Mini...

En fin

Pues realmente no sé que parte es la que cuesta emular, pero yo recuerdo tener un pentium 4 emulando a 100% a la N64 con "Proyect 64," de echo recuerdo que en su día me pase el Ocarina of time con parche español(entre otros) con ese emulador por no tener la consola, siempre he pensado que emulador de N64 de PC fue de los que mejor iba de todos los que había por entonces, que eso lo emulanba hasta una tostadora.

Creo que algo debe estar haciendo mal ¿Solo te pasa con el Mario tenis?, por que hasta uns Rasberry pi 2 emula la N64, incluso la Xbox Classic (la primera que salió) lo emula 100% y con mejora incluso.

@Chuss80 Yo hace eones que no emulo N64, pero recuerdo que desde el principio los juegos mejor soportados fueron siempre Super Mario 64 y Zelda OoT, porque eran los más populares (aún hoy). Pero claro, el resto de juegos solía tener fallos gráficos diversos. Y parece que aún sigue así, aunque hayan ido mejorándolos en la medida de lo posible.

Yo también abandoné la emulación de N64 hace unos años pillando un everdrive y una N64 RGB

Yo en PC no he tenido grandes problema para emular N64, algún juego raro existirá que no vaya o funcione mal, pero en general todo lo importante de la consola a mi me funcionó. De hecho todos los hacks y traducciones de N64 hasta que aparecieron los flashcard eran para emulador.

En Android también la probé hace 5-6 años y los resultados ya eran un poco peores con ralentizaciones y algún juego que no arrancaba, lo primero casi seguro que es que mi microconsola android no tenía potencia suficiente sumado a que el emulador estaba verde y poco optimizado.

El Mario Tennis no lo probé, quizás sea de los que no van o dan errores.

Yo nunca he tenido problemas para emular n64, recuerdo en mi época de universidad como viciabamos en un portatil chustero de la época con una integrada de intel y un gb de ram a mariokart en 4 jugadores sin problema alguno.
Estoy hablando de 2006/2007. Hace 15 años, casi nada... (Época de project64 1.6)
Hoy en día cualquier movil con snapdragon te chuta el full romset del sistema sin problema alguno creo yo

@raspael El mayor escollo de la emulación en N64 es el RCP. Es un procesador un poco mutiuso, capaz de renderizar triángulos, transformar geometría y procesar audio. Si no recuerdo mal tiene una base como la del MIPS VR4000 pero modificado para las necesidades gráficas. Se le puede cargar con microinstrucciones para realizar las instrucciones de forma personalizada y conseguir mejores efectos o más rendimiento.
El problema mayor es que el RCP esta muy poco documentado, y por eso cuesta emular algún juego y crear entornos de desarrollo libre.

Suele haber confunsión en entender porque Super Mario 64 se pudo emular bastante pronto y que luego cueste tanto incluso a Nintendo emular otros juegos, como se ha mencionado antes. Los primeros juegos se hicieron completamente con el SDK oficial y usaron las librerias por defecto sin más optimización. El SDK se filtró y a partir de ahí se creo un emulador que identificaba cuando un poligono se iba a dibujar con determinada función, y en vez de emular el proceso que hace el RCP, se procesa el triángulo con el hardware del ordenador (3Dfx en aquel entonces) imitando el resultado del hardware. De esa forma se ahorra mucha complejidad de programar el emulador y los requisitos bajan muchísimo. El problema es que en cuanto un juego personaliza sus funciones o su acceso al RCP hay que crear parches que subsanen los errores gráficos que se produzcan. Uno de los primero fue el Mario Kart, que al usar el framebuffer para crear las pantallas gigantes y ser este casi inaccesible en otro hardware, salen con errores o en negro. Se pudo ver en ese clon de consola que quiso sacar Hyperkin hace unos años y al final nada, porque era un cagarro:


Hay emuladores que tratan de ser cycle-acurate como el CEN64, pero requieren de mucha potencia de proceso.

En cuanto a FPGA, había un proyecto de crear un core para N64 y tenía avances prometedores:


Sin embargo es un core que está funcionando en una FPGA de desarrollo que cuesta 500€ y es solo para el RCP, ya que aparte tiene un VR4300. Es decir, hace falta un core para RCP y otro para CPU. Y por si fuera poco, hace más de año y medio que no se actualiza nada del proyecto. Tardaremos bastante en ver un core de N64 en una FPGA asequible.

Y en mi opinión personal, lo que mejor le sienta a la N64 es la consola con mod RGB y un CRT. Para mí luce mejor que con cualquier emulador, aún con sus defectos de framerate y baja resolución.

A ver, la aquitectura de N64 era muy "especial" y no se ha conseguido emular al 100% (a pesar de emular en máquinas cientos de veces más potentes que una N64). Otra cosa es que los juegos "den el pego" gracias a la potencia bruta. Pero hay algunos juegos que aún siguen dando glitches o que no funcionan.

Los programadores iban juego a juego corrigiendo errores, no es "meter la rom en el emulador y jugar".

A día de hoy lo mejor para apreciar la esencia de N64 sigue siendo hacerlo con su hardware original, un everdrive, su mando original, una TV de tubo y un cable S-video.

@cegador eso pasa en todos los emuladores, otra cosa es que SS o N64 o PS2 tengan más o menos fallos que otros sistemas emulados, pero hoy en día se puede emular cualquiera de las citadas para jugar el grueso de sus catálogos o juegos importantes. Que a lo mejor te comes un glitch suelto y tal, pero hace eones que son emulables para viciar, dependiendo de cuanto quieras viciar a sus catálogos compensará hacerse con una original claro, pero sí sólo quieres jugar Mario 64, Zeldas y Goldeneye pues emulador y a volar.

Recordemos que oficialmente están emulados prácticamente todos los importantes y que se puede acceder a dicha emulación de forma no oficial también

Yo hace unos 5-7 años emulé en PS2 el primero Project Zero y ya te avisaban en la lista de compatibilidades que había un bug que congelaba el juego en el boss final si te movías a una zona cambiando la cámara fija y la solución en aquel momento era pasarse el boss sin salirte de la zona inicial, cosa que hice y disfruté el juego completamente. Dudo mucho que haya errores mucho más importantes que este en la mayoría de juegos famosos de N64 o Saturn.

Jugar en hardware real tampoco está exento de errores, que lo retro tiene fama de no tener bugs, pero yo ahora que he experimentado más esta gen me he comido desde cuelgues hasta quedarme atascado en paredes o entre las dos cajas colisión de dos elementos 3D, etc.

A mi el efecto que me sacaba de quicio en la emulación de N64 era el cuadrado gris que pululaba por la pantalla, de vez en cuando, en Winback. Que siempre aprovechaba un tiroteo para salir.

Se acabó corrigiendo, pero al cabo de 15 años lo menos. Ya era un clásico, como las sombras de Pilotwings o el cielo de Goldeneye.

También recuerdo el día que un plugin emuló por primera vez Gauntlet Legends, mostrando tan solo los personajes, no el fondo. Era un plugin de Zilmar, anterior a Glide64, zAlgo. Qué alegría me llevé al verlo. En estar completamente emulado tardó una montonera de años.