Hilo de detalles y curiosidades de N64

Responder
1…60, 61, 62, 63, 64
¡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 [oki]

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 [oki]

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? [rtfm]
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 [oki]

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
INSTALAR LIBDRAGON
Venga pues empezamos con un tutorial en pasos para noobs, en un tiempo estimado de 10min, para tener la libdragon actual lista para trabajar.

DESCARGAR E INSTALAR MSYS2
1. Entrar en la web msys2 o bien descargar directamente de este link de descarga
2. Instalar por defecto (no trae nada raro)
3. De los accesos directos creados por el programa buscar MSYS2 MINGW64 y copiarlo en alguna carpeta de desarrollo para usar después

DESCARGAR BINARIOS
1. Descargar los binarios del compilador
2. Crear una nueva carpeta con el nombre "n64-toolchain" en C raiz ( c:/n64-toolchain )
3. Descomprimir el contenido dentro de n64-toolchain

VARIABLES DE ENTORNO
1. Abrir propiedades del sistema o bien buscar "editar las variables de entorno del sistema"
2. En opciones avanzandas clic en "Variables de entorno..."
3. En variables del sistema crear nueva variable con nombre "N64_INST" y en el valor de la variable se le añade la ruta de los binarios "c:/n64-toolchain"

DESCARGAR LIBDRAGON
1. Vamos al github
2. Click en el botón verde "Code" y ahora en el menú desplegable en "Download Zip"
3. Descomprimir dentro de "c:/n64-toolchain", renombrar nombre de la carpeta a "libdragon"

Con esto tendremos la versión más actual de la librería.

TERMINANDO INSTALACIÓN
1. Ejecutar MSYS2 MINGW64, el acceso directo que hemos guardado en alguna carpeta en el primer paso
2. En la consola tendremos que escribir los siguientes comandos (botón derecho, Paste, para los menos hábiles):

- Mover a carpeta de libdragon, si lo hemos hecho siguiendo el tutorial:
cd /c/n64-toolchain/libdragon

- Ahora hay que instalar las dependencias, nos preguntará si queremos instalar, escribimos Y (yes) y continuar, se descargaran algunos archivos:
pacman -S base-devel mingw-w64-x86_64-gcc mingw-w64-x86_64-make mingw-w64-x86_64-libpng git

- El último:
./build.sh


LISTO! [toctoc]

Si todo ha ido bien, la carpeta examples y tests dentro de libdragon (c:/n64-toolchain/libdragon), se habrá poblado de roms en formato z64.

Como sorpresa la mayoría no van en CEN64, bueno van, pero hacen saltar el debugger en modo handler exception por falta de "precisión", habrá que probar cosas más modernas, como Ares-emu, en consola si todo ha ido bien deberían funcionar sin problema.

COMO COMPILAR UN EJEMPLO
Lo que hemos visto es el tedioso paso de instalación de la librería, una vez instalada, todo es más sencillo, por ejemplo, en la carpeta examples/test, borramos test.z64.

Ahora desde MSYS2, si hemos salido por completo, introducimos el comando para posicionarnos en la carpeta:
cd /c/n64-toolchain/libdragon/examples/test


Sino:
cd examples
cd test


Dentro de la carpeta ahora escribimos:
make


La rom z64 debería volver a aparecer en la carpeta.

Y aquí empieza todo, que bajamos un ejemplo de libdragon compatible desde internet? Lo descargamos en la carpeta, seguimos el procedimiento anterior.

Que no quieres descargar nada? Prueba a copiar un ejemplo, renómbralo y edita sobre el, abre Makefile y modifica los nombres para el nuevo test.

Todo esto es muy vago y se puede ampliar, veamos si enganchamos a alguien más para programar en N64 y si interesa expandir [360º]

--
@masteries
Ok bueno ya estoy en ello, cuando tenga resultados te aviso [oki]
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 [360º]


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 XD
Conker64 escribió:INSTALAR LIBDRAGON

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



¡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. [boing]
EMaDeLoC escribió:Hablando de desarrollos en N64:


Es una brutalidad hasta que punto esta llevando el port. [boing]


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 ratataaaa ratataaaa ratataaaa
EMaDeLoC escribió:Hablando de desarrollos en N64:


Es una brutalidad hasta que punto esta llevando el port. [boing]


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. [boing]


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 XD


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.
3174 respuestas
Responder
1…60, 61, 62, 63, 64
Volver a Consolas clásicas