Hilo de detalles y curiosidades de N64

Sexy MotherFucker escribió:Te contesto mejor en este hilo:

radorn escribió:

Sexy MotherFucker escribió:De todas formas el original en Nintendo 64 también tiene errores que parecen de emulación, como por ejemplo las pixelaciones que se producen en ciertas texturas de vez en cuando, como las de la charca en la caseta del pescador de Lake Hylia en cuanto la cámara por defecto se desvía hacia un ángulo supuestamente muerto en la que entiende el jugador no debería estar viendo nada mientras está pescando, así que supongo que la consola desactiva el filtro o algo.

Esto sería mas bien para el hilo de detalles, pero bueno:

Creo que se de que hablas, y pasa en todos los juegos.
Yo deduzco que es una limitacion del filtro de texturas, pero no tengo ni idea de qué lo provoca. Alguna explicacion matematica/computacional tiene que tener. En PilotWings 64, con sus escenarios tan grandes con polígonos gigantescos, a los que, te puedes acercar un monton, especialmente con el jetpack, o aterrizando en cualquier superficie con el girocoptero pero sin decelerar hasta detenerse para que no se acabe el juego, puedes facilmente ver este curioso d/efecto.
Como ya digo, no sé por qué pasa, pero me ha recordado algo sobre el filtrado de texturas de la N64, o, al menos, el de muchos microcódigos, y que, en ciertos juegos que permiten acercarse de forma particular a algunos objetos, puede hasta apreciarse a simple vista.
Lo que hace el filtro de texturas es generar mediante filtro bilinear (lo de trilinear viene por la interpolacion entre mip-maps, que es como una tercera dimension) 32texels interpolados a partir de cada texel original.

De hecho, en GoldenEye, para mapear una textura a un triangulo, las coordenadas UV que se usan en cada vertice para decir que punto de la textura le corresponde, son enteros de 16bit con signo, y tiene una precision de 32subdivisiones de texel. O sea. si quieres que tu vertice empiece en el texel 1,1 de la textura, tus coordenadas UV tendrán que ser 32,32 (pero en hexadecimal o binario, claro) aunque, con el "sangrado" que causa el filtro bilineal, siempre es mejor añadir otro medio pixel para excluir la parte que se funde con el pixel anterior, asi que añade otros 16 (medio pixel).
De esta manera tenemos que, asumiendo que este patron sea universal, una textura en N64 puede repetirse a lo largo de un unico triangulo, hasta 2048 texels (65536 subtexels interpolados) de punta a punta con las coordenadas UV 0,0 en el centro. La cantidad de veces que una tetxtura en concreto se pueda repetir ya depende del tamaño de la textura en si. Con una de 32x32, la textura puede repetirse 64 veces de punta a punta (32 en direcion negativa y 32 en positiva, y no estoy hablando de efecto espejo, si no de meras repeticiones). una de 64x64, solo 32, una de 128, 16 veces.

Volviendo a lo del zoom, en ciertos juegos, y creo que turok 1 y 2 son dos ejemplos donde se puede apreciar, si te acercas lentamente a ciertos objetos atravesables, como algunos arbusos o plantas, puedes llegar a poner la camara tan cerca de un poligono que llegas a ver los sub-texels interpolados, que ya son meros pixeles no filtrados.
Si alguien puede sacar una imagen mejor, porque yo en este momento...

No se si esto realmente tiene que ver con esa extraña distorsion que se produce al ver algunos poligonos desde ciertos angulos, pero creo que alguna relacion ha de tener.

Pero por ejemplo eso es algo que no se ve NUNCA en Super Mario 64, el cual según Miyamoto emplea TLMMI. ¿Tendrá algo que ver el aplicar bilineal a "palo seco" o TLMMI, que se le dará mejor a la consola esto último?.

¿O nos estamos comiendo la cabeza de más y simplemente nos encontramos ante casos de códigos mal pulidos?

El Super Mario 64 no utiliza TLMMI , salvo en los cuadros que cambia de Peach a Bowser según te acercas y algún detalle más.
Yo creo que es más un bug de como realiza el filtrado la N64,que otra cosa,ya que me suena a ver leído que no filtra con la misma precisión que el estandar.

Saludos.

@dirtymagic puedo mostrarte fotos de revistas con Miyamoto declarando: "Super Mario 64 sí utiliza esa técnica (TLFMMI), el resto de los juegos no", en referencia al catálogo inicial del sistema en 1996.

Aparte de los cuadros que comentas se me ocurren más ejemplos en los suelos de algunas fases, o mismamente en las baldosas blancas y negras de ciertas secciones del castillo.

Supongo que tendrá sitios en los que irá desactivado como tú dices, pero que se usa a mí me consta tanto por declaraciones del diseñador como por experiencia propia.

@Sexy MotherFucker Yo a SM64 una vez completadas las 120 estrellas, poco mas lo jugué. Quizá algun dia se me de por re-jugarlo. Sin embargo, yo creo que si llegué a ver ese d/efecto en el juego tambien.

No se todas las ramificaciones que tiene el uso del TLMMI, pero, para empezar, a nivel de suavizado de texturas el algoritmo es el mismo, solo que con TLMMI, aparte de interpolar entre pixeles en los ejes XY (o mas bien UV) de la textura, interpola tambien entre las coordenadas correspondientes de un mipmap al siguiente, lo que es un fundido, vamos, y esa es la "tercera linea" del filtro.
Además de eso, esta distorsion que nos ocupa ocurre siempre al ACERCARSE mucho al poligono texturado, no en la distancia, que es cuando entra en juego la interpolacion o fundido con el siguiente mipmap, asi que, a mi parecer, dificilmente puede ser esta distorsion resultado de usar TLMMI. Claro que todo es posible, pero no parece muy logico segun este razonamiento.

Tambien probaré yo, pero si tal, vete a Mario 64 y pegate a paredes, a diferentes distancias del vertice. y, con la camara para ver al rederor, mira la pared "de refilon", y ya verás como encuentras algun punto donde se produce la distorsion. Estoy convencido.

Respecto a tu descripcion del d/efecto como "pixelado", si me puedes mandar un pantallazo mejor, porque lo que yo vi mas bien lo describiría como un efecto de banding "deshilachado" xD

Sexy MotherFucker escribió:Supongo que tendrá sitios en los que irá desactivado como tú dices, pero que se usa a mí me consta tanto por declaraciones del diseñador como por experiencia propia.

Pues aqui le doy mas razon a @dirtymagic que a miya y a ti xD
En SM64 hay un monton de aliasing en las texturas distantes, lo que indica una falta general de aplicacion del TLMMI. No tengo datos solidos, pero es que salta basante a la vista.

@radorn las declaraciones exactas son:

Super Mario 64 sí emplea esa técnica (TLMMI), el resto de los juegos no, aunque puede ser implementada fácilmente en las últimas etapas de desarrollo.

En vuestras HobbyConsolas, Nintendo Acción, 64 Magazine, y SuperJuegos de la época.

Yo en lo personal lo he visto activado en hardware real en más sitios que el de los cuadros, concretamente algunos suelos de las fases, aunque mirando vídeos ahora mismo en Youtube es cierto que hay muchas más zonas en las que está desactivado.

No estoy mintiendo, ni tampoco borracho.

@Sexy MotherFucker Es lo que tiene. A nivel del RDP, cada primitiva o triangulo se define con un comando GBI que dice "dibujame un triangulo entre estos 3 vertices, con esta textura, coordenadas UV, estos efectos, blah blah", y con un monton de tales comandos tienes una display list.
No tengo claro si a nivel del RDP se puede establecer efectos por grupo de comandos o cada uno tiene que ser independiente, pero a nivel del motor del juego ya es otra cosa. los formatos de cada juego están basados en GBI, y despues de procesados tienen que escupir un formato entendible por el microcodigo, pero a nivel del motor hay mucha flexibilidad.

Así que cada triangulo puede tener los efectos que quiera independientemente de los demas. Puedes generar un objeto y en cada triangulo aplicar efectos totalmente diferentes, y tener uno con todos los efectos de la consola a la vez (bueno, creo que hay que no se pueden aplicar al mismo tiempo y tienes que escojer uno u otro, pero ya me entiendes) y el siguiente con calidad PS1 xD.

Miya tiene mucho de chouman, pero sus declaraciones tecnicas me las tomaría con un poco de filosofia.

Tambien puede ser que en el momento de esas declaraciones el juego tuviese TLMMI generalizado pero luego se lo repensaron y lo quitaron de la mayor parte de los objetos...

@radorn Puedes tener una patilla de un chip soldada pero la soldadura no esta al 100% y generarte problemas de impedancia excesiva (resistencia electrica). Este defecto podría no detectarlo la consola al inicio porque los test no sean exhaustivos o no controlen esa línea en concreto, pero si aparecer más adelante ante una secuencia de datos muy alternada o a una variación producida por la dilatación del metal al calentarse. También puede ocurrir algo parecido si dos patillas estan haciendo contacto entre ellas cuando no deberian.
Has de tener en cuenta que los PC llevan contactos especiales de alta fiabilidad y que además llevan preparados test especiales, y aún así también tienen sistemas de protección que detectan y corrigen errores de transmisión de datos al vuelo.
En cambio la N64 puede no necesitar nada de esto en sus componentes a excepción de la conexión del cartucho, pues todos se sueldan en fábrica y pasan una prueba de conexión y fiabilidad in situ. Si no esta diseñada para que alguien le haga una sustitución de memoria, y menos alguien que no sea técnico de la casa, la consola puede que no haga más test que el básico de detectar la memoria y el expansion pak.

No recuerdo donde lei a uno de esos gurús de la electrónica que comprimia toda la placa de la N64 en 10cm cuadrados, que le habian surgido problemas con la RAMBUS ya que es más sensible a los temas de impedancia que otras memorias.

Ya que lo menciono, pongo una imagen. Plaquitas así son muy cucas.



N64 mini con hardware real confirmed!!

Fuente: https://twitter.com/ashevans81/status/988881640695980032

@EMaDeLoC OK, no tenia en cuenta todas esas cosas xD

Creo que vi ese twitter hace un par de meses tambien. Interesante placa. aunque me resulta curioso que no mencione ese cantoso modulo wifi en la descripcion...

EDITO: Parece que mas que una N64 reducida, es como una N64 "virtualizada". No solo no tiene ranura de cartuchos, si no que no tiene ni entradas de mandos, o incluso el PIF.
El modulo wifi que vi no es solo un modulo wifi, si no un SoaC que usa el tio para controlar todo el sistema y reemplazar incluso algunos elementos logicos de la N64, como el PIF, de manera que el encendido, el reset, la carga de ROMs, la emulacion de mandos, está todo virtualizado, como si tuvieses al chipset basico de N64 en matrix.
en las respuestas de twitter habla incluso de speedruns, así que me imagino que se podrían hacer unos scripts y controlar el juego desde el PC como si fuera en un emulador... aunque no creo que se puedan hacer savestates, así que estará algo mas limitado....

No se, no tengo claro del todo que es exactamente lo que tiene en mente este tio.

@radorn A mi el mero hecho de que le ponga HDMI como quien le pone una pegatina de colorines a la carcasa ya me deja flipado.
Quizá su idea de los speedruns es que se grabe un log de las acciones del mando y así cualquiera pueda comprobarlo en otro hardware, como una especie de verificador anti-cheats o de bugs que solo tienen consolas concretas.
Vete a saber, pero es una maravilla.

Y lo ha hecho un tío en su casa en su tiempo libre, imagínate Nintendo con sus archivos originales, sus ingenieros y sus millones de dolares... Ahí tienes tu N64 mini con hardware, @Sexy MotherFucker

Pero es más probable la emulación...

Lo que estáis comentando de que el filtrado bilinear se "rompe" en determinadas condiciones y/o juegos yo también lo he notado.
Por ejemplo, como comentáis en el agua del estanque de pesca del Ocarina of Time o en el Pilotwings 64 (en realidad me di cuenta en el port de la primera isla que hice para el GoldenEye). También en el Perfect Dark mirando las paredes prácticamente de canto. Recuerdo en especial en el mapa de multijugador del templo Skedar (el primero que ya está desbloqueado), en las paredes de piedra negra es muy notorio porque los patrones curvos se cortan de forma muy evidente. En otros juegos no me di cuenta si sucedía.

Parecería que el filtro se desactiva cuando miras la textura muy de cerca y "de canto", provocando téxeles muy grandes y deformados que el filtro no sabe muy bien cómo manejar, pero hay otro ejemplo del Ocarina of Time que el filtro se desactiva escandalosamente en condiciones de cámara normal.
https://youtu.be/8nsqsa45DG8?t=20m24s
La calidad de la imagen es bastante guarra aunque está capturada en unas condiciones muy buenas (es un canal muy recomendable para obtener capturas nativas), pero fijaos en la hierba después de que escale la pared de piedras y sobre todo cuando se acerca a la piedra chismosa. Esa superficie de hierba hace cosas raras y siempre parece que el filtro se activa y desactiva solo.

Si puedo, esta noche subo fotos.

EDIT: Y como decís. Super Mario 64 apenas usa filtrado trilinear si es que lo usa en algo a parte del truco del retrato de Peach/Bowser.

Hey, Sogun, cuanto tiempo! Al final hiciste Holiday Island y Big Boo's, eh?

Sogun escribió:fijaos en la hierba después de que escale la pared de piedras y sobre todo cuando se acerca a la piedra chismosa. Esa superficie de hierba hace cosas raras y siempre parece que el filtro se activa y desactiva solo.

El d/efecto que ves ahí es meramente aliasing de la textura por la falta de mip-mapping, como en las texturas de hierba de SM64.
El Zelda, además, como sabemos, usa una doble textura para terrenos como este. Una de hierba con detalle fino, y otra mas estirada para darle variedad subyacente a pinceladas mas gruesas.
La textura de mayor detalle, en este caso, al ser representada en pantalla con menor resolucion que la propia textura original, acaba mostrando aliasing, que varía a medida que la camara se mueve, causando ese "temblor", a pesar del filtro bilinear (que no es un algoritmo de resampleo de alta calidad). No ex pixelacion ni que el filtro se apague y se encienda. Si hubieran activado el TLMMI, la textura se reduciría a un borrón a poca distancia, y, sabiamente, prefirieron el aliasing en este caso.
Este aliasing es un fenomeno esperable y totalmente diferente al de la textura haciendo esas distorsiones raras a distancias cortas y angulos cerrados.

@radorn el ejemplo que te ha dicho del Zelda (cabaña de pesca) son pixelaciones como castillos durante unos segundos, no el «aliasing» típico de las texturas lejanas a la cámara, es como si por unos segundos el filtro se autodesactivase. Entra a la caseta del pescador y ponte a hacer el monguer un rato con la caña dentro de la charca, ya verás qué pasa

A veces me ponéis de mal humor los supuestos fans de la N64, porque me da la sensación de que yo sin serlo me he reventado más que vosotros los juegos más importantes del sistema, no puedo concebir que un tío que lleva de avatar un mando de Nintendo 64 se le hayan escapado esos detalles si se supone lleva jugándola 20 años, no es la primera vez que observo que esto sucede.

... ... te estas colando, tio... y mucho...
@Sexy MotherFucker Te invito a que te calmes un momento, repases los ultimos mensajes, y reflexiones sobre que se ha dicho, quien lo ha dicho, a quien se le ha dicho, y acerca de qué cuestion en concreto se ha dicho lo que se ha dicho...
Tambien te animo a que pienses bien en lo que afirmas y me gustaría tambien que aportes imagenes de eso a lo que tu llamas "pixelaciones como castillos", la mires bien y reflexiones, porque se perfectamente de lo que hablas, y no son "pixelaciones", como ya dije anteriormente.

Ahora no tengo tiempo para mas, pero si luego tengo que menear toda la mierda que tengo por aqui para sacar yo las imagenes y sigues tan borde como ahora, no seré tan amable y conciliador.

@radorn ya estoy calmado y te pido disculpas, pero es que estoy harto de los fans de boquilla en ciertos sistemas y que luego apenas han jugado una vez en su vida a una obra de sus obras culto.

Y a ver, que se te resquebrajen los texels = pixelación, porque no ocurre sólo en los bordes, ni a lo lejos, sino que la textura del agua se llena de cuadritos rectangulares y piquitos durante unos segundos.

@Sexy MotherFucker OK, acepto disculpa.

Con respecto al video que puso @Sogun, Iba a reafirmarme en el tema del antialiasing, porque en mi anterior visionado, debido a la calidad del video, honestamente te digo que no llegué a ver la distorsion de la textura y solo veia el aliasing. Probablemente ayudó el hecho de que lo vi en ventana y no a pantalla completa, y siendo tan sutil ni siquiera sospeché que hubiese algo mas. Pero ahora tengo que desdecirme, pues lo he vuelto a ver y esta vez si he identificado el dichoso d/efecto, aunque no es el ejemplo mas claro que te puedes encontrar en la consola, y en ese video en concreto, hay algo mas borrosidad de lo habitual si cabe.
Al final voy a tener que montar la consola aqui otra vez y capturar yo algunos ejemplos.

La distorision de la que estamos hablando es visual y fundamentalmente diferente del pixelado.
Es cierto que se forman unas "bandas" (no se me ocurre otra manera de describirlas) con unos bordes de transicion marcados, y puede parecer pixelacion. Pero esas bandas que se forman no estan ni de lejos alieneadas con los pixeles de la textura. De hecho, puedes tener multiples bandas formandose en el intervalo de interpolacion entre un pixel y el siguiente, y ni siquiera son los subpixeles que comenté en otro mensaje con respecto al algoritmo de suavizado de texturas.

¿Es feo? si
¿Hace "bloques"? si, bwana
¿Es pixelacion? NOOOORL!!

¿Que es entonces? aaaaah... esa es la pregunta del millon! yo solo puedo señalar lo obvio, y es que es una limitacion tecnica del algoritmo de suavizado de texturas que causa una distorsion a distancias cortas y angulos cerrados. Los detalles tecnicos del proceso que lo provoca ya se escapan a mi conocimiento.
Pero ni es pixelado ni está provocado porque "se apague o desactive" temporalmente el suavizado.
El filtro sigue ahí, y ese es el resultado en determinadas condiciones. Es lo que hay...

AÑADO: Para ahondar en mis motivos para diferenciar entre el defecto que nos ocupa y el pixelado, señalo no solo que no se aliea con los pixeles de la textura original, si no que las bandas que se forman, si bien tienen unas lineas de transicion cortadas a cuchilla entre ellas, en el eje perpendicular a estas, sigue habiendo transiciones suavizadas.
Pixelado es ver los pixeles originales de la textura aumentados por "point resample" "nearest neighbour interpolation" o, en español segun wikipedia, "interpolación proximal". Cuadrados bien alineados y con bordes bien definidos en los dos ejes del plano.
Lo que se ve aquí ni tiene relacion directa con los pixeles subyacentes de la textura, ni está perfectamente alineado, y los bordes definidos solo aparecen perpendiculares al angulo de la camara y el plano del poligono texturizado, mientras que, en el plano perpendicular a este, las transiciones siguen siendo suavizadas.
Es un defecto muy raro, pero no es pixelado.

Yo recuerdo en la época de ps2 que en las revistas algunos desarrolladores se quejaban de los problemas para programar, si embargo en la época con n64 nunca leí sobre los problemas como la memoria RAM o los cuellos de botella que tiene la consola.

O estoy equivocado?
O nintendo los amenazaba?

jeisonpsp escribió:Yo recuerdo en la época de ps2 que en las revistas algunos desarrolladores se quejaban de los problemas para programar, si embargo en la época con n64 nunca leí sobre los problemas como la memoria RAM o los cuellos de botella que tiene la consola.

O estoy equivocado?
O nintendo los amenazaba?

Tampoco lo escucharías en la NES o en la SNES en su momento, y sin embargo, la gente sufre para sacar cositas homebrew en la SNES....

Naitguolf escribió:

jeisonpsp escribió:Yo recuerdo en la época de ps2 que en las revistas algunos desarrolladores se quejaban de los problemas para programar, si embargo en la época con n64 nunca leí sobre los problemas como la memoria RAM o los cuellos de botella que tiene la consola.

O estoy equivocado?
O nintendo los amenazaba?

Tampoco lo escucharías en la NES o en la SNES en su momento, y sin embargo, la gente sufre para sacar cositas homebrew en la SNES....

En aquella epoca nada de eso y en ese tiempo nintendo era el manda mas, ya te podras imaginar jajaja

jeisonpsp escribió:Yo recuerdo en la época de ps2 que en las revistas algunos desarrolladores se quejaban de los problemas para programar, si embargo en la época con n64 nunca leí sobre los problemas como la memoria RAM o los cuellos de botella que tiene la consola.

O estoy equivocado?
O nintendo los amenazaba?

Supongo que eso fue debido a que en ps2 había mayor cantidad de desarrolladores trabajando para la consola que en N64 por tanto había mas probabilidades de encontrar algunos "inconformes", que además en N64 la mayoría eran o la misma Nintendo, o sus estudios second o colaboradores muy cercanos de Nintendo, que no iban a quejarse o criticar la maquina.

Sobre nes y supernes ahí si que puede ser que Nintendo los haya amenazado

Es que eso de los desarralloradores quejandose de los defectos de la arquitectura de una máquina no se veia en el milenio pasado.
Para empezar no había tantas oportunidades de trabajar en videojuegos, así que si quereis tener ese trabajo y te tocaba sudar sangre para mover un sprite porque la placa era un churro, te aguantabas, ponias una sonrisa de oreja a oreja ante la prensa y decias que la máquina tenía mucho potencial.
Luego también estaba que pocos eran los desarrolladores que trabajaban en más de un sistema a la vez, así que se comparaba poco y cuando se hacía era entre generaciones, y como lo normal es que hubiese mejoras pues tampoco había quejas.
Es a partir de que se empiezan a estandarizar los desarrollos usando lenguajes comunes como el C, a empezar a definirse las arquitecturas como las actuales y los estudios a empezar a tener fuerza y ser más independientes, cuando los programadores empiezan a revelar los problemas de diseño de las máquinas.

jeisonpsp escribió:Yo recuerdo en la época de ps2 que en las revistas algunos desarrolladores se quejaban de los problemas para programar, si embargo en la época con n64 nunca leí sobre los problemas como la memoria RAM o los cuellos de botella que tiene la consola.

O estoy equivocado?
O nintendo los amenazaba?

Kojima les contestó algo así como: difícil era programar en la NES. Os quejáis de vicio.

Diskover escribió:

jeisonpsp escribió:Yo recuerdo en la época de ps2 que en las revistas algunos desarrolladores se quejaban de los problemas para programar, si embargo en la época con n64 nunca leí sobre los problemas como la memoria RAM o los cuellos de botella que tiene la consola.

O estoy equivocado?
O nintendo los amenazaba?

Kojima les contestó algo así como: difícil era programar en la NES. Os quejáis de vicio.

Me quiere sonar que fué miyamoto, pero no estoy muy seguro.

Alguien ya a ha empezado con tu libreria @BMBx64

http://krikzz.com/forum/index.php?topic=7991.0

@Flash-Original
Mola

Pero no veo que esté acelerando por hardware, si el Everdrive 64 corre en modo software debe ser muy lento, imagina pintar el fondo de 640x480 con la CPU.

La idea sería un menú donde puedes ver las carátulas y que corre a 60fps (acelerado por RDP), incluso con fundidos alpha al abrir menú o con redimensiones, eso es posible en el estado que dejé la librería, pero el código de krikzz no me queda claro si es privado o hay que pedirlo.

@BMBx64 el everdrive de kirkzz no sé, el ED64 chinorri tiene un SO muy pobre estéticamente, pero va a una velocidad decente. El Alt64 lo probé y es mucho más bonito, pero va muy muy lento; pese a que tiene muchas opciones como lo de poder usar gameshark terminé volviendo al original.

BMBx64 escribió:@Flash-Original
Mola

La idea sería un menú donde puedes ver las carátulas y que corre a 60fps (acelerado por RDP), incluso con fundidos alpha al abrir menú o con redimensiones, eso es posible en el estado que dejé la librería, pero el código de krikzz no me queda claro si es privado o hay que pedirlo.

yo supongo que se le tiene que pedir el código a krikzz, no creo que se lo pase a cualquiera pero seguro que si se lo pasaría a un master como tu @BMBx64 además de que tienes bastante conocimiento sobre la consola

BMBx64 escribió:La idea sería un menú donde puedes ver las carátulas y que corre a 60fps (acelerado por RDP), incluso con fundidos alpha al abrir menú o con redimensiones, eso es posible en el estado que dejé la librería, pero el código de krikzz no me queda claro si es privado o hay que pedirlo.

Si nos haces un menú así para nuestros everdrives chinorris...

Se podría hacer una interfaz en una capa que fuera adaptable a cualquier tipo de flash.

He visto que el menú de 64drive es bastante ágil, pero no he encontrado que tenga carátulas, las hay? Las flash chinorris no usan el mismo tipo de menú o muy parecido al del ED64 original?

En todo caso necesitaría una fuente dónde estuvieran todas las portadas de los juegos de N64.

Y luego pensar como enfrentar el tema, establecer un tamaño máximo para cada imagen, cargarlas de 10 en 10, o en un menú de desplazamiento continuo usando el joystick, es decir buscar la forma más ágil.

Identificar los juegos al vuelo o bien actualizar un listado, habría que mirarlo y aún así en emulador nada de esto se podría hacer, es decir los accesos a SD.

BMBx64 escribió:Se podría hacer una interfaz en una capa que fuera adaptable a cualquier tipo de flash.

He visto que el menú de 64drive es bastante ágil, pero no he encontrado que tenga carátulas, las hay? Las flash chinorris no usan el mismo tipo de menú o muy parecido al del ED64 original?

En todo caso necesitaría una fuente dónde estuvieran todas las portadas de los juegos de N64.

Y luego pensar como enfrentar el tema, establecer un tamaño máximo para cada imagen, cargarlas de 10 en 10, o en un menú de desplazamiento continuo usando el joystick, es decir buscar la forma más ágil.

Identificar los juegos al vuelo o bien actualizar un listado, habría que mirarlo y aún así en emulador nada de esto se podría hacer, es decir los accesos a SD.

El menú alternativo creado por saturnou Alt64 y posterior modificación Altra64 con soporte a EverdriveV2 si dispone de carátulas aunque se muestra tras pulsar un botón en una ventana modal un poco simple.

Si te animas a realizar una versión propia el código de dichos menús están disponibles en github:
https://github.com/parasyte/alt64
https://github.com/networkfusion/altra64

@BMBx64 Como usuario de 64drive desde su inicio, no estoy al tanto de que haya habido soporte para caratulas. Tampoco creo que vaya a haberlo. Pero, tampoco podría jurarlo. Personalmente no es algo que eche de menos. Me van mas las cosas mas practicas. De todas formas, para ese tipo de característica, yo echo de menos una infrastructura algo mas robusta y flexible que simples ficheros en carpetas en una SD FAT32...
Pero quien sabe lo que vaya a pasar ahora que estamos viviendo tantas crisis en occidente, y concretamente en el mundo retro, esta ROMpocalipsis que ha desatado Nintendo.

yo soy usuario del everdrive 64 y la verdad es que si seria interesante ver un menu con caratulas o ver alguna mejora notable del menu oficial de kirkzz , ciertamente la versión china parece una copia del menu de kirkzz ,creo el 64drive tiene el mejor menu de todos los flash carts (debí optar por el xD)

Lo cierto es que la consola puede con más y seria muy buena idea un sistema operativo que aproveche la librería de BMBx64

@radorn tampoco te preocupes, todos vamos a morir en la tercera Guerra Mundial entre Alianza de Estados vs Google antes de que borren todas las webs de backups.

Comenté ayer el tema de las carátulas en el chat de N64 y por lo visto ya se está trabajando en un nuevo menú del 64drive con ese soporte.

En caso de hacer un menú sería solo para el ED64.

También se han hecho tests con un cartucho de expansión de 8MB (12MB de RAM) y no han conseguido acceder por software a los 4MB extra, no sé si hay consenso en esto y probaran otras formas, hablan de hard mod, pero yo me iba olvidando de que se llegue a usar más de 8MB en la scene. (para mi con eso ya es suficiente)

@BMBx64
¿Te refieres a #n64dev? ¿Quién dijo lo de las caratulas, marshallh?

Con lo de la RDRAM, yo habia leido hace un porrón de años, en la difunta comunidad Dextrose ( https://web.archive.org/web/*/http://www.dextrose.com/ ... el dominio ahora redirige a la web de krikzz, fabricante de los everdrives) que alguien si habia conectado 12MB con exito... pero vete a saber.
Cuando dicen que no consiguen acceder por software, a que nos referimos exactamente. A nivel de hardware, mediante librerias, homebrew u oficiales, con algun juego comercial hackeado?

En fin. Si no funciona con RDRAM siempre puede usarse la de los flashcart, especialmente el 64drive con sus 242MB usables y en modo R/W. No es tan rapida como la RDRAM, pero para algo servirá.

@radorn
Sí, la pregunta fue para marshall, pero es emu_kidid quién se encarga de las carátulas.

En cuanto a la expansión, lo que me comentaron es que la consola no consigue "ver" esa memoria extra, con ejemplos programados en ASM, aunque también comentaron algo de que Starcraft 64 podría sacarle partido, ya preguntaré qué hicieron exactamente la próxima vez que me pase.

Respondo aqui a una cosa del hilo de ventas de N64 viewtopic.php?p=1746356905

Sogun escribió:StarCraft 64 me parece que también funciona a 640x480 durante la partida. Y FIFA 99 tiene un modo de Super Alta Resolución similar al del Vigilante 8 que se ve de maravilla pero es del todo injugable.

BMBx64 dijo que el juego con menor resolución parecía ser el V-Rally 99 pero no pudo sacar capturas. También mencionó que el Bettle Adventure Racing era de los que menos resolución tenía, pero no dio números.

Lo más tocho sería esta demo de Marshallgs en la que en la descripción del vídeo se podía descargar una captura del frame-buffer. Afortunadamente aún la conservo y tiene un tamaño descomunal de 800x600. No sé si es correcto ni qué pretendía.

Yo el VR99 no lo tengo nada controlado. Lo alquilé una vez en su epoca y no me convenció nada, así que no volvi a tocarlo. Del que si se que tiene una resolucion muy baja, y, ademas, es un caso especial que ya he comentado aquí un par de veces, es el Body Harvest, que tiene la caracteristica inusual de que no solo usa escalado para hacer pantalla completa en PAL, si no que tambien lo hace la version NTSC del juego. El efecto es muyh evidente cuando se abre el menu de pausa. Las escenas animadas de introduccion no lo hacen si no que usan una resolucion 240p real y solo en PAL reescala (creo).

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

La demo de marshallh la conocía tambien. Además, eso lo incluyó en otra demo mas grande con mas escenas que hizo para la convencion Midwest Gaming Classic de 2011.

Al ver tu post se me ha ocurrido que mucha gente por aqui quiza no conozca esta demo u otras, así que os dejo aqui unas pocas compilaciones para que curioseeis.

https://mega.nz/#F!n40zlaBR!VGK0NeVhKI_cwG--GEMXNQ

@Sexy Motherfucker
Es codigo compilado con las bibliotecas oficiales y de hace años y no se cuan optimizado estará, pero si que prescinde de bastantes tecnicas del filtrado y tal. Por ejemplo, la demo de terreno en 3D se ve claramente que no usa Z porque hay una parte donde se ven algunos triangulos asomando por donde no deben. Tambien parece no haber anti-aliasing en general.

No es nada definitivo ni de lejos creo, pero viene a cuento de esa historia de prescindir de la paja paraa ver como chuta la consola así.

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

Durante la busqueda de la demo funnelcube de marshallh, me he topado con esta pagina de un tio listo que se dedica a flashear y etiquetar repros con carcasa y cobrarlas a un buen pellizco.
Fisgando por la pagina me he encontrado tambien tu traduccion del GoldenEye al español, @Sogun.
https://www.vintex64.com/store/p135/Gol ... panol.html
El tio ofrece practicamente cualquier cosa en un cartucho. ROMs hackeadas, mods completos, traducciones, prototipos, incluso prototipos cutrisimos llenos de bugs y sin practicamente nada que hacer como "Tommy Thunder"
Por entre 3 y 6 de esos cartuchos, te compras un flashcart como es debido.
Yo no me explico quien puede querer pagar por eso...
Tiene una seccion de "testimonios", con entusiastas declaraciones de clientes satisfechos. Cosas como "Estoy harto de esos repros chinos. Yo solo confio en los repros de Vintex 64"... desternillante
Huele a falso que echa pa atras... al menos espero que sea falso...

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

añado algunas otras fuentes de ROMs "PD" (Public Domain)
http://www.nesworld.com/article.php?sys ... 64homebrew
https://pdroms.de/files/nintendo64

Leyendo la entrevista del desarrollo de Body Harvest que ya había enlazado BMBx64: http://www.nintendolife.com/news/2015/0 ... dy_harvest

Muy interesante por cierto. Lo que no encuentro es que resolución exacta tiene el juego. El emulador me sacó un 300x225, pero no sé si es la resolución con ese zoom que comentas @radorn o la original antes del zoom. Si esa la nativa estaría por encima de la de FZero y V-Rally 99 (que a mi tampoco me gusto por cierto).

@radorn gracias, sabes que me interesa ver hasta donde llega la mierda sin ponerle puertas al campo

@radorn las compilaciones están muy interesantes me aventé todos los vídeos, verlos correr en la consola para mi es algo que no tiene precio

El Beetle adventure racing tiene una resolución de 320x240 en los menús.


En las carreras deja margenes negros hasta 274x206, he mirado si en consola hay reescalado y no lo he visto.


El Body Harvest 320x240 en el menú.


Y algo inferior la parte ingame, aquí muestra 302x227, con qué mediste la resolución Calculinho?


El V-Rally 99, edit, ahora sí, las resoluciones:

El menú corre a 640x480, siempre me sorprendió la calidad de esa imagen la verdad.


La pantalla de carga 320x240.


La parte ingame recorta 10 pixels por la izquierda, así que sorprendentemente es de 310x240, aunque por resultados se ve muy borroso, igual los filtros aplicados, la calidad de las texturas o venir de un menú nítido en hires tengan que ver, no sé.


A mi el juego tampoco me gustó demasiado, es muy exigente, aunque debe ser satisfactorio hacerse con él.

Los circuitos eran como túneles, mirabas los laterales y lo veías completamente vacío, además de que no habían choques ni desperfectos ni apenas sonidos, eran como gomas girándose en sentido contrario cada vez que cometías un error, creo que éste gif representa mi experiencia con el juego.


Por otro lado creo que solo conseguí dejar mi record en 1 o 2 pistas de la contrarreloj porque venían rellenados por los betatesters del juego

En cuanto a la resolución, veréis resultados raros como 320x237, parece que el RDP no pinta todos los scanlines y se deja algunos, es una teoría por confirmar, pero no queda claro si los buffers ya están optimizados para ahorrar esas lineas que no pinta o no, pero es un dato a tener en cuenta de cara a optimizar librerías.

--
Ah sí, tenía por esto por aquí.. yo llegaba hasta el tejado usando la gorra y el cañón, por supuesto también conseguí meterme por dentro del castillo, pero no con esos resultados

Voy a tener que mirar atentamente lo del Body Harvest, es posible que en otras fases tenga una resolucion aun menor, ahora que lo pienso. Yo no me di cuenta hasta que llegue a la fase de Java, que creo que es la segunda.

De todas formas, como aun nadie lo ha comentado. No se si alguno de vosotros ha prestado atencion a la demo Nacho 64. Es bastante profesional de por si para ser una produccion casera y de la epoca de la scene, creo. Pero hay un detalle tecnico especialmente alucinante. Tiene un espejo 100% funcional, que ademas rota, así no es que haya una habitacion escondida detras de el para simular... a no ser que usen un portal para que no renderize mas que cuando se la ve atraves de el espejo, y la hagan girar entera junto con el propio espejo pero en sentido contrario para compensar...
No se cómo lo habran hecho, pero es impresionante. Lo curioso es la poca atencion que se le presta durante la demo.

Eso ademas me hace recordar que hay un juego de rally licenciado que tiene reflejos 100% funcionales en todas las lunas del coche. No son reflejos del cielo ni leches, si no de lo que realmente hay en el escenario.
"Rally Challenge 2000" en su version USA o "Rally '99" en Japon

@radorn
¡Muy bueno lo del Rally Challenge 2000! Era un detalle que desconocía.
Parecen ser capturas de diferentes frame buffers a la resolucion perfecta para que aplicadas como textura en las ventanillas no se note nada de pixelización. Y lo hace a un framerate muy aceptable actualizándose a cada frame (no como los monitores del Mario Kart 64 que van a golpes y ni siquiera se actualiza la imagen completa).
El único pero es que los coches rivales no se reflejan y sus cristales tampoco reflejan nada. Bueno, sería pedir demasiado como para que el juego se mueva bien.

También he probado el juego emulado y como sospechaba con el plugin de Jabo que no soporta efectos de framebuffer los cristales quedan negros. Con el plugin Glide64 los reflejos se ven casi perfectos en modo ventana a 640x480 y dan muchos problemas cuando paso a pantalla completa a 1080p (eso sí, los reflejos se muestran en alta resolución). He probado la última beta del GlideN64 que en encontrado y los reflejos salen perfectos pero el rendimiento que me da ese plugin es paupérrimo (un 10% de la velocidad real, a cada versión que pruebo me va peor ).

Matizo lo anterior después de buscar un video del juego en youtube para mostrar los reflejos. Resulta que en este vídeo del juego emulado sí que se ven los coches rivales. Cuando lo he probado yo en la consola me he fijado varias veces y no los he visto. En este otro vídeo capturado de la consola sí que puede apreciarse que también se reflejan los coches rivales.


La demo Nacho64 ya la tenía vista de hace años y como bien dices el espejo es lo más alucinante que existe en Nintendo 64. Creo que no se le da mucho protagonismo porque en cuanto aparece algo reflejado en él el rendimiento cae en picado. Posiblemente porque los reflejos ocupan mucho porcentaje de la pantalla.

@Sogun Hace tiempo, cuando recibí el 64drive, me puse a probar sistematicamente "todas" las ROMs por diferentes razones. Clasificar, identificar esta o aquella caracteristica, y un largo etcetera de motivos que por supuesto incluyeron la mera curiosidad.
De esa manera descubrí curiosidades como esa.
Yo ni siquiera habia oido hablar de ese juego antes, que recuerde, así que me imagino que debe ser bastante desconocido. No le dedique mucho tiempo, pero aparte de esa virgueria tecnica, no parece que tenga mucho de especial.

@BMBx64 pues cuando hice el top, hace ya un año, jugué en consola; pero para decorar el listado hice capturas en emulador y en aquel momento me parecía una buena idea buscar hacerlas a resolución nativa (con PSX ya aprendí que es más cómodo hacerlo todo a 320x240 y fuera) así que googleando pillé un plugin que supuestamente dejaba hacer capturas y sacar resolución original. Pero vamos que si lo has comprobado tú, la resolución correcta será la tuya.

Pör cierto, aquí dijiste que la de F-Zero era 296x208: viewtopic.php?p=1741625954

Que es de donde vinimos hablando si es la resolución más baja del catálogo, ahora con ese Beetle a 274x206 podemos decir que estos dos juegos serían los que menor resolución tienen?

@Calculinho
Bueno incluso poniendo las resoluciones que dan los plugins, parece que entre versiones también puede haber diferencias, ahora he actualizado mis herramientas y ya puedo hacer debug a juegos que antes no podía como V-Rally 99, pero también contrastar si toda la información que di años atrás es correcta o cambia ligeramente con el último plugin.

Si queréis saber algunas resoluciones de juegos que no se hayan puesto las podría intentar sacar.

Como comentaba @radorn sobre el Body Harvest hay distintas resoluciones, por ejemplo dentro de ésta caseta sube a 320x240 (o 237), igual sería ponerse a probar, no conozco demasiado el juego.

@BMBx64 Cierto, cuando me jugué el Body Harvest (lo acabé y todo... y en modo dificil, si no recuerdo mal), si que noté que cambiaba la resolucion entre el interior de los edificios y el terreno exterior, siendo los exteriores notablemente mas borrosos. Cuando me dí cuenta de que la resolucion de los exteriores estaba escalada fue en la segunda fase, Java. No se si fue porque la resolucion era diferente a la primera fase, Grecia, o simplemente que antes no me habia dado cuenta y ahora si... supongo que ambas posibilidades son factibles.

Con que comprobais las resoluciones? yo hace siglos que no ando con emus de N64, y usar el 64drive con el action replay es un infierno, tanto por el proceso para usar el uno con el otro como que para sacar imagenes tengo que usar un PC viejo con puerto paralelo para impresoras, no todos los juegos son compatibles... en fin, un embrollo.

@radorn
Tienes el plugin de Angrylion's RDP, hay las versiones antiguas y la "plus", que mejora la velocidad de los juegos, es un plugin extremadamente lento, yo lo suelo usar solo para sacar resoluciones o ver algunos efectos especiales porque es el que intenta emular la consola.

Puedes encontrarlo para Project 64, de éste último he bajado la versión 2.4.0.9999, pero vamos, lo mismo de siempre viene con un plugin Jabo que pinta por debajo la sombra del Super Mario 64 y no se ve, no dan ni una en la emulación de N64 la verdad..

El angrylion no puede correr con cualquier plugin RSP, tiene que ser el static interpreter con un ini especial o bien puedes probar con los "RSP plugin" más modernos que ya soportan ese set de instrucciones.

Como el RSP plugin 1.7.3.202 o la 1.7.1.9999.

Ayer estuve trasteando y hay muchos juegos que no van o dejan de ir, quería ver las distintas resoluciones del Fifa 99 y al llegar al campo, boom.

Vaya movida lo del puerto paralelo

@BMBx64 Y aparte de PJ64 y plugins LLE, no hay hoy en dia emuladores nuevos de bajo nivel y cosas así? Yo pense que ya estarían mas popularizados, especialmente entre hackers y tal.
Del PJ64 yo tengo la version 2.3.2, y los compilados de la 2.4.0 parecen estar solo disponibles para donantes de patreon.
Aparte del RCP/RDP LLE, que tal es el GlideN64? No el viejo Glide64, si no el nuevo GlideN64
Nadie por aqui usa CEN64? Mupen?
Tengo muchos nombres en la cabeza pero la verdad es que, por una serie de circunstancias vitales mierdosas, no me he puesto a probarlos.

Y si, ya hoy en dia usar un cartuchode trucos de los 90 es una aventura, en si, pero si además pretendes usarlo con un cartucho flash moderno, ya es la leche.

El AR trata de inyectar su codigo en el del cartucho que su menú carga. En este caso, estárías haciendo trucos para el menu del cartucho de ROMs. Pero luego, cuando cargas un juego desde el cartucho de ROMs pues ya el AR no puede inyectarse en el de ninguna manera.
Una cosa que se puede intentar hacer, al menos con el 64drive que creo que tiene mejor soporte USB que el ED64, es, si tienes el PC al lado, cargar la ROM por USB, convirtiendo el cartucho en un cartucho normal, sin menu, mientras esté alimentado por USB. La desventaja de esto es que los guardapartidas te los tienes que transferir manualmente al PC, claro... Además, con la version HW1 del 64drive, que usa un CIC extraido de un cartucho original, solo puedes usar juegos compatibles con ese CIC (que puede ser al 7101/6102 o el X105), a no ser que tengas un cartucho conector T como el que me fabriqué yo, y, aun con eso, el tema de los diferentes CICs en el Action Replay ya es, de por si, bastante engorroso. Usando un juego con el CIC "standard" 7101/6102, que es el que usaron primero y el que usan "todas" las third parties, tienes que cargar el Action Replay, ir al menu "key codes" y seleccionar o introducir manualmente el codigo apropiado para el cartucho que vayas a usar, entonces apagas la consola, cambias el cartucho por el que quieras usar, y enciendes... La siguiente vez que enciendas la consola el "key code" se habrá reseteado al estandar, y tendrá que usar otra vez un cartucho con CIC 7101/6102.

Mi teoria es la siguiente: Primeramente, sabemos que el AR tiene su ROM almacenada en una EEPROM, y ahí está todo. El codigo ejecutable del menu, la lista de codigos... todo. Cada vez que usas cualquier caracteristica del AR estás modificando el almacenamiento donde se encuentra la ROM ejecutable. Por eso son tan propensos a corromperse y volverse in-arrancables.
Examinando la ROM, se ve que no tiene el codigo de carga del CIC. Lo que hace es usar el que tiene el cartucho insertado encima que vería segun la variante de CIC que quieras usar. Mi teoria es que los dichosos "key codes" no son mas que los CRCs que el PIF necesita para validar la ROM y arrancar, y que varían segun el CIC usado tambien.
De esta manera, cuando cambias un keycode de esos, lo que hace el menu del AR es sencillamente cambiar las CRCs de la cabecera de su ROM a una que vaya a validar la ROM del AR en el siguiente arranque con el CIC apropiado. Y una vez el menú arranca, vuelve a reescribir los CRCs a la version estandar y así queda listo para el siguiente arranque... con un cartucho normal.
Se considera que esto era una especie de metodo de seguridad por si te prestaban o alquilabas un cartucho con un CIC raro y luego te olvidabas de resetear el keycode manualmente pero ya no tenias el cartucho apropiado para cargar. Claro que de lo que no te salva nadie es de meter el keycode incorrecto y no tener un cartucho apropiado para volver a cargar el menu y quedarte con un AR inarrancable.

Despues de todo esto, queda la cuestion de que no todos los juegos son compatibles con el AR, especialmente si ya usan los 4MB extra del EP, que son los que el AR v3 intenta usar para sus cosas.

Volviendo al tema de cómo cargar juegos en un cartucho de ROMs de manera que puedas usarlo con un AR, un metodo alternativo que se puede intentar es empezar usando el 64drive normalmente, cargar una ROM desde el menu y arrancarla. En este momento, sin apagar la consola, y con mucho cuidado de no mover el cartucho demasiado, le enchufas el USB. No tiene porqué estar conectado a un PC; puedes usar una de esas fuentes de alimentacion USB como las que vienen con los moviles. De esta manera, puedes apagar la consola y la ROM no se volatiliza de la RAM interna. entonces, sacas el 64drive de la consola y pones el AR y pones el 64drive encima y arrancas (incluyendo el conector T si el CIC de la ROM es diferente al que está instalado en el 64drive). Una ventaja que tiene esto es que junto con la ROM el menu va a cargar el guardapartidas que haya en al SD tambien, claro que una vez que enchufas el USB los cambios ya no vuelven a la SD...

Una vez sacado de enmedio todas las consideraciones y metodos para PONER UNA ROM en el cartucho y que el AR arranque, para sacar imagenes tienes que arrancar el juego con una opcion que se llama Code Generator, que es la que activa el puerto paralelo, por supuesto, esta caracteristica es aun mas inestable que el motor de codigos estandar y no todos los juegos la aceptan igual de bien. y los juegos que usan el EP raramente la permiten.
Una vez cargado eso, necesitas un PC con puerto paralelo y un SO windows de 32bit, que, si está basado en NT, como XP y 2000, ademas requiere un driver especial para poder acceder a los puertos clasicos, que, en XP son considerados vulnerables y estan restringidos para acceso solo por drivers y no directamente por aplicaciones, como en la serie 9X.

Una vez llegados a este punto, puedes INTENTAR hacer alguna captura ocasional, que interrumpe la ejecucion del juego, copia lentamente el framebuffer al PC, si todo va bien, y resume la ejecucion del juego, causando, a veces, alguna inestabilidad en este. Por ejemplo, en GoldenEye, cuando el juego vuelve en si, bond sale mirando a cuenca y tarda unos segundos en regresar, con movimientos parkinsonianos al angulo de vision normal con el que estaba la ultima vez.

Hace unos cuantos posts creo que dejé una antigua coleccion de imagenes sacadas así, no se si mucha gente la vio porque nadie dijo nada al respecto... Fue cuando tuvimos aquella fiebre de posts gigantes, principalmente entre EMaDeLoC y yo.

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

Ultima nota: Antes de que salieran el Everdrive 64 y 64drive, salió tambien un cartucho frankenstein, el NEO Myth 64 de NEO-Flash, una empresa de Hong-Kong creo, que en su momento desarrolló productos para GBA y DS, principalmente en forma de cartuchos de GBA, y un buen dia decidió reutilizar los cartuchos de GBA que tenia, de la serie NEO2, y construir a su alrededor adaptadores para consolas grandes, SNES, MD, N64... y algunas cosas mas. Yo tuve la suerte de entrar en el betatest del producto y me enviaron uno gratuito con 2 cartuchos NEO2, uno de 512Mbit solo flash, y otro de 256Mbit flash + 128mbit RAM + SD. Tienes que tener flasheado todo el conjunto para usar uno u otro y para cargar de la flash o el menu que usa la SD.
Mi cartucho 256 tiene bloques corruptos de flash, y el de 512 creo que tampoco está bien del todo.
La cuestion es que con carga de flash basicamente puedes convertir el NEO Myth 64 en el equivalente a un repro, que carga una sola rom directamente sin menú, y eso deja usar cartuchos de trucos como si fuera un original.

Además, con carga flash, la memoria esta dividida en 2 bloques seleccionables mediante un interruptor fisico. Puedes tener una ROM de hasta 64MB o 2 de 256 maximo cada una. Creo que si cargas una rom mas grande de 256 ya no te deja poner otra aunque sea mas pequeña y tecnicamente haya espacio libre.
Con esto logré en su momento hacer copia de las partidas de mis cartuchos que no podía copiar a un CPak con su save manager y pasando luego las partidas al PC con un DexDrive o similar (Adaptoid).
Por ejemplo, copié mi Majora's Mask de la siguiente manera. flasheé dos copias de la misma ROM de MM de mi cartucho original a los dos bloques del NEO2. En uno de los bloques seleccioné la opcion de que el NEO Myth emulase la FlashRAM para partidas del cartucho. En el otro bloque seleccioné que usase el chip de guardado presente en el cartucho de carga de la ranura de detrás (Si, el NEOMyth no lleva CIC, hay que usar un cartucho original, y acepta cualquiera porque detecta el tipo de CIC leyendo el bootcode de la ROM). Lo que hice a continuacion fue cargar el juego con el bloque programado para leer la partida desde el cartucho original, cargué mi partida, y una vez dentro del juego, cambié el interruptor y usé la cancion del tiempo para regresar al primer dia y que el juego guarde la partida en la Flash. La flash a la que guardó, en este caso, fue la que el NEOMyth emulaba.
Ahora. usando la aplicacion de PC, dumpeé la partida desde el NEO myth y listo...
Todo est fue antes del UltraSave... que aun no tengo tampoco.

Esto si que fue una motiva alucinogena... una gitanada del carajo, enganchando cosas con cosas de maneras raras.

Algun día tendré que contar cómo areglé mi Action Replay al que en su dia se le corrompió la flash y no arrancaba, usando el 64drive, una rom hackeada del AR, un Passport3 a modo de conector T (antes de fabricarme el actual) y ya no me acuerdo que más.
Lo puse en AssemblerGames en su momento pero nadie respondió.

EDITO: aqui está https://assemblergames.com/threads/how- ... ing.50882/

@radorn
Muy interesante lo que comentas , pon esas capturas generadas directamente por la consola o el enlace en el hilo porque me gustaría verlas

Claro, emuladores a bajo nivel tienes el CEN64 pero es un horror hacerlo funcionar porque no se dan apenas explicaciones ni tampoco se dan ni siquiera todos los archivos necesarios, pone un exe y a buscarse la vida.

Lo primero de CEN64 es que no tiene interfaz, si quieres lanzar un juego tienes que hacerlo por la consola de comandos o bien montar un bat, tampoco se puede configurar un mando, tiene un input que podrías asignar a un joytokey o similar, pero la idea de CEN64 es más para desarrollo, aunque se puede jugar con una buena maquina con una emulación muy muy cercana a la maquina original.

Lo segundo es que necesitas conseguir de algún lado pifdata.bin para ntsc, pifdatapal.bin para pal, estos archivos no se proporcionan porque son propietarios, necesitas OpenAL32.dll.

Si tiras al bat por comodidad:

cen64 -multithread pifdata.bin %1 test.z64

Donde test.z64 sería la rom, creo que no acepta otro tipo de roms, tienen que ser z64.

--

El mupen 64 viene en el retroarch, pero no me gusta demasiado eso, también lo he probado en android, aunque el bueno era el n64oid, ese corre hasta bien en mi Xperia play, mientras que el mupen y los cientos de clones que tiene iban justitos en una Nexus 7 cuando los probe, hablo de memoria, de hace tiempo, ahora no sé como marcha la cosa en Android.

@radorn https://mega.nz/#F!n40zlaBR!VGK0NeVhKI_cwG--GEMXNQ

Es la misma carpeta de hace unos dias, y le he añadido las capturas de framebuffer por action replay y un par de ROMs de video mas que se me habian escapado la vez anterior.

Tambien he puesto mi partida terminada del Body Harvest.

@radorn
Perdona por responder tarde, gracias por las capturas

Según veo algunas resoluciones coinciden con lo que saca el plugin (320x237), otras no, aunque los números son muy similares.

Por ejemplo he intentado capturar el frame exacto que conseguiste en Banjo Kazooie en versión PAL, el emu a la izquierda, la imagen original a la derecha y parece que el angrylion recrea muy bien a la consola.


Sin embargo hay 1 pixel de diferencia, la original es 292x215 mientras la emulada 292x216 y luego mirando más a fondo, la del angrylion parece estirada, porque repite unas cuantas lineas.


Así que bueno en principio parece fiable pero con algunos errores.
--

Por otro lado ya se ha conseguido en la scene poder poner poligonos texturizados, con z-buffer y goraud sin usar las librerías oficiales

Cuando limpien y liberen el código podré implementarlo para añadir las rotaciones por hardware de sprites en libdragon y hacer algunos ejemplos con polígonos mientras montan un microcódigo en el RSP para poder empezar a trabajar en 3D más fácilmente.