Hilo de detalles y curiosidades de N64

Responder
1…76, 77, 78, 79, 80
@SuperPadLand Tal y como lo ha dicho @Seideraco parece eso.
No, se discute que los televisores aceptan PAL60 de buenas a primeras por vídeo compuesto, porque si pones un juego NTSC en una N64 PAL, la señal de compuesto es PAL60 (o PAL61).
EMaDeLoC escribió:@SuperPadLand Tal y como lo ha dicho @Seideraco parece eso.
No, se discute que los televisores aceptan PAL60 de buenas a primeras por vídeo compuesto, porque si pones un juego NTSC en una N64 PAL, la señal de compuesto es PAL60 (o PAL61).


Es que lo tengo en ignorados así que me faltan trozos de conversación, pero sobre ese tema yo probé el fullset con flashcard NTSCU, NTSCJ y algún PAL con cable compuesto en dos CRT que no aceptan señal NTSC sólo PAL50 o 60hz (lo sé porque PS2 a 60hz sí se ve en blanco y negro porque no saca PAL60 como Dreamcast sino que a 60hz se pone en NTSC).
SuperPadLand escribió: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 [carcajad]


Es difícil de notarlo, el framerate de muchos juegos es tan variable que cuesta de ver cuando es un tirón por el vídeo o por el infame Vsync de doble buffer que suelen llevar los juegos, es una especie de parpadeo similar.

--
NTSC 2 PAL
Bueno he estado probando lo del Fix NTSC y funciona, solventa el stuttering en algunos juegos, pero no es totalmente compatible con todos.

Dejo una lista de los que no (no he probado todo el catálogo, solo una lista selecta):

Sin efecto:
- 007 - The World is Not Enough

Problemas de audio:
- 1080 Snowboarding
- Banjo Kazooie
- Conker's Bad Fur Day
- Fighter's Destiny
- Rayman 2 - The Great Escape
- Road Rash 64

No parchea:
- Blast Corps
- GoldenEye 007

Hay 3 tipos de efecto, en el primero hay juegos que no me queda claro si simplemente funcionan bien, ni mirando al cielo, o buscando habitaciones pequeñas consigo un giro estable, que perdure durante segundos sin tirón o salto.

Los problemas de audio son bastante fáciles de notar, o sonido entrecortado, o repite buffer de la última parte de un sample, por ejemplo 1080 no funciona bien en la canción del menú, pero si lo hace en la música dentro del juego, otros muestran entrecorte solo en algunas notas en concreto, otros suenan entrecortados en todo, música y fx.

Los que no parchean o dan problemas suelen ser la mayoría de Rare, en el caso de no parchear es porque el programa no encuentra ninguna coincidencia, por ejemplo al comprimir datos dentro de la ROM que también incluyen el setting de vídeo, se pueden parchear mediante cheats (desde la RAM), en el hilo a gbatemp que puse en la página atrás sale como.

--
He subido el script para tenerlo aquí a mano, consta de 3 archivos, el json que cambia la frecuencia de 61.03hz a 59.93hz o 60.04hz, me ha parecido el más acertado, hay otro a 59.44hz, pero a mismos efectos creo que es más preciso el otro.

Un .ps1, script powershell que automatiza, lee la carpeta raíz en busca de roms y si las encuentra parchea y mueve a una nueva carpeta llamada "patched".

Y el patcher.exe, que proviene de github , es el programa que escarba dentro de una ROM buscando y reemplazando las coincidencias que se le indiquen.

Descarga
https://mega.nz/file/UpoRTbbA#RSmJoazxjDvb0hRg57g9vQtNnVBszulmT7ofMmZyFN0

Como funciona
1) Descomprimir en una carpeta nueva
2) Copiar roms en formato z64 NTSC dentro de esa carpeta (las U, puede que alguna J), junto a los 3 archivos
3) Botón derecho a Patcher_automated, ejecutar con PowerShell

Si PowerShell pone un mensaje de que los scripts ajenos pueden dañar el PC bla bla, se puede salir y volver a entrar, tanto el código del ps1 como el de json son visibles abriéndolos con notepad, no contienen nada raro.

Al finalizar crea una carpeta patched con todas las roms en un solo click, y de ahí ya se copian al cartucho flash.

Como nota, esto no arregla los CRC, he visto como hacerlo pero bueno esto es versión preliminar, el cartucho flash puede que se queje de CRC incorrecto o algo, pero el juego arrancará.

Donde se nota más?
> En aquellos juegos que sean estables a 30fps, o los de 60.

Ej: Yoshi's Story, Worms, Mischief Makers, Mario 64, Mario Kart 64, WDC, etc etc son la noche y el día para el que sufra "stuttering".
Como algunos recordaréis, ya no tengo nada de todo esto (ni consolas ni CRTs), pero todo este tema del stuttering o renqueo o como quiera llamarse, no sucede en CRTs por mucho que uses juegos con timings NTSC en consola PAL, o viceversa. El único requisito es que la TV reconozca la codificación de color para que no se vea en blanco y negro.
Eso al menos con CRTs "directos", Si son con procesado digital para "scan doubling" o alguna otra pijada técnica, ya no garantizo nada. Y claro, si usas una TV moderna de panel, en vez de tubo catódico, te chupas todo ese procesamiento digital si o si, y normalmente con peor soporte para señales analógicas no normativas, como las que sacan las consolas clásicas.

Solo asomaba la cabeza por aqui para contribuir esto.

Entiendo por qué existen esos parcheados, para adaptar las ROMs a timings de video mas aceptables para una TV moderna, pero no deja de ser una ñapa para salir al paso. Yo preferiría no usarlo. Supongo que una consola como N64, que renderiza a framebuffer es menos sensible al "timing" de video comparado con lo que sería una máquina de generaciones anteriores que dibujaban directamente a pantalla, sin framebuffer mediando, donde un cambio del timing de video podría interferir de forma notoria en el juego. En el caso de N64, que afecte o no dependerá mucho de cómo esté programado el juego en cuestión, pero veo potencial para resultados indeseados. Es una ñapa guarra, no me gusta.
Imagino que para mi capturadora de vídeo serán útil todo este tema. Gracias!
@radorn
Si arregla el stuttering no veo problema en usarlo, yo de hecho no reemplazo los juegos originales, siempre tengo múltiples carpetas para experimentos, el ED hasta me toma la partida guardada de la rom original. (la del game pak, la del controller también al ser lo mismo)

El primer parche que probé toqueteaba 3 registros de VI, este solo 1.

Más allá de lo que comento del audio, en los juegos donde va bien no he visto nada raro, tengo intención de pasarme el Yoshi's Story, que con los tirones se hacía poco agradable, así que ya iré comentando.

Al final lo suyo sería tener un setup NTSC para juegos NTSC y lo mismo para PAL, es la maquina quisquillosa por excelencia.

@SuperPadLand
Prueba y comenta a ver que tal [360º]
@Conker64 cambiando un poco de tema, existe en algún luego en el modo debug la opción de desactivar la niebla para ver hasta donde está tapando y donde empieza a generarse el escenario?
Conker64 escribió:Al final lo suyo sería tener un setup NTSC para juegos NTSC y lo mismo para PAL, es la maquina quisquillosa por excelencia.

Bueno, con un CRT te evitas ese problema, así que no es tanto la máquina como las pantallas modernas en este caso.


SuperPadLand escribió:@Conker64 cambiando un poco de tema, existe en algún luego en el modo debug la opción de desactivar la niebla para ver hasta donde está tapando y donde empieza a generarse el escenario?

Sin duda tiene que haberlos, pero no sabría decirte cuales. Lo único en que te puedo ayudar es con estos enlaces:

https://tcrf.net/Category:Nintendo_64_games
https://tcrf.net/Category:Games_with_de ... _functions

No se si hay forma de cojetar automáticamente esas dos listas

Si hay algo conocido, probablemente lo encuentres ahí
@SuperPadLand
Sí, así uno que recuerde y del que tenga capturas es el Shadows of the Empire:
Imagen

Se ganan 8fps al activar la niebla, en realidad no me queda claro que la desactive del todo, parece que hay algo de ambiente a lo lejos, igual solo era ampliar distancia, pero bueno.

Es bastante común ver opciones de niebla, color, profundidad, modos en los debug, si te interesa sería mirar en thecuttingfloor que juegos tienen debug y cuales opciones de niebla.

Según veo tiene opción:
Fog:
If set to OFF, will disable the distance fog and make clipping visible in the distance.


Supongo que lo del gif es más toqueteando por aquí:
Fog Max:
Sets the maximum view distance by altering how far back the fog starts. 200 is the default, but can go as low as 10 and as high as 999.

Fog Thick:
Interestingly, this value seems to act in reverse, with higher numbers making the fog "thinner" and lower values making the fog "thicker". 996 is the default and highest value, but can go as low as 10. Very sensitive to changes.


(PD: se adelantó radorn)
Conker64 escribió:@SuperPadLand
Sí, así uno que recuerde y del que tenga capturas es el Shadows of the Empire:
Imagen

Se ganan 8fps al activar la niebla, en realidad no me queda claro que la desactive del todo, parece que hay algo de ambiente a lo lejos, igual solo era ampliar distancia, pero bueno.

Es bastante común ver opciones de niebla, color, profundidad, modos en los debug, si te interesa sería mirar en thecuttingfloor que juegos tienen debug y cuales opciones de niebla.

Según veo tiene opción:
Fog:
If set to OFF, will disable the distance fog and make clipping visible in the distance.


Supongo que lo del gif es más toqueteando por aquí:
Fog Max:
Sets the maximum view distance by altering how far back the fog starts. 200 is the default, but can go as low as 10 and as high as 999.

Fog Thick:
Interestingly, this value seems to act in reverse, with higher numbers making the fog "thinner" and lower values making the fog "thicker". 996 is the default and highest value, but can go as low as 10. Very sensitive to changes.


(PD: se adelantó radorn)


Ni me extraña que gane 8fps, pensaba que detrás de la niebla se cortaría el renderizado no que se vería tan lejos 😢
Conker64 escribió:Sí, así uno que recuerde y del que tenga capturas es el Shadows of the Empire:

Esa captura que pones demuestra dos "capas" de niebla. Una basada en cálculos de profundidad para colorear mas los píxels mas alejados con el color de niebla, y otra capa consistente en aplicar color gouraud a los vértices mas alejados. sería interesante ver la diferencia entre niebla Z pura y la normal con Z y gouraud.

La verdad es que para sus muchos fallos y su temprano lanzamiento, SW SotE tenía una ambientación espectacular, con sus grandes escenarios y esa niebla verdaderamente ambiental y no solo usada para limitar visibilidad para mejorar el rendimiento.
Niveles como Ord Mantell Junkyard, temidos por su dificultad (que no es tanta si mantienes la calma y practicas, llegándo a convertirse en una delicia), resultan super escénicos, con esa visión amplia a lo lejos, pero con esa neblina que lo hace mas convincente y presente.

SuperPadLand escribió:Ni me extraña que gane 8fps, pensaba que detrás de la niebla se cortaría el renderizado no que se vería tan lejos 😢

Discúlpame si me equivoco, pero creo que no lo interpretaste bien: CON niebla va a 20fps, y SIN niebla a 12fps.
Si te fijas, la niebla es ligera y ambiental hasta aproximadamente el primer cubículo/box que se ve a la izquierda, y a partir de ahí se convierte en un muro sólido. Ahí es donde se corta/clipea la geometria y no se renderiza lo que hay mas allá. Al quitar la niebla el juego renderiza todo.

Quizá haya o quizá no alguna forma de quitar la niebla sin desactivar el clipping por distancia, pero eso no es lo que vemos en el GIF que nos pone @Conker64

Otro aspecto molón del debug de SotE es que permite modificar el "aspect ratio" de 1.33 (4:3) a 1.77 (16:9) manualmente y así jugar en pantalla panorámica en consola, aunque cuesta afinar porque va con el analógico y tiendes a pasarte.
@radorn ah vale, ya me parecía raro porqué suponía que la niebla cuesta, pero al aumentar la distancia de dibujado pensé que igual se comía ese ahorro. 😅
@radorn
Si, no ha sido buena idea buscar desde el móvil las capturas que hice hace 11 años, ese gif sería jugueteando con la distancia de dibujado, con diferentes rendimientos por distancia, sin desactivar la niebla, por lo visto no tomé ninguna captura sin niebla.
No sé si te servirá pero en el Zelda OoT , la niebla se puede configurar para que aparezca a máximo de lejanía del jugador 360 m,si no la activas el límite del motor son 12,8 Km aunque de normal está a 4,6Km. ( lo pongo en unidades métricas, porque es lo que yo uso, pero usa sus propias unidades).Depende más de lo que dibujes que de la lejanía aunque supongo que estructuras muy cercanas entre ellas a mucha distancia tendrán Z-Fighting como me pasaba a mí en mi mapa de Midgar.

Salud.
Sería interesante cacharrear con esto y tener unos gifs como el de Conker para mostrar cada vez que salga el monotema de la niebla de que era un recurso gráfico que consumía para paliar el defecto del popping y no porque no pudiese renderizar a trancas el escenario a más distancia.
SuperPadLand escribió:cambiando un poco de tema, existe en algún luego en el modo debug la opción de desactivar la niebla para ver hasta donde está tapando y donde empieza a generarse el escenario?

Supongo que lo comentas por el tema de distancia de dibujado.

Si se trata de niebla con un máximo absoluto de color, es decir, que a partir de una distancia todo se vea blanco, negro, azul, etc, la distancia de dibujado siempre tiene que ser un poquito mayor que esa distancia, o al menos la misma pero ya es pillarse los dedos.
Por ejemplo, pon que hay un triángulo que no está ni perpendicular ni paralelo a cámara, sino que está inclinado. De forma que tiene un vertice más cerca de la cámara y los otros más lejos. Si la consola no lo dibuja hasta que está a menos distancia que la distancia máxima de niebla, habrá un popping, ya que aparecerá de golpe. Por lo tanto la consola ya tiene que estar dibujando o al menos procesando este triángulo más allá de la distancia máxima de la niebla para que, al acercarnos al triángulo, este surja de la niebla de forma progresiva, sin popping.

No sé si me he explicado bien. [+risas]

Edit: La IA me ha hecho este dibujo para más o menos pillar la idea:
Imagen


Esto provoca cierto desperdicio al dibujar un triángulo que va a acabar tapado por la niebla, pero asegura que no haya popping. Aunque creo que hay técnicas de z-buffer que permiten dibujar solo la parte de triángulo que se hace visible y ahorrarse el resto.

Esto también significa que la distancia real de dibujado es más lejana de lo que parece cuando hay niebla de este tipo, y que pensar que la distancia de dibujado llega "hasta donde hay mucha niebla" es equivocado. Por eso en juegos de PC quitar la niebla mejoraba el rendimiento, podias ver un poco más, pero el popping se hacía muy evidente.
SuperPadLand escribió:Sería interesante cacharrear con esto y tener unos gifs como el de Conker para mostrar cada vez que salga el monotema de la niebla de que era un recurso gráfico que consumía para paliar el defecto del popping y no porque no pudiese renderizar a trancas el escenario a más distancia.


El tema rendimiento sería algo así:
- A mayor distancia de dibujado menos rendimiento (el ejemplo del gif)
- Si en esa distancia hay además niebla peor (el ejemplo del gif)
- Si la distancia es corta, no hay niebla, y se ve el popping o el clipping: mayor rendimiento (lo que tu pedías y puede que puedas activar mediante algún debug)

A la niebla puedes darle parámetros de profundidad, como donde empieza a crear ambiente y cuantos pasos necesita para el color absoluto, puedes dejar un margen muy corto y usarla como Turok, ajustas la distancia a mitad y así no se ve el corte, o puedes darle muchos más pasos de profundidad y crear un ambiente sin perder distancia, como hace el Zelda.

A mi un caso que me pica la curiosidad es el Gex: Enter the Gecko


En PSX hay fondo, en N64 no, es como si al activar la niebla se hubiera comido todo lo que hay detrás, quiero creer que decidieron dejarlo así, y realmente no hay un fondo que es siempre tapado la misma. (donde puede existir formas ingeniosas de aplicar niebla solo a algunas superficies, color mask, distinto buffer, etc)

Lo curioso es que luego si hay mapas con fondo, pero no el de la primera fase o el hub principal, es un port raro la verdad, si usan un método de degradado por superficie, puede que incluso se estuvieran ahorrando espacio en el cartucho, las nubes de ese escenario no se ven particularmente bien, las del hub son bastante mejores con montañas.
@EMaDeLoC es por el tema del otro hilo básicamente, aquí ya lo hemos hablado varias veces y Conker ha explicado a fondo y analizado muchos juegos sobre el uso de niebla y otros recursos, pero al final parece que lo mejor son gifs, capturas o lo que sea que lo muestre claro y ya.

Concretamente en el otro hilo han puesto Bichos como ejemplo de que PS1 dibuja mucho más lejano que N64, esta versión tiene otros fallos, pero en concreto la distancia, al menos en el vídeo que compartieron, yo veo que es idéntica en ambas versiones, pero en N64 hay una neblina en la zona más lejana, en esa neblina se puede percibir los mismos elementos que en PS1 (hierba y montañas que creo que son 2D) es decir que se ve que lo renderiza igual, pero a mayores lo adorna con un poco de niebla. Intuyo que si se desactivase esta niebla incluso ganaría algo de rendimiento.

Subí una imagen allí que pongo aquí también para que se entienda:
Imagen
Conker64 escribió:En PSX hay fondo, en N64 no, es como si al activar la niebla se hubiera comido todo lo que hay detrás,

Supongo que es por coherencia. Si una niebla te tapa un arbol, no te va a dejar ver las montañas que hay detrás tampoco.

@SuperPadLand Imaginaba que era por eso. Lo dicho, para evitar que haya popping en mitad de la niebla, hay que dibujar por detrás del máximo si esta lo tiene. Si es ambiental y se ve el infinito, pues ya habría que hacer otras cosas, rediseñar, etc.

Lo que comentas de Bichos es correcto, las decoraciones en N64 faltan o aparecen de cerca. La distancia es igual que en PSX, pero con una neblina al final para dar mayor profundidad.
Conker64 escribió:En PSX hay fondo, en N64 no, es como si al activar la niebla se hubiera comido todo lo que hay detrás, quiero creer que decidieron dejarlo así, y realmente no hay un fondo que es siempre tapado la misma. (donde puede existir formas ingeniosas de aplicar niebla solo a algunas superficies, color mask, distinto buffer, etc)

Gex en ps1 no tiene niebla, lo que hace es que pasado un límite los polígonos pasan de ser opacos a transparentes en función del Gouraud, y oscureciendo los vertex haces que se vuelvan transparentes y se muestre el Skybox. Esto se hace en varios juegos como por ejemplo Ape Escape. La idea es que el Skybox tenga algún parecido con lo que estás renderizando y así se camufla algo. En Gex la distancia es tan corta que yo creo que hicieron un Skybox que pudiese funcionar de las dos maneras.

Con niebla no puedes mostrar Skybox (esto es con niebla para ocultar el popping. Si es niebla decorativa como el Zelda no habría problema) porque si muestras el Skybox, se verían por encima la forma de los polígonos pintados con el color de la niebla que están en el borde de ser descartados. A lo sumo puedes poner algún Sprite por encima de todo como se hace el Extreme-G con el sol.

@SuperPadLand
El motor de A Bug’s Life parece renderizar en 3 capas. El escenario normal, el escenario LOD y el otro para los detalles más finos, enemigos, etc…

En el primero y el segundo parecen renderizar a la misma distancia, la capa del detalle parece ser que la ps1 renderiza más lejos.
N64
Imagen
PS1
Imagen

La resolución de texturas en Nintendo 64 es 64x64, en Ps1 de 32x32.

En Ps1 hace una cosa muy rara. Por ejemplo guarda en VRAM 16 versiones de la textura del suelo con pequeños cambios en los colores, algunas agrupadas y otra por la mitad.
Imagen
En n64 hay también bastantes variaciones para el suelo pero parecen ser variaciones más notables.
Imagen

Supongo que todas esas versiones son para que el suele parezca menos repetitivo pero el caso es que en ps1 son muy similares y además de un contraste muy alto que al final genera más ruido que variedad.

Como comenté antes todas las versiones tienen un escenario en LOD. Aquí seleccionado en Blender el de n64.
Imagen
Aquí se muestra el LOD en el juego. Se nota cuando entra por el cambio de textura.
Imagen
El hecho de que hayan mantenido el LOD en n64 se me ocurre que pueden ser dos cosas:
-remanente de usar la versión de PS1 aunque sería un poco raro ya que solo tendrías que no renderizar esta y renderizar la otra más alejada
-una manera de ahorrarse recursos sin darles muchas vueltas. A la n64 le cabrea bastante tener que cambiar de texturas y ahí en el suelo de cerca se ven unos cuantos cambios. La versión de LOD la puede renderizar de una pasada sin hacer ningún cambio. Además utiliza una textura que ya está renderizando de cerca pero cogiendo solo un cuarto.

La versión de PS1 funciona a 512x240. La de N64 a 320x240.

Sobre el framerate, no tengo herramientas adecuadas.
--

Para lo de la niebla puedes descarte Mupen64Plus:
https://github.com/mupen64plus/mupen64plus-core/releases/tag/2.6.0

Lo arrancas una vez, y luego vas a tu carpeta de usuario “AppData\Roaming\Mupen64Plus” y abres el archivo mupen64plus.cfg con el Notepad. Ahí tienes una variable llamada “FogMethod”, la pones a 0, guardas y luego arranca cualquier juego (lo tienes que arrancar desde la consola).

Lo he probado con el ExtremeG y funciona, ahora si es fiable o no, eso ya no te puede decir porque muchos emuladores de n64 suelen inventarse casi toda una vez se llama al RSP.
Misscelan escribió:La resolución de texturas en Nintendo 64 es 64x64, en Ps1 de 32x32.

No hombre, no, te tienes que equivocar, no puede ser que la versión de N64 tuviese más resolución de texturas. La N64 solo tiene 4Kb de caché de texturas y la PS1 tiene 37megabaitos y por eso las texturas se ven en HD mientras en la N64 se ven borrosas. Que lo dice todo el mundo y debe ser verdad.

Imagen


Bromita aparte, Kaze ha sacado un vídeo sobre la Analogue 3D:



De lo que dice y me parece bueno incluirlo por la temática del hilo, es el rendimiento que consigue su mod de SM64, que en la original es bueno pero en la A3D desciende ya que la parte de estructura del RCP la han hecho funcional para los juegos conocidos, pero no para nada está pulida o fiel para juegos nuevos.
Es decir, que no es la mejor consola para jugar a juegos en el futuro, no al menos de momento.
@Misscelan
Sí, más bien me refería a las inconsistencias del port de N64, el hub principal y la primera fase no tienen cielo, mientras que la jungla sí, es decir usaron los 2 tipos de método para ocultar el clipping, en lugar de decantarse por uno u otro.

No he llegado a investigarlo porque llevo tiempo que ando muy liado, y solo saco para lo que puedo, pero me gustaría ver si por lo menos están los datos de textura de esos cielos, o los descartaron por completo para hacer hueco en el cartucho.

Luego está lo que comentaba EMaDeLoC, y que por cualquier motivo el equipo decidiera usar un efecto u otro, con el consecuente cambio.
3971 respuestas
Responder
1…76, 77, 78, 79, 80
Volver a Consolas clásicas