Hilo de detalles y curiosidades de N64

Pues el resultado de buscar el texto de la marca de agua da que es del Twitter de Tim Stamper, poniendo los dientes largos a la gente con las cosas que se guardó de Rare antes de irse. Dudo que vaya a colgar un volcado (dump) de la ROM en la red. Podría equivocarme, pero me parece improbable.

https://twitter.com/InTimsWorld/status/ ... 8637732869

@radorn si hubiera querido hacerlo podria haberlo hablado con algun grupo de los que se dedica al dumpeo de prototipos y que hubiera salido sin saber de donde lo han sacado, pero ahora se pone una diana en la frente si lo dumpean

de todas maneras, en ocasiones siento como que la aparicion de betas antiguas jode un poco la magia, cuando se filtraron todo esos datos del OoT con escenarios que habiamos visto en revistas para encontrarte con que algunos escenarios parecian mas hechos para sacar la foto que para jugarlos, se pierde un poco la magia

Hay port del Xeno Crisis a N64, lo he tenido que mirar varias veces ya que no se les ocurrió otra cosa que ponerlo en April fools, luego sigue presente la actualización en kickstarter y en la tienda.

Libdragon según parece, con soporte para texturas de 4bit.

De paso os animo a poner curiosidades, homebrew, betas o lo que se os ocurra, para darle algo de vidilla al hilo

Ahora que dices lo de la libultra, leí en el discord, que en breve, van a sacar la libultra, libre de código propietario, gracias a la decompilación que han hecho, y se podrá usar sin problemas con Nintendo, espero que esto facilite las cosas, para ver homebrew nuevo.

Salud.

Conker64 escribió:Hay port del Xeno Crisis a N64, lo he tenido que mirar varias veces ya que no se les ocurrió otra cosa que ponerlo en April fools, luego sigue presente la actualización en kickstarter y en la tienda.

Libdragon según parece, con soporte para texturas de 4bit.

De paso os animo a poner curiosidades, homebrew, betas o lo que se os ocurra, para darle algo de vidilla al hilo

¿Quieres decir que el port de Xeno Crisis para N64 está hecho con Libdragon?

@ashurek
Sí, con ayuda de Rasky, que lleva años a cargo de la rama oficial, yo creo que la han modificado para añadir cosas que inexplicablemente no tiene la librería oficial todavía, tenían un proyecto para migrar todo aquello que sirviera del fork que hice, pero no han añadido mucho más que el mirroring por hard y algunas correcciones, imagino que el tema del RSP y el 3D les tiene ocupados.

Fortunately the excellent Libdragon from the N64 homebrew community made working on this port possible. A massive thanks to Rasky for his amazing support helping us tweak a few aspects like ADPCM music playback and pushing full size 4 bit textures into TMEM. Thanks to a few optimised settings better suited for 2D rendering on the N64 the result is the game plays great and now joins a small list of 2D only titles on the platform.

@dirtymagic
No sé, el SDK se filtró hace muchos años con código, igual la decompilación es de otra cosa? Aunque podrían tomarla como base sin copiar código, creo que también valdría.

Discord
Esta es una captura del mensaje original.
También están desarrollando F3DX3, con soporte para bumpmapping, cellshading y ambient oclussion entre otras cosas.

Salud.

Conker64 escribió:
De paso os animo a poner curiosidades, homebrew, betas o lo que se os ocurra, para darle algo de vidilla al hilo

Que yo sepa no hay nada nuevo últimamente de N64

Yo podría poner una beta de mi mod de zelda por rellenar pero preferiria que no hasta poner los textos
pero de n64 que yo sepa no hay nada mas ademas de lo que pase atrás lo mas que supe es que algunas teles tratan mejor el m-pal que el pal y algunos ni funcionan
Yo tuve que usar la m-pal para zelda ocarina PAL y sin and punishment NTSC pero para el pokemon tengo que ponerlo en PAL o si no ni carga

Si sacan otro SDK espero que simplifiquen la instalacion porque el libdragon hace poco hable con alguien de instalarlo y no llego a instalarlo porque no sabia

Conker64 escribió:@ashurek
Sí, con ayuda de Rasky, que lleva años a cargo de la rama oficial, yo creo que la han modificado para añadir cosas que inexplicablemente no tiene la librería oficial todavía, tenían un proyecto para migrar todo aquello que sirviera del fork que hice, pero no han añadido mucho más que el mirroring por hard y algunas correcciones, imagino que el tema del RSP y el 3D les tiene ocupados.

¿Libdragon es el mejor sdk actual para homebrew en N64?

Salen cosas, pero son más mods de mario 64 y zelda que juegos propios, al fin al cabo son 2 juegos con unas mecanicas y engine ya hechos, siempre es más fácil que programarlo de 0.
De Zelda a salido The sealed palace.

Y de Mario 64, Dog Collab


Salud.

@ashurek
Es de lo poco libre que puedes usar, cojea en 2D y en 3D, lo más completo es la libultra original de Nintendo, pero no se puede utilizar directamente salvo lo que comenta @dirtymagic, si la han reescrito o han reinterpretado un build más moderno (con el microcódigo), quizás sí.

La Libdragon oficial en 2D sigue sin ofrecer scaling, rotación, alpha blending, modos gráficos, ni texturas de 4/8 bit (sigue usando mksprite), gestión de paletas, gestión RGB para fundidos, degradados, todo ello está en el fork que hice, aunque han mejorado muchas otras cosas y conviene usar la oficial, del fork solo los archivos del RDP, porque casi todo lo demás es libradon 2017.

Luego queda la libn64, con un core rapidísimo y código marciano en ASM, pero tiene solo la base, le falta todo lo demás.

@SuperPadLand
Yo creo que también valen las impresiones, como cuando se hace una reseña o como he visto en el otro hilo preguntar que tal está el port del Xeno Crisis, todo eso también se podría comentar por aquí, a este punto de participación donde el hilo cae por semanas vendría muy bien

Conker64 escribió:Luego queda la libn64, con un core rapidísimo y código marciano en ASM, pero tiene solo la base, le falta todo lo demás.

Osea que es ahí donde la escena debería meter todas las fichas.

Estaría curioso ver que cifras podría arrojar una n64 en las condiciones mas ideales posibles de optimización.

@Señor Ventura
Sí, el core de la libn64, de la libultra todas las funciones "pro", las herramientas auxiliares pero modernizadas, el 3D y el ucode más moderno.

Para entenderse ese micro código sería el equivalente a las funciones en C para controlar al RDP, que o bien mandas los comandos a la memoria y el RDP las lee de ahí, o cargas un programa en el RSP, se comunica directamente con el RDP y en paralelo a la CPU, no le robas tiempo ni escribes en RAM, doble win, bueno eso es solo una pequeña parte, hay que controlar el audio y características 3D, los mejores lo hacen todo sin recargar en 4KB, los antiguos vienen en 3 bloques: 2D, 3D y audio.

También el último GCC o el más óptimo para el MIPS que usa la consola, muy sensible a eso.

De la libdragon los ejemplos y comunidad, el sistema de archivos es fácil de usar, siempre que lo optimicen para que lea rápido.

@Conker64 pues no sé si es realmente algo interesante, pero estamos jugando el Castlevania Legacy of Darkness y en la historia de Reinhardt cuándo visita la mansión en un cuarto hay un espejo y entra un aldeano miedoso y tal, Reinhardt mira al espejo y ve que el aldeano no se refleja y por tanto es un vampiro.

Hasta ahí nada raro al ser cinemática, pero al empezar el combate el espejo refleja todo el cuarto y al protagonista, pero no al vampiro del que solo muestra la sombra. Me ha parecido curioso.

Flash-Original escribió:algunas teles tratan mejor el m-pal que el pal y algunos ni funcionan
Yo tuve que usar la m-pal para zelda ocarina PAL y sin and punishment NTSC pero para el pokemon tengo que ponerlo en PAL o si no ni carga

¿Tienes una N64 Brasileña M-PAL? Si realmente hablas de eso, eres el primero que conozco con una.

¿O te estás hablando mas bien de lo que genera la consola PAL cuando el juego pone el modo de video a 60Hz?
Esto se llama comunmente "PAL60", y no es lo mismo que "M-PAL" o "PAL-M". Son dos cosas diferentes.
PAL60 es un nombre ad-hoc para una cosa rara que empezaron a usar productos de consumo PAL para ofrecer algún tipo de compatibilidad básica con contenido a 60Hz, mientras que PAL-M es una norma oficial usada en Brasil para emisiones de TV (no se si siguen con la analógica o ya se pasaron a digital), que combina señal de color estilo PAL con la base monocroma de NTSC y una frecuencia portadora de color ligeramente diferente, entre otras pequeñas diferencias.
Vamos, que no son lo mismo.

A la espera de que me confirmes qué es lo que tienes entre manos, también te pregunto qué problemas son esos que cuentas.

mas bien que el juego al dar la señal me da una imagen fantasma como una sombra lo dije hace tiempo aqui pero sin respuesta alguna lo cual hay que juegos que debo usar la PAL obligatoriamente si quiero que se vea decente y en otras NTSC
lo de que es si es PAL brasileña no tengo ni idea han pasado por mis manos varios n64 de echo ahora 3
He intentando usando un reescalador (de los malos) y me sale PAL60 no se es muy raro

No acabas de aclararme la situación. Pero por tus dudas, me inclino a pensar que de hecho no es la M-PAL brasileña.
En este foro hay un usuario de Brasil que cuenta los detalles de su consola. Aún no he leído casi nada pero tiene imágenes útiles para esta averiguación: https://www.tapatalk.com/groups/nintend ... t2727.html

( Para ver sin marca de agua http://i49.photobucket.com/albums/f293/ ... bab54a.jpg )
Si la etiqueta está en portugués brasileño y pone BRA en el modelo, es M-PAL. Si no, es PAL o NTSC.

Se me han olvidado los nombres de modelo, pero estoy bastante seguro que la PAL llevará una P y/o EUR y la NTSC llevará USA o JPN o algo a tal efecto.

Y respecto a eso que contaste "hace tiempo", ten en cuenta que llevo mucho tiempo desconectado de esto y seguramente no lo haya visto. Así que no tengo ni idea de qué problema estás teniendo.

Pues entonces no es brasileña
Pues no encuentro las imagenes pero ya da lo mismo casi ni toco la 64, si lo toco sera para dos juegos especificos en los que trabajo y si según como vaya la cosa si algun dia hacen un sdk funcional y hay documentacion en español (cosa que dudo profundamente) para tantear que tanto daria la consola para rpgs porque no hay ni uno o son maluchos

¿Se sabe si alguien ha extraído los ficheros internos de Rare Replay, especialmente los relativos a N64?

La pregunta me surge porque estaba viendo videos de los Hard4Games donde comentan los tuiteos de Timoteo Estampador mostrando los prototipos de Banjo y Conker, especulando sobre si saldrá algo jugable de la situacion, y sacaron a colación Rare Replay como demostración de que los protos están volcados y a salvo, comentando que los juegos corren bajo emulacion.

Bueno, no se mucho de Rare Replay pues no tengo el hardware para probarlo, pero en su momento vi algunos de los videos explicativos de cómo funciona el sistema y la impresión que me quedó es que es una forma de emulación un tanto peculiar, que yo sospecho que tiene que ver con la necesidad de evitar usar código de Nintendo/SGI (específicamente libultra)

En los videos que vi donde los desarrolladores explicaban la situacion, si no recuerdo mal se hablaba de una cosa llamada "source level emulation" o algo así, que, tras la explicacion parcial que se daba, humildemente interpreto como que el hardware de N64 se emula en buena parte pero se excluyen los binarios propietarios de Ninty, y no ejecuta las mismas ROMs que salieron en su momento en los cartuchos, si no compilaron nuevamente los juegos desde el codigo fuente, tras reemplazar libultra por una reimplementación nativa o emulación o combinación de ambas, para no tener que usar código de Nintendo y no tener ni que pedirles permiso ni negociar condiciones, cosa que ya sabemos lo facil que es tratandose de Nintendo

Pero la duda me quedó y pasó el tiempo. En fin... ¿Hay algo sólido en cuanto a hackeos o extracciones de Rare Replay o no? ¿Se sabe qué usa exactamente?

@radorn Las versiones del rare replay van a 60fps, tienen pinta de ser recompilados sobre el sdk de xbox one

@ashurek no digo que no hayan hecho algunos apaños sobre el código fuente, y yo mismo he mencionado que están recompilados, pero, por lo que vi en los videos aquellos, si que se daba a entender que había algún tipo de emulación de por medio, y tiene sentido que así sea, porque si no tendrían que reescribir todos los juegos y reconvertir todos los recursos a algo que funcione con las librerías de xbox one.
Alguna cosa tienen que emular, aunque sea a modo de "capa de compatibilidad", porque si no les tocaría repropgramarlo todo. Puede ser que el resultado sea un binario con rutinas de emulación de libultra/n64 integradas en el programa.

En cualquier caso, la duda sigue siendo si alguien lo ha comprobado. ¿se ha extraído, analizado, etc? ¿hay algo ahí dentro que tenga el mas mínimo rastro de nintendosesentaicuatridad?

radorn escribió:@ashurek no digo que no hayan hecho algunos apaños sobre el código fuente, y yo mismo he mencionado que están recompilados, pero, por lo que vi en los videos aquellos, si que se daba a entender que había algún tipo de emulación de por medio, y tiene sentido que así sea, porque si no tendrían que reescribir todos los juegos y reconvertir todos los recursos a algo que funcione con las librerías de xbox one.
Alguna cosa tienen que emular, aunque sea a modo de "capa de compatibilidad", porque si no les tocaría repropgramarlo todo. Puede ser que el resultado sea un binario con rutinas de emulación de libultra/n64 integradas en el programa.

En cualquier caso, la duda sigue siendo si alguien lo ha comprobado. ¿se ha extraído, analizado, etc? ¿hay algo ahí dentro que tenga el mas mínimo rastro de nintendosesentaicuatridad?

No es posible que tengan el código fuentes o que lo hayan decompilado y a partir de ahí creado un port nativo? Vamos lo que ha hecho la comunidad con Mario 64 por ejemplo. No sería extraño que al adquirir las IP de RARE tuvieran acceso directamente al código fuente.

@SuperPadLand Claro que tienen el código fuente original, de eso no cabe duda ninguna; es algo sabido. Pero en los videos relacionados con RareReplay (yo no tengo el juego, no he visto los videos incluidos, mas allá de lo que se haya resubido online, ya sea oficialmente o por usuarios) ellos mismos hablan de algún tipo de emulación. No es que venga yo haciendo especulaciones arbitrarias. Yo sabía que Rare conservaba básicamente todo en sus archivos, y tienen todo el codigo fuente de sus juegos, así que asumí que simplemente portarían y listo. Pero como ya dije antes, estoy bastante seguro que en los videos dijeron algo como "source level emulation" y daban algún tipo de explicación.
Si quieres encontrar la referencia, tendrás que buscarlo tu, yo no tengo ánimos para volverlo a encontrar.

Las conclusiones que saqué de la información que se dió en esas intervenciones, mezclada con lo que he podido aprender sobre la N64 a lo largo de los años, es que no son ports al uso, donde tienes que adaptar el motor y los recursos gráficos y de sonido a las APIs del entorno de destino, si no que todo eso lo dejaron mas o menos como estaba, y encargaron la adaptación a una capa de compatibilidad, "traducción al vuelo", que, en efecto, supone un tipo de emulación.
Una de las razones por las que hicieron esto, y creo que hasta lo explicaban en los videos, es porque eran muchos juegos a portar de una sola vez (cuantos eran? Banjo 1 y 2, JFG, Conker, Blast Corps, KIG?... que mas?) y además, no solo querían que funcionasen versiones finales de unos cuantos juegos, si no tener una solución genérica para poderle meter cualquier cosa que surgiese en un momento dado. En aquellos videos también mostraron prototipos varios corriendo en su sistema de emulacion.

Un port lleva mucho tiempo y solo cubre un único juego. Un sistema de emulacion, del tipo que sea, la haces una vez y luego funciona todo, si lo hiciste bien.

Y bueno, los "source-ports" de los juegos de-compilados han tenido también que llevar a cabo alguna taréa que podría describirse como como "source-level-emulation", ya que han tenido que reemplazar las librerías de Nintendo, que comunican el software con el hardware, por algo que comunique el software con openGL o DX o las APIs que toquen, todo ello a partir del procesado de las displaylists y audio lists que el software produce, que luego son procesadas de algún modo por algo que reemplaza el RSP, y producen comandos nativos para el hardware de N64, que ahora tienen que ser cambiados por comandos para APIs mas normativas, ya sea mediante una nueva capa de traducción, o cambiando la primera, o algo... ya a estos niveles me pierdo y no conozco los casos concretos.

No se exactamente qué caminos toman los distintos source ports que hay de los juegos decompilados. Son nativos, pero dentro hay algo de emulación. Repito, no es el mismo tipo de emulación al que estamos normalmente acostumbrados. Es una emulación parcial, limitada a ciertos ámbitos donde es mas dificil simplemente reescribir o recompilar sin cambios. Los de Rare lo llamaron "Source-level emulation", sin explicar detalladamente qué significaba, solo soltaron unas pocas explicaciones muy superficiales, y a partir de ello yo extrapolo.

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

Al final me he puesto a buscar la mención. No se si la encontraré o abandonaré, pero por ahora he encontrado esta muestra de Conker 64 antes de ser un borrachuzo. https://www.youtube.com/watch?v=dDnvVbdEs7c
si te fijas, cuando se ve el cielo en ese juego, la mitad inferior del skybox está negro y en la superior las nubes están corruptas. Yo diría que tiene bastante pinta de emulación.

@radorn podría ser emulación y que tengan acuerdos con Nintendo a fin de cuentas los títulos de RARE de Microsoft ahora están en Switch (también emulados) ¿no?

AHORA tienen un acuerdo con Nintendo para GoldenEye.
Hace 8 años cuando salió el Replay... no se yo.

radorn escribió:AHORA tienen un acuerdo con Nintendo para GoldenEye.
Hace 8 años cuando salió el Replay... no se yo.

Pues ni idea, de todas formas sin saber exactamente los pormenores de la emulación empleada, en principio emular no es ilegal, vease que un emulador de PS1 con una bios no propietaria de Sony no tiene ningún problema legal y de hecho muchos juegos que vende GOG son usando emuladores libres tal cual.

Si se curraron un emulador que ejecute la ROM del juego tal cual quitando los logos y referencias a Nintendo en principio debería ser legal.

Digo desde la completa ignorancia, quizá lo que hicieron es una especie de wrapper de la libultra.

No sé si solo reimplementando está librería los juegos ya son capaces de correr en otro hardware. Calculo que programarían en C++, por lo que no sería descabellado.

Cómo ejemplo, sería algo así como los wrappers de Glide para PC, para poder ejecutar los juegos que funcionaban con esa tecnología.

@SuperPadLand El problema no es emular el hardware si no el código propietario sobre el que corre el juego, que como indica @punch666 y también dije yo antes, contiene libultra, que es la librería precompilada suministrada en el SDK de Nintendo y SGI. Es el componente básico del N64OS (así lo llama la documentación oficial). El kernel y los servicios básicos de control de hardware y librerías de video y audio.
Como mínimo absoluto, necesitan tener algo que reemplace las funciones de libultra si no quieren tener que reescribir el motor del juego. Luego ya si emulan estilo HLE o LLE depende de lo que quieran hacer, pero necesitan algo que les permita correr el juego sin incluir libultra en la aplicación como minimísimo requisito.

@radorn Probablemente aún tendrían que emular algunas partes del hardware por lo tan acoplado que tenía que estar el software con el hardware en estos sistemas tan limitados. Y no estoy seguro de que se usase C++ en N64. Diría que solo C y ensamblador, pero quizá me equivoque. No lo se seguro.

Yo creo que la parte del RDP y RSP, tiene que ser emulado, más que nada porque básicamente es un procesador programable con unas características muy específicas, sólo hay que ver la evolución de las propias librerías, que le iba añadiendo características, he incluso hoy la scene, esta intentando implementar nuevos efectos en un nuevo F3Dx3.

Salud.

radorn escribió:@SuperPadLand El problema no es emular el hardware si no el código propietario sobre el que corre el juego, que como indica @punch666 y también dije yo antes, contiene libultra, que es la librería precompilada suministrada en el SDK de Nintendo y SGI. Es el componente básico del N64OS (así lo llama la documentación oficial). El kernel y los servicios básicos de control de hardware y librerías de video y audio.
Como mínimo absoluto, necesitan tener algo que reemplace las funciones de libultra si no quieren tener que reescribir el motor del juego. Luego ya si emulan estilo HLE o LLE depende de lo que quieran hacer, pero necesitan algo que les permita correr el juego sin incluir libultra en la aplicación como minimísimo requisito.

@radorn Probablemente aún tendrían que emular algunas partes del hardware por lo tan acoplado que tenía que estar el software con el hardware en estos sistemas tan limitados. Y no estoy seguro de que se usase C++ en N64. Diría que solo C y ensamblador, pero quizá me equivoque. No lo se seguro.

Pues ni idea, pero si Nintendo no ha demandado es porque es legal 99%

https://youtu.be/U7uAYfrl2ls?t=169

El bueno de Tony de Hard4Games hace un volcado de un prototipo casi final de WinBack que le han pasado y lo compara con la ROM final en un editor hexadecimal, a colación de lo cual, comenta que el ve diferencias en los datos, y lo consulta con LuigiBlood, scener y webmaster de 64DD.org, para "una inspección en profundidad", y este le dice que casi no hay diferencias, pero que, según cómo nos lo relata Tony, LB dice que "los datos están barajados como cartas"...

¡Ay la leche! Tantos años de experiencia que tiene este hombre con la N64, pasando por sus manos prototipos y cacharros de desarrollo y qué se yo que cosas más, y, en un alarde de virtuosismo, compara en un editor su volcado perfecto big-endian con una ROM de No-Intro en el tonto "formato" byteswapped, llegando a la conclusión de que "there is, in fact, difference". Y lo dice mirando a la cabecera de la ROM que contiene el código de arranque y la etiqueta con el nombre, entre otras cosas, y, a pesar de que la suya pone "WIN BACK" y la otra pone "IW NABKC", no cae el tio...

No se qué le explicaría LuigiBlood exactamente, ni si Tony lo entendió bien o no, pero estoy seguro de que LB entiende perfectamente la diferencia y me asombra ver que H4G parece no tener ni idea de esta cuestión.

Si alguien necesita una explicación, que lo diga y explico por qué hay varios "formatos" de ROMs en N64, que son realmente, cual es el bueno, el absurdo de defender el otro, y los factores históricos que han llevado a algunos a creer que el malo es el bueno.

¡Cuánto daño han hecho el Doctor V64 y No-Intro!

Como era aquel blog de un scener que estaba intentando hacer un programa o algo así que permitia optimizar el código de los juegos y mejorar el rendimiento o algo así.

@SuperPadLand No tengo claro a qué te refieres. ¿Estarás hablando de las decompilaciones?
Me he perdido los últimos dos años de novedades por circunstancias personales, así que tengo duda de si no será algo que se me ha pasado.

celgadis_84 escribió:He estado siguiendo este blog https://olivieryuyu.blogspot.com/?m=1 durante un año en el que explica la creación de un microcodigo con el fin de optimizar los códigos existentes, documentando el código así como la lógica de cada algoritmo utilizado.

Recientemente lo ha finalizado y está buscando colaboración para crear demos y test para probar el rendimiento del mismo.

Teniendo en cuenta los proyectos de decompilación, podría en un futuro reemplazar los microcodigo de roms oficiales por este, mejorando el rendimiento, calidad de imagen, fps más estables...

Encontrado, dale un ojo que seguro que lo entiendes mejor que yo @radorn

@SuperPadLand Hmmm, si, me suena de haber visto a este oliveryuyu anteriormente, aunque no lo ubico con ninguna cosa concreta, pero si se que anda metido en cosas de bajo nivel con la N64, no sabía que estuviera optimizando microcódigos.

Piensa en los microcódigos como el Direct-X de N64, supongo, o el driver de la gráfica.
La diferencia es enorme, son arquitecturas totalmente diferentes, pero en cierto sentido hay paralelismos.
En N64, la parte del motor de juego que corre en la CPU procesa una serie de cosas y produce una "descripción de escena" que representa un frame que se verá en pantalla. Lo manda al RCP, y este usa un microprograma o microcódigo que procesa esa descipción de escena (display list en la terminología oficial) para genera los comandos que usa el rasterizador para "pintar" los pixels de la pantalla. Con este proceso en dos partes, la CPU queda libre para procesar una nueva escena mientras el RCP dibuja la pantalla, en vez de ser la propia CPU la que mande cada comando de dibujado, que ralentizaría toto enormemente.

Si optimiza el microcódigo, se supone que mejorará el rendimiento del juego en aquellos casos en que sea esta parte del proceso la que obligue a esperar a la CPU.

No se si esta optimización va dirigida únicamente a desarrollos nuevos o si su microcódigo será compatible con juegos comerciales existentes con la idea de reinyectarlos en las ROMs licenciadas.
De todas formas hay varios microcódigos de gráficos y varias versiones de cada uno, y hay microcódigos de 2D y microcódigos de 3D, y de audio también.

Ya veré si me pongo a leer todo esto.

Tanto el trabajo de Oliveryuyu como el grupo de personas que están trabajando en una especie de F3Dx3 ( mejora de rendimiento, con añadidos de poder usar efectos de cellshading, Bumpmapping y Ambient occlusion), sólo se puede usar en juegos de nueva creación o en los decompilados, ya que hay que tocar código para adaptarlo al nuevo microcodigo y volver a compilar, no se puede hacer por inyección de código, ya que por ese método sólo se puede modificar el código que corre en RAM, pero no el código que se carga en los 4KB del RCP, aparte que por lo visto tienes que sincronizar los pasos, y una ganancia de rendimiento en alguna parte de pipeline, sin reprogramar el resto del pipeline, desincroniza y produce errores.

Salud.

@dirtymagic Gracias por la explicacion.
Aunque cuando yo decía "inyectar" simplemente me refería a reemplazar el binario del microcódigo en la ROM, no RAM injection ni otra cosa. Lo que yo decía funcionaría si el microcódigo fuera compatible. Pero ya me dices que no, que no sirve como reemplazo sin mas, si no que hay que cambiar todo a su al rededor, pues nada.

Ya que estás tan puesto, no sabrás de alguna demo que hayan hecho o mediciones de las mejoras de rendimiento? Están en el blog ese?

@radorn
Donde más tangibles se ven las mejoras en rendimiento, es en los videos de Kaze, con su mod de Súper Mario 64, ya que las mejoras que hace él, se están añadiendo al futuro Fast3Dx3, el resto lo que muestran son los efectos añadidos como el Bumpmapping, Cellshading y Ambient Oclussion, sin pérdida de rendimiento con el motor del Zelda, ya que básicamente esos efectos tienen el mismo impacto en el rendimiento que cualquier efecto estándar que use 2 cycles, ya que usa combinaciones del Color Combiner.
El microcodigo de Oliveryuyu, dicho por el mismo, no supera en rendimiento a la última revisión del F3Dx2 ( Majoras Mask, Banjo Toei, Animal Crossing).
Yo todo esto lo saco del Discord de Fast64 y N64brew.
Salud.

@dirtymagic Quieres decir que Kaze Emanuar también ha toqueteado el microcódigo de Mario?
No he visto todos sus videos, pero mas o menos estoy al tanto de algunas de sus mejoras de rendimiento. Lo que no era consciente es que parte de las mismas fuera por modificar el microcódigo. ¿Es eso lo que quieres decir o lo estoy entendiendo mal?

radorn escribió:@dirtymagic Quieres decir que Kaze Emanuar también ha toqueteado el microcódigo de Mario?
No he visto todos sus videos, pero mas o menos estoy al tanto de algunas de sus mejoras de rendimiento. Lo que no era consciente es que parte de las mismas fuera por modificar el microcódigo. ¿Es eso lo que quieres decir o lo estoy entendiendo mal?

Igual me he explicado mal, entre ellos hay contacto, y las mejoras en F3D, él las usa, ya que usa Fast64 para hacer los escenarios,modelos, ect, y este te permite compilar directamente con F3Dx2 en vez de F3D del Mario 64, por lo que las mejoras de rendimiento de este en comparación con el microcodigo original, aparte de las optimizaciones que el hace, las comparte con ellos y viceversa, no usa un microcodigo diferente por la compatibilidad con emuladores, pero si ayuda en la mejora del F3Dx3 y en un futuro migrara a este, ya que paralelamente se esta haciendo un plugin para los emuladores para que puedan interpretar el nuevo microcodigo.

Aquí puedes ver que versión del Fast3D, quieres usar, dentro del Fast64.
Salud.

Estaba ligeramente enterado de que habían hecho algo para exportar para N64 directamente desde Blender, pero no me había metido mucho, sobre todo porque no se usar Blender.
Me llama mucho la atención esa casilla de selección que pone "Is hardware v1?". Sabes a qué se refiere?

He estado haciendo pruebas con Castlevania Legacy of Darkness con y sin AA. Para mí se ve mejor sin AA aunque se genere dithering (supongo que siempre está ahi pero con el procesado AA se difumina)

¿Qué opción os gusta más a vosotros?

@radorn
No sé porque lo pusieron así, pero se refiere a que no habilite el Expansion Pak, que esta habilitado de base, pese que a los 2 juegos a los que exporta ( SM64 y OoT) no lo soportaban originalmente. Supongo que marcando esa casilla, también deshabilita el extended Dynapoly Vertex limit, que permite cargar más escenario y personajes, que en el juego base esta limitado por la RAM de stock.

Salud.

@ashurek lo jugué sin AA y por no editar el nombre del save para continuar con AA lo pasé así y bien, pero la verdad que con RGB de ahora en adelante creo que usaré AA siempre, si estás con vídeo compuesto o S-Videos supongo que mejor sin AA.

Yo no sé si es que me he acostumbrado a ver la N64 por compuesto, que verlo más nítido se me hace raro, incluso cuando juego en emulador le pongo un filtro que simula CRT con compuesto o con S-video, este último se ven mejor las letras pequeñas.
Por cierto @SuperPadLand
He visto por fotos que has subido,que tienes la misma TV CRT que yo, ¿ sabes si acepta S-Video por el scart?.

Salud.

dirtymagic escribió:Yo no sé si es que me he acostumbrado a ver la N64 por compuesto, que verlo más nítido se me hace raro, incluso cuando juego en emulador le pongo un filtro que simula CRT con compuesto o con S-video, este último se ven mejor las letras pequeñas.
Por cierto @SuperPadLand
He visto por fotos que has subido,que tienes la misma TV CRT que yo, ¿ sabes si acepta S-Video por el scart?.

Salud.

No tengo ni idea, sólo tengo compuesto y RGB

@dirtymagic El S-video por SCART es una ampliación posterior del estandar de este último. Normalmente los fabricantes se ciñen a la norma y punto, porque cualquier extra es un coste que a saber si se usa. Vamos, innecesario.

Tendrías que mirar el manual de tu televisor y ver si acepta S-video por el SCART. Pero normalmente si el televisor acepta S-video, lo hará con su conector propio, porque hacerlo por SCART requiere circuiteria de detección, y de nuevo, es más caro.

En resumen, a menos que el manual diga lo contrario, descarta que sea compatible.

@dirtymagic S-Video "es casi tan bueno" como RGB excepto por una menor resolución de color en el plano horizontal a causa de la codificación intrínseca de la señal, y en el plano horizontal debido a cómo tratan la señal de oficio las TVs PAL bajo la asunción de que contienen señales grabadas del aire y es necesario aprovechar la caracterísitica principal de PAL.
Si no sabes de qué hablo y te interesa, lo puedo explicar. Cuando tenía una SNES PAL también noté que su salida s-video era un poco chapucera en la inversión de fase que da nombre al formato. Imagino que la de compuesto también pero nunca me molesté en probarla.

@EMaDeLoC Una forma de comprobar parcialmente si la entrada SCART tiene S-Video en TVs que solo tienen un SCART y no hacen autodetección es entrár en los menús y ver si hay un selector para cambiar entre S-Video y RGB, dado que tienen una patilla en conflicto: Rojo de RGB y Croma de S-Video comparten la misma patilla, y, si no hay detección automática, hay que seleccionar el modo entrada manualmente. Eso, o no hay S-Video, claro.
O sea, si el selector existe, sin duda hay S-Video. Si no hay selector, te quedas con la duda hasta que le conectes algún aparato con salida S-Video.

Mi Trinitron tiene 2 SCARTs traseros, uno con compuesto y RGB y el otro con compuesto y S-Video, y también un conjunto frontal con conectores RCA y S-Video. En vez de ofrecer un selector de modo enterrado en los menús, la TV ofrece dos "canales" diferentes para cada entrada.
AV1 = SCART 1 como Compuesto
RGB = SCART 1 como RGB
AV2 = SCART 2 como Compuesto
YC2 = SCART 2 como S-Video
AV3 = Frontal Compuesto
YC3 = Frontal S-Video

Por otro lado, tengo una SANYO de 15 o 14 pulgadas con un único SCART y un AV frontal sin S-Video.
En este caso, tengo que meterme en los menús para seleccionar si el SCART funciona como Compuesto + RGB o como S-Video.

@radorn

Olivieryuyu está programando de cero una versión de Portal para N64: https://github.com/lambertjamesd/portal ... tag/v0.8.0
En su canal de youtube hay vídeos de dicho Portal 64 y también de otras demos y juegos que ha hecho para N64. Es muy impresionante. https://www.youtube.com/@happycoder1989/videos
También es el responsable de realizar ingeniería inversa a los microcódigos de Factor 5 para hacerlos compatibles con GlideN64. Su microcódigo se basa en ése y según fui leyendo las entradas (sin enterarme de nada, o al menos no recuerdo datos útiles) sí que había conseguido hacerlo más ligero y rápido.

De las mejoras de Kaze no sé qué pensar porque los vídeos que publica capturados de la consola y con el contador de frames no me cuadran para nada. Muchas veces veo tirones muy bruscos y el contador está en 40 y tantos fps, o baja a por debajo de 30 pero no se nota ningún cambio en la fluidez. En su último video, en la parte final va a 60 fps (el contador marca 61) pero me sigue dando la sensación de que funciona a 30. Es como si la tasa real fuese la mitad de la que indica el contador. De todas formas se nota que hay mucho trabajo de optimización porque sus escenarios son muy complejos (aunque artísticamente no me gusten mucho) y con el motor gráfico original iría a pedales.