Hilo de detalles y curiosidades de N64

@MasterDan efectivamente, gracias por darme la razón.

SuperPadLand escribió:@MasterDan efectivamente, gracias por darme la razón.

¿Podrías especificar exactamente en que te ha dado la razón? Más que nada porque sólo he expuesto unos razonamientos teóricos y me gustaría saber el motivo específico en sí.

¿No había EPROMS más grandes? ¿No se podían colocar más? ¿No se podía usar una tecnología diferente? Como ya he comentado antes no cuento el factor costo y tamaño físico del cartucho en la ecuación (cosas más raras se han visto en este mundillo y estamos hablando de tecnología, no de economía/negocios).

La máquina parece que puede llegar a tratar con 4GB a pelo (seguro que paginando aun más), si en la época los juegos no pasaban de cierto tamaño era principalmente por un tema de costos de producción de los cartuchos. La duda que tengo es si también había un límite tecnológico y no sólo económico.

@MasterDan pues vale, tienes tú razón entonces.

SuperPadLand escribió:@MasterDan pues vale, tienes tú razón entonces.

Ahora ya simplemente creo que me estás vacilando. Si te has tomado mi respuesta como un ataque, lo siento no era mi intención (en serio me interesa saberlo), en caso de que simplemente lo hagas por trolear pues te ignoro y listos.

Saludos.

@SuperPadLand LLevas el tema de la exactitud histórica demasiado lejos para mi gusto

@MasterDan El mapa de memoria de la CPU es de 32bit, si, pero, según la documentación, y siguiendo la arquitectura MIPS, está dividido en unos segmentos que no tengo muy claro lo que son, y solo uno de ellos está en uso en la N64.
Además, ese mapa está dividido entre diversos bloques, para RAM, ROM, diversas interfaces a accesorios y cachés y demás. El tema se discutió de forma bastante exhaustiva hace un tiempo en este hilo. Busca "mapa de memoria".
En cualquier caso, para el cartucho (en el bus PI, o Parallel Interface) hay asignado un rango de direcciones de hasta 256MB para ROM. El 64drive HW2, aunque tiene 256MB de RAM interna, solo 240 se pueden usar como ROM porque los últimos 16 el diseñador, marshallh, los utiliza para otras cosas: Internamente, almacenamiento de, por ejemplo, los datos de los guardapartidas emulados, y también administración interna del hardware, y, de cara a la N64, en esos últimos 16MB se expone la interfaz interna para que la N64 se comunique con el cartucho, para acceder a la tarjeta SD, el USB, y el módulo wifi, y otras funciones internas del cartucho.
Imagino que todo eso realmente no satura esos 16MB ni en el aspecto físico ni en el aspecto lógico, pero supongo que tuvo alguna otra razón para dar ese hachazo tan grande.
En definitiva, un cartucho original podría tener 256MB de ROM como máximo, sin recurrir a bankswitching.

Las ROMs de los cartuchos de N64 son "custom" porque el bus multiplexa direcciones y datos en el mismo bus. Por eso los repros no pueden simplemente montar memorias a pelo, si no que tiene que haber algún elemento lógico bastante complejo para traducir el protocolo del bus al de las memorias.

radorn escribió:@SuperPadLand LLevas el tema de la exactitud histórica demasiado lejos para mi gusto

@MasterDan El mapa de memoria de la CPU es de 32bit, si, pero, según la documentación, y siguiendo la arquitectura MIPS, está dividido en unos segmentos que no tengo muy claro lo que son, y solo uno de ellos está en uso en la N64.
Además, ese mapa está dividido entre diversos bloques, para RAM, ROM, diversas interfaces a accesorios y cachés y demás. El tema se discutió de forma bastante exhaustiva hace un tiempo en este hilo. Busca "mapa de memoria".
En cualquier caso, para el cartucho (en el bus PI, o Parallel Interface) hay asignado un rango de direcciones de hasta 256MB para ROM. El 64drive HW2, aunque tiene 256MB de RAM interna, solo 240 se pueden usar como ROM porque los últimos 16 el diseñador, marshallh, los utiliza para otras cosas: Internamente, almacenamiento de, por ejemplo, los datos de los guardapartidas emulados, y también administración interna del hardware, y, de cara a la N64, en esos últimos 16MB se expone la interfaz interna para que la N64 se comunique con el cartucho, para acceder a la tarjeta SD, el USB, y el módulo wifi, y otras funciones internas del cartucho.
Imagino que todo eso realmente no satura esos 16MB ni en el aspecto físico ni en el aspecto lógico, pero supongo que tuvo alguna otra razón para dar ese hachazo tan grande.
En definitiva, un cartucho original podría tener 256MB de ROM como máximo, sin recurrir a bankswitching.

Las ROMs de los cartuchos de N64 son "custom" porque el bus multiplexa direcciones y datos en el mismo bus. Por eso los repros no pueden simplemente montar memorias a pelo, si no que tiene que haber algún elemento lógico bastante complejo para traducir el protocolo del bus al de las memorias.

Entonces el direccionamiento está capado a un máximo de 240MB de ROM. Era de suponer que utilizara parte de las direcciones de memoria en la RAM y algunas ROMs internas (En la NES, que es la que tengo más presente es así) aunque me sorprende que decidieran limitar las ROMs máximas a ese tamaño (olvidándonos del bank switching claro). Voy a suponer que lo hicieron para ahorrar costes, como todas las carencias importantes de esta máquina y no por otros motivos.

MasterDan escribió:Entonces el direccionamiento está capado a un máximo de 240MB de ROM.

No, el direccionamiento de la consola puede llegar a 256. Los 240 es algo del 64drive porque usa los ultimos 16 de direccionamiento para hacer interfaz entre el hardware especial del cartucho y la N64, y la RAM restante para uso interno y almacenar los datos de las partidas. Apunto también que de los guardapartidas de cartucho, los de tipo eeprom usan un bus en serie específico al margen del PI, y los guardapartidas en SRAM y Flash tienen rangos específicos asignados aparte de los 256MB de ROM

radorn escribió:No, el direccionamiento de la consola puede llegar a 256. Los 240 es algo del 64drive porque usa los ultimos 16 de direccionamiento para hacer interfaz entre el hardware especial del cartucho y la N64, y la RAM restante para uso interno y almacenar los datos de las partidas. Apunto también que de los guardapartidas de cartucho, los de tipo eeprom usan un bus en serie específico al margen del PI, y los guardapartidas en SRAM y Flash tienen rangos específicos asignados aparte de los 256MB de ROM

Error mío al leerte, aun así continua capado a un tamaño mucho menor del que debería según el tamaño del bus de direcciones de la máquina. Es una lástima que una máquina con tanto potencial lo haya desperdiciado tanto para ahorrarse unas cuantas perras por unidad.

@radorn ya he dicho que cada uno pondrá las limitaciones en donde quiera, pero para mi no hay demasiada duda de que si Nintendo hubiera podido lanzar cartuchos de 256 megas en 1996 no hubiera impuesto los de 8 y 16 megas. Y si el 64DD tiene cuatro juegos contados, no salió de Japón y casi no se vendió, es un poco absurdo considerar que la mayoría de usuarios pudimos acceder a uno. Tampoco es que pida que vendieran millones, pero al menos que fuera como el MegaCD que salió en las tres regiones y vendió 2 millones de unidades.

@SuperPadLand Yo creo que si la consola lo aguanta y no interfiere de manera esencial en la operación básica de la consola, vale.
Hay una diferencia grande entre accesorios que respetan la naturaleza de la consola y lo de ejecutar algo en un sistema moderno enteramente independiente y usar la consola clásica meramente como interfaz, como lo del RasPi en la NES. Yo tampoco le encuentro sentido a eso, incluso como curiosidad me resulta bastante absurda.

Si la consola soporta 256MB de ROM nativamente, no veo razón por la que no proporcionarselos. Que no fuera económicamente factible en la época poner tanto no me parece motivo suficiente para no hacerlo hoy.
Que el 64DD acabase siendo un cacharro que no llegó a nada no significa que no formase parte del "ecosistema" de la consola. Estaba planeado desde el principio, pero se torció.
Si hablamos de expandir la consola con hardware extra a través del puerto de cartucho, para empezar tenemos el 64DD, pero también cartuchos con modem, con lectores de tarjetas smartmedia, una capturadora de video...
No veo ningun motivo para no meter expansiones modernas, como acceso a la SD, wifi, usb... son EXPANSIONES al servicio de la consola, que sigue controlandolo y haciendo el procesado principal a través de sus componentes originales. No es como si quisiera meterle un procesador i9 con 1TB de RAM y gráficos con raytracing y usar la consola como un mero terminal Hay una diferencia muy grande.

Lo que tu propones es una especie de recreación histórica o algo así, y me parece una limitación arbitraria sin demasiado sentido. O sea, para alguna proyecto puntual puede tener su gracia eso de hacerlo exactamente como en los viejos tiempos y ver hasta donde lo puedes exprimir. Pero como imposición general lo veo innecesario.

Hoy en día tenemos el road blaster de snes ocupando 4Gb, y podrían hacerse juegos para esta de hasta 32Gb.

No se que problema de purismo tiene el saltarse los limites de direccionamiento impuestos de un sistema, cuando ya en los 90 los juegos de neo geo los excedían con mappers... y los de megadrive... y los de nes... y los de GB... y los de master system... y nunca ha parecido mal. Pero a la n64 parece que hay que exigirle que no se acerque a la capacidad de un cd.

La única pobre que no explotó el tamaño de sus cartuchos fué la snes

@radorn yo creo que no me estás entendiendo, yo no tengo ningún problema en que se haga un juego de 1000GB para N64 si lo mueve sin más, aunque no podré jugarlo en mi N64 porque el ED64 sólo permite juegos de 64mb. Pero por muchas vueltas que les demos un juego de más de 64 megas en la vida original de la consola no fue posible por varias razones y por tanto para saber como hubiera sido un port de aquella época de haberse realizado hay que aceptar que habrían recortado contenido o ripeado sonido/video más compresión de datos a tope para que entrase en esos 64 megas. Y ya bastante generoso estoy siendo aceptando 64 megas que son la excepción a la norma porque el precio de esos juegos al consumidor costaba casi lo mismo que la consola nueva en el 99 y 2001; siendo estrictos cualquier juego que imaginemos como hubiera sido para N64 tendría que ser de máximo 32 megas.

Pero todo lo anterior es si hablamos de como hubiera sido el juego en aquella época, yo después virguerías aparte que se puedan hacer en el año 2020 y en el futuro me parecen geniales.

@Señor Ventura estamos hablando de N64, no de NeoGeo o PlayStation 5 o de mi microondas. Y estoy hablando de como hubiera sido el juego en su época con lo que había en aquel entonces, incluso aceptando los mappers de todas las consolas que citas, ellas mismas llegaron a un máximo de almacenamiento en aquel momento porque la cosa se disparaba de precio y ese sería su límite en aquella época. No los 32GB del 2020. Tema aparte es que no queramos imaginar como hubiera sido el juego en 1997 sino simplemente hacer el mejor port posible con todo lo que tenemos a nuestro alcance hoy.

Y si tengo que volver a explicarlo me quito magisterio infantil que al menos me pagan.

Esas son chorradas, para cualquier port que se quisiera hacer, el limite debería ser que funcione en una n64 real, es ridículo limitar el tamaño de una rom en estos tiempos.
Porque seguramente sacarían otra flashcart con más capacidad.

Cambio de tercio:

Alguien ha creado un exploit para el juego de shogi con modem en el cartucho de forma que conectandolo a un servidor simulado en el PC, el juego carga un "homebrew channel".

Obviamente poca utilidad va a tener, pero es curioso.

A ver, para temas de direcciones de memoria de la consola, aquí hay una wiki completita.
Sobre los pines del cartucho, en esta página que es para hacerte tu propio cartucho de N64 están detallados. Por cierto, que esa página pone los planos para crearte tu propio cartucho repro, y de hecho de ahí salen los planos de las repros chinorras:

Y como curiosidad, según un diagrama que sale ahí, se transmiten 448bytes en 85 microsegundos, lo que son 5MB/s clavados.
En los pines del cartucho como dice radorn hay para audio izquierda y derecha. ¿Dejaron abierta la posibilidad de expansión a una unidad de CD? El caso es que usando el serial data como interfaz o direcciones de memoria concretas, sería teoricamente posible meter un reproductor de MP3, pasar el audio por su pines y que el juego mezcle la música con los efectos. Que igual el cartucho costaría 200€, pero teoricamente sería posible.

Pero bueno, seamos históricamente puristas... Cartucho de 12MB para un C:SOTN en N64. ¿Se puede? Si, pero con un sacrificio.
Se puede tranquilamente porque tenemos ejemplos de sobras en SNES de juegos con buenos gráficos en 4MB o menos, y ahí dentro se incluye sonido, música y código además de los gráficos. Los Donkey Kong Country, Killer Instinc o Mortal Kombat 3 son algunos ejemplos, pero entrando dentro de los RPG para acercarnos al C:SOTN está Chrono Trigger, Mario RPG o Earthbound. Y eso los de 4MB, que con menos capacidad hay más juegos. Recordemos que con 4MB tenemos el Automobili Lamborghini en la N64, un juego de coches modesto, pero ocupando la mitad del Mario 64, es buen ejemplo de que administrando bien el espacio se consiguen buenos resultados.
Subiendo a los 8MB en la propia N64 tenemos una aventura gráfica 2D como es Wonder Project, buenos gráficos, muy coloridos y con bastantes escenarios. Esta repleto de animaciones y fondos detallados. Es una buena muestra de lo que la N64 habría dado de si en este tipo de juegos, y además sin devanarse la cabeza con optimizaciones con el 3D, aunque puntualmente si hay algún escenario 3D. Review de Glenn para ver más: https://www.youtube.com/watch?v=_K3binhMds0
En cuanto a la música, y sabiendo que C:SOTN usa mayormente MIDI, la N64 puede usar un MIDI estandar o uno mejorado con instrumentos personalizados. Hay buenos ejemplos en la consola de bandas sonoras en MIDI resultonas, no debería ser problema el obtener una música de calidad muy similar o idéntica a la oída en PSX. También tenemos juegos que usan trackers para generar su propia música.
Pero he hablado de un sacrificio, y es que aparte de dos pistas de música en CD C:SOTN tiene muchos diálogos. Pero bueno, me he quedado en los 8MB, aún puede que con cierta compresión y sacrificio de calidad quepan los diálogos más relevantes en los 4MB que quedan para llegar a los 12. O ya puestos tirar a los 16MB que en 8MB podrían caber todos los diálogos. Creo que el vADPCM que nombró radorn hace nada tiene un ratio de compresión 4:1. Tenemos FIFA 64 y FIFA: Road to World Cup 98 que tienen diálogos del comentarista y canciones de las gradas, y cada uno ocupa 8 y 12MB respectivamente. No sé si hay tantos efectos de voz como en C:SOTN, pero son ejemplos de que caben bastantes. Eso si, habría que sacrificar calidad.
A todo esto, el que se usasen cartuchos de 8 o 12MB al principio no era por que Nintendo no quisiera. Poderse se podía, pero las maskROM era una tecnología bastante nueva y por lo visto hecha a medida para Nintendo para asegurarse evitar las réplicas de cartuchos. El caso es que con tecnologías nuevas el aumentar la capacidad no es proporcional al coste. Si un cartucho de 8MB les costaba, por decir algo, 10$, uno de 16MB igual no salía por 20 sino por 25$. Y encima las desarrolladoras pagaban por adelantado la tirada completa. Normal que ahorraran todo lo posible en tamaño de ROM, podía suponer una buena pasta de diferencia entre uno y otro. Hasta que la tecnología no avanzaba lo suficiente no se hacian más y más económicos los precios, hasta llegar el punto que merecia la pena tirar por 16MB en vez de 8, 24MB en vez de 16, o 32 en vez de 24MB. Seguramente podrían haber salido cartuchos de 32MB el día uno, seguro que era posble tecnológicamente, pero igual costaba el juego 200$, y Nintendo nunca ha hecho una Neogeo...

En esto de los ports de PSX a N64, yo lo tengo claro: N64 solo perderá con el tema de capacidad de CD y relacionado. Pistas de música CD, FMV, diálogos, etc, se van a a ver recortados o eliminados necesariamente, lo cual no quita que con mucho esfuerzo se pueda meter RE2 en un cartucho. Pero en cuanto al resto de prestaciones, la N64 es bastante capaz.

Un 64 DD por 400-€ al cambio con caja (47540Y)



En el 2008 el año de mi primer viaje a Japón, tienda Super Potato que pena no haberme traido uno..
Aun tengo fotos de cosas que solo con verlas a día de hoy pienso pq cono no te lo traiste, atontao !!

@EMaDeLoC hay cartuchos muy raros en tamaño, por ejemplo Ogre Battle 64 tiene 320 Mb, o 40 MB, siendo un juego de 1999 puede que un hipotético SotN pudiera tirar con ese espacio y no con 8 o 16, teniendo en cuenta que Ogre Battle salió con precio estándar en Japón, no con precio desorbitado. Recuerdo pensar en importarlo y al cambio era como rozando 9000 ptas .

Un saludo

EMaDeLoC escribió:¿Dejaron abierta la posibilidad de expansión a una unidad de CD?

No creo que pensasen en eso.
Me parece que el cartucho de captura de video del 64DD lo usa, magino que, como forma barata para monitorear la entrada sin tener que cargar el ancho de banda de la consola también con la reproduccion digital del sonido durante una captura.
No se exactamente qué usos se le pueden dar al cartucho de captura. En los videos demostrativos oficiales se muestra cómo se puede usar para capturar la cara de alguien y usarla de textura en un personaje de "Talent Maker". Creo que también se pueden grabar clips de sonido pequeños, por ejemplo para samples de voz.
No se si se pueden grabar y almacenar directamente secuencias de video. Sospecho que solo almacena una secuencia breve para permitir la selección de cuadros a modo de fotografía y cortes de sonido pequeños.

@radorn Mmmm... Siendo solo dos líneas, una para izquierda y derecha, creo que se trata de audio analógico y no digital. Ya comprobaré hacia donde van esas líneas, pero seguramente al amplificador de audio para sacarlo por la salida de audio.

EMaDeLoC escribió:@radorn Mmmm... Siendo solo dos líneas, una para izquierda y derecha, creo que se trata de audio analógico y no digital. Ya comprobaré hacia donde van esas líneas, pero seguramente al amplificador de audio para sacarlo por la salida de audio.

Claro que es audio analógico. Nunca dije que fuera digital. Pero, para tener monitoreo de sonido durante la grabación, la alternativa a tener una linea "externa" que vaya directamente a la salida de sonido analógica, sería pasar la version digitalizada como datos a través del PI, cacheandose en RAM, pasando por el RSP y el AI, etc.
A eso me refería con lo de no "tener que cargar el ancho de banda de la consola también con la reproduccion digital del sonido durante una captura", no a que tuviera que ser digital y luego ver si lo pasas "por fuera" o "por dentro"

@EMaDeLoC a ver si explicándolo como lo has explicado tú con un texto enorme terminan entendiendo lo que trato de decir porque parece que no. Ni que estuviera hablando de física espacial. En cualquier caso que la música sea MIDI juega a favor de un hipotético port en 1997, los diálogos dan igual, sobran ejemplos de juegos multiplataforma que en N64 cambiaban las voces por cajas de texto y los vídeos por cómics por ejemplo. En todo caso, al menos tú sí me has entendido y has teorizado como podría haberse echo un SotN en 1997 para N64 aceptando el reto de que tiene que entrar en un cartucho de entonces. Para mi esto es lo bonito y no porque le exija mucho a N64, para mi lo interesante es el reto de adaptar algo buscando soluciones y trucos a las barreras. De todas formas aunque el reto de meterlo en uno de 16MB sería toda una hazaña, atendiendo a la propia realidad de esta consola sería bastante probable que el juego hubiese salido en 1998 (32MB) o 1999 (64MB), no hace falta tampoco ponerse en el peor de los escenario. Lo que me parece inconcebible es imaginar como sería el port de un juego en los 90 para N64 y pretender hacerlo de 256MB o más porque de haber sido esto posible Nintendo seguramente no hubiera cortado con Square y su FFVII ni perdido un montón de thirds por el camino. Especialmente si tenemos en cuenta que la inmensa mayoría de juegos de PSX si le eliminas los vídeos de los logos de la distribuidora, desarrolladora e intro los tamaños de muchos juegos andan en 80-200MB (que era básicamente lo que se hacía entonces para grabar backups con varios juegos y ahorrarse CD que no iban baratos precisamente) También no sé si fue en este hilo, pero un usuario compartió una teoría interesante sobre como FFVII hubiera podido caber en 64MB entre los datos repetidos en los 3 discos, comprensión de datos y eliminando información innecesaria.

Falkiño escribió:@EMaDeLoC hay cartuchos muy raros en tamaño, por ejemplo Ogre Battle 64 tiene 320 Mb, o 40 MB, siendo un juego de 1999 puede que un hipotético SotN pudiera tirar con ese espacio y no con 8 o 16, teniendo en cuenta que Ogre Battle salió con precio estándar en Japón, no con precio desorbitado. Recuerdo pensar en importarlo y al cambio era como rozando 9000 ptas .

Un saludo

En 1999 salió RE2 así que si aceptamos ese año para el port no hace falta limitase a 40MB.

@SuperPadLand Bueno, por un lado te he entendido en lo relacionado a como sería o podría hacerse el SOTN en la N64 en el 97, pero por otro también entiendo que si se hiciera hoy aprovecharía que se puede usar más espacio.
Si el tamaño máximo del cartucho son 32MB y los de 64MB usan algún truco para acceder a más espacio, me quedaría en los 32MB para facilitar la programación, a menos que no sea tan complicado acceder a los 64MB al completo.
Aunque si hicieran un desde cero y se pudiese acceder a 256MB, iría a esos 256MB y desarrollaría un cartucho a proposito modificando el diseño repro chinoso.

Por cierto, @radorn

Manual del 64drive, página 10

Dice que son 240MB por limitaciones de direccionamiento del PI. Para mí eso significa que la consola no accede a más de 240MB de cartucho, trucos al margen.

Vamos que un SOTN de 240MB en la N64 sería la leche.

CORRIJO: La N64 no alcanza 256MB. "Solo" puede mapear 252MB de h1000000 a h1FBFFFFF, que son 4MB menos, de acuerdo con el mapa de memoria de la página que enlazó @EMaDeLoC. El 64drive mapea CI (cartridge interface), los registros internos del hardware expuestos a la N64 en h1F800000, posición equivalente a 248MB desde el inicio del rango. Por tanto el límite no es 240.
Así que ni pa ti ni pa mi, aunque, siendo objetivos, un poco mas pa mi xD

EMaDeLoC escribió:Dice que son 240MB por limitaciones de direccionamiento del PI. Para mí eso significa que la consola no accede a más de 240MB de cartucho, trucos al margen.

Hay una diferencia sutil entre lo que tu dices y lo que dice el manual. En el manual, marshall dice que "solo ha mapeado 240MB al "espacio cartucho" debido a una limitación en el direccionamiento del PI". Eso da cabida a tu conclusión y también a la mia sin mas detalles.
Tu concluyes que la limitación son los 240 en si, y ya está. Sin embargo, si la limitación de la N64 fueran 240 y los mapea enteros a ROM, no le quedaría espacio para meter el CI, y, sin embargo, ahí está, 8 MB mas adelante del que tú interpretas como límite máximo del PI. Y 4MB después, el limite máximo real.

----------------------
POST ORIGINAL:
----------------------
@EMaDeLoC Ya tratamos esto antes, y, si consultas otras secciones de ese mismo manual, encontrarás que en esa región de 16MB "sobrante" están mapeados diversos registros internos del 64drive para que la Nintendo 64 pueda acceder a su hardware interno. Por tanto la consola SI lee mas de 240, pero no mas de 256. Así que aunque el cartucho tiene 256, la necesidad de mapear mas cosas en el mismo lugar impone tener que limitar el espacio ROM disponible.
Si fuera un cartucho normal sin funciones especiales y solo ROM, si podría llegar a 256.

16MB parece mucho MB de nuestro señor para dedicarle a unos registros internos, eso si te lo reconozco. Desde luego no se usa todo ese espacio ni de lejos. No tengo explicación confirmada.

Después de hablar con marshallh durante bastantes años me da cierta experiencia de que probablemente se explicó de manera ambigua o sencillamente no quiso dar todos los detalles para no liarla demasiado.
Si tuviese que deducir cual es la limitación, sería "Como el máximo que acepta es 256, no puedo mapear los 256 de RAM como ROM y también tener los registros internos expuestos a la consola ni tener espacio extra para los datos de las partidas internas y otros usos detrás de bambalinas, por tanto es una limitación del bus que no me permite encajarlo todo"

@SuperPadLand Yo si te entiendo perfectamente, teorizar sí, pero dentro de mundos "reales" (256), no irse a la cuarta dimensión donde N64 o Snes (que se sacó a la palestra) puede alcanzar a la PS4 o la Xbox One porque " y sí....".

@EMaDeLoC @radorn una cosa que no entiendo esos 240-256MB del manual son los que puede manejar unificados? Me refiero en una única memoria rom, pero esto no sería impedimento para hacer un cartucho llevase dos o más memorias rom por separado de 240-256 MB no?

He seguido probando a ver si consigo mejorar el efecto de la hierba. Ha mejorado pero quiero probar más cosas.

Primero generé mis propios mipmaps a ver si conseguía darle más nitidez a las texturas en la distancia y el efecto se pudiera ver mejor sin tener que bajar la vista pero no noté ninguna mejora. En el pasado sí que había conseguido más nitidez generando mis propios mipmaps en texturas a color, pero parece que en texturas en escala de grises la N64 ya hace un buen trabajo. De todas formas me gustaría probar a darle más contraste a los mipmaps porque cada nivel tiende a un gris más uniforme y eso funciona en contra del efecto.
El último nivel mipmap era un píxel gris bastante oscuro pero no lo suficiente como para explicar ese extraño oscurecimiento del suelo que ocurre cuando se levanta la vista hacia el cielo. Así que lo hice totalmente blanco para ver qué ocurría y para mi sorpresa ese oscurecimiento es provocado por otra cosa diferente y, de momento, desconocida para mí. Con la vista plana podía verse el último nivel de mipmap como una especie de resplandor verde fosforito en el perfil de las montañas, y también probé en los mapas con texturas más estiradas para darme cuenta de que incluso en la textura base se puede observar ese oscurecimiento. Así que me puse a jugar el juego original y otros hacks a ver si veía algo parecido y sí que encontré el mismo efecto raro en tres texturas contadas entre mis otros mapas y Goldfinger 64. En el juego original no encontré ninguna textura que hiciese lo mismo pero me dio la impresión de que el suelo del principio de Dam se ilumina ligerísimamente cuando se inclina la cámara hacia el suelo. El caso es que las texturas con el oscurecimiento son de distintos formatos así que no sé no por donde empezar a mirar para averiguar lo que ocurre.

Después separé las capas a 2 unidades entre ellas (mi anterior prueba tenía una separación de 1 unidad) y ya empieza a notarse bastante mejor el efecto en consola. Creo que si le doy más separación a las capas todavía se verá mejor. Aunque cuando el personaje se agacha se nota demasiado el truco y no queda muy bien.
Dejo una imagen comparativa de la evolución cuando 1 texel = 1 unidad: de izquierda a derecha sin el efecto, el efecto con 4 capas separadas 1 unidad y con 4 capas separadas 2 unidades entre sí. Arriba con el personaje de pie y la vista inclinada hacia el suelo. Abajo la misma vista pero con el personaje agachado.

Quizás el truco no sea muy efectivo para hierba pero sí podría servir para alfombras y tapices en los que desde lejos parece un color plano pero de muy de cerca se pueden apreciar las distintas fibras. Se podrían crear como objetos y así tener su propia escala independiente de la del nivel y poder meter muchas capas muy juntas.
Seguiré haciendo pruebas hasta quedar satisfecho.

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

En cuanto a las últimas noticias que se han discutido en las últimas páginas.

-El port a PC de Mario 64:
Ya comenté cuando se supo que se había conseguido obtener por ingeniería inversa el código fuente del juego que no veía qué cosas podría aportar respecto a los emuladores y los hacks actuales. He estado viendo algunos vídeos del port a PC y han perdido el efecto gráfico de texturas con ruido que se ven cuando Mario se teletransporta o se pone la gorra de invisibilidad. Al menos sí que mantienen el efecto del retrato de Peach/Bowser. La verdad es que no estoy muy entusiasmado con el port, pero sí los arreglos que se han hecho al juego original como quitar el lag a la parte del submarino y recuperar el aspecto real de la textura del humo.

-Respecto a lo que se haya podido filtrar de momento sólo se ha visto la punta del iceberg.
Conker64 comentó que era posible hacer funcionar juegos en otros microcódigos así que algo que creo que se podría conseguir serían mejoras visuales y de rendimiento si se tiene acceso a los códigos fuente de los juegos (concretamente a los cercanos al lanzamiento). Por ejemplo:
·Super Mario 64 a 320x240 en lugar de 256x224 (creo que era una resolución similar) y con filtrado trilineal.
·PilotWings 64 a 320x240 sin franjas negras y framerate más estable.
·Wave Race 64 sin franjas negras, a 320x240 y el framerate bloqueado a 30 fps en lugar de a 20fps. Hay un código que desbloquea el framerate a 60 fps (el juego va acelerado) y se mantiene más tiempo a 30 fps que ha 20 fps (también hay picos de 60 fps).
·Mario Kart 64 sin franjas negras y framerate desbloqueado. Gráficamente es muy sencillo y me pregunto si podría alcanzar los 60 fps en modo 1 jugador.
·Star Fox 64 con el dithering y el gamma correction corregidos. Framerate más estable aunque las ralentizaciones casi que forman parte del juego.

He estado jugando al F-Zero X (versión 64DD, pero la original es igual) y tiene un dithering muy agresivo que empeora la calidad de la imagen creando artefactos (se supone que actúa junto al antialising "postprocesado" para evitar bandas de colores). También me he fijado que no tiene antialiasing en los bordes ni filtrado trilineal (puede que el tamaño de las texturas no lo permita). A este juego le vendría bien funcionar a pantalla completa y eliminar ese dithering.

@radorn El rango que has puesto corresponde al dominio 1 dirección 2, pero te has dejado los otros dominios que están por debajo.

En total eso corresponde a 448MB.
Y espera, que hay otro valor que igual se te ha pasado por alto en esas direcciones de memoria:

Que corresponde a 1.5GB.
Y en el manual del 64drive, da dos direcciones base de CI para acceder a los registros:

Que si nos limitamos a la dirección 0x10000000 que has usado antes, nos da que el rango entre 0x10000000 y 0x1800 0000 es de 128MB.
La cuestión sería saber si solo se puede usar el dominio 1 dirección 2 o si están todos disponiles. Y en caso de esto último, porqué marshall "limita" a 200 "y pico" MB y no pone más memoria accesible.

@SuperPadLand Si te refieres a mapear como la NES o la Gameboy, si, se podría hacer.
Lo que hay que tener claro es que las ampliaciones por hardware deben acompañarse de software capaz de aprovecharlas.

@Andrómeda Vaya, has mencionado consolas de siguientes generaciones, qué original, nadie lo había hecho hasta ahora...

Bueno, yo también he entendido a SuperPadLand y le he dado una respuesta basandome en ejemplos de juegos existentes.
En cuanto a las posibilidades "y si", tenemos ejemplos de todas las consolas de quinta generación y anteriores en que la scene a ampliado sus posibilidades más allá de lo que se pensaba. Desde emular unidades de disco por el cartucho o el puerto paralelo a añadirle salida HDMI.
Teniendo en cuenta que para la N64 existen cartuchos con modem o que capturan vídeo, usar el Serial Interface para controlar una plaquita decodificadora de MP3 como la de la siguiente foto no lo veo descabellado:

Otra cosa es que alguien que haga homebrew tenga la capacidad para desarrollar tanto el software como el hardware necesarios para eso.
Por cierto, igual no te has enterado que con el SD2SNES la de 16bits de Nintendo es capaz de reproducir música con calidad CD...

@Sogun Ponle barba a algún personaje
O un afro descomunal

SuperPadLand escribió:@EMaDeLoC @radorn una cosa que no entiendo esos 240-256MB del manual son los que puede manejar unificados? Me refiero en una única memoria rom, pero esto no sería impedimento para hacer un cartucho llevase dos o más memorias rom por separado de 240-256 MB no?

Los 252MB esos constituyen el bloque de direcciones que el controlador de memoria de la N64 tiene asignado para la ROM del cartucho. Ahí busca la consola el juego para arrancarlo.
El número de chips ROM es irrelevante mientras cada una responda en el rango de direcciones debido y no interfieran una con otra. Uno puede responder a los primeros 32MB y otro a los siguientes 32MB.
No sería posible superar los 252MB poniendo mas chips ROM a no ser con algún sistema de bankswitching.

EMaDeLoC escribió:@radorn El rango que has puesto corresponde al dominio 1 dirección 2, pero te has dejado los otros dominios que están por debajo.
SeleccionarCopiar
0x05000000 to 0x05FFFFFF Cartridge Domain 2 Address 1
0x06000000 to 0x07FFFFFF Cartridge Domain 1 Address 1
0x08000000 to 0x0FFFFFFF Cartridge Domain 2 Address 2
0x10000000 to 0x1FBFFFFF Cartridge Domain 1 Address 2

En total eso corresponde a 448MB.
Y espera, que hay otro valor que igual se te ha pasado por alto en esas direcciones de memoria:
SeleccionarCopiar
0x1FD00000 to 0x7FFFFFFF Cartridge Domain 1 Address 3

Que corresponde a 1.5GB.

La última vez que tratamos este tema también estuvimos mareando con esas áreas y no llegamos a ninguna conclusión sólida de qué eran. Muy probablemente alguna de ellas esté asignada a los chips de S-RAM y FlashRAM, que también van conectados al PI, pero esto es especulación por mi parte.
El caso es que el rango de donde la N64 arranca los cartuchos es el D1A2 y no otro.
Si alguien sabe a ciencia cierta qué son los otros que lo diga.
Igual valen para ampliar aún mas la ROM a modo de almacenamiento secundario no arrancable, pero yo no lo se.

EMaDeLoC escribió:Que corresponde a 1.5GB.
Y en el manual del 64drive, da dos direcciones base de CI para acceder a los registros:
SeleccionarCopiar
0x1800 0000 Regular Adress Mode
0x1F80 0000 Extended Adress Mode

Que si nos limitamos a la dirección 0x10000000 que has usado antes, nos da que el rango entre 0x10000000 y 0x1800 0000 es de 128MB.

En la página 9 del manual encontrarás la explicación. El 64drive HW2 arranca por defecto en modo compatibilidad con HW1, con el "extended address mode" desactivado, actuando, efectivamente como el modelo viejo, el cual funciona en "regular address mode" donde el CI está en la posición de 128MB (recordemos que el HW1 solo tiene 64MB de RAM interna, así que tenía donde elegir para poner el CI). El "extended address mode" debe ser activado explícitamente, y entonces la cantidad de RAM que se expone a la consola como RAM pasa a 240MB en vez de 64MB y el CI es movido de los 128MB a los 248MB.
La razón de que arranque en modo de compatibilidad con HW1 que da el manual es que ya existía algún homebrew que esperaba encontrar el CI en 128MB (o hacks, como las adaptaciones a cartucho de los juegos de 64DD, que detectan una transferencia por USB de una nueva imagen como un cambio de disco), y que algunos juegos comerciales esperan ver el espacio sin mapear a esas alturas.

EMaDeLoC escribió:La cuestión sería saber si solo se puede usar el dominio 1 dirección 2 o si están todos disponiles. Y en caso de esto último, porqué marshall "limita" a 200 "y pico" MB y no pone más memoria accesible.

como ya dije antes, no se si los otros bloques son usabes o no, o de qué forma.
En el caso de que sí se pudiera poner mas almacenamiento con esos rangos, la razón de no hacerlo probablemente sea pragmática. Es muy probable que nunca veamos homebrew tan grande, y mapear mas memoria también implicaría poner mas RAM física en el cartucho. Al final 240MB de 256MB o 252MB tampoco es una gran pérdida, solo son 12-16MB, o entre 4.5% y 6.5% aproximadamente.
Por otro lado, una posible pista de que los otros rangos no son usables podría estar en la asignación del propio CI. Si esos rangos fueran usables, parecerían el mejor lugar para poner el CI en vez de tener que encajarlo en el último tramo de D1A2, que podría dar acceso a 12MB mas de ROM.
También podría ser que no quiso meterse en más berenjenales, pero me sorprendería.

EMaDeLoC escribió:usar el Serial Interface para controlar una plaquita decodificadora de MP3 como la de la siguiente foto no lo veo descabellado

El SI lo controla el PIF y va directo a la EEPROM del cartucho si la hay. No se cuán flexible es ese bus y si se le podría dar ese uso. Recuerdo que una vez sugerí una posible conexión entre consolas a con un cable que las conectase a través de los puertos de los mandos, y la respuesta fue que crear protocolos especiales a través del PIF era un infierno xD
No se, supongo que se podría hacer, pero parece ser un tema peliagudo.

radorn escribió:@Sogun Ponle barba a algún personaje
O un afro descomunal

Pues me acabas de recordar otro efecto que tenía pensado para los cabellos y sobre todo las barbas.

radorn escribió:Cambio de tercio:

Alguien ha creado un exploit para el juego de shogi con modem en el cartucho de forma que conectandolo a un servidor simulado en el PC, el juego carga un "homebrew channel".

Obviamente poca utilidad va a tener, pero es curioso.

Bueno igual es una alternativa barata a poder cargar juegos de más de 64MB a través de ese modem usando un PC

radorn escribió:

EMaDeLoC escribió:usar el Serial Interface para controlar una plaquita decodificadora de MP3 como la de la siguiente foto no lo veo descabellado

El SI lo controla el PIF y va directo a la EEPROM del cartucho si la hay. No se cuán flexible es ese bus y si se le podría dar ese uso. Recuerdo que una vez sugerí una posible conexión entre consolas a con un cable que las conectase a través de los puertos de los mandos, y la respuesta fue que crear protocolos especiales a través del PIF era un infierno xD
No se, supongo que se podría hacer, pero parece ser un tema peliagudo.

Ahora lo mirado en el cartucho de Morita Shogi 64 y efectivamente el SI va directa a la EEPROM.
En tal caso, el juego se comunica con el modem a traves de direcciones de memoria reservadas.
Que podría ser ese el motivo de tener tantos dominios y direcciones asignadas al PI, para dar vias de acceso a funciones especiales de los cartuchos, chips de apoyo, modems, capturadoras de video, etc.

@SuperPadLand Pues prepárate un café o dos mientras te tragas los tiempos de carga.

@EMaDeLoC Realmente no sabemos para qué se usan esos dominios extra si es que se usan para algo. En cualquier caso, habiendo 252MB en el dominio "normal", no hay mucha necesidad de irse mas lejos, igual que hizo marshallh para el CI. Bueno, sin duda alguno se usa para el Flash y la SRAM. Mas allá, ni idea.

@radorn te recuerdo que las malas lenguas del foro me llaman fanboy de PS1. Los tiempos de carga me molan.

Por cierto 252MB que puede manejar cuantos megas reales podría manejar apróximadamente usando la comprensión de datos de la época?

@SuperPadLand Hmmm... ya se que lo dices de coña, pero...
La PS1 tiene un CD-ROM 2X, o sea, 300KB/s en lectura lineal en datos MODE1 (para audio CDDA y streams MODE2-XA son unos KB/s más porque no tienen una protección tan robusta). Los módems telefónicos en su punto álgido llegaon a 56kbps (kilobits por segundo), y con suerte obtenías 4.5 o 5 KB/s (KibiBytes). Hubo algun estandar posterior que no llegó a nada con picos de 64, creo, pero ya.
El Morita Shogi este no se qué velocidad alcanzaba, pero, siendo un modem barato incrustado en un cartucho y pensado para un juego de tablero que básicamente solo necesita transmitir un movimiento de ficha cada muerte de obispo, y consultar tablas de clasificación y tal... en fin, podría ser de 33.6, 28.8, 14.4 o incluso 9.6 kbps
Cuando salió la Dreamcast traía un modem de 33.6kbps, y dudo que el del Morita Shogi 64 fuera mejor. 33600bps son 4200bytes por segundo, pero eso no tiene encuenta el "overhead", los datos que consume el propio protocolo, la redundancia, etc. Así que date con un canto en los dientes si logras negociar una conexión de 3 o 4 KBs por segundo. Y eso asumiendo que sea de 33.6kbps, que ya sería mucho suponer.
Aquí tienes unas fotos de hardware abierto de N64, incluido el shogi este https://jrra.zone/n64/ No tiene mucha cosa...

En fin, los tiempos de carga de PS1 o Saturn son INSTANTÁNEOS comparado con lo que sería cargar cosas por el modem este.

Respecto a lo de la compresión... no sé que decirte. La verdad es que no tengo ni idea de qué cifras se manejan en ningún juego de N64 a ese respecto. Lo único que puedo decirte es que hay muchos tipos de compresión que se pueden usar y que unos datos se comprimen mejor que otros.
No se si el SDK proporcionaba algún método de compresión para datos generales o tenías que hacerlos tu mismo u obtenerlos de algún otro sitio. vADPCM para el audio si que iba incluído en el SDK, pero para datos generales, como ejecutables, texturas y modelos, no tengo ni idea. Yo no me he mirado el SDK tanto como otros por aquí.

@radorn lo que no sabía era que el biosensor sí llego a usarse en un juego. Creía que era un addon cancelado.

@radorn sería posible replicar el raton con uno de ordenador? el chip que controla el raton parece muy normal.

Natlus escribió:@radorn sería posible replicar el raton con uno de ordenador? el chip que controla el raton parece muy normal.

Si es posible:


Y también puedes comprar un adaptador de mando de SNES a N64 y usar el ratón del Mario Paint.
https://www.raphnet-tech.com/products/s ... /index.php

EMaDeLoC escribió:

Natlus escribió:@radorn sería posible replicar el raton con uno de ordenador? el chip que controla el raton parece muy normal.

Si es posible:

Y también puedes comprar un adaptador de mando de SNES a N64 y usar el ratón del Mario Paint.
https://www.raphnet-tech.com/products/s ... /index.php

No conocía ese video. De todas formas, ahí se demuestra el adaptador con StarCraft 64, que no es un juego especialmente diseñado para el ratón, que solo salió en Japón como parte del 64DD.
Claro que luego los juegos diseñados para el ratón resulta que se pueden controlar con el mando y también hay gente que usa el ratón como mando para juegos normales... donde la bola controla el stick y los dos botones son A y B. Superficialmente parece que usa el mismo protocolo que el mando, pero tampoco lo sé seguro.

Por eso lo digo, si el chip que integra el ratón es similar al de un ratón normal, y se puede adaptar un ratón normal, lo mismo se podría acceder a la creación de ratones con mas botones o directamente mandos a partir de ese chip (o uno compatible) en el chip del ratón pone MX1720MC, sin el MC hay por ahí datasheets, pero no se si serán compatibles.

Aparentemente el ratón transforma los movimientos de la bola en rangos del joystick, pero en vez de mantener el valor cuando se para, manda la posición cero y el cursor se detiene. Hay que recordar que mecanicamente ratón y joystick funcionan igual, registrando el movimiento por los pulsos de luz que produce un disco con agujeros en ambos ejes x e y. Sin embargo mientras que en el mando se mantiene el valor de la posición del joystick hasta que este no vuelva al centro, en el ratón solo envía valores mientras la bola se mueve, sino manda cero.

Así que realmente no hace falta un protocolo concreto para que un juego sea compatible con el ratón, simplemente que si lo sea su gameplay. Starcraft o Command & Conquer se van a beneficiar, pero Mario64 no. Claro que solo los botones de A y B hace que la mayoría de juegos sean injugables. Y algunos juegos no reconocen el ratón como mando al encender la consola.

Un vídeo probando juegos con el ratón.


Dejo una página con detalles técnicos de la señal del mando y de cómo hacer un adaptador USB. Con la suficiente experiencia y conocimientos se podría adaptar y crear un ratón para la consola.
http://www.pieter-jan.com/node/10

@Natlus La N64 no va a aceptar el protocolo PS/2 o USB de un ratón normal, que es el que producirá uno de esos chips. Hace falta si o si traducir el protocolo de un ratón "normal" al protocolo del de N64, que parece ser el mismo que el del mando.

Aportando mi granito de arena especulativo a la explicación de @EMaDeLoC, yo me imagino que el ratón lo que enviará a la N64 en cada refresco de estado del mando será la diferencia de movimiento entre el último refresco y el actual en forma de una posición relativa al centro del stick. O sea, que para simular un angulo fijo en el stick, tendrías que mover el ratón a una velocidad constante en esa misma dirección de manera que en cada refresco la diferencia de movimiento respecto al anterior sea igual al ángulo de un stick en esa posición deseada.

Hola que tal, Hay alguna forma sencilla de usar el codigo fuente de Super mario 64?
Basicamente quiero extraer los archivos y volverla a compilar,
O tengo que hacerlo en linux por fuerza,
Lo he intentado con esto "Subsistema de Windows para Linux para Windows 10" pero no me deja instalar algunos paquetes...
Ahora esto instalando una imagen de ubunbtu con la virtual box, a ver hasta donde llego.

¿Otra pregunta, Las mejoras que hay sobre ralentizaciones y el humo ya estan incluidas en el codigo fuente o hay que implementarlas?

Quiero intentar incluir esas mejoras a mi Traducción, o por lo menos saber si necesito ayuda de alguien mas para incluirlas.

blade133bo escribió:Hola que tal, Hay alguna forma sencilla de usar el codigo fuente de Super mario 64?
Basicamente quiero extraer los archivos y volverla a compilar,
O tengo que hacerlo en linux por fuerza,
Lo he intentado con esto "Subsistema de Windows para Linux para Windows 10" pero no me deja instalar algunos paquetes...
Ahora esto instalando una imagen de ubunbtu con la virtual box, a ver hasta donde llego.

¿Otra pregunta, Las mejoras que hay sobre ralentizaciones y el humo ya estan incluidas en el codigo fuente o hay que implementarlas?

Quiero intentar incluir esas mejoras a mi Traducción, o por lo menos saber si necesito ayuda de alguien mas para incluirlas.

pues no se mucho de eso, pero molaría hacerlo sobre la segunda versión japonesa que trae soporte para el Rumble Pak, una versión así y en español no me importaría tener en la estantería en forma de repro, al lado del Mario 64 original.

@blade133bo Nunca he compilado nada, así que no sé que decirte. Si no hay instrucciones en el proyecto/repositorio n64decomp yo no te puedo ayudar. Creo que se requiere una ROM original para sacar los recursos gráficos y de sonido.
No se si habrá algún repositorio con arreglos, pero imagino que el de n64decomp tendrá el código original sin tocar, por aquello de la preservación y tal.

@radorn
Si hay, algo de docker y linux.
Ya instale un linux virtual, ahora tengo dos librerías fuera de linea sin alternativas, así que hasta ahí llegue.
Y con docker, seguí todas las instrucciones pero como soy muy listo, aun no me aclaro.
Hasta lo de cambiar de carpeta en la terminal no me funciona... toca profundizar linux o a tomar por... el linux.

EMaDeLoC escribió:Un vídeo probando juegos con el ratón.

Siempre di por hecho que Starcraft y Command & Conquer eran completamente jugables, y resulta que son injugables. Vaya tela..

Al menos el ratón funciona en los juegos que funciona y no lo hace en los juegos que no lo hace. No es como en Playstation 2 que, encontrar un ratón USB que funcione bien en todos los juegos, ha sido una tarea imposible para mi. Incluso llegué a pillarme el que recomendaban en Playstation Underground y es una lotería.

He encontrado este foro donde han conseguido cambiar los microcodigos del Mario 64 pero no detallan sin hay mejoras en rendimiento tras esto.

Incluye un pantallazo con el Turbo3D pero apenas se distingue nada, excepto que esta volteado.

https://hack64.net/Thread-Fast3D-Microcodes

No se si existen otras páginas donde se explique como se cambian los microcodigos a las Roms porque igual mejoraria el rendimiento de forma general.

De este mismo foro, hay otro filtro aliasing del fast3d que si se deshabilita se ganan 4-5fps

https://hack64.net/Thread-SM64-Fast3D-A ... ng-Reducer

Bueno al final instalando mil porquerias al ubuntu, no se en que momento ya me dejo compilar el juego.
Ahora me toca Ver si basta con reemplazar archivos...
Ya que estoy en mi momentum de felicidad.
Cuando consiga hacerlo funcionar en en n64 ire a por otras plataformas. (iluso de mi)
Ya le di un vistazo al código fuente, para los gráficos me basto hacer un corta y pega, en los textos, me lo hecho atras por simbolos unicode.
Pues yo lo dejo por ahora, (A ver si Queueram se digna a leerme el correo, y quiera volver a echarme una mano con la fuente, que andará liado estando en el ajo.)

Bueno, pues parece que hay un loco que se ha propuesto hacer una implementación N64 en FPGA: https://twitter.com/UFp64
Y se ve que la cuenta se ha registrado en abril de este año, así que es posterior a la filtración, lo cual indicaría que fue esta la que le ha motivado a intentarlo.
Temo que la conclusión vaya a ser que no es factible económicamente con los FPGAs de hoy día, pero ya veremos en qué queda. Quizá pueda hacerse un híbrido, con partes en FPGA (el RCP, quizá) y otras emuladas por CPU...
ya veremos.

También tiene YT https://www.youtube.com/user/mazamars312

y web http://www.ultrafp64.com/

Reflejos en tiempo real en N64:



Traducido lo que comenta el autor:

ROVERT
Básicamente, lee los píxeles del framebuffer y sobrescriben la textura metálica. Era conveniente porque tanto la textura metálica como el framebuffer son texturas RGBA16. Realmente no soy tan inteligente, solo estoy usando jerga. Este es solo un truco genial que se puede mejorar. Probablemente pondré esto en uno de mis futuros ROM-hackers. Gracias a Devwizard por escribir el código para la colocación de píxeles.