Hilo de detalles y curiosidades de N64

@Conker64 oye Conker cuando tengas un rato de tiempo libre podrías echarle un ojo al firmware Alt64 para los flashcards, me suena que me habías dicho que iba lentísima porque habían hecho algo mal y que debería ser fácil que funcionase fluidamente incluso con caratulas (esto último a mi personalmente me da igual con que pueda usarlo para meter trucos sin tardar 3 horas me vale)

Si lo ves complicado pues nada, hasta ahora he vivido muy bien con el firmware pirata chinorro.

@SuperPadLand
El Alt64 usa la CPU para todo, cuando dibuja los menús en alta resolución y mete submenús encima le debe costar, quizás lo mejor que podrías hacer es ponerlo a 320x240 o más bajo si deja.

Para compilarlo también tendría que compilar todas las otras librerías que usa en el entorno, la de acceso a la SD del Everdrive, no sé si alguna para leer PNG o música, creo que están bastante desactualizadas, lo suyo sería empezar algo de 0, tenía pensado un menú con portadas (muy al estilo de lo que hay en Wii), pero lo dejé aparcado.

@Conker64 ¿Puedo bajar la res yo desde el alt64? No vi eso. Por mi como si va a 120p fondo negro y texto blanco.

@SuperPadLand
No te sabría decir, no llegué a probarlo (vi el código en github para entender porqué iba tan lento), el ED original tiene varios modos de resolución.

El chinorris como va en eso?

En el Alt64 si trae PNG de fondo y lo lee fuera de la ROM estaría bien probar que pasa borrando, la libdragon comprueba si es nulo al dibujar por software y eso que se ahorraría (mucho), o si da la opción de no elegir fondo.

Conker64 escribió:@SuperPadLand
No te sabría decir, no llegué a probarlo (vi el código en github para entender porqué iba tan lento), el ED original tiene varios modos de resolución.

El chinorris como va en eso?

En el Alt64 si trae PNG de fondo y lo lee fuera de la ROM estaría bien probar que pasa borrando, la libdragon comprueba si es nulo al dibujar por software y eso que se ahorraría (mucho), o si da la opción de no elegir fondo.

El chinorri salvo que tenga algún tipo de pulsación de botones que modifique la res yo no lo he visto nada. Tiene modo TV y deja elegir entre velocidad de carga normal o fast, nada más que yo recuerde, bueno la típica selección del tipo de guardado y favoritos.

Probaré con el Alt64 borrando el PNG a ver si mejora, con que no hay un lag tremendo al pulsar botones me llega porque escribir códigos de trucos así es una jodienda

Interesaría un nuevo tutorial sobre como instalar libdragon?

Tengo un nuevo portátil, toca instalar el entorno y seguramente aproveche para hacer un megazord, con la versión más moderna de la lib, pero combinando todo aquello que no tenga del chip gráfico.

@SuperPadLand
Hubo suerte con alt64?

@Conker64 todavía no me puse a ello 🤦 tengo que buscar el alt64 y ponerme un día a cacharrear. De paso probar esos nuevos hacks que hay por ahí

Interesaria que fuera facil porque es complicado instalar intente reinstalarlo y no hubo manera.
Si se hace una buena libreria sino facilita la instalacion no se puede hacer mucho

@conker64

Creo que este repositorio tiene bastantes updates recientes

https://github.com/Suprapote/Altra64/releases

Conker64 escribió:Interesaría un nuevo tutorial sobre como instalar libdragon?

Tengo un nuevo portátil, toca instalar el entorno y seguramente aproveche para hacer un megazord, con la versión más moderna de la lib, pero combinando todo aquello que no tenga del chip gráfico.

@SuperPadLand
Hubo suerte con alt64?

Pues Conker64,

Nos viene genial, porque queremos portar nuestro nuevo juego en desarrollo para Megadrive/Genesis a Nintendo64;
y los añadidos a libdragon que has hecho en forma de soporte a color de 4 bits, y la herramienta Sprite 64, junto con el soporte para ficheros comprimidos (los .zpsrites que he podido generar con Sprite 64) y el poder manejar puntos de control como en Fénix / Bennu es genial,

Te he puesto un mensaje, pues deseo poder hacer uso de una versión de libdragon con los añadidos que tan bien te has currado,



El nuevo juego está basado en una versión muy refinada del engine multiplataforma que ha permitido hacer esto realidad (estos vídeo aún no se corresponden al nuevo juego, ni a la versión refinada del código):


https://masteries.itch.io/metal-slug-for-megadrive-ste








Es hora de añadir Nintendo 64 a la lista de plataformas...

masteries escribió:Pues Conker64,

Nos viene genial, porque queremos portar nuestro nuevo juego en desarrollo para Megadrive/Genesis a Nintendo64;
y los añadidos a libdragon que has hecho en forma de soporte a color de 4 bits, y la herramienta Sprite 64, junto con el soporte para ficheros comprimidos (los .zpsrites que he podido generar con Sprite 64) y el poder manejar puntos de control como en Fénix / Bennu es genial,

Te he puesto un mensaje, pues deseo poder hacer uso de una versión de libdragon con los añadidos que tan bien te has currado,

Hola, te respondo por aquí y luego miro el PM

Aún no la he instalado, pero tengo pensado hacerlo en breve (en este mes vaya), supongo que también necesitarías algunos ejemplos.

Si quisieras ir probando con la más antigua, reemplazando rdp.c y rdp.h desde github para actualizar a la última versión personalizada valdría, si los métodos de compilación modernos no funcionaran en las primeras páginas del hilo puse un tutorial y la descarga de todos los ficheros necesarios para instalar la versión antigua, trabajé con las libs originales de 2012 entre 2016 y 2018.

Aunque lo ideal sería unificar todo lo que hice en la nueva, eso en cuanto me ponga no debería tomar mucho tiempo.

Para desarrollar también recomendaría el emu CEN64 (o alguno de los nuevos que citan en github, pero no los he probado), con el resto de emuladores más populares tendrás problemas o no irán con libdragon, además del hardware original y de cambiar la ROM generada a z64, aunque supongo que en la nueva lib ya habrán apañado eso.

@rigoyagami
Ah, ese es el fork del proyecto original, parece que aún está vivo

@Flash-Original
No tendrás problemas, han mejorado y actualizado la forma de instalar.

Conker64 escribió:
Hola, te respondo por aquí y luego miro el PM

Aún no la he instalado, pero tengo pensado hacerlo en breve (en este mes vaya), supongo que también necesitarías algunos ejemplos.

Si quisieras ir probando con la más antigua, reemplazando rdp.c y rdp.h desde github para actualizar a la última versión personalizada valdría, si los métodos de compilación modernos no funcionaran en las primeras páginas del hilo puse un tutorial y la descarga de todos los ficheros necesarios para instalar la versión antigua, trabajé con las libs originales de 2012 entre 2016 y 2018.

Aunque lo ideal sería unificar todo lo que hice en la nueva, eso en cuanto me ponga no debería tomar mucho tiempo.

Muchas gracias por estar ahí estos días tan de vacaciones,


supongo que también necesitarías algunos ejemplos.

Exacto, sobre hacer un scroll de varias capas;
y cómo funciona en el scroll el tema de las coordenadas... en Megadrive y el Atari STE,
la pantalla tiene unas coordenadas fijas, mientras que el scroll no; así que hay una función
que convierte (para los sprites) de coordenadas scroll a coordenadas pantalla...

aquí supongo que será similar, pero los ejemplos serán necesarios y más que bienvenidos


Aunque lo ideal sería unificar todo lo que hice en la nueva, eso en cuanto me ponga no debería tomar mucho tiempo.


Esto si que sería perfecto

Estoy probando el Quake II de N64 que viene incluido como campaña extra en el nuevo remaster de Nightdive, se juega como dios.


--
@masteries
No prob, en unos días actualizo

Conker64 escribió:Estoy probando el Quake II de N64 que viene incluido como campaña extra en el nuevo remaster de Nightdive, se juega como dios.

--
@masteries
No prob, en unos días actualizo

Yo tambien, y me esta pareciendo muy divertido.

Caerá para switch o pc, tiene pintaza

Segastopol escribió:Caerá para switch o pc, tiene pintaza

Lo tienes en Gamepass. Yo he estado jugando a ratos muertos.

SuperPadLand escribió:

Segastopol escribió:Caerá para switch o pc, tiene pintaza

Lo tienes en Gamepass. Yo he estado jugando a ratos muertos.

Me da un poco de pereza aunque solo sea un euro, pero es una excelente opción para pasarmelo enterito con los extras y de paso el uno y alguno que otro juego que también tengo en la mira xD.
Gracias por el consejo, como se agradecen estos juegos de acción pura sin tramas, ni dramas, ni historias que a mí por lo menos no me interesan.
Le estaba dando al brutal doom 64, oh sí, buenas escabechinas.

Tenemos otro remaster, ahora Turok 3, aún por detallar la fecha de lanzamiento.

@Conker64 uno de los infravalorados del catálogo, es cierto que cuando salió los FPS de PC eran mucho más avanzados, pero seguía siendo un FPS más que competente.

Yo lo disfruté mucho. Y la Intro viendo como movían la boca fue una locura.

Luego es cierto que bajo la calidad con el 2 pero era muy divertido.

Conker64 escribió:Tenemos otro remaster, ahora Turok 3, aún por detallar la fecha de lanzamiento.

Están los shooters exclusivos de n64 viviendo una segunda juventud, primero doom64, luego quake 64, quake 2 64, y ahora turok3... La leche tu, nunca lo creí ver

Buenas. Me enterado por otro hilo gracias al usuario @celgadis_84 que se ha publicado una demo mostrando un escenario con unas texturas muy definidas y variadas:



La rom hay que compilarla y no tengo ni idea de cómo se hace. Los archivos están en este repositorio.
¿Alguien podría compilarla y pasar el enlace? ¿O no es posible hacerlo por algún tipo de licencia?

Una de las personas que ha trabajado en esta demo es James Lambert, que está realizando el Portal 64 que ya se ha mostrado por aquí alguna vez. Dice que publicará un vídeo en su canal explicando cómo lo han conseguido.

Estaba pensando que igual no estaría mal tener un listado de los remasters, versiones de juegos que también están en PC y demás.

Ya solo de Nightdive:
- Turok 1
- Turok 2
- Turok 3 (por lanzar)
- Doom 64
- Shadow Man Remastered
- Forsaken Remastered (aunque no sé hasta que punto tiene de la versión N64, he avanzado poco y solo he visto pequeños detalles como cambiar el HUD, no he visto opción de la campaña de 64, ni de la OST)
- Quake 64 (Dentro del remaster, no he podido probarlo)
- Quake II (Dentro del remaster, este sí y es una pasada)

@Sogun
Usa libultra por lo visto (#include <ultra64.h>), supongo que por eso esconden la rom en discord y ponen el código para que cada uno se lo guise.

@Sogun Esa demo es increíble, y no solo por las texturas con los dibujos tan detallados, sino por la iluminación que hay en general, le da un aspecto muy realista y de ser hardware mucho más actual.
Me recuerda mucho a ciertos escenarios de Perfect Dark, pero más detallado y con más resolución.
Se me ocurren varios tipos de juego que se podrían hacer con algo así...
A ver si al menos alguien rula la ROM que podamos verlo moverse en tiempo real.

@Conker64 Con la libdragon no sería posible hacer esa demo?

@Conker64 bueno, está el de Golden Eye... aunque bueno es en emulador en PC, y no oficial, el de la 360, los Mario y Zelda... o solo contamos "oficialmente"?

Aquí está los juegos que se presentan en la N64BREW summer https://tinyurl.com/ykfhz432
En cada carpeta de juego esta la rom y el código fuente.
La demo gráfica se puede controlar el detalle de escena con arriba y abajo del D-Pad, a máxima definición se arrastra, pero 1 o 2 escalones menos, se ve bastante bien y se mueve bien.
Salud.

@Naitguolf
Sipo, podríamos hacer una lista así global de todo lo que hay, sea oficial o no.

- Mario 64 nativo
- Con Zelda no sé que ha pasado, le perdí la pista hace tiempo, esperaba ports hasta en la tostadora como con Mario
- Goldeneye supongo que resta que sea emulado, aunque se entiende que es por el remaster, el que han sacado recientemente creo que también era exclusivo en consolas
- Perfect Dark creo que no ha llegado a PC, no entiendo muy bien a Microsoft, el Rare Replay lo hubiera comprado día 1 en Steam (por el Jet Force Gemini más que nada)

Luego están los multis que salían en todos los lados, habría que ver como de interesante sería esa lista:

Los de Factor 5:
- Star Wars: Rogue Squadron
- Star Wars Episode I: Racer
- Star Wars Episode I: Battle for Naboo
- Indiana Jones and the Infernal Machine
etc, etc..

@bluedark
No creo, la libultra usa un ucode3D completo para las 3D, lo que hay en libdragon aún necesita trabajo, si bien podrían copiar funciones de un lado al otro, pero ya no sería código libre.

@dirtymagic ¡Gracias!
Probada la demo y examinando los assets, y a la espera del vídeo explicativo que seguramente mostrará algo muy distinto a lo que voy contar, voy a poner mis impresiones:

¡Números!
-325 triángulos (*)
-10 texturas de 1024x1024 píxeles a 16 bits de color ¿y con mipmaps activados?. (**)
-7 texturas de 1024x512 píxeles a 16 bit de color ¿y con mipmaps activados?. (**)
-1 textura de 512x512 píxeles a 16 bit de color ¿y con mipmaps activados?. (**)
-Resolución en pantalla 640x474 (según captura incluida en los archivos, pero se nota que funciona a muy alta resolución).
-Según el readme no usa Z-buffer. Se me ha olvidado fijarme si usa antialising, pero viendo el vídeo me parece que tampoco lo usa (a esa resolución se puede prescindir de él perfectamente, yo no lo he echado en falta).
-Framerate variable. Muy bajo con las texturas a detalle máximo y 30 fps con las texturas al mínimo de detalle. Si muchas texturas están "aumentando detalle" a la vez, el audio pega un petardazo o incluso se detiene un instante.

(*) Es la geometría base del escenario que se puede extraer de los archivos que acompañan el código fuente. Se trata de una geometría sin florituras de ningún tipo (vértices extras para ayudar a colorear los polígonos o polígonos extras para "dibujar" sombras como se ve en juegos comerciales). Geometría superbásica que me da a mí que se subdivide según el detalle que tiene la textura. Parece que están usando teselación, como hacen muchos juegos de PS1 y Saturn, y que en N64 sólo la he percibido en Rogue Squadron y Battle for Naboo. Esto aumentaría la cantidad de polígonos en pantalla de forma exponencial. Por cada iteración de la textura habría que multiplicar x4 y en la demo hay muchas iteraciones. Aunque parece que es una teselación "inteligente" y que se aplica a lo que aparece en pantalla y según la distancia de la cámara.

(**) Son las imágenes que vienen con los archivos que acompañan al código fuente. Por tamaño (2 MB las texturas grandes, 1 MB las texturas medianas y 0,5 MB la más pequeña) evidentemente no caben ni en la caché (4 kB), ni en la memoria RAM (27'5 MB todas las texturas. Yo lo he probado con el Expansion Pak de 8 MB, pero no sé si funcionaría también en los 4 MB que trae por defecto la consola). Son texturas "modernas" donde en la misma imagen se proyectan los polígonos que se van a texturizar a modo de desplegable, por lo que quedan zonas de las texturas sin usar que se podrían emplear para elementos más pequeños. Además, las vidrieras de las paredes se repiten a la izquierda y a la derecha, pero utilizan archivos distintos. El caso es que para que entren en la caché habría que dividir esas megatexturas en trozos más pequeños (de 32x32 píxeles, como hace la Play Station. Cada trozo de textura ocuparía 2 kB y los otros 2 kB se usarían para los mipmaps).

Cuando en la demo te acercas a una pared a veces puedes visualizar las costuras de los trozos de textura al máximo detalle. Se puede intuir que, efectivamente, son texturas de 32x32 píxeles. Pero cuando bajas el nivel de detalle algunas de esas costuras desaparecen, reforzando mi idea de que están usando teselación en la geometría para alojar todas esas pequeñas texturas.

El nivel de detalle de las texturas es sensacional. Especialmente el empedrado que rodea al altar, donde apenas se pueden diferenciar los téxels. Diría que es superior a lo que se vio en la generación posterior (Metroid Prime usa texturas de 256x256 píxeles). Se nota el "banding" que provoca la iluminación precalculada incorporada en las texturas de 16 bits. Creo que podría tener mejor aspecto si se empleara dithering en la textura y se emborronase con los filtros.
No siempre están las texturas a tope de definición. Parece que el motor gráfico las va adaptando según aparecen o no en pantalla y la distancia de la cámara por evidente falta de memoria. Cuando muchas texturas se están actualizando al mismo tiempo se puede ver cómo realizan la transición e incluso el sonido comienza a petardear porque el harware no da para todo. No sé si es descompresión de texturas, streaming directo desde el cartucho o lo que están utilizando, pero está exprimiendo a la N64 a lo bestia.

La ROM ocupa 46 MB por lo que es evidente que usar esto es inviable para un juego comercial (incluso si los cartuchos tuviesen la capacidad de un CD-ROM). Pero es que se han pasado tres pueblos con el nivel de detalle. Además de sobrarle detalle para algo a 640x480, si se plantea para un juego funcionando a 320x240 que requiere la cuarta parte de detalle sí que podría quedar algo muy fluído, vistoso y que cupiese en un cartucho comercial.

@Sogun
Básicamente has llegado a la misma conclusión que yo, tengo curiosidad de cómo a conseguido hacer para cargar texturas tan tochas, y sobretodo, si se puede usar para algo más balanceado pero que permita texturas más detalladas de las que se suelen ver en la consola, la verdad es que a 320x240, no creo que haga falta texturas de más de 128x128 y el salto sería considerable.

Salud.

Que alguien me pase ese mod de quake 2,por diós

mcfly escribió:Que alguien me pase ese mod de quake 2,por diós

Qué mod?

Me ha traicionado el subconsciente por el remaster de quake 2, y lo he confundido con doom 64 complete edition

dirtymagic escribió:@Sogun
Básicamente has llegado a la misma conclusión que yo, tengo curiosidad de cómo a conseguido hacer para cargar texturas tan tochas, y sobretodo, si se puede usar para algo más balanceado pero que permita texturas más detalladas de las que se suelen ver en la consola, la verdad es que a 320x240, no creo que haga falta texturas de más de 128x128 y el salto sería considerable.

Salud.

He estado mirando el discord, y sí es lo que pensábamos, teselación de los polígonos, los trozos de texturas las va cargando desde el cartucho y a 320x240 mejora el rendimiento, pero decidió ponerlo a 640x480 para que se viera mejor.


Salud

dirtymagic escribió:

dirtymagic escribió:@Sogun
Básicamente has llegado a la misma conclusión que yo, tengo curiosidad de cómo a conseguido hacer para cargar texturas tan tochas, y sobretodo, si se puede usar para algo más balanceado pero que permita texturas más detalladas de las que se suelen ver en la consola, la verdad es que a 320x240, no creo que haga falta texturas de más de 128x128 y el salto sería considerable.

Salud.

He estado mirando el discord, y sí es lo que pensábamos, teselación de los polígonos, los trozos de texturas las va cargando desde el cartucho y a 320x240 mejora el rendimiento, pero decidió ponerlo a 640x480 para que se viera mejor.


Salud

Pensaba que tenía mucho menos carga poligonal, los bloques del suelo que hacen de asientos tienen tanto poligono por el tema de las texturas no? Si el lado de bloque estuviera hecho con dos triángulos quedaría una textura cutrisima imagino, pero también podía hacer mundos enormes con texturas planas tipo vr, muy interesante.
El empedrado del altar se ve brutal.

Era obvio que no podían ser texturas tan grandes, tiene que ser a base de muchos polígonos para "pegar" todos esos trocitos de las texturas.

Pero igual se está desaprovechando la teselación de las paredes para que las texturas que van en ellas cuenten con mas detalles diferentes... o en su defecto reducir el número de polígonos.

Con todo, viendo la cantidad de polígonos que hay ahí, y a 640x480, el rendimiento es definitivamente bueno.


P.D: La clave está en que gracias al cartucho puedes transitar por habitaciones sin cargas, y que gracias a la ram y a la caché de texturas el resultado es superior, pero que ocupe 46MB es demasiado, haría falta un cartucho con el tamaño de un DVD para poder obtener un juego de eso, algo falla aquí...

El otro vídeo con bump mapping e iluminación pseudo por pixel me parece como mínimo igual de impresionante,

@dirtymagic Muchas gracias de nuevo por las capturas. Se ven perfectamente los distintos niveles de teselación.

Haciendo algunos cálculos chapuceros me sale que si todo el escenario estuviera completamente teselado la carga poligonal de la habitación sería de unos 192.000 triángulos si empleasen trozos de texturas de 32x32, que parece que es el caso. Pero no llega a ese número ni de coña.
Serían 96.000 polígonos si fuesen texturas de 64x32 pero no tendrían mipmaps. No estoy muy seguro de si los usan o no. Han precalculado las texturas con menor detalle (por eso la ROM ocupa mucho más de los 27'5 MB de las texturas grandes) pero no estoy seguro de si esas texturas usan sus propios mipmaps generados por la consola o si ponen texturas más pequeñas y tiran de filtro bilineal. El caso es que no parece existir ningún tipo de aliasing resultado de la falta de estos filtros...

Ya teoricé sobre un sistema parecido hace unos años cuando me di cuenta de la teselación en Rogue Squadron. Pero mi idea iba más por aprovechar los 8 MB del Expansion Pak y llenarlo con cientos de texturas que de hacer un streaming constante desde el cartucho (cosa que por cierto, Factor 5 dijo que hizo para el Indiana Jones and the Infernal Machine).

Los escenarios de Rogue Squadron están formados por una retícula cuadrada y modificando la coordenada de la altura de los vértices es como se genera el relieve (algo como esto). Factor 5 texturizó cada cuadrado con una textura de 64x64 a 16 colores (el máximo de resolución que permite la caché, aunque por ello no se aplica filtrado trilinear) y diseñó las texturas en forma de puzzle para ir encajándolas sin que se notaran costuras ni patrones repetidos. Es una idea muy buena.
Pero lo extraordinario es que dependiendo de lo cerca de la cámara en la que se encuentren esos cuadrados, se subdividen y los nuevos vértices adquieren nuevas alturas para redondear los contornos.

No sé si se podría dar un paso más allá y además cambiar las texturas a la vez que se subdividen los polígonos. Se podría conseguir eliminar la pixelización en la distancia que produce la falta de filtrado trilinear (poniendo texturas de 32x32 o menor resolución que sí permitiesen ese filtrado) o mejorando el colorido de las texturas de los polígonos cercanos al pasar de una textura de 64x64 a 16 a 4 texturas de 32x32 a 256 colores. Claro que estamos multiplicando x4 la cantidad de memoria necesaria en los polígonos cercanos y aumentando la carga de trabajo, por lo que el rendimiento se vería afectado.
¿De todas formas no hicieron algo similar en Battle for Naboo? Me suena que los polígonos en la distancia usan goraud shading en lugar de texturas al igual que los Spyro de PSX.

Sogun escribió:Serían 96.000 polígonos si fuesen texturas de 64x32

96 mil polígonos con texturas de 64x32 a 640x480 de resolución es mucha tralla, ¿cuantos polígonos se pueden conseguir entonces a 320x240?.

Señor Ventura escribió:

Sogun escribió:Serían 96.000 polígonos si fuesen texturas de 64x32

96 mil polígonos con texturas de 64x32 a 640x480 de resolución es mucha tralla, ¿cuantos polígonos se pueden conseguir entonces a 320x240?.

No llega a esos números ni se le acerca. Lo mejor sería contar los polígonos de los wireframes que se han puesto.

Mis cálculos son muy chapuceros. No tenía que haberlo puesto:
-La escena base son 375 triángulos. Un cuadrado lo forman 2 triángulos, así que que hay 187'5 cuadrados.
-Un cuadrado se subdivide en otros 4 cuando avanzamos una iteración en la teselación.
-Las texturas son de 32x32, pero las megatexturas son mayormente de 1024x1024. Hay estas iteraciones -> 32, 64, 128, 256, 512 y 1024.
Con texturas de 1024x1024 hay 187'5 cuadrados
Con texturas de 512x512 hay (x4) 750 cuadrados
Con texturas de 256x256 hay (x4) 3.000 cuadrados
Con texturas de 128x128 hay (x4) 12.000 cuadrados
Con texturas de 64x64 hay (x4) 48.000 cuadrados
Con texturas de 32x32 hay (x4) 192.000 cuadrados -> que son 384.000 triángulos. Se me olvidó esta última conversión.
En pantalla no se ven todos los polígonos de golpe. Aunque se viese la cuarta parte (96.000), no importa la magia negra que hagas, a esa resolución casi estaríamos hablando de segundos por frame en lugar de frames por segundo.

Si simplificamos el escenario a un cubo -> un cubo tiene 6 caras -> 192.000 / 6 = 32.000 cuadrados por cara -> cada cara deberían tener casi 179 cuadrados por lado. Eso no es lo que se ve el la imagen del wireframe. Es muchísimo menor.

De todas formas para la resolución que gasta la demo, la carga poligonal (sea la que sea) y la cantidad de texturas... el rendimiento es altísimo.

Lo que estaría muy bien es que la misma demo se pudiera correr a 320x240.

@Sogun Esa resolución sería la óptima para la consola, no tiene mucho sentido los 480p salvo por ser una demo técnica. Y en un CRT se vería más nítido todo.

@dirtymagic Perdona si es una pregunta obvia,pero yo no tengo mucha idea... ¿Los colores de la lineas del wireframe están relacionados con el tipo de iluminación que tiene cada triángulo o son residuos del color de las texturas que se aplican encima?

Hoy en día, reduciendo algo el asunto para que no sea una animalada de cambios, se podría hacer juegos swap-cartucho cada 64mb, generas un save al terminar un cartucho y cargas el segundo. No valdría para todos los géneros, pero para un walking simulator por ejemplo sí.

@bluedark son los colores de la textura.


Salud.

SuperPadLand escribió:Hoy en día, reduciendo algo el asunto para que no sea una animalada de cambios, se podría hacer juegos swap-cartucho cada 64mb, generas un save al terminar un cartucho y cargas el segundo. No valdría para todos los géneros, pero para un walking simulator por ejemplo sí.

Para eso mejor aprovechar que los cartuchos tienen comunicaciones de sobra y hacer un cambio de banco al vuelo. El cartucho podría tener 512MB o los que se quiera, y saldría mucho más barato que varios cartuchos sueltos.

EMaDeLoC escribió:Para eso mejor aprovechar que los cartuchos tienen comunicaciones de sobra y hacer un cambio de banco al vuelo. El cartucho podría tener 512MB o los que se quiera, y saldría mucho más barato que varios cartuchos sueltos.

Para eso sirven los mappers.

Es que quitando los frames por segundo, y el tamaño de la estancia, eso son gráficos de dreamcast, es una barbaridad xD

Del vídeo del bump mapping + iluminación pseudo por pixel, ya ni hablemos. Menudo demake del doom 3 podría salir de ahí.

@EMaDeLoC yo estoy pensando en los flashcards

@EMaDeLoC según los documentos del gigaleak de Nintendo la consola soporta hasta 2Gb (o 256MB como lo mostraría un PC) es decir, 4 veces el cartucho de RE2, pero si ese cartucho ya se acercaba a los 100€, imagínate el precio d eun cartucho con 4 veces esa capacidad.

Ese límite también se aplica a los discos de 64DD que obviamente serían más baratos (aparte de permitir cambiar entre discos)

Conker64 escribió:Interesaría un nuevo tutorial sobre como instalar libdragon?

Tengo un nuevo portátil, toca instalar el entorno y seguramente aproveche para hacer un megazord, con la versión más moderna de la lib, pero combinando todo aquello que no tenga del chip gráfico.

Hola Conker64,

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

Gracias anticipadas,

La libreria libdragon está en desarrollo continuo.
Han creado un microcodigo 3D, implementando opengl 1.1, con algunas extensiones a mayores.
Para ello es necesario usar el branch unstable.

Por ahora tiene peor rendimiento que libultra, ya que falta la fase de optimización.

Sobre libultra lo adecuado es usar modernsdk y acaban de decompilarlo, por lo que igual estan aplicando optimizaciones que se podrían aplicar a las roms oficiales, al menos a los proyectos ya descompilados.

Existen hilos de discord donde tratan estos temas

ALCAMJI escribió:@EMaDeLoC según los documentos del gigaleak de Nintendo la consola soporta hasta 2Gb (o 256MB como lo mostraría un PC) es decir, 4 veces el cartucho de RE2, pero si ese cartucho ya se acercaba a los 100€, imagínate el precio d eun cartucho con 4 veces esa capacidad.

Ese límite también se aplica a los discos de 64DD que obviamente serían más baratos (aparte de permitir cambiar entre discos)

La verdad es que eso ya salía en algún documento de desarrollo filtrado hace tiempo y @radorn y yo estuvimos mirando y discutiendo la tabla de direcciones de la consola durante dias para ver cuanto realmente era el tamaño máximo de cartucho que soportaba. De hecho creo que el 64drive de Retroactive soporta ROMs de 256MB (o casi).
Pero como son movidas teóricas en base a las direcciones de memoria de la consola y algunas estan reservadas y otras no, no nos quedó muy claro, pero lo de los 256MB si que llegó a salir en algún momento.
Hay que tener en cuenta que, teoricamente, con su bus de 32bits puede manejar 4GB de datos, pero hay montones de direcciones reservadas a registros, periféricos, etc.
Hace 5 años años ya de eso, la hos*** p*** como pasa el tiempo.

En cualquier caso yo creo que tanto sean 64 como 256MB actualmente no hay límite real del cartucho usando soluciones como mappers. Los chips de memorias estan baratisimos y van por gigas, teoricamente se podría. Otra cosa por supuesto es en la época comercial de la consola, que era totalmente inviable economicamente meterle más de 64MB, fuese con soporte nativo de la consola, con mappers o lo que fuese.

@EMaDeLoC Si no recuerdo mal el mapa de memoria de la consola permitiría los 256 MB completos para ROM, pero el 64drive V2, que internamente tiene esos 256 en chips de RAM para emular la ROM, reserva un bloque de 16MB al final de ese rango para lo que marshallh llama CI o Cartridge Interface (no confundir con el PI, Parallel Interface, que es el nombre técnico de la ranura de cartucho de la consola). Este CI es la manera en que la CPU de la N64 puede acceder a las funciones especiales del 64drive, como son algunos registros internos (por ejemplo, para establecer el tipo de guardado a emular), la tarjeta SD, la interfaz USB, y, en el hardware V2, el módulo WiFi integrado (para los que no sabían que tenía tal cosa, que dudo que haya tenido uso alguno, puesto que la mayor parte de desarrollo se hace con variantes de Everdrive en mente)

Así que N64 permite 256MB de ROM (probablemente), pero el 64drive lo limita a 240 por reservar los últimos 16 para uso interno.

No se qué motivo técnico tuvo marshallh para reservar un bloque tan grande para algo que, según recuerdo, en realidad no usa ni 1MB (tendría que ver el PDF otra vez para confirmarlo). Supongo que es por simplicidad de implementación. En cualquier caso, dudo que alguien vaya a hacer jamás una ROM homebrew tan grande.

Al final es mas fácil acceder directamente a la SD para almacenamiento extra.
Incluso si quisiera uno hacer un homebrew de gigas de tamaño (por poner un ejemplo exagerado), sería mas simple tener una ROM, digamos, con el motor y algunos recursos básicos, y posteriormente luego cargar datos desde la SD para niveles o lo que sea.

El hardware interno del 64drive (como seguro que también hacen los EDs) puede hacer DMA desde la SD a la RAM interna, aunque no se qué flexibilidad tiene este mecanismo, puesto que generalmente solo usa el software del menú para cargar ROMs enteras desde la SD a la RAM interna del cartucho para luego arrancarlas. Tendría sentido que se pudiera hacer DMA en cualquier momento para mover ficheros entre la SD y esa RAM interna de forma arbitraria, pero no puedo confirmar que sea así ni conozco ningún ejemplo que lo haga.

En fin, que la forma mas práctica para hacer "juegos gigantes" en N64 con un 64drive sería tener una ROM básica que arranque de forma normal, y expandir el almacenamiento cargando cosas dinámicamente desde la SD. Por ejemplo, un homebrew o mod podría incluir un driver FAT32 para acceder a la SD, y además de la ROM sería necesario copiar a la SD una carpeta con un nombre específico que contuviese el contenido extra. Una vez cargada la ROM buscaría esa carpeta y la usaría.
La idea básica es similar a lo que hace el 64DD.

En una situación así, también podría usarse la RAM sobrante del cartucho como... ejem, como RAM. Si bién, una RAM lenta para usos secundarios de poco ancho de banda, como recordar la posición de objetos de forma permanente. Se podrían hacer cosas muy muy ambiciosas... con tiempo y recursos, claro...
De todas formas no hay que olvidar que estamos hablando de una máquina de 1996 y manejar tantos datos, aunque tengas la memoria disponible, requiere proceso, y ya van las cosas suficientemente justas.
Lo que si permite mejorar fácilmente esta disponibilidad de almacenamiento es no tener que escatimar en cuanto a cantidad y variedad de texturas al no estar limitado por ROMs de unos pocos MB. También la calidad de las muestras de sonido. Ye podrían incluir audio y video pregrabados sin mas limite que el de la SD.

Ya que hablamos de expandir cosas, esto si que no lo recuerdo nada bien, pero CREO que el mapa de memoria de la consola permitiría hasta 32MB de RDRAM. Otra cosa es que lo soportase el controlador de RDRAM integrado en el RCP. Creo que soporta hasta 4 chips de RDRAM, juzgando por la información que muestra en pantalla una herramienta interna que se filtró para inspeccionar los chips de RAM, que tenía 4 espacios, así que QUIZÁ sea posible enlazar hasta 16MB a base de sacrificar EPs, pero ya entrarían en juego cosas como la integridad de la señal y la estabilidad del suministro eléctrico.
Una posible vía para hacer una N64 de 12MB de RDRAM sería con una placa de las primeras remesas, que tenían dos chips de 2MB, sustituirlos por dos chips de 4MB sacados de 2 EPs, y un tercero sin modificar en la ranura habitual. Por lo que vi en su momento es "probable" que funcionase, aunque nunca vi a nadie que lo hiciese. Quizá en estos ultimos años alguien lo haya hecho y no me he enterado, no lo se.

En fin. Todo esto son mayormente sueños húmedos.

radorn escribió:Ya que hablamos de expandir cosas, esto si que no lo recuerdo nada bien, pero CREO que el mapa de memoria de la consola permitiría hasta 32MB de RDRAM. Otra cosa es que lo soportase el controlador de RDRAM integrado en el RCP. Creo que soporta hasta 4 chips de RDRAM, juzgando por la información que muestra en pantalla una herramienta interna que se filtró para inspeccionar los chips de RAM, que tenía 4 espacios, así que QUIZÁ sea posible enlazar hasta 16MB a base de sacrificar EPs, pero ya entrarían en juego cosas como la integridad de la señal y la estabilidad del suministro eléctrico.
Una posible vía para hacer una N64 de 12MB de RDRAM sería con una placa de las primeras remesas, que tenían dos chips de 2MB, sustituirlos por dos chips de 4MB sacados de 2 EPs, y un tercero sin modificar en la ranura habitual. Por lo que vi en su momento es "probable" que funcionase, aunque nunca vi a nadie que lo hiciese. Quizá en estos ultimos años alguien lo haya hecho y no me he enterado, no lo se.

En fin. Todo esto son mayormente sueños húmedos.

El soporte de 4 chips de RDRAM creo que es porque las primeras revisiones venian con dos chips de 2MB (2'25 siendo exactos, pero simplifico) y seguramente si hubiese salido el Expansion Pak al año siguiente habría venido también con dos chips en vez de uno. Y de hecho hay clones chinos con dos chips. Así que el soporte de 4 chips vendría por ese motivo. Si luego soporta más de 8MB siendo su máximo planeado quizá sea algo más accidental que a propósito, debido a la organización de memoria.
Luego ya aparte el SDK oficial seguramente ni de coña soporta más de 8MB y por supuesto los juegos tampoco.

Me suena que alguien metió 12MB en una N64 soldando chips y usando Expansion Pak, y la consola los reconocia. Pero claro, si el juego esta programado para 8MB como máximo, no se obtiene ninguna ventaja.