Hilo de detalles y curiosidades de N64

@dinodini sí, la primera consola que soportó por hardware suavizado gráfico fue N64 (o eso creo). A algunos les gusta a otros les parece que emborrona y estropea la nitidez, especialmente porque al jugar por video compuesto ya estás emborronando la señal y con eso fue suficiente para PS1 y SS. Va para gustos supongo.

Edit: Se me olvidaba, PS1 tiene al menos un juego que generaba un efecto antialising:


No es antialising real, es el típico truco para paliar una carencia del hardware, pero el resultado es bastante bueno, lo que me gustaría saber es si es un truco que apenas consume recursos o no, porque si era un truco "barato" fue una pena que más juegos no lo copiaran.

@dinodini @SuperPadLand Se le conoce como filtrado bilineal y consiste en que, al proyectar la textura del polígono en el framebuffer, cada pixel que se dibuja en vez de ser el más cercano, como hace PS1, es el producto de una interpolación entre los 4 píxeles más cercanos. Aunque por abaratar la complejidad del RCP en la Nintendo 64 se hace con tres píxeles.
El mipmapping al que os referis es coger una textura y disminuir su resolución varias veces, con la idea de que según el ángulo del polígono, se use la textura de menos resolución cuanto más acentuado sea el ángulo. Esto evita que se creen patrones raros o demasiados píxeles moviendose en los polígonos lejos de la cámara.

Y el antialiasing es crear pixeles en el borde de un polígono para evitar los famosos bordes de sierra, pintando un pixel con un grado de transparencia cuando no es un píxel completo (subpixel).
Los tres los soporta la N64, aunque su uso es variado dependiendo del juego.

Yo que tenía la PS1 me daba envidia como se veían esas texturas de N64. Y hasta que no tuve la PS2 no disfrute de ese tipo de texturas.



En PS1 era todo mas pixelado, mas emborronado, mas sucio, no se como explicarlo.
Esta captura esta en demasiada baja resolución, pero hace idea de lo que quiero decir.

@dinodini ten en cuenta que sigues pillando imágenes dopadas de lo que pretendes mostrar como mejor (que lo era) y no las estiras y las comparas con imágenes a resolución nativa estiradas por tres o por cuarto y por supuesto sin ningún tipo de filtro que simule la señal compuesta de la época y CRT.

Aquí tienes como se ve esa captura a resolución nativa sin estirar:


Aquí tienes aplicando un filtro CRT de la época que aun así es demasiado nítido, pero filtro de vídeo compuesto por ahora todavía no existe:



Cambia bastante la cosa a la imagen que has puesto tú, es como algunos gifs o memes que hay para reirse de los gráficos de consolas viejas que están distorsionados para hacer las risas:


Aquí lo que hacen de primeras es estirar la imagen dos o tres veces el tamaño original en la escena de arriba y luego a mayores cogen un trozo enano de dicha imagen y la vuelven a estirar hasta el mismo tamaño que la escena previamente estirada. Entonces claro se ven píxeles por todos lados, la imagen original a 320x240 y filtro CRT se ve así:


No era 4K precisamente, pero tampoco eran cuatro píxeles moviéndose.

SuperPadLand escribió:@dinodini ten en cuenta que sigues pillando imágenes dopadas de lo que pretendes mostrar como mejor (que lo era) y no las estiras y las comparas con imágenes a resolución nativa estiradas por tres o por cuarto y por supuesto sin ningún tipo de filtro que simule la señal compuesta de la época y CRT.

Aquí tienes como se ve esa captura a resolución nativa sin estirar:


Aquí tienes aplicando un filtro CRT de la época que aun así es demasiado nítido, pero filtro de vídeo compuesto por ahora todavía no existe:



Cambia bastante la cosa a la imagen que has puesto tú, es como algunos gifs o memes que hay para reirse de los gráficos de consolas viejas que están distorsionados para hacer las risas:


Aquí lo que hacen de primeras es estirar la imagen dos o tres veces el tamaño original en la escena de arriba y luego a mayores cogen un trozo enano de dicha imagen y la vuelven a estirar hasta el mismo tamaño que la escena previamente estirada. Entonces claro se ven píxeles por todos lados, la imagen original a 320x240 y filtro CRT se ve así:


No era 4K precisamente, pero tampoco eran cuatro píxeles moviéndose.

Si, es lo que pasa. Cuando veo hoy en día los graficos que se ponen de juegos del Amiga, con su resolución de 320x240, se ven cuadraditos por todos lados, y yo me acuerdo que cuando jugaba en su día no se veía así ni de coña, y es que en aquellos años las teles de tubo, con su resolución SD, simulaba muy bien los bordes de los pixels, hasta el punto que no sabía lo que era la pixelación hasta que llegó la tv plana y se puso a mostrar los juegos de generaciones anteriores sin filtros ni nada.

@SuperPadLand Esa imagen ampliada, además de los píxeles lógicos de la consola, hay muchos más que son los típicos de la compresión de imagen JPG, no de la consola. Si ampliaran una captura directa en .bmp o .png ser vería pixelada también, pero mucho mejor.

Por cierto, @Conker64 , podrías pasarnos el emulador de Neogeo compilado para la consola?
También estoy buscando si hay nuevas versiones del alt64 compatibles con el ED64 chino, y también de los emuladores de NES, Gameboy, MSX... porque parece que las hay pero no se si son compatibles con este everdrive. La última vez que lo miré fué en 2015!

@bluedark
Hola, la beta que me enviaron venía con el Metal Slug inyectado y se rompía por la parte final del primer nivel.

Supongo que habrá que esperar un poco hasta que tengamos algo más funcional

bluedark escribió:@SuperPadLand Esa imagen ampliada, además de los píxeles lógicos de la consola, hay muchos más que son los típicos de la compresión de imagen JPG, no de la consola. Si ampliaran una captura directa en .bmp o .png ser vería pixelada también, pero mucho mejor.

Por cierto, @Conker64 , podrías pasarnos el emulador de Neogeo compilado para la consola?
También estoy buscando si hay nuevas versiones del alt64 compatibles con el ED64 chino, y también de los emuladores de NES, Gameboy, MSX... porque parece que las hay pero no se si son compatibles con este everdrive. La última vez que lo miré fué en 2015!

En cuanto al emulador de Game Boy y Game Boy Color que funciona en el ED64, echa un ojo aquí: hilo_hilo-oficial-nintendo-64_2275957_s2850#p1751923148

Conker64 escribió:@bluedark
Hola, la beta que me enviaron venía con el Metal Slug inyectado y se rompía por la parte final del primer nivel.

Supongo que habrá que esperar un poco hasta que tengamos algo más funcional

El autor ha realizado cambios en los últimos días.

Yo intenté compilarlo, pero la versión que obtuve no funciona en mi ED64P, aunque sí en emuladores.

Instalé libdragon manualmente, igual ahí está el fallo. Miraré el libdragon-docker a ver.

bluedark escribió:@SuperPadLand Esa imagen ampliada, además de los píxeles lógicos de la consola, hay muchos más que son los típicos de la compresión de imagen JPG, no de la consola. Si ampliaran una captura directa en .bmp o .png ser vería pixelada también, pero mucho mejor.

Por cierto, @Conker64 , podrías pasarnos el emulador de Neogeo compilado para la consola?
También estoy buscando si hay nuevas versiones del alt64 compatibles con el ED64 chino, y también de los emuladores de NES, Gameboy, MSX... porque parece que las hay pero no se si son compatibles con este everdrive. La última vez que lo miré fué en 2015!

El Alt64 lo tienes aquí: https://ed64p.com/downloads/

Pero ya te digo que salvo que quieras usar mucho la opción de cheats no es un firmware nada recomendable, funciooooooonnnaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaasssssssssssiiiiiiiiiiiiiiiiiiiiiiiiiiiii deeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee leeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeentoooooooooooooooooooooooooooooo.

En principio cualquier homebrew que salga debería ser compatible con el ED64 chino, el flashcard sólo se transforma en la ROM que tú le digas, el resto es cosa de la N64. Aquí no hay chips de apoyo como en SNES ni mil mappers como en NES, además de que el mapper de RE2 está soportado y que yo sepa no hay más.

@SuperPadLand Sí, recuerdo probarlo en su dia y lo sabía, pero pensaba que en sus últimas versiones habría mejorado en algo la velocidad...
Sigo esperando a esa versión de las que nos hablaba @Conquer64 del menú que iba a utilizar aceleración 3D

Vale pues entonces probaré sólamente las últimas versiones de los emuladores a ver si alguno ha mejorado.

Otra cosa. Ayer estuve probando el Dinosaur Planet en la consola y después de varios intentos, he comprobado que no funciona si se selecciona el idioma castellano (en inglés sí). Sólo permite entrar al menú y configurar, pero al iniciar el juego -> pantalla en negro.
¿Alguno ha conseguido cargarlo en español? Yo utilizo el ED64p (el chino), con los saves en modo FLASH.

@bluedark es que creo que el Alt64 no se ha actualizado en 7-8 años, yo lo probé en el 2016 y que yo sepa no hubo ningún avance en él.

El Alt64 solo lo he usado una vez, para meter un cheat que desactiva el expansion pak; ya sabeis que en RE2 con el expansion pak hay un baile de entrelazado-progresivo que con el OSSC provoca unos parones en la imagen muy molestos

Kaze Emanuar ha publicado un vídeo del último mod de Super Mario 64 en el que está trabajando corriendo en el hardware real con contador de FPS para mostrar las mejoras en el rendimiento que ha ido introduciendo.



El problema de los mods de SM64 es que inicialmente no funcionaban en hardware real ni tampoco estaban pensado para ello, aprovechándose de la manga ancha que proporcionaban los emuladores. Solían tener una carga gráfica imposible de renderizar en el hardware real a una tasa de imágenes jugable. Creo que para estos mods era obligatorio el uso de los 8 MB del Expansion Pak, lo que permitía a los autores aumentar el nivel de geometría a niveles absurdos.
Kaze lleva años desarrollando los mods más avanzados de SM64 añadiendo nuevas mecánicas muy alejadas del juego original. Sus primeros trabajos, aunque no tan desmesurados como lo que se solía ver, también tenían problemas de rendimiento cuando empezaron a hacerse compatibles los mods con el hardware. Ya se publicó por aquí un vídeo de los retoques que había tenido que hacer a unos de los primeros mods más populares (Star Road) para que funcionara aceptablemente en el hardware real.
Con el transcurso de los años, Kaze ha ido mejorando las herramientas de creación de hacks, sus habilidades artísticas y también ha introducido multitud de mejoras en el motor gráfico del juego para hacerlo más eficiente, más moderno, y enfocado a que sus mods puedan disfrutarse también en la Nintendo 64 mejorando la experiencia del juego original.
Dejo en secreto unos cuantos vídeos ordenados cronológicamente donde el propio Kaze describe los cambios que ha ido introduciendo.


Me molaría muchísimo ver el Super Mario 64 original con todas las mejoras técnicas y artísticas que ha ido realizando (halo de brillo en las estrellas, nueva textura alucinante para las monedas, efectos de luz sobre Mario, modelos mejorados de Mario y enemigos, textura del humo con tratamiento de semitransparencia...) y ver si es posible alcanzar los 60 fps.

---------------------

Y a aprovecho para dejar el vídeo de DF retro sobre la saga F-Zero, aunque la parte de F-Zero X y la expansión del 64DD se explican bastante por encima y hemos realizado análisas más detallados en este hilo.

Como nos la metieron doblada con N64 y sus framerates. Ya no digo a 60fps, pero todo el catálogo podría funcionar perfectamente a 30fps estables

@SuperPadLand No creo que fuese intencionado. Había muy poca experiencia con el 3D y en como optimizarlo debidamente. Posiblemente los únicos con dicha experiencia para abordar debidamente los desarrollos eran los miembros de ID software, pero se centraban en PC.
Además la N64 era una máquina que había que coordinar muy bien los accesos a la única memoria RAM y durante el periodo de renderizado esta muy ocupada.

Desde que se lanzó hasta ahora han pasado 25 años donde se ha estudiado mucho el 3D, se calculan más rapido algunas operaciones, los artistas tienen mucha más experiencia y conocen mejores técnicas. Por ejemplo el Mario 64 de DS tiene menos polígonos que el de N64 y se ve mejor, gracias al mayor conocimiento y mejores herramientas.

Y sin olvidar que antes internet estaba en pañales y era difícil encontrar información actualizada de nuevas técnicas, y mucho menos si eran propias de determinada desarrolladora. Ahora en un clic accedes a código fuente libre de técnicas brutales o libros enteros de geometría.

Es por ello bastante normal que ahora con el código fuente se pueda optimizar mucho los juegos.
Sería genial decompilar el F-Zero y aplicar las mismas técnicas que el World Driver Championship para tener escenarios con más decoraciones manteniendo el framerate.

@Sogun
Interesante, ha conseguido mejorar el rendimiento del juego cambiando funciones matemáticas, flags del compilador y demás.

Si metiera mano al ucode o a las librerías la cosa se pondría interesante, pero por lo visto quiere mantener la compatibilidad con los emuladores y no va a seguir esa ruta.

@bluedark
Ah, no tenía pensado acelerar el alt64, pero sí hacer una especie de loader nuevo con portadas, similar a los que hay en Wii, acelerado claro, integrarle una base de datos con los cheats conocidos ya precargados, manejo avanzado para el controller pak, como acceder a su contenido para copiar o borrar juegos, ​pero es trabajo.

Hace ya tiempo que el slot del Everdrive está en las últimas, supongo que si me lo hubiera montado bien como el colega Kaze tendría un patreon para poder invertir en un ED con USB, o dedicarle más tiempo a la scene de N64

Creo que esto es interesante, @Conker64

https://twitter.com/forestillusion/stat ... 9746267138

@bluedark
Ah genial

Sí, hay algunos vídeos en youtube probando el software, aunque hace falta todo el kit de desarrollo, pero seguro que alguno en la scene le saca partido

Conker64 escribió:@Sogun
Interesante, ha conseguido mejorar el rendimiento del juego cambiando funciones matemáticas, flags del compilador y demás.

Si metiera mano al ucode o a las librerías la cosa se pondría interesante, pero por lo visto quiere mantener la compatibilidad con los emuladores y no va a seguir esa ruta.

@bluedark
Ah, no tenía pensado acelerar el alt64, pero sí hacer una especie de loader nuevo con portadas, similar a los que hay en Wii, acelerado claro, integrarle una base de datos con los cheats conocidos ya precargados, manejo avanzado para el controller pak, como acceder a su contenido para copiar o borrar juegos, ​pero es trabajo.

Hace ya tiempo que el slot del Everdrive está en las últimas, supongo que si me lo hubiera montado bien como el colega Kaze tendría un patreon para poder invertir en un ED con USB, o dedicarle más tiempo a la scene de N64

Nunca es tarde Conker

@ChepoXX


Por cierto el tipo de los framerates sigue subiendo vídeos interesantes, esta comparativa me ha gustado:


Dice que está grabando un vídeo del World Driver Championship para el siguiente

@Conker64 lo que no entiendo es como ese juego tiene problemas de framerate en ambas consolas

Conker64 escribió:@ChepoXX


Por cierto el tipo de los framerates sigue subiendo vídeos interesantes, esta comparativa me ha gustado:

Dice que está grabando un vídeo del World Driver Championship para el siguiente

Es curioso, tienen un framerate parecido sino igual y en la N64 lo percibo más fluido que en PS1.
Creo que debe ser porque en PS1 no hay precisión subpixel y al moverse los polígonos de forma tosca y poco precisa la percepción del movimiento es que es peor que en N64.

Es subjetivo, pero no sé si también lo notais así.

EMaDeLoC escribió:

Conker64 escribió:@ChepoXX


Por cierto el tipo de los framerates sigue subiendo vídeos interesantes, esta comparativa me ha gustado:

Dice que está grabando un vídeo del World Driver Championship para el siguiente

Es curioso, tienen un framerate parecido sino igual y en la N64 lo percibo más fluido que en PS1.
Creo que debe ser porque en PS1 no hay precisión subpixel y al moverse los polígonos de forma tosca y poco precisa la percepción del movimiento es que es peor que en N64.

Es subjetivo, pero no sé si también lo notais así.

Siempre me pareció así. Los juegos que iban suaves en N64 a 30fps, iban mucho más suaves y fluidos que en PS1/Saturn. ¿Podría ser por que N64 disponía de "doble buffer"?


Pd. En cualquier caso... el juego tampoco lo veo como "algo prodigioso", quizás por que por la temática luce poco o directamente porque los gráficos son reguleros y además tiene desactivado el AA en N64.

sgonzalez escribió:Siempre me pareció así. Los juegos que iban suaves en N64 a 30fps, iban mucho más suaves y fluidos que en PS1/Saturn. ¿Podría ser por que N64 disponía de "doble buffer"?

Ps1 también tiene doble buffer, y creo que Saturn también, pero no estoy seguro.

sgonzalez escribió:Pd. En cualquier caso... el juego tampoco lo veo como "algo prodigioso", quizás por que por la temática luce poco o directamente porque los gráficos son reguleros y además tiene desactivado el AA en N64.

Esta capturando con mod HDMI y el filtro de deblur. Y me aventuro a decir que la PS1 también tiene mod HDMI.

Según vi en todo lo que he ido analizando, una gran mayoría de juegos de N64 suele usar sync doble buffer, que salta de 30 a 20 y luego a 15, es bastante molesto.

Los que usan triple buffer se mueven mucho más suaves, yo diría que es el caso de este juego, supongo que siguen usando el vsync, en las consolas de Sony es bastante normal que lo desactiven, lo he visto bastante en PS2 y 3, ahora no recuerdo que tal hace PSX, pero el de los vídeos deja a veces las versiones de PSX fuera por el tearing ya que le altera los resultados, así que aquí supongo que PSX también va con el sync en este caso concreto.

Claro, el desplazamiento en N64 es siempre más suave, sobretodo en movimientos cortos o que requieran precisión, también ayuda la estabilidad global, es lo que me gusta del vídeo, son casi idénticos, pero mostrando como cada una renderiza.

El rendimiento es solo parecido en el primer nivel, en los demás N64 rinde mejor, por ejemplo en el 2:01 se puede ver lo que pasa cuando llevas PSX ahogada y le pones semi transparencias, N64 ni se inmuta ya que en cycle 1 le cuesta casi lo mismo poner superficies con o sin ella, ayer lo probé en modo contrarreloj y como es de esperar rinde mejor que en una carrera abierta con más pilotos.

Faltaría saber que están usando para todas las superficies flat, de hecho a pesar del estilo se ve limpio y con algo de geometría en los niveles.

Para ser una third party está bastante mejor optimizado que lo que se solía ver en la maquina, como este otro que tiene todos los defectos comunes, texturas pastel en baja resolución, poca geometría, sobre los 15..

@Conker64 da la sensación de que si le desactivas el framerate el juego funciona a 40-60fps el 90% del tiempo

@SuperPadLand
Cual de ellos, el Lego?

Si bueno, el algoritmo del frameskip cuando evalúa los tiempos requiere que el resultado esté siempre por encima de la tasa que has establecido, por eso es tan difícil alcanzar 60 estables, el juego tiene que ir por encima de eso, ahora viene la gracia, muchos algoritmos ni están adaptados a PAL, a poco que saque 29 bajará a 20 en NTSC o 17/16 en PAL (cuando el set de PAL son 25) si es sync doble buffer.

El Hot Wheels fatal, ni mirando al cielo donde apenas renderiza parece hacerlo bien, hay secciones que se pone a 30 y otras incluso a 60, así que me hace dudar si son fallos del análisis del vídeo, si tiene limite a 20 no debería subir y si no lo tiene mirando al cielo casi siempre debería alcanzar 30 por lo menos, esto viene a raíz de que en el cielo no hay superficies amontonadas, salvo que la lógica del juego meta un impacto importante al rendimiento.

@Conker64 lo decía por el LEGO, pero el Hot también tiene pinta.

Ostia con el Hot wheels, un juego de coches a 20 FPS y ni siquiera estables, el de LEGO lo veo bastante bien para la época.
Siempre me pareció raro que no saliese un juego con el estilo gráfico de GT para N64, me parece que es más resultón por su dirección estética, que por potencia bruta, cosa aparte hubiese sido meterle tanto contenido como el GT, cuando los juegos de carreras no solían pasar de 128 Mbits de Rom.

Salud.

Yo tampoco me fiaría mucho de esas mediciones de framerate de señal analógica. Dependiendo de cómo configures trdrop, que es lo que ha usado, te puede salir desde 5 frames por segundo hasta 60, con la misma fuente. Y lo mismo va por Digital Foundry y todo ese tipo de canales.

En fuente digital es más exacto porque tienes una imagen 1:1 del buffer, y ahí fácilmente un programa puede detectar si hay cambios reales, pero con fuente analógica hay ruido, uses lo que uses.

un stunt race para Nintendo64 hubiera sido cojonudo !

Doriandal escribió:Yo tampoco me fiaría mucho de esas mediciones de framerate de señal analógica. Dependiendo de cómo configures trdrop, que es lo que ha usado, te puede salir desde 5 frames por segundo hasta 60, con la misma fuente. Y lo mismo va por Digital Foundry y todo ese tipo de canales.

En fuente digital es más exacto porque tienes una imagen 1:1 del buffer, y ahí fácilmente un programa puede detectar si hay cambios reales, pero con fuente analógica hay ruido, uses lo que uses.

Supongo que esta es la explicación de porqué mi capturadora de video chinorra va bien con consolas digitales y en las analógicas, pese a usar OSSC, graba con congelaciones de la imagen en unos juegos, en otros desincroniza por completo el audio, etc.

Me he topado por casualidad con un efecto gráfico para simular agua que no creía que fuera posible en Nintendo 64. Parece algo más propio de la siguiente generación de consolas. Pongo el resto del mensaje en secreto porque son varios vídeos.


Feliz Navidad y Feliz Año a todos.

Yo siempre he flipado con el agua de Wave Race 64:

Sogun escribió:Me he topado por casualidad con un efecto gráfico para simular agua que no creía que fuera posible en Nintendo 64. Parece algo más propio de la siguiente generación de consolas. Pongo el resto del mensaje en secreto porque son varios vídeos.

¿Alguien sabría explicar cómo se consigue el efecto y el nombre técnico si es que tiene uno? Por lo que he entendido son dos texturas desplazándose a velocidades y direcciones diferentes que hacen cosas chulas cuando se combinan diferentes píxeles de ambas texturas.

Ocarina of Time hacía lo de las dos texturas entrecruzándose pero sin la "magia" que están haciendo estos modders. Daba la impresión de ser una textura animada, pero en realidad son dos capas de texturas desplazándose en diagonal en distintas direcciones. Me parece que es incluso la misma textura.

Hace poco hubo una competición de juegos homebrew y uno de ellos llamado Tecto tiene un efecto similar (si es que no es el mismo) para el agua. También hace un uso muy inteligente del environment mapping para simular cel-shading.

EDIT: Kaze Emanuar ya lo había hecho antes. O al menos el resultado es muy parecido.

Feliz Navidad y Feliz Año a todos.

Tendría que mirarlo exactamente, pero parece 2 texturas con diferente movimiento y velocidad y una de ellas haciendo de máscara de transparencia.
El agua del Zelda se hace igual pero con 2 texturas sólidas y haciéndolas semitransparente desde el motor del juego.
La del mod de Mario diría que es igual a como se hace en Zelda, pero con texturas con semitransparencia en vez de sólida, así puedes hacer que sea con partes con diferente nivel de transparencia, no como cuando usas sólidas, que toda la superficie tiene el mismo nivel de transparencia.
Salud y feliz año a todos.

@Sogun @dirtymagic


Supongo que se basa en algo que dice aquí del Color Combiner y el Alpha Combiner: http://n64devkit.square7.ch/tutorial/graphics/4/4_1.htm

El efecto en las texturas de WR igual es menos avanzado, pero lo interesante del juego es la deformación de la malla poligonal.

Port de OpenLara para N64, todo muy experimental en 5 días de desarrollo, por software sin aceleración de ningún tipo.


A la pregunta del millón:

> Is the N64 cpu slower than the GBA?

- The gba "port" repacks all of the data and has a bunch of handwritten assembly for the math and rendering. This is just the full C++ code with the PC data untouched

And this isn't using the RSP at all for geometry processing right now

Veremos si el port acaba teniendo código personalizado o tira de fuerza bruta, tiene algunos tests con el RDP, pero sin texturizar.

Por otro lado parece que las texturas de OpenLara serían de 256x256x8bit, unos 64KB, obviamente eso no entra en los 4KB de N64 o los 2KB de PSX, lo curioso es que ataca a las capacidades de texturizar de la consola, espero que se fije en las texturas originales de PSX, ya que los packs de texturas HD llevan años circulando.

@Conker64 lo mueve la 3DO decentemente como para no poder conseguir en N64 algo mucho mejor a nada que lo adapten un poco al hardware.

@SuperPadLand
Sí, no hay duda de eso.

El que hizo el port de GBA es un auténtico gurú

@Conker64 Se sabe si este Open Lara se limita al primero o tendría potencial para el 2 y el 3 que comparten motor gráfico? Lo digo porque sobre todo el 3 porteado a N64 sería un puntazo sólo por evitar los tiempos de carga infinitos cada vez que mueres.

@Conker64 ¿a qué resolución funciona OpenLara en N64 de momento?

@SuperPadLand
No estoy muy puesto en OpenLara, pero tienes el hilo oficial por aquí

Según he leido XProguer es el autor del engine y en teoría si no me equivoco también ha hecho los ports de GBA y 3DO, hace ports si dispone de las maquinas, en el caso de N64 es jnmartin que trabajó previamente con la libdragon para hacer el port "64doom", creo que también era por software, porque la poca aceleración gráfica que le puse a la librería es 2D o el de pintar triángulos sin texturizar (tiene algún test de eso en su vídeo).

@Sexy MotherFucker
Si es libdragon probablemente 320x240 o 256x240, la librería no tiene funciones preparadas para poner un framebuffer a un tamaño diferente de la resolución seleccionada, salvo que lo haya programado a mano.

En uno de los comentarios dice de migrar a libultra/f3dex, así que tampoco me queda claro si ya está usando libultra pero en modo software.

Cuando suba el proyecto a github será más fácil conocer los detalles

@Conker64 bueno, vamos poco a poco situándolo en el mapa:

- La demo se ejecuta en modo software sin sonido, esto quiere decir que únicamente se está empleando la CPU para mover todo el juego en 1 framebuffer, lo que viene significando apenas el 30% de la potencia total del sistema.

- A 320x240 y un framebuffer de 16 bits, con texturas de ¿256x256?¿8BPP?, un MIPs R.I.S.C 32 bits @93’75 Mhz con 8+16 Kb de caché obtiene un rendimiento de ¿3-5 fps? Un C.I.S.C Pentium de la época @100 Mhz con 8+128 kb de caché y un framebuffer de 8 bits con texturas mucho peores que las de OpenLara a 320x200 en modo software alcanzaba unos 15 fps aproximadamente.

He leído los comentarios de Youtube y el tío parece no acordarse de la resolución de las texturas originales en Saturn/PlayStation Parece 1 hater.

@Sexy MotherFucker
Eso es lo que me deja alucinado.

He estado mirando y por ejemplo esas texturas grandes que he puesto más arriba son 128x128, dando un vistazo largo por la comunidad de Tomb Raider parece que era bastante habitual ese tamaño "HD" mejorado, las de 256x256 no sé de donde salen, pero tiene sentido con la evolución de los años.

El caso es que las herramientas para montar el juego son para extraerlo por ejemplo de GOG, es decir versiones originales de PC, tengo que repasar un poco todo esto.

Porque si hablara de páginas de textura, entonces sería esto:


Y obviamente si yo genero texturas al vuelo desde un framebuffer y las cargo en la memoria de textura, no veo que problema debería tener en escoger una región de esa página y subirla a TMEM, siguen siendo de 64x64.

En el resto no me sorprende nada con 5 días de desarrollo, sin ser el autor original y otros factores.

Pero con esa página de texturas, si tiene que extraer la textura de 64x64 tiene que ser a 16 colores,va a tener que convertir una una, sí o sí¿en PSX y Saturn utiliza texturas tan grandes?

Salud.

@dirtymagic
Tendrían que ser de 16 colores si van a ser de 64x64 para caber en los 2KB de cache de la PSX .

Edit: Pero para aportar algo más detallado: en N64 subes la textura a una RAM de uso global, por eso se decantaron por un control manual de las mismas, al final es cosa del desarrollador decidir si limita la superficie al tamaño de la cache, que suele ser el caso.. no en el render por software claro, ahí se lo traga todo.

En PSX las texturas se suben en un formato concreto a la VRAM, al cargarlas se descomponen en bloques dependiendo del bitdepth, si son de 4, de 8 o de 15bit.

Los bloques son del tamaño que alcanza la cache de textura, por supuesto esa es la parte automatizada, como la de cargar diferentes bloques si se solicita para 1 superficie, o seleccionar regiones concretas de la VRAM.

Conker64 escribió:@dirtymagic
Tendrían que ser de 16 colores si van a ser de 64x64 para caber en los 2KB de cache de la PSX .

Edit: Pero para aportar algo más detallado: en N64 subes la textura a una RAM de uso global, por eso se decantaron por un control manual de las mismas, al final es cosa del desarrollador decidir si limita la superficie al tamaño de la cache, que suele ser el caso.. no en el render por software claro, ahí se lo traga todo.

En PSX las texturas se suben en un formato concreto a la VRAM, al cargarlas se descomponen en bloques dependiendo del bitdepth, si son de 4, de 8 o de 15bit.

Los bloques son del tamaño que alcanza la cache de textura, por supuesto esa es la parte automatizada, como la de cargar diferentes bloques si se solicita para 1 superficie, o seleccionar regiones concretas de la VRAM.

Solo hay que ver otro vídeo del que hace el port que es en flat, y las paredes, tiene a saco de polígonos, podría poner mejores texturas que el original, troceandolas, aunque seria un currado la verdad😅.
Salud.

Ver Tomb Raider funcionando en una Nintendo64 parece algo sacado de un universo paralelo, aunque de momento sea tan torpemente.

Es un juego de inicio de generación, así que está lejos de ser un portento y fue superado enormemente por cientos de títulos. Si se tratara de hacer una versión de cero específica para Nintendo 64 no veo nada que impida tener un juego perfectamente funcional y con todas sus características.
El propio diseño de los niveles a modo de retícula, combinado con teselación, podría usarse a favor para poder tener texturas nítidas en primer plano y texturas filtradas en los planos medio y lejano. No sé si "ports" de PS1 a N64 (estoy pensando especialmente en Wipeout) aún conservan ese modo de renderizar los escenarios. Es algo con lo que ya he especulado en el pasado y que Rogue Squadron utiliza a medias. Igual es que existe algún tipo de limitación técnica que impide a la Nintendo 64 funcionar de esa manera, o que el rendimiento caería en picado con tanta subdivisión de polígonos y cambios de texturas.

Mi idea sería (usando Tomb Raider para ilustrarla), usar texturas de 32x32@8bits en los polígonos subdivididos más cercanos a la cámara (texturas A,B,D y E) y otra textura F de 32x32@8bits que sería una versión reducida de la composición de las cuatro anteriores en los polígonos a media y larga distancia que no están subdivididos. La gracia estaría en ver a qué distancia de la cámara hacer el cambio para que se notase lo menos posible. En el caso ideal sería como tener texturas de 64x64@8bits con filtro trilineal y además se podría usar una gran cantidad de texturas para evitar patrones, como en la beta de Banjo. En juegos con escenarios contenidos donde poder controlar la carga poligonal creo que se le podría sacar mucho partido a este tipo de diseño de escenarios. Pero me extraña mucho que siendo la tónica habitual de hacer las cosas en PS1 (la plataforma donde más se desarrollaba), no parece que haya nada igual en N64.

Para este port de OpenLara creo que lo ideal sería renderizar los escenarios sin teselar y emplear texturas de 64x64 de 16 colores. Si las textura textura está formada por tonos de un mismo color, como la mayoría de aquella época, el cambio de 256 colores a 16 no se nota mucho (incluso el filtro bilineal crea tonos intermedios que hacen que la textura no parezca tan pobre) y sin embargo el cambio de resolución de 32x32 a 64x64 es abismal. Es el enfoque que usaron juegos como Turok 2, Donkey Kong 64 o Banjo Tooie que destacan por tener unas texturas de grandísimo nivel. Lo malo de esto es que no hay filtrado trilineal y las texturas se pixelan en la distancia; aunque si no hay variaciones de color muy acusadas, el baile de píxeles no resulta molesto.

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