Hilo de detalles y curiosidades de N64

EMaDeLoC escribió: @Señor Ventura No existe "escala de grises" como textura en la N64, sino Intesidad o Intensidad con Alfa. Esta intensidad se refiere al color del triángulo o polígono. Si el triángulo es blanco, el valor 255 será el blanco y el valor 0 será el negro, siendo los valores intermedios una escala de grises. Pero si el triángulo es verde, 255 será el verde puro, 0 el negro y los valores intermedios los pasos de este verde al negro. Y así con otros colores que se pinte como rojo, azul, morado, naranja, etc, y supongo que también si cada vertice es de un color y se hace un degradado.
En cierta forma vendría a ser la "luminosidad", pero luminosidad es erroneo y confuso. Si el triángulo es de color azul oscuro, el valor 255 no va a dar un azul luminoso, solo el mismo azul oscuro.

¿Esto afecta a todo el polígonos homogéneamente?, o puedes variar el grado del color con mas precisión (estaría genial por pixel, pero me da que no va a ser así).



edit: Ah, ¿entonces si?, que confundido estoy...

@Señor Ventura Puedes pintar los vertices del triángulo o polígono de colores distintos, el RCP (y cualquier GPU) pinta la transición de colores entre distintos vertices. Luego la textura aplica la intensidad de cada color según donde caiga el pixel en dicho polígono.
Creo que, en el ejemplo que he puesto, en la caja de la izquierda, han hecho que los vertices de arriba sean un poco más oscuros que los de abajo, lo que hace un efecto de sombra, pero la textura sigue siendo de intensidad y los vertices color marrón.
Un ejemplo práctico sería una textura tipo hierba, y en el polígono pones un lado verde y otro marrón claro, y parece que hay una transición entre tierra y hierba.

@EMaDeLoC
Está claro que aparte de configurar la textura en CC, programa como actua, parece como que pinta los vértices en una escala de grises en tiempo real como si fuera iluminación, y dependiendo del grado de gris pinta una máscara de un patrón o otro, está muy bien pensado, lo otro es el "bump-mapping" que ya se a mostrado por aquí.
De todas maneras,tanto lo de Kaze, el "bump" y lo que yo he mostrado , todo usa 2 cycles, y 2 texturas,aunque lo de Kaze sea en "diferido" y no mezcle las dos en CC, al final pinta una textura y luego elimina partes con una máscara que es otra textura.

Salud.

SuperPadLand escribió:@radorn hola que es NTSC-M?

NTSC-M un nombre semi-técnico del NTSC original. la M viene por el "system M", la designación internacional que se le dió al sistema de TV en blanco y negro original Americano al que luego se le añadió el color NTSC retrocompatible.
NTSC-J en jerga de señal de video, es la designación informal que se le da a la variante Japonesa de NTSC, que principalemente tiene un nivel de señal para representar el negro diferente al NTSC-M.
Las consolas de los 90, mas allá de que alguien me enseñe una que no (y no digo que no la haya), todas generaban una señal NTSC-J en vez de NTSC-M. Un decodificador ajustado para los niveles de NTSC-M, al recibir una señal NTSC-J, mostrará una imagen mas oscura y, si el receptor es digital, además, se perderán los detalles finos en zonas oscuras al reducirse esa cola de grises a negro.

En estos enlaces lo explico mas detalladamente:
1: Diferencias NTSC-M y NTSC-J
2: Un poco de lo mismo con incapié en captura digital
3: ejemplo ilustrativo

BONUS - Diferencias regionales N64

@radorn ah vale no sabía que se llamaba así, pero entiendo que te refieres a lo que yo llamaría como NTSC-U de USA.

@SuperPadLand NTSC-U es mas una designación de región para videojuegos, entiendo que primeramente implementada por Sony para la PS1 (alguien sabe si otros lo hicieron antes?). Pero si hablamos de normas de video, NTSC-M sería un nombre mas correcto. Entiendo que no es un término habitual para muchos, pero bueno, yo hablo así y si alguien pregunta se lo explico. Así se aprende

Con esta demo la N64 va al límite .


Descripción:

@doblete ¿por qué se supone que me tiene que impresionar ese pase de diapositivas con vsync galopante en algunos tramos?

@Sexy MotherFucker La gracia es darle a la N64 un trabajo típico de los servidores de gráficos de Silicon Graphics de donde viene parte de su diseño principal.
Vamos, como poner al nieto a labrar el campo del abuelo. Tiene gracia, pero no futuro práctico.

Sexy MotherFucker escribió:@doblete ¿por qué se supone que me tiene que impresionar ese pase de diapositivas con vsync galopante en algunos tramos?

Lo explica en la descripción, pero vamos que la sorpresa es que lo mueva, como el Doom de Megadrive a 0,5fps. Es un techo entiendo, a partir de ahí podrás rebajar y mirar otras aplicaciones.

EMaDeLoC escribió:Vamos, como poner al nieto a labrar el campo del abuelo. Tiene gracia, pero no futuro práctico.

Ah vale, ya lo pillo:



Para que se crea importante.

Señor Ventura verá en esto un potencial sin desarrollar en los videojuegos, el cual nos perdimos.

Nintendo 64; la FollaDreamcases.

Pues veo en eso una máquina con potencia para hacer todo eso incluso mas rápido de lo que esperaba, por lo que celebro que hay cpu para lo que quieras en un entorno de juego normal.

Con potencia para hacer demos a diapositivas, sí; sin colisiones, IAs, etc. Y confundirlo con algo remotamente cercano a la siguiente generación, o extrapolable a juego real.

Pero tío, que me estás poniendo un vídeo de los mundos de yupi literalmente tras decir algo que no es lo que esperabas como para ponérmelo

Para ti esta demo es despreciable porque no renderiza lo que renderizaban estaciones de trabajo en tiempo real y a 60 frames por segundo, lo cual si que compete que te pongas ese vídeo a ti mismo

Señor Ventura escribió:Pues veo en eso una máquina con potencia para hacer todo eso incluso mas rápido de lo que esperaba, por lo que celebro que hay cpu para lo que quieras en un entorno de juego normal.

No estoy entendiendo bien lo que tratas de decir, pero su creador dice esto:

As far as practical use-case go... well not much tbh.
Even the basic loop for the raymarcher without actually checking a SDF is slow.
So the only thing i may look into in the future is to make an optimized skybox-only version.

Como testeo de máximos de algo "imposible" se mueve más que bien, porque saca varios fps. Como ya dije, el Doom en MD iba a 0,5 y es un logro que lo mueva al menos xD

@SuperPAdLand Pues justo eso, que esperaba que renderizara esas imágenes todavía mas lento de lo que lo hace. No es poca cosa lo que se ve ahí.

Sexy MotherFucker escribió:@doblete ¿por qué se supone que me tiene que impresionar ese pase de diapositivas con vsync galopante en algunos tramos?

No tiene que impresionar, simplemente es para la curiosidad.

Acerca de la demo anterior del Ray-Marching, el autor da una explicación en uno de los comentarios:

Usually you render objects with triangles, which get rasterized into pixels.
Here you do it the other way around checking for each pixel on screen if an objects is there.

For that you shoot a ray into the scene per pixel from the camera position.
Each ray then steps though the scene checking if it hits something.
If it does, it also check the direction the surface points at (normal vector) and can then apply shading.
In this case some color effects or fancy texturing.

The special part about raymarching compared to e.g. ray-tracing is the way objects are described.
Instead of meshes out of triangles, objects are just mathematical functions telling you how close you are to them (called SDFs).
Or in other words, if i give it a point in 3D space, it tells me how far away the closest point on the surface is.
So the raymarcher can then stop if the distance becomes small enough for me to consider it a hit.
Note that it has no idea where objects are, or even the direction, it can only check the distance.

A sphere for example can be described as:
"sqrt(x*x + y*y + z*z) - radius"
Where xyz are the position of the ray.

The special thing that makes raymarching "fast" is that instead of stepping the ray at small fixed steps,
you can always step by the amount the SDF returned.
Since you know that that distance is the closest thing to possibly hit.

But on N64 as you can imagine it is painfully slow, since there are many (looped) steps i have to do per pixel.

Lo que se está renderizando no es una malla de polígonos generada a partir de vértices en el espacio, sino formas geométricas descritas por fórmulas matemáticas. Por eso las formas son tan simples. A cambio la superficies son perfectamente curvas. Fijaos que no se notan segmentos en las aristas y que la iluminación es por píxel.

Pero la principal peculiaridad de la demo es que en lugar de montar la escena en la parte del espacio que puede ver la cámara y empezar a dibujar y descartar las formas que hay delante y detrás para dibujar la imagen final, lo que hace es lanzar un rayo desde la cámara por cada píxel de la pantalla y comprobar si choca con algo para poder dibujarlo. Cuando el rayo choca con la superficie luego tiene en cuenta la normal de esa superficie para aplicar texturas y otros efectos.

Se supone que esta forma de renderizado es rápida, pero en Nintendo 64 es lentísima supongo que por los problemas de fillrate que tiene la consola y que todo se hace secuencialmente y no es posible hacerlo en paralelo. Quizás alguien lo pueda explicar mejor.

Yeah i tried skip some of the calculations for repetition, but the issue i was running into was that it ironically increased cost.
One main difference to modern hardware is that the CPU/RSP are single core processors.
So each pixel/ray happens in sequence (well the RSP is vectorized, so some calculations can do 2 rays at once).
But adding one instruction per ray means i pay it per-pixel, whereas modern hardware / GPUs can offset the cost since you only pay it once per batch as they actually run in parallel.

Esto no se puede aplicar en juegos, pero el autor comenta que sí que se puede sacar partido a los skyboxes. Por lo que entiendo de la descripción son como cubemaps de 1024x512 píxeles de resolución. Supongo que RGBA16, como las texturas de la demo, pero eso no lo especifica.
Por comparar, el skybox de los Zeldas está formado por medio cubo troceado en cuadrados para acoplar 93 texturas de 8 bits de profundidad de coloar de 32x32 píxeles de tamaño. Estas texturas se acoplan para formar una imagen de 512x192 píxeles.

Yo creo que no es para nada así, el ray-maching es mucho más exigente en figuras que no sean esferas o cubos donde el raytracing es más rápido, está claro que esto para un juego como que no, pero no me parece banal, a lo mejor abre camino a algo a medio camino y potente para el estándar de N64.

Salud.

Curiosidades Mario Kart 64:

Lo de aumentar la velocidad por encima de la del jugador cuando se quedaban rezagados es lo mas asqueroso que tenían los juegos de carreras antes. Dan ganas de apagar la consola.

@Señor Ventura de antes y de ahora, que es imposible despegarte de ningún rival en los últimos Mario Kart.

Ya puedes hacer la carrera perfecta usando 50 setas turbo, que en cuanto te lancen la concha azul, eres rebasado al momento por 5-6 corredores fácilmente. No se despegan de ti ni aunque hagas tiempos de speed run.

Es una de las cosas que más odio en juegos de carreras.

A ver si entre tanto técnico podéis echarle un ojo a porqué Indiana Jones elimina un nivel sin el expansion pak. Dejo aquí el comentario donde lo informo: hilo_juego-del-mes-5agen-octubre-indiana-jones-and-the-infernal-machine-n64_2473785_s2300#p1756273313

Y aquí el vídeo donde lo vi:

@SuperPadLand No tenía ni idea de que Indy se saltaba un nivel sin el EP.
Supongo que será demasiado grande en algo... texturas, geometría, elementos interactivos... ni idea. No recuerdo si llegué a pasarme el juego ahora mismo, pero creo que si que jugué ese nivel con los vagones de carga sobre railes.
Jo, mi memoria ultimamente es una anténtica porquería. Que asco da ser viejo...

Por lo que veo en los videos, es posible que sea que el nivel se cargue entero en RAM y sea muy grande para la memoria de stock.

Salud.

No lo he jugado mucho, pero ya que este juego hacía streaming, parece que la velocidad de – streaming de la ROM+descompresión (sumada a la no linealidad del nivel) - es más lenta que la velocidad de la vagoneta entre puntos de carga.

Con la expansión podrían tener más secciones en RAM o quizás el nivel entero.

Otro vídeo muy técnico de Kaze explicando como funciona el mezclador de sonido de SM64, y de casi cualquier otro juego de N64:

Vengo con otro what if de esos raros míos, pero como de potable hubiese sido un Hitman 64 en el año 2000-2001 que fue cuando salió el de PC? Estoy asumiendo los 320x240 (o menos internamente) y los 15-20fps más niebla en fases de exteriores.

Así es como se veía en la todopoderosa vodoo de 4MB del 96:

Yo lo veo bastante complicado, lo más parecido en N64 podría ser el Duke Nukem Zero hour, no he jugado al juego, para saber como son sus niveles, pero si son como el video, tal vez algo con la calidad del Duke, podría ser viable.

Salud.

dirtymagic escribió:Yo lo veo bastante complicado, lo más parecido en N64 podría ser el Duke Nukem Zero hour, no he jugado al juego, para saber como son sus niveles, pero si son como el video, tal vez algo con la calidad del Duke, podría ser viable.

Salud.

Yo lo probé en PC, pero con todo al máximo y no con generación expontanea de edificios y niebla, las calles están vacias de hecho ahí vi un peatón suelto y yo no recuerdo que hubiese. El juego no tiene mucho más que lo que ves (hasta donde yo jugué que fue poco porque iba fatal el control en PC moderno y vi vídeos para saber que me perdía si seguía la saga), cuando lo jugué yo pensé que ni de coña, pero al ver que era del 2000 pensé que eso tenía que moverse en PC del 96-97 aunque fuera mal y si se mueve ahí es factible una versión en N64 con su niebla y tal y en ese vídeo ya se ve que usan niebla, en N64 podría ser más cercana si eso y con menos elementos decorativos en la calle (arboles, bancos, etc) aunque Perfect Dak tenía alguna fase urbana muy detallada.

En Hitman la cámara corta al personaje por la mitad y no me suena que nunca se vea completo así que es algo de geometría que ahorras, lo que no recuerdo es el maximo de enemigos que podían juntarse aunque siempre pueden recudirse y como el juego se compone de encargos de asesinatos que cada una tiene su propia historia interna, pero independiente de las otras también puede omitirse alguna misión que fuese demasiado compleja para N64 si se estima, solo hay un par de misiones que son imprescindibles porque te cuentan el origen del personaje y es lo que realmente importa para el resto de secuelas.

@SuperPadLand Adaptado , seguramente todo es posible, a lo mejor algún detalle mejor, posiblemente el framerate bloqueado a 20 fps o a 30 fps, pero creo que con el detalle que hay en los escenarios, a la mínima que salgan enemigos bajaría.
Luego ya si quieres un port con una consola de la época, a 60 fps, 480i , escenarios gigantes sin niebla y con vida propia, sólo podría la PSX

Salud.

dirtymagic escribió:Luego ya si quieres un port con una consola de la época, a 60 fps, 480i , escenarios gigantes sin niebla y con vida propia, sólo podría la PSX

Ein?

@dirtymagic mejor Saturn que tiene la panorámica 704x480 😎

@Señor Ventura
¿no te has enterado de que la PSX es el hardware más potente creado en los 90?, no hay nada que no haya podido hacer comercialmente, y si no han podido es por la falta de recursos de esa época, pero ahora,lo que le pidas, es más, seguramente que se incluyese el hardware de PSX en PS2, no era por compatibilidad, el GTE es el que mueve realmente la geometría de juegos de PS2, el EE sólo se usa para descomprimir el MPEG2 de los DVD- Video y por supuesto el aumento de memoria que era un cuello de botella para sacar todo el rendimiento del GTE.

Salud.

@Señor Ventura que la gente sigue viendo fotograma de PS1 pixelado con líneas en las uniones de los polígonos y sin un puñetera textura recta y sigue diciendo que es mejor que la calidad de N64 ya sea por 480i o por 60fps sin texturizar o eliminando IA y geometría, etc. O que PS1 mueve cosas más grandes y lejanas con algo de lo anterior porque une varías instancias 3D con pasillos para cargarlas o te mete niebla en mitad del suelo para ocultar que no renderiza nada ahí y si caea ahí te mueres (fantástica adaptación de Gameplay a sus limitaciones que conste).

dirtymagic escribió:@Señor Ventura
¿no te has enterado de que la PSX es el hardware más potente creado en los 90?, no hay nada que no haya podido hacer comercialmente, y si no han podido es por la falta de recursos de esa época, pero ahora,lo que le pidas, es más, seguramente que se incluyese el hardware de PSX en PS2, no era por compatibilidad, el GTE es el que mueve realmente la geometría de juegos de PS2, el EE sólo se usa para descomprimir el MPEG2 de los DVD- Video y por supuesto el aumento de memoria que era un cuello de botella para sacar todo el rendimiento del GTE.
Salud.

Por supuesto! Y la tierra no es esférica, tiene forma de disco y está sostenido por cuatro elefantes que se apoyan sobre una tortuga gigante que surca el espacio 😁.

bluedark escribió:

dirtymagic escribió:@Señor Ventura
¿no te has enterado de que la PSX es el hardware más potente creado en los 90?, no hay nada que no haya podido hacer comercialmente, y si no han podido es por la falta de recursos de esa época, pero ahora,lo que le pidas, es más, seguramente que se incluyese el hardware de PSX en PS2, no era por compatibilidad, el GTE es el que mueve realmente la geometría de juegos de PS2, el EE sólo se usa para descomprimir el MPEG2 de los DVD- Video y por supuesto el aumento de memoria que era un cuello de botella para sacar todo el rendimiento del GTE.
Salud.

Por supuesto! Y la tierra no es esférica, tiene forma de disco y está sostenido por cuatro elefantes que se apoyan sobre una tortuga gigante que surca el espacio 😁.

A veces desearía vivir en ese universo para que viniera la muerte y me llevase de viaje con ella antes de aguantar a más ciegos.

dirtymagic escribió:@Señor Ventura
¿no te has enterado de que la PSX es el hardware más potente creado en los 90?, no hay nada que no haya podido hacer comercialmente, y si no han podido es por la falta de recursos de esa época, pero ahora,lo que le pidas, es más, seguramente que se incluyese el hardware de PSX en PS2, no era por compatibilidad, el GTE es el que mueve realmente la geometría de juegos de PS2, el EE sólo se usa para descomprimir el MPEG2 de los DVD- Video y por supuesto el aumento de memoria que era un cuello de botella para sacar todo el rendimiento del GTE.

Salud.

A ver, cuando las exageraciones y las ironías pasan desapercibidas con ciertos relatos, es que no son suficientes xD

A mi me ha resultado creíble con la narrativa oficial

Señor Ventura escribió:

dirtymagic escribió:@Señor Ventura
¿no te has enterado de que la PSX es el hardware más potente creado en los 90?, no hay nada que no haya podido hacer comercialmente, y si no han podido es por la falta de recursos de esa época, pero ahora,lo que le pidas, es más, seguramente que se incluyese el hardware de PSX en PS2, no era por compatibilidad, el GTE es el que mueve realmente la geometría de juegos de PS2, el EE sólo se usa para descomprimir el MPEG2 de los DVD- Video y por supuesto el aumento de memoria que era un cuello de botella para sacar todo el rendimiento del GTE.

Salud.

A ver, cuando las exageraciones y las ironías pasan desapercibidas con ciertos relatos, es que no son suficientes xD

A mi me ha resultado creíble con la narrativa oficial

La culpa fue mía por darle alimento al troll, pero la verdad es que tenía cierta esperanza de que esta vez fuera alguien meramente desinformado. Volveré a mi estrategia antigua de ignorar directamente a cuentas nuevas o con pocos mensajes que abran hilos o lancen determinados tipos de opiniones ya de inicio porque:


Al final es que incluso le das información útil para ahorrales explorarse y filtrar la porquería de catálogos que a ti te llevó años y ni las gracias te dan, sólo te rompen la moral y no aportan nada útil.

Estais hablando demasiado de la Playstation en este hilo ultimamente... ¿eso no sería Offtopic? xD

Es broma shurmanos, no os mosqueeis.

Un saludo.

No sé si recordáis hace tiempo que comenté que una N64 PAL con roms NTSC causa stuttering.

Hoy andaba trasteando y he anotado los resultados que da una N64 PAL FRA en un OSSC:
PAL: 49,88hz, 49.94hz, 49,96hz, 49.97hz, 50.00hz
NTSC: 60.99hz, 61.03hz

Y parece que he dado con una solución, en gbatemp hay un hilo , que trata sobre lo mismo y ya han diseñado un script para auto parchear ROMs, o inyectar ciertos cambios en VI.

Dentro del hilo, la respuesta que me interesa es la 14, así que bueno, voy a probar esos scripts, parchear alguna ROM y probarla, a ver si el stuttering desaparece, y comento de vuelta, si los ficheros son buenos, los personalizo y subo en un único zip para tenerlos a mano aquí.

Salvo que alguien tenga el mismo problema, se me adelante y quiera probar.

@Conker64
¿El stuttering sólo se nota en paneles LCD o también sería apreciable jugando en CRT?
Tenía entendido que la diferencia de timings hacía que las roms NTSC en consola PAL funcionasen ligeramente más rápidas y por tanto el sonido se escuchaba un pelín más agudo, pero no recuerdo nada de stuttering. En mi experiencia personal la verdad es que no he notado ni una cosa ni la otra.

Y ahora con el Analog 3D fuerza los timings NTSC a 60 Hz y los juegos también funcionan a una velocidad diferente a la consola original. ¿Estos parches podrían hacer que funcionasen a la velocidad que tocan? Sobre todo que se note en los cronómetros.

@Conker64 ¿Puedes decirme cómo ejecutas roms NTSC en una N64 PAL?

¿Se ven en color o en blanco y negro? Lo digo porque hace mucho me negaron que los pudiera jugar en color en mi N64 PAL usando roms NTSC a través de mi copión V64 JR. Y usando un simple cable de audio video pues mi N64 no contaba con salida RGB.

Gracias por adelantado y un saludo.

@Sogun
Pues solo la he usado en pantallas planas, así que recuerde:
> Philips 32" LCD 2009 (bien, sin stuttering)
> Bravia 32" 2007 (mal)
> Bravia 40" 2015 (mal)
> Philips Ambilight 40" 2020 (mal)
> Samsung 24" 2022 (mal)
> Toshiba 32" 2022 (mal)

En blanco y negro solo la vi al usar un conversor S-Video a Scart en la Bravia 2015, lo cual me hizo vender la consola original que usaba con S-Video y pillar una con mod RGB.

Los parches habrá que probarlos, yo de momento solo los he bajado, si te ves con ganas pásate por el hilo, hay varios descargables, el usuario original ha montado 3 script, y otro usuario después ha puesto otro que parchea todas las roms que arrastres a esa carpeta.

@Seideraco
Pues uso un antiguo ED2.5.

Siempre se han visto en color (salvo por lo que comento arriba), sea compuesto, S-Video o RGB en pantallas planas a 50 o 60hz, cuando conseguí el ED ya no tenía CRT, así que no te puede confirmar, pero vamos que si los jugaste así en su día bien por ti, salvo por las optimizaciones que hace Rare y algún otro equipo europeo es la mejor forma.

Tenía un colega que la compró de importación, pero era NTSC con juegos NTSC en panel europeo, no es lo mismo, pero también le iba bien.

@Conker64 Gracias, era justo lo que necesitaba confirmar.

Pues sí, jugaba en mi N64 PAL sin modificar, con el V64JR a juegos americanos y japoneses NTSC. Y en color y sin ningún problema.

Era un copíon para N64,un cartucho con 256 MB donde cargabas la ROM desde el PC usando un cable paralelo grandote y luego lo metías en la N64 y a jugar. Mantenía la ROM en memoria usando pilas o conectándolo a la corriente.

No recuerdo tener problemas para ejecutar ningún juego. Iban todos. Tambien tenía el Expansion Pak de 4 MB y funcionaba todo perfectamente.

Gracias y un saludo.

Pues yo tenía una Sanyo de 21" con euroconector comprada en 1991 y la Sega Saturn y la Nintendo 64 los juegos NTSC se veían en blanco y negro con el ED64, los de Saturn los parcheaba a Pal con un programa, hasta que me compre un cable RGB y el mod 50/60hz y entonces no hacía falta parchear los NTSC, la N64 hasta que un compi del curro me dio una Philips de 14" de los 2000´s que soporta NTSC por compuesto, no podía jugar en color, la Sanyo murió hace un par de años, la philips es la única CRT que tengo.
Así que depende de la TV.

Salud.

Conker64 escribió:No sé si recordáis hace tiempo que comenté que una N64 PAL con roms NTSC causa stuttering.

Hoy andaba trasteando y he anotado los resultados que da una N64 PAL FRA en un OSSC:
PAL: 49,88hz, 49.94hz, 49,96hz, 49.97hz, 50.00hz
NTSC: 60.99hz, 61.03hz

Y parece que he dado con una solución, en gbatemp hay un hilo , que trata sobre lo mismo y ya han diseñado un script para auto parchear ROMs, o inyectar ciertos cambios en VI.

Dentro del hilo, la respuesta que me interesa es la 14, así que bueno, voy a probar esos scripts, parchear alguna ROM y probarla, a ver si el stuttering desaparece, y comento de vuelta, si los ficheros son buenos, los personalizo y subo en un único zip para tenerlos a mano aquí.

Salvo que alguien tenga el mismo problema, se me adelante y quiera probar.

Yo jugando no noté demasiado problema, pero sí que cuando quise usar la capturadora (en aquel entonces chinorra) el vídeo que me grababa se congelaba cada pocos segundos y supuse que era porque los hz no eran exactos. Lo de los parches estaría bien aunque me va a dar toda la pereza del mundo si tengo que parchear uno a uno

Seideraco escribió:@Conker64 ¿Puedes decirme cómo ejecutas roms NTSC en una N64 PAL?

¿Se ven en color o en blanco y negro? Lo digo porque hace mucho me negaron que los pudiera jugar en color en mi N64 PAL usando roms NTSC a través de mi copión V64 JR. Y usando un simple cable de audio video pues mi N64 no contaba con salida RGB.

Gracias por adelantado y un saludo.

Hola Seideraco. Veo que aún sigues escocido por el tema del PAL60.

Ya dije que la cosa podía depender del televisor, pero no siempre se cumple. Por eso en los juegos que admitian 50 o 60Hz a partir de Dreamcast había una opción al inicio y te preguntaba si mantenía la configuración o no. Por ejemplo, Daytona USA.

Todavía a estás alturas no has podido rebatirme el vídeo:


Por cierto, es de muy mala educación mentar una discusión que has tenido con alguien y no mencionarlo. Pero tranquilo, de ti no me sorprende.

@EMaDeLoC que se discute? Que N64 PAL no puede lanzar juegos NTSC a 60hz?