@EMaDeLoC Genial!
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
Estoy comparando con mis calculos, pero no me aclara que combinaciones exactas se corresponden.
Las cifras de tu OSSC dan 15.62khz H y 49.92hz V para PAL en PAL.
Yo tengo varios calculos que se aproximan:
Con consola PAL al intentar hacer los 50Hz, me sale que, con lineas de 794px salen 15.63492...kHz de horizontal, y con 795px, 15.61526...kHz. El primero varía +9.92Hz de PAL estandar, y el otro -9.73Hz. La segunda cifra parecería ser ligeramente mas cercana a tus resultados de 15.62kHz. Sin embargo, eso nos deja con 50.05 para campos de 312 lineas 49.89 para 313, con 49.67 para entrelazado o progresivo alternado (que tengo dudas de que pueda funcionar bien)
Por otro lado, volviendo a los 794px, y sus 15.63492...kHz, encontramos que el progresivo con 313lineas da 49.95, que se aproxima mucho a tus 49.92, con una proporcion similar entre V y H a tus resultados también.
Para consola NTSC, tus resultados y mis calculos salen mucho mas igualados, incluso con la divergencia de BK.
Tu OSSC da 15.72khz 59.79hz para Mario y Wave Race.
Mis calculos con lineas de 774px dan 15.724101kHz y 59.78745Hz con 240p de 263lineas (estandar + media linea de relleno). Mas redondo no se puede.
Tambien para BK, que es diferente, mis calculos coinciden:
Tu OSSC da 15.76khz 59.93hz, y yo, con lineas de 772px calculé 15.76483kHz y 59.94234Hz con 240p en campos de, nuevamente, 263 lineas.
Por desgracia, la tabla que calculé para PAL 60Hz la hice a partir de la premisa errónea de conseguri 60Hz exactos con el pixel clock de PAL, por tanto no vale para calcular los resultados de software NTSC en consola PAL. Para NTSC no hize ninguna tabla para 50Hz. Pero ahora que parece que sabemos posibles valores de NTSC usados en juegos reales, podría usar las mismas cifras para sacar resultados PAL y ver si también coinciden:
772 y 774 para la longitud de linea y campos de 263 lineas para 240p.
--------
Luego tenemos que cada consola puede variar ligeramente, y que el OSSC necesariamente redondea y tampoco sabemos hasta qué punto es fiable la cifra que da, como bien indicas.
Lo llamativo es la diferencia entre juegos de la misma region en una misma consola.
![[tomaaa]](/images/smilies/nuevos2/tomaa.gif "toma")
Parecería indicar lo que sugerí de que es el juego el que establece la temporización de video y que incluso hubo juegos que toquetearon la configuración oficial. Desde luego, uno de los ejemplos, BK, siendo de Rare, es un gran candidato para ponerse a trastear con esas cosas.
---------
Me llaman la atención también el patron mosaico de variaciones (aunque con tres "especímenes" es dificil de hacer muchas estadísticas xD). Por ejemplo, todos los PAL en PAL dieron el mismo resultado, pero de los NTSC en NTSC varía Banjo con algo mas de velocidad. De los NTSC en PAL, el que varía es Wave Race, y de PAL en NTSC, Mario.
Mario y Wave Race fueron de la primera generación de juegos, y esos suelen tener la característica común de que, en las primeras técnicas de importación (y copia), donde se limitaban a tomar prestado un CIC local para que el juego cargase, descubrieron algunos problemas:
Asi como en las hornadas posteriores los juegos empezaron a negarse a funcionar si el valor de OsTvType no era el esperado, dando pantalla negra o con pantallas de advertencia, la primera remesa de los mismos solia aceptar ejecutarse en la consola que no era (asumiendo que solucionaras lo del CIC), pero corriendo mal. Si bien se pueden usar bootemulators y los menús de los cartuchos nuevos para hacer que la consola suplante la región que la ROM espera, cambiando el valor en RAM, y, así, los juegos corren sin ningún problema (con excepciones mínimas de las que se ha hablado por aqui), estos primeros juegos si aceptaban correr como importaciones aunque no cambiases la region de la consola. Aceptan la region erronea, pero no lidian bien con ella, pues adaptan los buffers de audio mal, y se fastidia el sonido. Si quereis experimentar con ello, y el menú de vuestro cartucho lo permite, cargad juegos como Mario, PilotWings, Mario Kart, etc, usando ROMs de diferente región a la consola y diciendole al menú que no haga coincidir la región con la ROM. Por ejemplo: N64 PAL, Mario NTSC, forzar PAL. Ya oiréis lo que le pasa al sonido. (Las ROMs NTSC, por mandato de Nintendo, deben testarse también en consola MPAL, así que no espereis que funcione el experimento en ese caso... aunque me sorprendería que alguien por aquí tuviese una consola brasileña).
En fin, otro oscurantismo del tito rad xD
Todo esto a raiz de ver el Mario PAL variar con respecto a WR y BK en la consola NTSC.
----------
Otra cosa que estaría interesante probar son juegos que pueden cambiar de progresivo a entrelazado, para ver la diferencia de sincronización vertical entre uno y otro. Asumiríamos que en SDTV/entrelazado, se respetarían las 625 lineas de PAL y 525 de NTSC, y viendo si la frecuencia vertical sube o baja o se mantiene al cambiar a LDTV/progresivo sabríamos si usa "campos progresivos" con media linea de menos, de mas, o alternando campos de distinto numero de lineas para mantener las cifras de SDTV en cada par de campos.
De juegos que hagan cambios de entrelazado a progresivo dinamicamente durante el ejugo están el Majora's Mask, al entrar en el cuaderno de los Bomber, Turok 2, desde el menú, Rogue Squadron(?), Ep1 Racer(?)... y no se incluso si había juegos que hacen una transición sin interrupciones de un modo a otro, aunque puede que me esté confundiendo con transiciones entre 50Hz y 60Hz con software especial. Ambos tipos de transición solo se pueden ver en CRTs, claro.
(NOTA: creo que los fabricantes de escaladores deberían experimentar con los protocolos VFR de los nuevos monitores para intentar eliminar los apagones de imagen durante dichas transiciones)
---------
Ya en otras rarezas de video...
Un ejemplo raro raro es el primer Goemon, que en versión PAL tiene el típico reescalado de 240 a 288, en NTSC americano es 240p puro, y la versión japonesa la pusieron renderizada a 240 y escalada a 480i
Creo que el primer Castlevania japo hace lo mismo... ambos de Konami. Se ve que nunca oyeron eso de "los experimentos, con gaseosa" xD
GoldenEye, Perfect Dark, Diddy Kong Racing y la beta de 40 Winks son los únicos 4 juegos que conozco que en sus versiones PAL (o única, en el caso del prototipo 40W, al menos en cuanto a disponibilidad como ROM, no sé que hace el cartucho de Piko), renderizan 288p nativo, sin reescalar después por VI. No sé si eso resultará en alguna variación de la señal de video.
La mayoría de juegos en alta resolución entrelazada hacen upscaling, no hay casi ninguno que chute 480 reales. Hasta la versión NTSC va estirada. Y Body Harvest es el único juego 240p que hasta en NTSC va estirado también, porque renderiza por debajo de esa resolución.
El menú de carpetas de GoldenEye es aún mas raro, porque renderiza en alta resolución 440 y luego lo estruja hasta 240p y 288p para PAL y NTSC respectivamente. Me hace pensar que, en su momento, quizá pensasen ponerlo en entrelazado también. Por lo visto la escena del beso cuando te pasas la fase de la antena también va con framebuffer de 440.
No se si estas cosas afectarán a los tiempos de video, que no deberían, pero quien sabe... Con la N64 vale todo, por lo visto xD
![[comor?]](/images/smilies/nuevos/interro_ani1.gif "comor?")
![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
. Me da cosa mencionarlo al pobre xD.
![[angelito]](/images/smilies/nuevos/angelito.gif "angelito")
me refería al RGB en una consola Japonesa (del 96, pero creo que de la 4ª revisión que salió).
