Hilo de detalles y curiosidades de N64

172, 73, 74, 75, 76
Señor Ventura
MegaAdicto!!!
12.833 mensajes
desde ene 2014
BMBx64 escribió:300K pero sin iluminación dinámica, me confirman por aquí que un 99,9% de los triángulos se pueden pintar con fill color, el 0,1% restante debe dividirse en 2, pero se puede evitar la representación de esa posición en concreto.


Que putada, sin iluminación dinámica... ¿adios gouraud?.

BMBx64 escribió:Eso haría que los triángulos en flat se pintaran a 4 pixels por ciclo, que es la velocidad de limpieza de buffer.


300.000 x 4= 1.200.000 ciclos.

¿Entonces si un polígono ocupa la mitad de la pantalla, significa que a 640x480 se lleva el solito 38.400 ciclos para ser dibujado?.

Sería un problema si algunos polígonos empiezan a requerir mas ciclos para ser pintados cuando el número total sigue siendo el mismo (300k polígonos), ¿como se soluciona ese problema?, porque bajaría el frame rate si no se hace.

BMBx64 escribió:En copy también se puede texturizar, en libdragon puse un ejemplo hace poco de un triangulo texturizado, sin iluminación, sin corrección y sin efectos, ya que casi todo el pipeline está desactivado, muy similar a lo que comentan del Turbo3D, pero desconozco qué usa éste último.


Cierto, parece que en COPY y en FILL a 16 bits se pueden dibujar 300k polígonos, ¿alguna diferencia mas entre ambos modos a parte del texturizado?.
cegador
Adicto
477 mensajes
desde jun 2005
@BMBx64 En 2D tengo experiencia profesional en Photoshop y podría aprender a usar cualquier programa necesario más especializado en pixel art.

En 3D también tengo experiencia profesional usando 3D Studio y MODO. Sobretodo entornos y arquitectura, modelado orgánico no he hecho.

No sé si te acuerdas de mí, pero hiciste un concurso en Vandal (en un hilo hermano de este) en el que premiabas con un cable s-video de N64 y yo lo gané [beer]
Calculinho
MegaAdicto!!!
7.423 mensajes
desde ene 2010
en Galicia
Cuanto más leo, más nervioso se pone mi flashcard [mad]
BMBx64
Adicto
277 mensajes
desde may 2016
cegador escribió:En 2D tengo experiencia profesional en Photoshop y podría aprender a usar cualquier programa necesario más especializado en pixel art.

En 3D también tengo experiencia profesional usando 3D Studio y MODO. Sobretodo entornos y arquitectura, modelado orgánico no he hecho.

No sé si te acuerdas de mí, pero hiciste un concurso en Vandal (en un hilo hermano de este) en el que premiabas con un cable s-video de N64 y yo lo gané [beer]


Pues estaría genial tener alguien que se encargue de hacer modelados a medida de las especificaciones de la consola [360º]

Claro que me acuerdo, qué tal te fue el cable? notaste mejora? [hallow]

Señor Ventura escribió:¿Entonces si un polígono ocupa la mitad de la pantalla, significa que a 640x480 se lleva el solito 38.400 ciclos para ser dibujado?.

Sería un problema si algunos polígonos empiezan a requerir mas ciclos para ser pintados cuando el número total sigue siendo el mismo (300k polígonos), ¿como se soluciona ese problema?, porque bajaría el frame rate si no se hace.


He portado la demo de los cubos a la libdragon para tener un poco más de control y poder probarla en hardware, hay que tener en cuenta que en libdragon se parte de un rendimiento de 500fps de una pantalla en negro, así que estos se pueden considerar buenos resultados para lo que es la librería.

Cubos en chiquitín, se usa blend, no fill color:
Imagen

Más grandes.. vaya 1fps de diferencia, esto es porque aún con este tamaño todavía hace a tiempo lo que se le solicita y claro el RDP va en paralelo a la CPU.
Imagen

Mec.. problemas, el cubo empieza a ser demasiado grande y el RDP empieza a tardar más que el código, hace esperar a la CPU para el siguiente paso, bajan los fps, esto es a grandes rasgos lo que pasa con el 3D en estas maquinas, por eso el número de polígonos en frío no importa tanto, sino más bien lo que está pasando en pantalla, que podías poner por un decir 500K triángulos de 8x8? Bueno pero en un juego 3D vas a estar dentro de un cubo o de varios del tamaño de la pantalla, así que las cifras bajan.
Imagen

El test viene con cull back de serie, así que la cara que no se ve del cubo no se pinta, pero eso no es lo importante, imagina que cojo los 6 cubos y los pongo uno encima del otro, rotando de la misma forma, un engine óptimo solo pintaría 1 cubo, un engine antiguo de la época seguiría pintando los 6, pero sin la cara de atrás de cada uno, daría lo mismo que estuvieran juntos que separados.

Fill y copy no usan la mayoría del pipeline, por eso son tan rápidos.
Calculinho
MegaAdicto!!!
7.423 mensajes
desde ene 2010
en Galicia
No sé mucho donde preguntar esto, pero es un sueño húmedo que tengo desde que compré en 2008 mi N64 y he visto un poco más atrás un usuario que puso lo de un programa para modificar los Zeldas ¿Sería posible que alguien pillase todos los minijuegos de los tres Mario Party y los pusiese en un único juego? Sin tableros ni nada, el típico modo que traen para jugar sólo minijuegos aleatorios y que va dándo un punto a cada usuario que gana para hacer un recuento final del mejor. En resumen, una especie de Mario Party Remix 64.

He googleado y sé que hay una página donde usuarios suben nuevos tableros que hacen con un editor, pero no he visto si pueden crear minijuegos nuevos o recopilarlos como me gustaría a mi. Preguntaría por algo así también con los de GameCube y Wii; pero creo que la scene de ambas está muerta o limitada sólo a emuladores.
Flash-Original
Adicto
150 mensajes
desde mar 2016
@Calculinho Si era yo xD

Por poder se puede pero necesitas expandir la rom (depende en que mario party lo quieras meter) extraer los minijuegos de los otros y meterlos (a excepcion del menu antes del minijuego son scripts) ya que son pocas las diferencias de motor de uno a otro

Si sabes programar hay un programa que injecta asm a los juegos( hay un tutorial por ahi para mario 64 con el hello world) [angelito]

En resumen por poder se puede, pero no me suena haberlo visto

¿Lo dices por el mario party top 100 de 3ds? ratataaaa
BMBx64
Adicto
277 mensajes
desde may 2016
La verdad es que para eso habría que reprogramar bastante el juego.

Una comparativa de velocidad:
Imagen

Libn64: 418-422fps (1A2-1A5)
Libdragon: 337fps

Los tests no son exactamente los mismos, en libdragon hay controles, pero bueno, si se quitan las esperas libn64 puede alcanzar los 975fps, pero no se asegura que lo que pinte sea el display list para ese frame, sin embargo creo que hay margen de mejora desde esos 418fps, el test muestra tearing, eso es porque no usa doble buffer, usa un único buffer.

Ya se está mirando sistema de archivos eficiente, con soporte transparente de gzip, libdragon tarda hasta 47 segundos en cargar 1400 archivos de 4KB, según una charla de ayer, programando bien para la maquina esa espera se reduciría a 1 segundo.

Para no saturar más el hilo sobre esto, ya iré poniendo noticias cuando la cosa esté más avanzada. [beer]
Señor Ventura
MegaAdicto!!!
12.833 mensajes
desde ene 2014
BMBx64 escribió:Mec.. problemas, el cubo empieza a ser demasiado grande y el RDP empieza a tardar más que el código, hace esperar a la CPU para el siguiente paso, bajan los fps, esto es a grandes rasgos lo que pasa con el 3D en estas maquinas, por eso el número de polígonos en frío no importa tanto, sino más bien lo que está pasando en pantalla, que podías poner por un decir 500K triángulos de 8x8? Bueno pero en un juego 3D vas a estar dentro de un cubo o de varios del tamaño de la pantalla, así que las cifras bajan.
Imagen

El test viene con cull back de serie, así que la cara que no se ve del cubo no se pinta, pero eso no es lo importante, imagina que cojo los 6 cubos y los pongo uno encima del otro, rotando de la misma forma, un engine óptimo solo pintaría 1 cubo, un engine antiguo de la época seguiría pintando los 6, pero sin la cara de atrás de cada uno, daría lo mismo que estuvieran juntos que separados.

Fill y copy no usan la mayoría del pipeline, por eso son tan rápidos.


Es como si la nintendo 64 estuviese diseñada con cpu y gpu equivalentes, pero el downgradeo que sufrió durante su desarrollo se cargara ese equilibrio.

La cpu va a 93mhz, y el rdp/rsp a 62mhz. Por lo que cuentas, a la misma velocidad que la cpu pocos cuellos de botella debería sufrir (si hablamos de pintado).

93mhz para ambas, y una caché de texturas de 8kb, y esta máquina hubiera sido otra.

BMBx64 escribió:La verdad es que para eso habría que reprogramar bastante el juego.

Una comparativa de velocidad:
Imagen

Libn64: 418-422fps (1A2-1A5)
Libdragon: 337fps

Los tests no son exactamente los mismos, en libdragon hay controles, pero bueno, si se quitan las esperas libn64 puede alcanzar los 975fps, pero no se asegura que lo que pinte sea el display list para ese frame, sin embargo creo que hay margen de mejora desde esos 418fps, el test muestra tearing, eso es porque no usa doble buffer, usa un único buffer.

Ya se está mirando sistema de archivos eficiente, con soporte transparente de gzip, libdragon tarda hasta 47 segundos en cargar 1400 archivos de 4KB, según una charla de ayer, programando bien para la maquina esa espera se reduciría a 1 segundo.

Para no saturar más el hilo sobre esto, ya iré poniendo noticias cuando la cosa esté más avanzada. [beer]


No, por favor, tu pon todo lo que puedas, que siempre es mas que bien recibido [beer]

¿Cuanto aumento de rendimiento sueles obtener con doble buffering?.
Sogun
MegaAdicto!!!
697 mensajes
desde jul 2009
Editado 1 vez. Última: 8/12/2017 - 14:52:39 por Sogun.
@BMBx64
Pasar de 47 segundos a 1 segundo es una mejora impresionante. A ver si lo conseguís.
De todas formas 1400 archivos de 4 KB son unos 5.5 MB ¿Estáis planteando todo con el Expansion Pak en mente?

No me imaginaba que el sistema de archivos pudiera ser tan determinante. Supongo que la forma de comprimir los datos también lo es.
Por ejemplo el juego Soul Reaver de PS1 que mencionaba antes, que en principio en N64 debería de ser la consola ideal para desarrollarlo por la cantidad de RAM y la velocidad de acceso al cartucho. En PS1 el CD está lleno de datos redundantes para hacer su acceso más rápido y supongo que estarán descomprimidos para evitar cualquier tipo de de procesamiento extra y hacer el streaming más fluido. ¿En N64 se podría seguir usando este streaming mientras se descomprimen los datos o es necesario hacer pausas hasta que se descomprime todo?
En GoldenEye me parece que en RAM no se carga todo el escenario al principio (porque no hay memoria suficiente) y va cogiendo los datos del cartucho según los necesita. Al cargar nuevos trozos de mapa se producen micropausas imperceptibles en consola, pero si hay mucho nuevo que cargar entonces ya se nota más y a veces se puede ver cómo aparece el escenario de la nada (esto más en hacks, pues los niveles originales están bien diseñados para que no ocurra). En Perfect Dark ya cargaban todo el nivel de una tacada en la RAM (de ahí el uso obligatorio del Expansion Pak) para evitar estos microcortes. Por eso los niveles tardaban tanto en cargar.

Me gustaría saber cómo de factible sería un juego que fuera haciendo streaming constantemente en pequeños trozos para que lo que se muestre en pantalla esté sacando el mayor provecho de los 8 MB de RAM (nada de texturas pre-cargadas de zonas del escenario que no se ven, o modelos de enemigos y sonidos que no aparecen en pantalla). No sería necesario que fuera un juego de mundo continuo como Soul Reaver (aunque sería donde más luciría), si no que te serviría para cualquier juego donde el escenario abarcara más de lo que se muestra en pantalla.
Calculinho
MegaAdicto!!!
7.423 mensajes
desde ene 2010
en Galicia
@Flash-Original llevo soñando con ello desde mucho antes de ese Mario Party Top 100; pero ahora me ha calentado la cabeza porque tras años esperando algo así para jugar con mis amigos, me lo sacan para un hardware donde tendría que comprar tres portátiles más para jugar con ellos. cawento

No sé programación, pero si dices que es posible estaré atento a la web que encontré de hacks y mods de los Mario Party, quizás ahora con el lanzamiento este para 3DS a alguien se le ocurra hacerlo [jaja]

Gracias.
172, 73, 74, 75, 76