Hilo de detalles y curiosidades de N64

¡POLE PÁGINA 64! ¿Qué he ganado?

Pues con una consola de las viejas, y la placa de uno de esos EP clónicos con dos chips, reemplazandolos todos por chips de 4MB quizá se podrían llegar los 16MB, aunque no sirvan para nada en juegos licenciados sin modificar, o las librerías de desarrollo existentes. Si bien no veo ningún motivo por el que, asumiendo que semejante montaje arranque, no pudiese la CPU acceder a toda esa RAM. El único problema (y no digo que sea pequeño) sería modificar el software para usar toda esa RAM. Pero esta cuestión, aparte de ser una fantasía a día de hoy, es algo que no creo que nadie vaya a dedicar esfuerzo alguno a materializar, y aún si se hiciese, no sería algo que fuese a tener gran adopción entre los usuarios, y por tanto tampoco habría abundancia de software que lo usase, por muchos motivos, empezando por la disponibilidad de los necesarios chips RDRAM compatibles con la consola.

Estoy de acuerdo con tu teoría de por qué el controlador de memoria acepta 4 chips. Bien visto.

Claro que esos EP clónicos, por usar dos chips en ese espacio cerrado con poca refrigeración explicaría por qué dice la gente que los EP clónicos se recalientan y y provocan que se cuelgue la consola.
Yo nunca tuve uno de esos, pues en cuanto a hardware siempre preferí las versiones oficiales. Otra cosa son los cacharros raros, pero para algo como el EP, no me hubiese inspirado confianza usar uno clónico con carcasas raras.
Claro que eso explica por qué la mayoría de esos reemplazaban la tapa original con su propia protuberancia fea externa como forma de mejorar la disipación de calor.

Lo que dices de los 2.25MB se entiende por el noveno bit, como resultado de contar los bits en bruto y luego convertirlos a bytes estandarizados de 8 bit, pero si lo cuentas como bytes de 9 bit, que es como los usa el RCP, siguen siendo 2 y 4 megas exactos
Imagino que el noveno bit solo es accesible por el RCP para sus cosas internas (¿se le conoce algún otro uso aparte de almacenar los valores precalculados para la segunda mano de AA que hace el VI?), y dudo que sea visible por la CPU, a la que solo se le muestran los primeros 8.

En fin, vine por la mención, pero como ya no tengo nada de esto, me resulta un tanto raro seguir el hilo.

masteries escribió:Hola Conker64,

¿Has podido echarle el guante durante estos días?

Gracias anticipadas,

Hola, sí, estuve mirando este fin de semana, la rama stable sigue siendo la misma de siempre, creando comandos que van a un buffer de RAM y los lee el RDP, luego tienen la rama unstable con algo experimental que me llama más la atención.

En lugar de subir a la RAM ya los manda directamente al RSP, como si fuera parte de un microcódigo, es buena idea pero esa parte tengo que estudiarla bien, leyendo de RAM se pueden saltar la mayoría de sync/wait to pipe y similares, pero no desde el RSP que es más rápido.

De todas formas me bajaré las 2 y las intentaré compilar, antes de ponerme con el resto

Necesitas el código de la función de carga de texturas de N64 para PC? Los primeros tests que hice en N64 los ejecutaba en PC y luego cambiaba 4 líneas para portarlos a N64.

radorn escribió:Imagino que el noveno bit solo es accesible por el RCP para sus cosas internas (¿se le conoce algún otro uso aparte de almacenar los valores precalculados para la segunda mano de AA que hace el VI?), y dudo que sea visible por la CPU, a la que solo se le muestran los primeros 8.

De forma general el noveno bit se usa como comprobador de paridad para chequear que un byte se ha transmitido o guardado correctamente y no se ha producido un fallo.

En la N64 ni idea de como se usa, lo que había oido hace muchos años es algo del z-buffer, lo cual es ridículo porque no basta para esa información si no fuese en un gran grupo de bytes. Lo del AA si tiene sentido, recuerdo vagamente haber visto una tabla o algo así con lo que se aplicaba, supongo que estará por el hilo.

Aparte de eso, ni idea del uso del noveno bit.

EMaDeLoC escribió:Lo del AA si tiene sentido, recuerdo vagamente haber visto una tabla o algo así con lo que se aplicaba, supongo que estará por el hilo.

Normalmente en N64 se usa búfer de 16 bits. Eso supone 2 bytes por pixel, lo cual nos deja 2 bits extra con la memoria de 9 bits.
Con 2 bits se puede contar de 0 a 3, o sea, 4 valores.
Si tienes alguna forma de hacer una buena captura de la consola, que creo que si, saca una imagen de alguna escena donde haya un borde flotante/externo: o sea, una arista superpuesta a un fondo donde no haya conexión "fisica" entre dichos triángulos. No valen dos aristas conectadas por los mismos vertices, donde el antialiasing es "interno".
Este tipo de aristas flotantes se renderizan internamente sin AA en el framebuffer, pero normalmente el RDP calcula un valor de 2 bit por cada pixel que se almacenan ahí. Estos valores los usa el VI para mezclar el color del pixel en cuestión con una cantidad especifica de del color de los pixels adyacentes. No conozco los detalles exactos de qué pixels se toman en cuenta para este calculo, pero la proporción de la mezcla se determina por ese valor de 2 bits.

Si capturas un borde como el que describo (lo haría yo, pero no tengo con qué), donde haya un angulo no muy acentuado respecto al plano horizontal, podrás apreciar que en el "suavizado" hay un patrón de cuatro "escalones" donde un escalon es "sólido" y luego otros tres estan "difuminados" en distinto grado y vuelta a empezar.
Esta es la segunda mano de AntiAliasing que hace el VI.

Seguramente no sigan en en pie, pero había subido en su día un zip con capturas de framebuffer hechas con un ActionReplay donde se podía ver la diferencia entre lo que hay en el framebuffer y lo que sale después por el VI, que aplica esa segunda mano de AA, escalado horizontal y vertical, interpolación, o lo que se tercie según la programación de turno.

Habiendo escrito todo esto, ahora me pregunto si el Z-Buffer también hace uso de estos bits extra... aunque imagino que no. 2 bit extra por pixel implica una precisión 4 veces mayor para la profundidad, que no está nada mal, pero, igual que tu, tampoco creo que lo usen.
De hecho, con el ActionReplay, activando el "generador de trucos" también se puede ver toda la RAM interpretada imagen de framebuffer. Con esto se pueden ver los framebuffers en uso, normalmente do (aunque se supone que la consola puede hacer triple búfer...?), el terminado que se está mostrando, y el que está en construcción, donde depende de la suerte que tengas puedes ver la escena a medio dibujar, o sea, algunos poligonos dibujados y otros aún no. Con este visor, también puedes desplazarte por toda la RAM y llegar a encontrar el z-bufer y verlo como imagen. Los recuerdos que tengo de el no me sugieren que me estuviese perdiendo un bit de precisión, aunque realmente no tengo forma de discernir tal cosa con certeza.

Conker64 escribió:

masteries escribió:Hola Conker64,

¿Has podido echarle el guante durante estos días?

Gracias anticipadas,

Hola, sí, estuve mirando este fin de semana, la rama stable sigue siendo la misma de siempre, creando comandos que van a un buffer de RAM y los lee el RDP, luego tienen la rama unstable con algo experimental que me llama más la atención.

En lugar de subir a la RAM ya los manda directamente al RSP, como si fuera parte de un microcódigo, es buena idea pero esa parte tengo que estudiarla bien, leyendo de RAM se pueden saltar la mayoría de sync/wait to pipe y similares, pero no desde el RSP que es más rápido.

De todas formas me bajaré las 2 y las intentaré compilar, antes de ponerme con el resto

Necesitas el código de la función de carga de texturas de N64 para PC? Los primeros tests que hice en N64 los ejecutaba en PC y luego cambiaba 4 líneas para portarlos a N64.

La rama unstable tiene implementado una cola de envio al rdp y rsp (rdpq y rspq) con las que han creado los distintos microcodigos.
Sobre estos, han creado una implementación opengl 1.1 (con algunas extensiones) para facilitar el desarrollo y ports de antiguos juegos de pc

radorn escribió:¡POLE PÁGINA 64! ¿Qué he ganado?

Pues con una consola de las viejas, y la placa de uno de esos EP clónicos con dos chips, reemplazandolos todos por chips de 4MB quizá se podrían llegar los 16MB, aunque no sirvan para nada en juegos licenciados sin modificar, o las librerías de desarrollo existentes. Si bien no veo ningún motivo por el que, asumiendo que semejante montaje arranque, no pudiese la CPU acceder a toda esa RAM. El único problema (y no digo que sea pequeño) sería modificar el software para usar toda esa RAM. Pero esta cuestión, aparte de ser una fantasía a día de hoy, es algo que no creo que nadie vaya a dedicar esfuerzo alguno a materializar, y aún si se hiciese, no sería algo que fuese a tener gran adopción entre los usuarios, y por tanto tampoco habría abundancia de software que lo usase, por muchos motivos, empezando por la disponibilidad de los necesarios chips RDRAM compatibles con la consola.

Estoy de acuerdo con tu teoría de por qué el controlador de memoria acepta 4 chips. Bien visto.

Claro que esos EP clónicos, por usar dos chips en ese espacio cerrado con poca refrigeración explicaría por qué dice la gente que los EP clónicos se recalientan y y provocan que se cuelgue la consola.
Yo nunca tuve uno de esos, pues en cuanto a hardware siempre preferí las versiones oficiales. Otra cosa son los cacharros raros, pero para algo como el EP, no me hubiese inspirado confianza usar uno clónico con carcasas raras.
Claro que eso explica por qué la mayoría de esos reemplazaban la tapa original con su propia protuberancia fea externa como forma de mejorar la disipación de calor.

Lo que dices de los 2.25MB se entiende por el noveno bit, como resultado de contar los bits en bruto y luego convertirlos a bytes estandarizados de 8 bit, pero si lo cuentas como bytes de 9 bit, que es como los usa el RCP, siguen siendo 2 y 4 megas exactos
Imagino que el noveno bit solo es accesible por el RCP para sus cosas internas (¿se le conoce algún otro uso aparte de almacenar los valores precalculados para la segunda mano de AA que hace el VI?), y dudo que sea visible por la CPU, a la que solo se le muestran los primeros 8.

En fin, vine por la mención, pero como ya no tengo nada de esto, me resulta un tanto raro seguir el hilo.

No importa si son fantasias o si su implementación requiere de un esfuerzo por adecuar software.

El tema aquí es que una n64 puede calzar 16MB de ram, y que se podrían hacer cosas con ella...

¿Cuales?

Señor Ventura escribió:No importa si son fantasias o si su implementación requiere de un esfuerzo por adecuar software.

El tema aquí es que una n64 puede calzar 16MB de ram, y que se podrían hacer cosas con ella...

¿Cuales?

Pues hombre, menos aumentar la velocidad de proceso, cualquier cosa que dependa de RAM.
Así a botepronto se me ocurren las siguientes posibilidades:
-Mayor nivel de persistencia de estado en objetos dinámicos (seguro que hay un mejor nombre técnico para ello): agujeros de bala, cuerpos de enemigos, marcas de pisadas, posiciones y estados de todo tipo de objetos... Combinado con el uso de almacenamiento secundario como una tarjeta SD, hasta podrían hacerse permanentes hasta cierto límite.
-Pre-carching o precarga dinámica en segundo plano de zonas del mapa adyacentes a la actual en un potencial juego de mundo abierto (Aidyn Chronicle), para una experiencia sin cortes, o también cualquier otro tipo de recurso como NPCs u otros objetos. Según las necesidades de cada juego, podría hacerse en un proceso de baja prioridad contando con que el propio progreso del juego proporcionaría una generosa ventana de tiempo para terminar la carga de esos recursos mucho antes de ser utilizados.
-Mover a RAM cosas como animaciones, y de muestras de audio para efectos y música, que normalmente se cargan dinámicamente desde ROM para cada fotograma, para así no ocupar la escasa RAM (4 u 8 MB). Con 16MB se puede mover buena parte de eso a RAM y dejar el relativamente lento acceso a ROM para carga dinámica de otras cosas, como en el anterior punto.
-Generación dinámica de recursos como escenarios y distribución de objetos (aunque quizá sea abusar de la capacidad de proceso de la consola dependiendo de a donde quiera uno llegar).
-Reducción de limitaciones en software creativo como Mario Artist, al poder trabajar con mas datos de cada vez.
-¿...Inteligencia rtificial generativa? xDD En fin, por ambición que no quede.

radorn escribió:

Señor Ventura escribió:No importa si son fantasias o si su implementación requiere de un esfuerzo por adecuar software.

El tema aquí es que una n64 puede calzar 16MB de ram, y que se podrían hacer cosas con ella...

¿Cuales?

Pues hombre, menos aumentar la velocidad de proceso, cualquier cosa que dependa de RAM.
Así a botepronto se me ocurren las siguientes posibilidades:
-Mayor nivel de persistencia de estado en objetos dinámicos (seguro que hay un mejor nombre técnico para ello): agujeros de bala, cuerpos de enemigos, marcas de pisadas, posiciones y estados de todo tipo de objetos... Combinado con el uso de almacenamiento secundario como una tarjeta SD, hasta podrían hacerse permanentes hasta cierto límite.
-Pre-carching o precarga dinámica en segundo plano de zonas del mapa adyacentes a la actual en un potencial juego de mundo abierto (Aidyn Chronicle), para una experiencia sin cortes, o también cualquier otro tipo de recurso como NPCs u otros objetos. Según las necesidades de cada juego, podría hacerse en un proceso de baja prioridad contando con que el propio progreso del juego proporcionaría una generosa ventana de tiempo para terminar la carga de esos recursos mucho antes de ser utilizados.
-Mover a RAM cosas como animaciones, y de muestras de audio para efectos y música, que normalmente se cargan dinámicamente desde ROM para cada fotograma, para así no ocupar la escasa RAM (4 u 8 MB). Con 16MB se puede mover buena parte de eso a RAM y dejar el relativamente lento acceso a ROM para carga dinámica de otras cosas, como en el anterior punto.
-Generación dinámica de recursos como escenarios y distribución de objetos (aunque quizá sea abusar de la capacidad de proceso de la consola dependiendo de a donde quiera uno llegar).
-Reducción de limitaciones en software creativo como Mario Artist, al poder trabajar con mas datos de cada vez.
-¿...Inteligencia rtificial generativa? xDD En fin, por ambición que no quede.

Te lo compro todo.

¿Triple buffer...? xD

Señor Ventura escribió:¿Triple buffer...? xD

No estoy seguro de cómo va el tema de los búfers de video en N64. Por menciones de las revista de la época, creo recordar que se mencionaba el triple búfer. No tengo ni idea de si esa información es correcta o no, ni se qué juegos lo emplean, si es que alguno lo hace.

Sea como sea, un búfer típico de 320x240 de 16bit ocupa 150 KB en RAM, y para 640x480 son 600KB, así que con eso calcula. Se puede tener triple búfer 240p a cambio de 450KB de RAM, que supone un 11% de la RAM de serie. Es perfectamente factible, dependiendo del juego.

La verdad es que no tengo claro cómo funciona y cuales son los beneficios y detrimentos de usar triple búfer en vez de doble dependiendo de las situaciones, pero diría que el búfer triple parece ser beneficioso cuando la tasa de renderizado se acerca mucho o incluso supera el refresco de la pantalla.

En el caso de N64, que habitualmente va bastante justa de rendimiento, no estoy seguro de que usar un búfer triple ofrezca ventajas. Mas bien parece que provocaría mas lag sin ninguna contrapartida, o muy poca. Que alguien me corrija si considera que me equivoco. Es un tema que no tengo claro.

----------------------
http://n64.icequake.net/doc/n64intro/ka ... 2/4-2.html
documentación oficial sobre el búfer triple

Así que si, se puede, y está contemplado. Pero también se advierte que aumenta el retraso entre darle al mando y ver el resultado en pantalla, como imaginaba.
Es cuestión de escoger el equilibrio adecuado entre costes y contrapartidas para cada situación.

Un búfer triple de 640x480x16b supondría 1800KiB de RAM (1.76MiB) pero claro, renderizar a tal resolución ya es costoso de por si. Lo que no se es si hay un solo juego que tenga tal resolución a nivel de framebuffer. Desde luego, ninguno de los juegos populares que usan 480i/576i renderizan a esa resolución completa. Turok 2 renderiza a una resolución inferior, algo a medio camino entre 240 y 480. Quizá algún menú de ciertos juegos renderize esa resolucion a escala 1:1 (quizá el libro de los Bomber de Majora's Mask), pero en general se usa escalado por VI en casi todos los juegos que sacan esos modos de video. Recuerdo probar un juego de ajedrez, cuyo nombre no recuerdo, que me dió la impresión de que quizá si tenía 480p real, pero no lo llegué a comprobar meticulosamente. En cualquier caso el rendimiento era atroz en alta resolución aún con un escenario mínimo consitente en el tablero de juego con las piezas sobre fondo negro, y alguna animación grotesca para ilustrar que una pieza toma otra.

@celgadis_84
Ya, eso vi.

--
He estado mirando todo el procedimiento de instalación de libdragon y creo que no haría falta un tutorial, lo han simplificado muchísimo, antiguamente había que compilar por ti mismo los binarios sin demasiadas indicaciones (1 o varias horas dependiendo de la CPU), ahora ya te dan hasta los binarios cocinados, yo diría que cualquier desarrollador que quiera programar para N64 debería estar de enhorabuena.

Pero lo haré, no he usado Docker (opción 1) y creo que WSL2 limitaría a usuarios de Win10 para arriba, creo que me inclinaré por un tutorial de MSYS2.

En cuanto a MKSPRITE la han modernizado, con soporte para todas las texturas que soporta N64 (antiguamente solo 16/32bit), con soporte mip map y demás, miraré, aunque dudo que para un juego 2D se le pueda sacar partido a según que tipo de texturas o el mip map.

Conker64 escribió:

masteries escribió:Hola Conker64,

¿Has podido echarle el guante durante estos días?

Gracias anticipadas,

Hola, sí, estuve mirando este fin de semana, la rama stable sigue siendo la misma de siempre, creando comandos que van a un buffer de RAM y los lee el RDP, luego tienen la rama unstable con algo experimental que me llama más la atención.

En lugar de subir a la RAM ya los manda directamente al RSP, como si fuera parte de un microcódigo, es buena idea pero esa parte tengo que estudiarla bien, leyendo de RAM se pueden saltar la mayoría de sync/wait to pipe y similares, pero no desde el RSP que es más rápido.

De todas formas me bajaré las 2 y las intentaré compilar, antes de ponerme con el resto

Necesitas el código de la función de carga de texturas de N64 para PC? Los primeros tests que hice en N64 los ejecutaba en PC y luego cambiaba 4 líneas para portarlos a N64.

Gracias,

Respecto a la pregunta... lo que necesito es poder hacer lo que hacías con la demo de scroll de Golden Axe, y con las demos de dibujar sprites...

poder tener soporte, control de sprites y varias capas de scroll usando paletas/texturas de 4 bits;
todo lo que queremos hacer es sólo en 2D

Por mi parte utilizo Win7 y MSYS2

Conker64 escribió:Todo esto es muy vago y se puede ampliar, veamos si enganchamos a alguien más para programar en N64 y si interesa expandir

Gracias por el esfuerzo. Ardo en deseos de verlo; a ver si se animan.

@Conker64 que currada de post.

A mi me llama la atención la n64, y le tengo un ojo echado porque tengo la impresión de que va a pegar un petardazo de rendimiento, pero en cuanto pueda volcarme con algo me apetece mas la super nintendo.

Tu encárgate de alcanzar los 200 mil polígonos postprocesados por segundo, y yo te aplaudo desde la barrera

Conker64 escribió:INSTALAR LIBDRAGON

--
@masteries
Ok bueno ya estoy en ello, cuando tenga resultados te aviso

¡Muchísimas gracias!


@gynion

Nosotros ya estamos animados,

masteries escribió:@gynion

Nosotros ya estamos animados,

De vosotros (tú y Conker) ya me consta eso, pero a los que aportáis prefiero no presionaros y esperar a lo que os salga de ahí ofrecer. A mí además las demos técnicas o experimentos me dan curiosidad de por sí; no preciso juegos completos.

Hablando de desarrollos en N64:


Es una brutalidad hasta que punto esta llevando el port.

EMaDeLoC escribió:Hablando de desarrollos en N64:

Es una brutalidad hasta que punto esta llevando el port.

Para mi este port es una de las demostraciones de que n64 era brutalmente superior a sus coetaneas y estaba mas cerca de una dreamcast que de una psx

EMaDeLoC escribió:Hablando de desarrollos en N64:

Es una brutalidad hasta que punto esta llevando el port.

Y ese mismo autor:



Es un vídeo, que nadie se venga arriba diciendo que N64 es una Wii Pro.

EMaDeLoC escribió:Hablando de desarrollos en N64:

Es una brutalidad hasta que punto esta llevando el port.

Pues de entrada, esas físicas... quizás sea la única máquina de aquella generación capaz de soportarlas en un ambiente complejo.

Es la clase de cosas que a lo mejor tenían que haberse explotado mas.

Kaze ha publicado otro vídeo optimizando su versión de Mario 64.

En realidad es más bien un vídeo de porno de matemáticas, pero esta interesante.

James Lambert ya ha publicado un vídeo explicando cómo funcionan las megatexturas en Nintendo 64.



Hay trozos del vídeo muy ilustrativas donde se muestra entiempo real como el mapa de memoria va cargando las texturas que se utilizan en pantalla. Lo más impresionante es que está usando sólo 4 MB, así que pienso que sería posible disimular muchísimo más los cambios bruscos de detalle de las texturas.
Confirma que el escenario usa unos 40 MB de texturas divididas en trozos de 32x32 píxeles de resolución (y supongo que 16 bits de color).

Pero lo que no me termina de quedar claro porque me había hecho una idea distinta de lo que entiendo en el vídeo es que no se usa teselación para ir acoplando trozos de texturas con más detalle, si no que la geometría se mantiene simple y que un algoritmo decide qué "nivel de mipmap" (porque son todo texturas pregeneradas) es el que se utiliza. Habrían logrado en la práctica superar el límite de los 4 kB de la caché porque estarían aplicando múltiples texturas en un mismo polígono, algo que ningún juego comercial logró.

A ver si alguien lo puede explicar mejor y me corrige, porque esto me ha dejado más loco todavía.

Sogun escribió:James Lambert ya ha publicado un vídeo explicando cómo funcionan las megatexturas en Nintendo 64.

Hay trozos del vídeo muy ilustrativas donde se muestra entiempo real como el mapa de memoria va cargando las texturas que se utilizan en pantalla. Lo más impresionante es que está usando sólo 4 MB, así que pienso que sería posible disimular muchísimo más los cambios bruscos de detalle de las texturas.
Confirma que el escenario usa unos 40 MB de texturas divididas en trozos de 32x32 píxeles de resolución (y supongo que 16 bits de color).

Pero lo que no me termina de quedar claro porque me había hecho una idea distinta de lo que entiendo en el vídeo es que no se usa teselación para ir acoplando trozos de texturas con más detalle, si no que la geometría se mantiene simple y que un algoritmo decide qué "nivel de mipmap" (porque son todo texturas pregeneradas) es el que se utiliza. Habrían logrado en la práctica superar el límite de los 4 kB de la caché porque estarían aplicando múltiples texturas en un mismo polígono, algo que ningún juego comercial logró.

A ver si alguien lo puede explicar mejor y me corrige, porque esto me ha dejado más loco todavía.

Solo he visto un trocito, pero era lo esperable. Un streaming constante de texturas con muchos niveles de LOD y mip mapping para que las transiciones sean tan suaves, que de hecho ni parece que se esté usando ningún mip mapping.

Esto por supuesto solo es posible gracias a los accesos de un cartucho, y no es que se haya superado el límite de 4KB de la caché, es que está borrando y escribiendo constantemente todo lo que se va quedando fuera de la cámara, y todo lo que se va enfocando.

Lo mejor es que efectivamente puede hacerse con habitaciones mas grandes, implementando mas niveles de LOD y mip mapping sin sacrificar detalles, porque si miras al horizonte, no miras de cerca una pared, y viceversa. Con el expansion pack multiplicas la distancia de dibujado por muchas, pero muchas veces, pero seguro (4MB adicionales para texturas ínfimamente mas pequeñas, podríamos estar hablando de tamaños de mapeado muy grandes, mientras se usan algunas para transiciones, y mientras se carga el resto para nuevas zonas, sin recurrir al cambio de zonas. Todo transiciones).

En definitiva, que una n64 come en la mesa de una dreamcast, aunque tenga que servir los cafés primero, y esperar a que se levante


La única duda es a que resolución corre, creo que lo ha mencionado pero no he prestado atención, y no he rebobinado.

@Señor Ventura tampoco exageres Dreamcast caga por encima de toda la quinta gen junta mientras estas les dan las gracias por ello.

Sogun escribió:Pero lo que no me termina de quedar claro porque me había hecho una idea distinta de lo que entiendo en el vídeo es que no se usa teselación para ir acoplando trozos de texturas con más detalle, si no que la geometría se mantiene simple y que un algoritmo decide qué "nivel de mipmap" (porque son todo texturas pregeneradas) es el que se utiliza. Habrían logrado en la práctica superar el límite de los 4 kB de la caché porque estarían aplicando múltiples texturas en un mismo polígono, algo que ningún juego comercial logró.

Igual me equivoco pero si no lo he entendido mal, un polígono con una megatextura única, por ejemplo la vidriera de la pistola, esta dividido en tiles de forma virtual. Cuando se han de dibujar, le manda al RCP dibujar el triángulo con el tile correspondiente. Como este tile no ocupa todo el triángulo, dejará huecos sin pintar, pero no pasa nada, porque se pintaran con el siguiente tile.

Es decir, le pasa al RCP un triángulo con una textura que se pintará en unas coordenadas de este triángulo sin completarlo del todo, y luego le vuelve a pasar el mismo triángulo pero con otra textura que se pinta en otras coordenadas de este triángulo. Conforme se va pintando las diferentes texturas, se va pintando todo el triángulo y luego toda la pantalla conforme se pinten triángulos. De esta forma la geometría es simple, ahorrando espacio de memoria, que se usa en almacenar las texturas, o tiles, que requiere la habitación.

Es una técnica que se puede usar en juegos corrientes sin necesidad de llegar a absurdos de los 40MB. Por ejemplo, una pared que mejore el detalle sin necesidad de teselación pasando de 1 a 4 texturas, y con el mipmapping de forma suave.

Es una técnica interesante.

Kaze Emunar sigue con su modificación de Mario 64 y nos muestra que la consola puede pintar miles de triángulos sin despeinarse.

EMaDeLoC escribió:Kaze Emunar sigue con su modificación de Mario 64 y nos muestra que la consola puede pintar miles de triángulos sin despeinarse.

Pasando del z-buffer se ahorra mucho ancho de banda de memoria, como ya hace World Driver Championship.

Es que es una pasada lo de esta máquina, lo infrautilizada que estuvo.

La oclusión ambiental, lo que te ahorras quitando el z-buffer, las ventajas del cartucho a la hora de cargar grandes texturas... y ahora resulta que si que puede dibujarte 10k polígonos en pantalla como si nada, ¡eso son cifras de una sega model 2! (aunque a menos resolución, menos capacidad para almacenar texturas simultáneas, pero conservando el filtrado, antialiasing, etc).

Y es que encima da la impresión de que no ha tocado techo.

@Señor Ventura Hay que decir que parece un caso concreto, ya que son triángulos con la misma textura y por tanto no hay que recargar nada de la RAM dejando mucho ancho de banda disponible.

EMaDeLoC escribió:@Señor Ventura Hay que decir que parece un caso concreto, ya que son triángulos con la misma textura y por tanto no hay que recargar nada de la RAM dejando mucho ancho de banda disponible.

Si, está claro, pero la clave está en que, caber, caben unas cuantas texturas en la ram. Igual también influye no tener que mover una textura de la caché, pero si hay que estar moviendo una (misma textura) a esa memoria (caché) cada vez que quieras pintar un polígono... ahí lo tendríamos.

Es dudable, pero bueno.


Mi curiosidad es ver hasta donde llega sin texturizar, tipo virtua racing, porque a menos que exista la posibilidad de mejora, el tope real de la consola son los 180 mil polígonos del wdc (¿o eran 120K?).

Señor Ventura escribió:

EMaDeLoC escribió:@Señor Ventura Hay que decir que parece un caso concreto, ya que son triángulos con la misma textura y por tanto no hay que recargar nada de la RAM dejando mucho ancho de banda disponible.

Si, está claro, pero la clave está en que, caber, caben unas cuantas texturas en la ram. Igual también influye no tener que mover una textura de la caché, pero si hay que estar moviendo una (textura) a esa memoria (caché) cada vez que quieras pintar un polígono... ahí lo tendríamos.

Es dudable, pero bueno.


Mi curiosidad es ver hasta donde llega sin texturizar, tipo virtua racing, porque a menos que exista la posibilidad de mejora, el tope real de la consola son los 180 mil polígonos del wdc (¿o eran 120K?).

Sin texturizar y sino recuerdo mal ya llegaba la PS1 a 120K en Tobal y a 640x480, así que en N64 en ese mismo contexto tiene que ser más. Los datos oficiales del Turbo 3D eran 300K y no me parece ninguna exageración.

Es que Kaze también parte de un juego que usa el microcodigo más viejo, hay muchas cosas que dice en el video que el último microcodigo F3DX2 ( Zelda OoT) ya hacía, como usar Zsort, para reducir el sobrepintado de superficies, también es verdad que los Zeldas van a 20Fps, pero también usan mucho 2 cycle en superficies ( suelos con 2 texturas, Trilinear mipmapping, niebla atmosférica, reflejos en superficies metálicas, simulación de reflejos cáusticos del agua, iluminación dinámica + fuente de luz independiente ( antorchas, navi, ) ect...).

En este video que hice yo, la escena tiene +8.000 polígonos y unas 30 texturas únicas y lo mueve bien en la N64, excepto cuando se ve todo el escenario que salta el Frameskip y se pone a 15 fps.El video es viejo y tengo cosas cambiadas para mejorar el rendimiento como LOD en los reactores.

Eso si todo el curro de depuración y optimización del código fuente del Mario es increíble, y es lo que le hace ganar mucho rendimiento.

Salud.

@dirtymagic 8000 y en los otros hilos pegandonos por si PS1 o SS eran putentes con picos de 1300 🤣

SuperPadLand escribió:@dirtymagic 8000 y en los otros hilos pegandonos por si PS1 o SS eran putentes con picos de 1300 🤣

8000 es toda la escena, no sé cuánto estará renderizando cuándo está la cámara más alejada, con el backculling y el Z-Sort, tal vez el 60% de la escena, sin físicas (el escenario no tiene colisiones) y las cinemáticas se pone a "16:9" y supongo que bajará la resolución de pantalla con las franjas negras, pero vamos en las extracciones de escena que hizo conker64 en su día, ya se veía que renderiza unos 4.000 polígonos por frame en juego real en el Majoras Mask.

Salud.

SuperPadLand escribió:@dirtymagic 8000 y en los otros hilos pegandonos por si PS1 o SS eran putentes con picos de 1300 🤣

Mmmm... Si no recuerdo mal algunos escenarios del Mario 64 tenían 2000 o 3000 y podías ver practicamente todo el escenario.

@EMaDeLoC
Sí, por ahí anda los escenarios de SM64, renderiza algo menos, porque creo que el backculling estaba disponible desde el primer microcódigo, todo a 1 cycle ( no usa Trilinear mip mapping, escepto en el cuadro de Bowser/Peach ) y 2 cycle en Mario metálico, lo más seguro es que renderice unos 2000~2500 polígonos por fotograma.

Salud.

Otra funcionalidad interesante de la N64 que en manos creativas se convierte en una genialidad difícil de replicar:

@EMaDeLoC

Interesante, genialidad creativa, y algo dificil de replicar al emular juegos de N64, pero para nada dificil de replicar en sí.

EMaDeLoC escribió:Otra funcionalidad interesante de la N64 que en manos creativas se convierte en una genialidad difícil de replicar:

Lo mejor es lo bien que lo explica y otro ejemplo de como N64 adelantó en técnicas que terminaron siendo el estándar en las siguientes generaciones.

gynion escribió:Interesante, genialidad creativa, y algo dificil de replicar al emular juegos de N64, pero para nada dificil de replicar en sí.

Bueno, a eso me refería, que era difícil de replicar en el emulador, no en general.

EMaDeLoC escribió:

gynion escribió:Interesante, genialidad creativa, y algo dificil de replicar al emular juegos de N64, pero para nada dificil de replicar en sí.

Bueno, a eso me refería, que era difícil de replicar en el emulador, no en general.

Sabes si existe algún truco o cutreza para hacer algo parecido en PS1 o SS?

SuperPadLand escribió:

EMaDeLoC escribió:

gynion escribió:Interesante, genialidad creativa, y algo dificil de replicar al emular juegos de N64, pero para nada dificil de replicar en sí.

Bueno, a eso me refería, que era difícil de replicar en el emulador, no en general.

Sabes si existe algún truco o cutreza para hacer algo parecido en PS1 o SS?

Con mip-mapping no. Puedes usar mip-mapping en PS1 y SS pero la textura que utilices la tienes que decidir para cada polígono antes de enviarla a la GPU, así que las transiciones serían muy evidentes (pasaría algo parecido a la niebla del Mega Man Legends de PS1)

Puedes hacer algo parecido con vertex colors, presuponiendo una geometría decentemente subdivida, y a costa de ciclos de la CPU. O con dobles texturas como la niebla de Soul Reaver a costa de las dos (la CPU y la GPU)

Esto lo ha usado más veces Nintendo después, por ejemplo el agua de Super Mario Sunshine utiliza un mipmap de por el medio para darle esos puntos de brillo.

dirtymagic escribió:Es que Kaze también parte de un juego que usa el microcodigo más viejo, hay muchas cosas que dice en el video que el último microcodigo F3DX2 ( Zelda OoT) ya hacía, como usar Zsort, para reducir el sobrepintado de superficies, también es verdad que los Zeldas van a 20Fps, pero también usan mucho 2 cycle en superficies ( suelos con 2 texturas, Trilinear mipmapping, niebla atmosférica, reflejos en superficies metálicas, simulación de reflejos cáusticos del agua, iluminación dinámica + fuente de luz independiente ( antorchas, navi, ) ect...).

En este video que hice yo, la escena tiene +8.000 polígonos y unas 30 texturas únicas y lo mueve bien en la N64, excepto cuando se ve todo el escenario que salta el Frameskip y se pone a 15 fps.El video es viejo y tengo cosas cambiadas para mejorar el rendimiento como LOD en los reactores.

Eso si todo el curro de depuración y optimización del código fuente del Mario es increíble, y es lo que le hace ganar mucho rendimiento.

Salud.

No había visto esto antes, mu chulo!

SuperPadLand escribió:

EMaDeLoC escribió:

gynion escribió:Interesante, genialidad creativa, y algo dificil de replicar al emular juegos de N64, pero para nada dificil de replicar en sí.

Bueno, a eso me refería, que era difícil de replicar en el emulador, no en general.

Sabes si existe algún truco o cutreza para hacer algo parecido en PS1 o SS?

Creo que PS1 no tiene capacidad de mipmapping, se tendría que hacer a base de CPU y cambiando las texturas.
Saturn me parece que lo mismo.

En ambos casos programando un cambio de texturas según la distancia se podría hacer, pero no sé si vale la pena ocupar memoria o gastar CPU con las distintas texturas de transición. La N64 solo necesitaría dos y la transición se haría por hardware automaticamente.

Otra prueba más de que Nintendo roba los emuladores, los renombra y ya tiene el trabajo hecho.

Viendo como tratan la scene, es que casi ni tengo dudas.

En el discord de Fast64 ( plugin de Blender para exportar a las descopilaciones de SM64 y OoT) han colgado un documento donde sale el rendimiento por frame ( sólo gráficos) con diferentes configuraciones de FrameBuffer, Z- Buffer, Z- Fail ( sombras proyectadas), con búfer separados, juntos ect.
Os dejo los resultados.Todo de parte del usuario Tharo.

All are 320x240 rgba16 fillrect, each ran 1000 times and results averaged.

Note only the first 2-3 decimals are meaningful. Numbers that are close together
should be considered the same speed, as different runs may reorder such results.

The timing method uses the RDP counter registers BUFBUSY and PIPEBUSY. These are
reset to 0 before the RDP is woken up from idle so they begin counting precisely
when the processing begins. A single fullscreen fillrect is processed before a
fullsync, which returns the RDP to idle and stops the counters automatically.
This produces highly precise timings, the only variance is due to variation in
stall times for waiting on RDRAM accesses. All setup is done prior to resetting
the counters in a separate RDP command list.

force_blend does not affect timings. If image_read (IM_RD) is on the RDP will
fetch spans from the color image irrespective of whether the span contains any
edge pixels.

Numbers are: min time, average time, max time



No ZB, No VI
image_read off
1-cycle
Buf: 1.2873920ms, 1.2879956ms, 1.2889920ms
Pipe: 1.2874720ms, 1.2880889ms, 1.2890880ms
2-cycle
Buf: 2.5176000ms, 2.5182880ms, 2.5190720ms
Pipe: 2.5176480ms, 2.5183484ms, 2.5191360ms
image_read on
1-cycle
Buf: 2.6149760ms, 2.6168881ms, 2.6184640ms
Pipe: 2.6154240ms, 2.6172602ms, 2.6188160ms
2-cycle
Buf: 2.5916480ms, 2.5933406ms, 2.5950400ms
Pipe: 2.5916960ms, 2.5934009ms, 2.5951040ms

No ZB, VI
FB + VI same
image_read off
1-cycle
Buf: 1.3064640ms, 1.3086625ms, 1.3098880ms
Pipe: 1.3067200ms, 1.3092097ms, 1.3101440ms
2-cycle
Buf: 2.5401920ms, 2.5430985ms, 2.5457440ms
Pipe: 2.5404320ms, 2.5434541ms, 2.5460320ms
image_read on
1-cycle
Buf: 2.8738560ms, 2.8805193ms, 2.8864960ms
Pipe: 2.8746240ms, 2.8814859ms, 2.8875040ms
2-cycle
Buf: 2.8176160ms, 2.8217543ms, 2.8279200ms
Pipe: 2.8182240ms, 2.8222642ms, 2.8286400ms
FB + VI separate
image_read off
1-cycle
Buf: 1.2943360ms, 1.2955808ms, 1.2961280ms
Pipe: 1.2946720ms, 1.2959020ms, 1.2964320ms
2-cycle
Buf: 2.5297120ms, 2.5317828ms, 2.5328320ms
Pipe: 2.5299360ms, 2.5320411ms, 2.5331040ms
image_read on
1-cycle
Buf: 2.7813120ms, 2.7849509ms, 2.7901120ms
Pipe: 2.7818240ms, 2.7856396ms, 2.7910560ms
2-cycle
Buf: 2.6768640ms, 2.6821616ms, 2.6881280ms
Pipe: 2.6771040ms, 2.6825271ms, 2.6883840ms

ZB Read-Only, No VI, Z Fail
FB + ZB same
image_read off
1-cycle
Buf: 1.6950720ms, 1.6960029ms, 1.6973120ms
Pipe: 1.6951680ms, 1.6961030ms, 1.6973760ms
2-cycle
Buf: 2.8206560ms, 2.8214202ms, 2.8223520ms
Pipe: 2.8206720ms, 2.8214399ms, 2.8223680ms
image_read on
1-cycle
Buf: 3.0357120ms, 3.0501998ms, 3.0667840ms
Pipe: 3.0361280ms, 3.0506080ms, 3.0671680ms
2-cycle
Buf: 3.1809280ms, 3.1817527ms, 3.1827520ms
Pipe: 3.1809280ms, 3.1817569ms, 3.1827520ms
FB + ZB separate
image_read off
1-cycle
Buf: 1.6950400ms, 1.6959862ms, 1.6974400ms
Pipe: 1.6951360ms, 1.6960921ms, 1.6975680ms
2-cycle
Buf: 2.8207520ms, 2.8214512ms, 2.8223520ms
Pipe: 2.8207680ms, 2.8214707ms, 2.8223680ms
image_read on
1-cycle
Buf: 2.6585920ms, 2.6616913ms, 2.6642880ms
Pipe: 2.6590080ms, 2.6621160ms, 2.6647040ms
2-cycle
Buf: 2.9316960ms, 2.9335407ms, 2.9351200ms
Pipe: 2.9317120ms, 2.9335548ms, 2.9351680ms

ZB Read-Only, No VI, Z Pass
FB + ZB same
image_read off
1-cycle
Buf: 3.1898240ms, 3.1916047ms, 3.1932160ms
Pipe: 3.1902880ms, 3.1921021ms, 3.1937440ms
2-cycle
Buf: 3.0171680ms, 3.0188267ms, 3.0206560ms
Pipe: 3.0173600ms, 3.0190432ms, 3.0208480ms
image_read on
1-cycle
Buf: 4.2146880ms, 4.2161827ms, 4.2174720ms
Pipe: 4.2154720ms, 4.2170242ms, 4.2182560ms
2-cycle
Buf: 3.9238240ms, 3.9250248ms, 3.9274080ms
Pipe: 3.9243680ms, 3.9255191ms, 3.9278880ms
FB + ZB separate
image_read off
1-cycle
Buf: 2.8025600ms, 2.8046261ms, 2.8085440ms
Pipe: 2.8029920ms, 2.8050739ms, 2.8089760ms
2-cycle
Buf: 2.9250400ms, 2.9280915ms, 2.9309280ms
Pipe: 2.9252640ms, 2.9283136ms, 2.9311200ms
image_read on
1-cycle
Buf: 3.7236800ms, 3.7260063ms, 3.7289920ms
Pipe: 3.7245280ms, 3.7268759ms, 3.7298400ms
2-cycle
Buf: 3.4491680ms, 3.4518791ms, 3.4543840ms
Pipe: 3.4496320ms, 3.4523457ms, 3.4547840ms

ZB Write-Only, No VI
FB + ZB same
image_read off
1-cycle
Buf: 2.9999840ms, 3.0009138ms, 3.0030880ms
Pipe: 3.0012000ms, 3.0021614ms, 3.0043040ms
2-cycle
Buf: 3.0711520ms, 3.0719140ms, 3.0729920ms
Pipe: 3.0717760ms, 3.0725508ms, 3.0736000ms
image_read on
1-cycle
Buf: 4.3505600ms, 4.3521833ms, 4.3538560ms
Pipe: 4.3520640ms, 4.3536053ms, 4.3552800ms
2-cycle
Buf: 4.4280000ms, 4.4348793ms, 4.4404320ms
Pipe: 4.4292320ms, 4.4360466ms, 4.4417120ms
FB + ZB separate
image_read off
1-cycle
Buf: 2.2241440ms, 2.2255112ms, 2.2265760ms
Pipe: 2.2248480ms, 2.2262640ms, 2.2273120ms
2-cycle
Buf: 2.5890400ms, 2.5908666ms, 2.5922400ms
Pipe: 2.5894080ms, 2.5911838ms, 2.5925120ms
image_read on
1-cycle
Buf: 3.5482880ms, 3.5506336ms, 3.5534400ms
Pipe: 3.5492480ms, 3.5516131ms, 3.5544000ms
2-cycle
Buf: 3.4315360ms, 3.4342707ms, 3.4369120ms
Pipe: 3.4321120ms, 3.4348760ms, 3.4376320ms

ZB Read/Write, No VI, Z Fail
FB + ZB same
image_read off
1-cycle
Buf: 1.6978880ms, 1.6988937ms, 1.6999360ms
Pipe: 1.6980160ms, 1.6990296ms, 1.7000320ms
2-cycle
Buf: 2.8209760ms, 2.8217375ms, 2.8225440ms
Pipe: 2.8210240ms, 2.8217945ms, 2.8225920ms
image_read on
1-cycle
Buf: 3.0519680ms, 3.0573361ms, 3.0643840ms
Pipe: 3.0524160ms, 3.0577764ms, 3.0648000ms
2-cycle
Buf: 3.1970560ms, 3.2003370ms, 3.2040320ms
Pipe: 3.1970880ms, 3.2003789ms, 3.2040640ms
FB + ZB separate
image_read off
1-cycle
Buf: 1.6978560ms, 1.6989140ms, 1.6999360ms
Pipe: 1.6979840ms, 1.6990534ms, 1.7000320ms
2-cycle
Buf: 2.8210080ms, 2.8217400ms, 2.8225440ms
Pipe: 2.8210560ms, 2.8217951ms, 2.8225920ms
image_read on
1-cycle
Buf: 2.6704640ms, 2.6731843ms, 2.6759680ms
Pipe: 2.6708800ms, 2.6736335ms, 2.6763840ms
2-cycle
Buf: 2.9370720ms, 2.9377959ms, 2.9386720ms
Pipe: 2.9371200ms, 2.9378499ms, 2.9387200ms

ZB Read/Write, No VI, Z Pass
FB + ZB same
image_read off
1-cycle
Buf: 4.3943360ms, 4.3958008ms, 4.3968960ms
Pipe: 4.3957760ms, 4.3972474ms, 4.3983040ms
2-cycle
Buf: 4.4609920ms, 4.4626164ms, 4.4635520ms
Pipe: 4.4617280ms, 4.4632450ms, 4.4641600ms
image_read on
1-cycle
Buf: 5.7570560ms, 5.7588886ms, 5.7607040ms
Pipe: 5.7588160ms, 5.7606624ms, 5.7624640ms
2-cycle
Buf: 5.8497600ms, 5.8513218ms, 5.8527360ms
Pipe: 5.8505600ms, 5.8519578ms, 5.8533440ms
FB + ZB separate
image_read off
1-cycle
Buf: 3.6082880ms, 3.6108570ms, 3.6128320ms
Pipe: 3.6092160ms, 3.6117797ms, 3.6137280ms
2-cycle
Buf: 3.4315680ms, 3.4344351ms, 3.4372320ms
Pipe: 3.4322400ms, 3.4350564ms, 3.4379200ms
image_read on
1-cycle
Buf: 4.4896000ms, 4.4941924ms, 4.4983040ms
Pipe: 4.4910080ms, 4.4956123ms, 4.4998080ms
2-cycle
Buf: 4.4413920ms, 4.4451813ms, 4.4492800ms
Pipe: 4.4419200ms, 4.4457147ms, 4.4496320ms

ZB Read/Write, VI, Z Fail
FB + ZB + VI separate
image_read off
1-cycle
Buf: 1.7084480ms, 1.7102473ms, 1.7124480ms
Pipe: 1.7089280ms, 1.7105477ms, 1.7127360ms
2-cycle
Buf: 2.8380000ms, 2.8380421ms, 2.8380640ms
Pipe: 2.8382400ms, 2.8382739ms, 2.8383040ms
image_read on
1-cycle
Buf: 2.7617280ms, 2.7673997ms, 2.7740320ms
Pipe: 2.7624320ms, 2.7682306ms, 2.7746240ms
2-cycle
Buf: 3.0108960ms, 3.0133547ms, 3.0171040ms
Pipe: 3.0111040ms, 3.0135766ms, 3.0173120ms
FB + VI same, ZB separate
image_read off
1-cycle
Buf: 1.7066080ms, 1.7084610ms, 1.7104640ms
Pipe: 1.7068800ms, 1.7087828ms, 1.7107520ms
2-cycle
Buf: 2.8380000ms, 2.8380422ms, 2.8380640ms
Pipe: 2.8382400ms, 2.8382741ms, 2.8383040ms
image_read on
1-cycle
Buf: 2.8933920ms, 2.8976609ms, 2.9018560ms
Pipe: 2.8940160ms, 2.8983998ms, 2.9027840ms
2-cycle
Buf: 3.0922240ms, 3.0964800ms, 3.0986400ms
Pipe: 3.0924480ms, 3.0966959ms, 3.0988480ms
FB + ZB same, VI separate
image_read off
1-cycle
Buf: 1.7072960ms, 1.7083185ms, 1.7104640ms
Pipe: 1.7075840ms, 1.7086568ms, 1.7107840ms
2-cycle
Buf: 2.8346240ms, 2.8356603ms, 2.8380640ms
Pipe: 2.8348480ms, 2.8358922ms, 2.8383040ms
image_read on
1-cycle
Buf: 3.1821120ms, 3.1885343ms, 3.1961440ms
Pipe: 3.1827520ms, 3.1892260ms, 3.1969280ms
2-cycle
Buf: 3.2984800ms, 3.3029583ms, 3.3068160ms
Pipe: 3.2986880ms, 3.3031741ms, 3.3070400ms
FB + ZB + VI same
image_read off
1-cycle
Buf: 1.7481600ms, 1.7493226ms, 1.7508000ms
Pipe: 1.7484480ms, 1.7496253ms, 1.7510720ms
2-cycle
Buf: 2.8488480ms, 2.8524904ms, 2.8536000ms
Pipe: 2.8490880ms, 2.8527223ms, 2.8538240ms
image_read on
1-cycle
Buf: 3.2257920ms, 3.2338199ms, 3.2420000ms
Pipe: 3.2264320ms, 3.2346110ms, 3.2425920ms
2-cycle
Buf: 3.3355680ms, 3.3417789ms, 3.3459360ms
Pipe: 3.3357760ms, 3.3419948ms, 3.3461440ms

ZB Read/Write, VI, Z Pass
FB + ZB + VI separate
image_read off
1-cycle
Buf: 3.9212480ms, 3.9302227ms, 3.9372320ms
Pipe: 3.9223360ms, 3.9316653ms, 3.9388640ms
2-cycle
Buf: 3.8262240ms, 3.8356241ms, 3.8415360ms
Pipe: 3.8271200ms, 3.8364558ms, 3.8423040ms
image_read on
1-cycle
Buf: 4.9459360ms, 4.9552894ms, 4.9627680ms
Pipe: 4.9479680ms, 4.9572820ms, 4.9648000ms
2-cycle
Buf: 4.8403680ms, 4.8550267ms, 4.8666400ms
Pipe: 4.8419360ms, 4.8563647ms, 4.8672640ms
FB + VI same, ZB separate
image_read off
1-cycle
Buf: 4.1321440ms, 4.1436483ms, 4.1573280ms
Pipe: 4.1339680ms, 4.1455078ms, 4.1592160ms
2-cycle
Buf: 4.0444000ms, 4.0574917ms, 4.0683680ms
Pipe: 4.0452480ms, 4.0585348ms, 4.0690720ms
image_read on
1-cycle
Buf: 5.4221920ms, 5.4364861ms, 5.4536640ms
Pipe: 5.4237440ms, 5.4384871ms, 5.4557120ms
2-cycle
Buf: 5.2941120ms, 5.3288225ms, 5.3623040ms
Pipe: 5.2965760ms, 5.3296287ms, 5.3635360ms
FB + ZB same, VI separate
image_read off
1-cycle
Buf: 4.7766720ms, 4.7887886ms, 4.7969440ms
Pipe: 4.7785760ms, 4.7907949ms, 4.7997120ms
2-cycle
Buf: 4.8563200ms, 4.8647094ms, 4.8696640ms
Pipe: 4.8571200ms, 4.8656398ms, 4.8707840ms
image_read on
1-cycle
Buf: 6.2826720ms, 6.2904572ms, 6.3062880ms
Pipe: 6.2848480ms, 6.2927203ms, 6.3084000ms
2-cycle
Buf: 6.3386720ms, 6.3505622ms, 6.3573760ms
Pipe: 6.3399520ms, 6.3520545ms, 6.3581760ms
FB + ZB + VI same
image_read off
1-cycle
Buf: 4.9294240ms, 4.9359958ms, 4.9442560ms
Pipe: 4.9314560ms, 4.9380782ms, 4.9463680ms
2-cycle
Buf: 4.9986400ms, 5.0076045ms, 5.0172000ms
Pipe: 4.9996480ms, 5.0086640ms, 5.0181120ms
image_read on
1-cycle
Buf: 6.4048320ms, 6.4214492ms, 6.4380960ms
Pipe: 6.4075520ms, 6.4239375ms, 6.4405440ms
2-cycle
Buf: 6.4958560ms, 6.5066720ms, 6.5179200ms
Pipe: 6.4969440ms, 6.5076984ms, 6.5192160ms

Alpha Compare
FB + ZB same
image_read off, z_compare off
1-cycle
Buf: 1.2443520ms, 1.2443520ms, 1.2443520ms
Pipe: 1.2443200ms, 1.2443200ms, 1.2443200ms
2-cycle
Buf: 2.4808320ms, 2.4808320ms, 2.4808320ms
Pipe: 2.4807840ms, 2.4807844ms, 2.4809760ms
image_read off, z_compare on
1-cycle
Buf: 1.6950400ms, 1.6960017ms, 1.6974080ms
Pipe: 1.6951680ms, 1.6961082ms, 1.6975360ms
2-cycle
Buf: 2.8206560ms, 2.8214354ms, 2.8223520ms
Pipe: 2.8206720ms, 2.8214550ms, 2.8223680ms
image_read on, z_compare off
1-cycle
Buf: 1.6950400ms, 1.6959837ms, 1.6974720ms
Pipe: 1.6951360ms, 1.6960918ms, 1.6975680ms
2-cycle
Buf: 2.5297280ms, 2.5306625ms, 2.5316480ms
Pipe: 2.5296800ms, 2.5306197ms, 2.5316000ms
image_read on, z_compare on
1-cycle
Buf: 3.0330240ms, 3.0495475ms, 3.0667520ms
Pipe: 3.0334400ms, 3.0499489ms, 3.0671680ms
2-cycle
Buf: 3.1808960ms, 3.1817453ms, 3.1826560ms
Pipe: 3.1808960ms, 3.1817508ms, 3.1826560ms
FB + ZB separate
image_read off, z_compare off
1-cycle
Buf: 1.2443520ms, 1.2443520ms, 1.2443520ms
Pipe: 1.2443200ms, 1.2443205ms, 1.2445760ms
2-cycle
Buf: 2.4808320ms, 2.4808322ms, 2.4808480ms
Pipe: 2.4807840ms, 2.4807868ms, 2.4812640ms
image_read off, z_compare on
1-cycle
Buf: 1.6950400ms, 1.6959935ms, 1.6973760ms
Pipe: 1.6951680ms, 1.6961102ms, 1.6975040ms
2-cycle
Buf: 2.8206560ms, 2.8214239ms, 2.8223520ms
Pipe: 2.8206720ms, 2.8214443ms, 2.8223680ms
image_read on, z_compare off
1-cycle
Buf: 1.6950080ms, 1.6959589ms, 1.6973120ms
Pipe: 1.6951360ms, 1.6960598ms, 1.6974080ms
2-cycle
Buf: 2.5296640ms, 2.5306507ms, 2.5316160ms
Pipe: 2.5296160ms, 2.5306092ms, 2.5315680ms
image_read on, z_compare on
1-cycle
Buf: 2.6589120ms, 2.6616334ms, 2.6643200ms
Pipe: 2.6593280ms, 2.6620630ms, 2.6647360ms
2-cycle
Buf: 2.9316640ms, 2.9335089ms, 2.9351520ms
Pipe: 2.9316800ms, 2.9335275ms, 2.9352320ms

Salud.

Cuesta interpretar las cifras, pero si no lo he entendido mal, es lo que tarda el RDP en pintar una pantalla en determinadas condiciones de framebuffer y z-buffer.


Rellenaría una pantalla entera de 320x240 y 16bits RGBA en 1'28ms (No ZB, No VI,image_read off, 1-cycle ) como mejor cifra, y como peor 6'5ms (FB + ZB + VI same, image_read on, 2-cycle).
Sale a 781fps de máximo y 153fps de mínimo.
60Mpixels/s máximo, 11'8Mpixels/s de mínimo.

Ojo, de fillrate, sin renderizar triángulos, si no lo he entendido mal.

Eso significa que en 2D la consola es una bestia parda.

Cogedlo con pinzas, que no sé si he entendido bien el tipo de test y los datos. Además, es domingo por la mañana.

EMaDeLoC escribió:Eso significa que en 2D la consola es una bestia parda.

¿A que nivel?, porque tampoco puede manejar planos, cosa que una saturn si hace, ni parece que la capacidad para dibujar sprites de una jaguar sea fácilmente superable.

Señor Ventura escribió:

EMaDeLoC escribió:Eso significa que en 2D la consola es una bestia parda.

¿A que nivel?, porque tampoco puede manejar planos, cosa que una saturn si hace, ni parece que la capacidad para dibujar sprites de una jaguar sea fácilmente superable.

153fps vendría a ser 153 fondos por segundo, o más de dos planos de fondo por frame a 60fps.
Si te refieres a planos transformados, con inclinación, rotación, etc, eso ya sería con 3D.

Para sprites tienes una prueba que hizo @Conker64 hace ya unos cuantos años, seguida de otra prueba.
Por entonces, 900 sprites a 60fps.

Pero a ver si con la invocación se pasa y te da cifras más actualizadas.

EMaDeLoC escribió:153fps vendría a ser 153 fondos por segundo, o más de dos planos de fondo por frame a 60fps.
Si te refieres a planos transformados, con inclinación, rotación, etc, eso ya sería con 3D.

Para sprites tienes una prueba que hizo @Conker64 hace ya unos cuantos años, seguida de otra prueba.
Por entonces, 900 sprites a 60fps.

Pero a ver si con la invocación se pasa y te da cifras más actualizadas.

2D típicos, planos y sprites.

Saturn creo que puede poner 5 planos, y de momento obviaremos los dos planos "modo 7", y jaguar he leído que te puede dibujar cientos de sprites por scanline (son sprites auténticos, con su line buffer, ojo), pero no se cuantos en total, ni planos.

Doy por hecho que 3DO y ps1 no llegan a donde llega una n64 en 2D.

Eso si, n64 puede aportar hasta 8MB de ram, y encima con la ventaja del streaming de datos de los cartuchos.

@EMaDeLoC Sí, es lo que dices, pero al usar 1 Cycle, no creo que en 3D, diera resultados muy diferentes, al fin al cabo el cuello de botella de esa generación era el Fillrate, no tanto el cálculo de la geometría.
Lo que también , me parece curioso, es que en algunas circunstancias, la diferencia de rendimiento entre 1 cycle y 2 cycle es mínima, he incluso en alguna, es más rápido en 2 cycle, xD, también se ve la diferencia de rendimiento de poner los Buffer en distintos bancos de memoria ect.
Ahora están comentando la diferencia de rendimiento al usar AA, no usarlo o usar Reduced Alising y el dithering del IV/s.

Salud.

@Señor Ventura Ten en cuenta que no todos los planos de fondos se pintan al completo en las consolas que mencionas, que son las pruebas que se han hecho en la N64, y que te he dado los datos más malos para saber el mínimo, pero no necesariamente para pintar fondos necesitas z-buffer ni 2-cycle. Con los datos mejores serían 10 fondos a 60fps. Así que de media se cumplen los 5 de Saturn, aunque los dos hardware funcionan de forma muy distinta.

@dirtymagic Yo creo que sí que habría diferencia con 3D, ya que habría que leer vertices, rasterizarlos, etc, y además añadir lectura de texturas que ocuparía algo de ancho de banda de memoria. Así que algo sí que se resintiría en los datos aportados.

Sobre las últimas pruebas, parece que activar el antialising al completo corta bastante el rendimiento.
¿Alguna información sobre ese "reduced aliasing"? No me suena que había otra opción entre tener o no tener antialiasing, y parece la mejor opción ya que mantiene buen rendimiento y la calidad de imagen es buena.