¿Cómo trabajaban las consolas con resoluciones entrelazadas?

cirote3 escribió:El no$psx tiene un visor de VRAM en el que se muestran las texturas y la imagen con la que se trabaja a resolución interna. Adivina qué pantallazo es del port original y cuál es de la Hi Spec demo:





Como se puede ver "con el ojo desnudo" , la Hi Spec demo maneja una imagen interna al doble de resolución vertical, con los polígonos sin escalar en el eje vertical (a resolución nativa).

Misscelan escribió:Sobre el tema del interlaced y los FPS. En el caso de PSX, no es lo mismo renderizar 480i ni para la GPU ni para la CPU.

Cuando se usa interlaced en PSX, la GPU debería alternar la escritura de líneas, ósea las líneas pares estarán en un frame, y las impares en otro, si el emulador no muestra eso quizás no lo está emulando correctamente (o tiene dos buffers a ese tamaño!?). Pero el coste para la PSX es significativamente más grande, porque la GPU hace prácticamente el proceso de renderizado normal, pero solo se salta el última paso de escritura al buffer. Hace mucho tiempo se hicieron ejemplos de esto en psxdev pero ahora no los encuentro

La GPU de PS1 es bastante competente y me imagino que podría soportar un 480p en este escenario, el principal problema es que con dos buffers así te comes la VRAM y no hay casi espacio para texturas.
Después está obviamente el hecho de que a 60fps entrelazados o no, obligas a la CPU a transformar y proyectar todos los polígonos en menos de 16.6ms en vez de 33ms. Aunque en este caso la carga de la CPU debería ser más liviana al tener menos coches.

Yo sobre el tema de los datos con Turbo (el modo “PSX”) soy muy escéptico sobre que el rendimiento se triplique en un escenario real (Igual que también soy escéptico sobre que se puedan alcanzar en ps1 240 polígonos texturizados en un escenario real).

Por las pruebas que he hecho el peso sobre todo son los accesos a memoria. Puedes ganar algo de rendimiento en otros casos, pero no será comparable al ahorrarte accesos a memoria.
Dos casos eran los más flagrantes dentro de los accesos a memoria, subida de texturas y cluts a TMEM, acceso a los buffers tanto de color como el z-buffer.

-Las texturas y los cluts, son algo inevitable, solo puedes reducir el tamaño, agrupar los polígonos por material para reducir las subidas y por última usar porcas texturas con el fin de limitar cambios también.

Respecto a los buffers, la N64 tiene un span buffer (un buffer para líneas de 16*9 bytes con el fin de no tener que ahogar la memoria accediendo pixel a pixel). Si necesitas algo del buffer de color que no tienes, como por ejemplo para hacer una transparencia o para acceder al zbuffer pues la subes al span buffer, escribes lo que tengas que escribir en el span buffer y luego del span buffer lo guardas al buffer correspondiente. Cada carga/descarga del span buffer a los buffers normales bloqueas el bus y no dejas que nadie más acceda. Así por ejemplo un buffer de 32 bits dejará menos espacio para almacenar nuevas líneas en el span y molestará más al bus, lo mismo si tienes que acceder al z-buffer.

-El z-buffer se puede desactivar, pero como ha mencionado Conker es que por una parte requiere que hagas tú el ordenamiento de polígonos que puede consumir tanto recursos de CPU como bus, así como te puede afectar al agrupamiento por materiales por lo que puede generar subidas más frecuentes de texturas a TMEM. Además en casos con excesivo overdraw puede ser hasta contraproducente.

-La precisión subpíxel y la corrección por perspectiva, creo que no son parte de un estado configurable para la GPU. Pero se pueden desactivar pasando los parámetros adecuados.
El subpíxel son 2 bits en las coordenadas X e Y que recibe la GPU. La GPU recibe estas coordenadas en formato 16.16. Las primeras son lo que se consideraría el valor absoluto y de las segundas solo se usarían los susodichos 2 bits. Yo he probado a limpiar esos dos bits, todo se vuelven “flan-a-la-PSX” pero el rendimiento no parecía cambiar. Lo que tendría sentido ya que el subpíxel solo debería actual en las aristas internas y esos valores deberían estar en el span buffer de cualquier manera para una texturización normal.

-la corrección de perspectiva, es sobre todo calculada en el RSP (o la CPU) que necesita calcular la 1/W para pasársela la GPU, puedes pasar ese valor como 1 y con eso haces que deje de funcionar la corrección de perspectiva. En mi escenario solo tuvo implicaciones en la CPU (todavía no lo hago en el RSP) pero no hubo cambios en los FPS porque en mi escenario está limitado por la memoria no por el proceso, podría dar algún resultado en juegos limitados por proceso

-El antialiasing, en mi caso tenía un cambio de entre 2/5 fps. Aunque este proceso también requiere de acceder al buffer de color, supongo de que el hecho de que sea la fase final el VI puede trabajar con volúmenes de datos más grandes, en vez de micro accesos. El VI también solo debería tocar las aristas externas, así que me imagino que por ejemplo un escenario con un montón de partículas pequeñitas (todo aristas externas) tiene que tener mucho más trabajo que renderizar un quad gigante que ocupe casi toda la pantalla.

-Sobre modo de dos ciclos no he hecho pruebas, pero ya el hecho de tener que tener otra texturas en TMEM significa más estrés para el bus. Así que por esa parte mal, pero luego 2 cycle mode también permite que puedes subir texturas más pequeñas y enmascarar una bajar resolución con un segundo pase a diferente escala.

El turbo code también parece desactivar el cálculo de luces dinámicas y el clipping!? Esto no tiene mucho que ver con dejarlo tipo ps1 pero si entonces no hacen clipping espera que el usuario lo haga en la CPU? O que tesele y empuje la Z? no veo como va a ser eso más rápido en la CPU.

Misscelan escribió:

DefMod escribió:@Misscelan Si parece que aquí el único que tiene la PS1 de verdad soy yo , pero ni poniéndolo fácil y dando indicaciones para verlo en directo en emuladores se atreven.

Esto lo lanzo desde PSIO, no sé que métodos usas tú, o que tele tienes. No están exactamente en el mismo punto pero creo que se ve la diferencia.

Puede existir una conspiración judeo masónica que haga que todos los emuladores digan que sale a 480i, que muestren la VRAM renderizando internamente a 480, o que se invente un modo que desconocido en la PS1(por lo menos yo no conozco un modo que renderize dos líneas iguales al mismo tiempo), o no sé, puede ser que el juego vaya a 480i renderizando líneas diferentes de cada vez, no sé tampoco es que esto sea el Crysis para pensar que es algo inconcebible.

dirtymagic escribió:Lo que muestra la captura de @cirote3 es que a 320x240 usa 2 buffer de imagen y a 320x480 es un solo buffer que mediante entrelazado intercala la lineas pares e impares, algo parecido a lo que hace este juego homebrew de N64

Lo que no tengo tan claro es si a la consola le cuesta más o menos renderizar un 1 buffer de 320x480 que 2 de 320x240.
En la descripción del video dice un poco por encima como lo a hecho.

Yo no tengo PSX, para probar, pero si funciona como el Driving Strikers 64, que si lo he probado en consola, si que da la sensación de tener más resolución y se ve bien, así que como truco está bien.

Salud.

naxeras escribió:

SuperPadLand escribió:Entiendo que lo de no sacarlos en progresivo es porque los CRT de entonces no soportaba 480p no?

PSX no tiene salida a 480p lo tiene que sacar a 480i y si, era raro un CRT a 480p, piensa que PS2, Dreamcast y CUBE lo normal es que renderizaran a 480p pero luego mostraban 480i.

SuperPadLand escribió:Que parches hay en PS1 para forzar 240p?

Que yo sepa no hay ninguno ni yo he dicho que lo haya, lo que hay son juegos de PS2 que van a 480i y se pueden parchear a 480p ya que PS2 si soporta salida a 480p y como el juego se renderiza internamente a esa resolución pues la comunidad ha sacado cientos de parches. (ojo no todos los juegos a 480i de PS2 se renderizan nativamente a 480p).

Un Saludo.

Sogun escribió:Lo de las "resoluciones" de 240p y 480i se debe a cómo funcionaban los televisores de consumo (15 KHz).

Cuando se inventaron los televisores y se establecieron los distintos estándares no existían las consolas y estaban pensados únicamente para retransmisiones en directo. Centrándonos en el estándar NTSC, estos televisores pueden pintar pintar unas 480 líneas, pero no pueden hacerlo de una tacada. Así que dividen la misma imagen en dos campos, uno con las líneas impares y otro con las pares. Cada uno de estos campos se dibuja en 1/60 segundos, lo que significa que las televisiones mostraban 30 imágenes por segundo. Dividir la imagen en dos campos es lo que se conoce como entralazado; la "i" de los 480i (interlaced).

Otro aspecto muy importante a tener en cuenta es que en las televisiones no existe la resolución horizontal ni dibuja píxeles. En horizontal hay "variaciones de color" que no tienen un valor fijo, aunque sí un máximo que podríamos decir que son 720 variaciones (no me sé el valor exacto, pero es superior a 640). Esto significa que los "píxeles" no son cuadrados, se estiran y se contraen, y que la resolución horizontal puede ser la que queramos. La resolución vertical, sin embargo, está encorsetada por esas 480 líneas visibles.

Los 240p de las consolas no están contemplados en el estándar. Es una trampa que idearon los ingenieros de las consolas porque éstas no podían generar los datos con la suficiente velocidad como para llenar la pantalla. Dando la orden de que los dos campos se dibujen uno encima de otro se reduce la resolución vertical a la mitad. La "p" (progresivo) de los 240p significa justamente eso, se dibujan siempre las mismas líneas. La resolución horizontal hemos visto que puede ser cualquiera. Si aún así no diera tiempo a dibujar la pantalla entera, lo que se hace es justamente dejar de dibujar esas líneas. Por ejemplo, la resolución de la Atari 2600 es de 40 píxeles en horizontal y 192 lineas verticales de las 240 visibles (quedan franjas negras arriba y abajo, parcialmente ocultas por el overscan). Otro ejemplo es la Master System, que tiene una resolución de 256x192, que parecería que es una imagen que se adapta a la perfección al formato 4:3, pero en realidad llena la pantalla en horizontal y tiene franjas negras arriba y abajo. Para rellenar la pantalla, la imagen tiene que tener 240 píxeles de resolución vertical (como la NES), aunque si tenemos en cuenta el overscan tampoco se verían franjas negras con 224 líneas verticales (dependería del televisor).

En las consolas de quinta generación (Saturn, PlayStation y Nintendo 64) ya hay suficiente potencia y flexibilidad para jugar con todo tipo de resoluciones. Cada consola tiene sus propias peculiaridades, pero siempre estarán encorsetadas por la tecnología en la que se muestran (televisores de consumo, de 15 kHz).
-Saturn puede componer la imagen final a partir de varias capas con distintas resoluciones. Los ejemplos de juegos de lucha con resoluciones entorno a los 700x480 son tramposos. Los marcadores sí que se muestran a esa resolución, pero los elementos 3D y los fondos están a una resolución inferior.
-Nintendo 64 renderiza internamente a cualquier resolución (por ejemplo 400x300, o 558x441, o 296x208) y luego la escala a 640x480. Este proceso de escalado es el mayor culpable de la borrosidad de la imagen. Esto no significa que se vea siempre en entrelazado: se descarta la mitad de las líneas horizontales para mostrar la imagen en progresivo si es lo que se desea.
-PlayStation es más sencilla. En el caso que se discute del Ridge Racer Hi Spec lo que ocurre es que renderiza internamente la imagen a 320x480 y, como no puede mostrar la imagen entera en un campo, dibuja las líneas impares en un campo, ACTUALIZA la imagen antes de que se empiece a dibujar el siguiente campo, y dibuja las líneas pares en la siguiente pasada. Actualiza la imagen 60 veces por segundo, dibuja las 480 visibles del televisor, pero en cada paso sólo dibuja 240 líneas. Si hiciésemos una foto a la televisión que sólo capturase un campo, contaríamos 320x240 píxeles. El juego renderiza a 320x480 pero no los puede mostrar por las limitaciones del televisor (y porque la PlayStation fue diseñada con esas limitaciones en mente).

Es absurdo pedirle a estos sistemas que muestren resoluciones de 512x384 por ejemplo, porque lo que falla es el televisor. Las máquinas arcade sí podían porque usaban monitores de 24 kHz.

DreamCast, con su salida VGA preparada para monitores de ordenador de 31kHz que sí soportaban mayores resoluciones y refrescos, fue la primera en mostrar 480 líneas simultáneamente (480p).

Misscelan escribió:

Sogun escribió:...El juego renderiza a 320x480 pero no los puede mostrar por las limitaciones del televisor.

Esta parte justo es la que no me cuadra (por lo demás excelente post). A lo mejor me estoy perdiendo algo pero sigo sin ver eso posible salvo que el juego tenga screen tearing, lo cual yo no noté por lo menos. O te refieres a que solo actualiza impares/pares en el screen buffer?

Esto a lo cutre sería la representación del frame 1, a la izquierda está el screen buffer de ps1 a la derecha la TV. El DAC va pasando las líneas verdes a la tele para que las muestre.



Una vez el haz de electrones de la CRT llega a la esquina de abajo a la derecha de la tele (a terminado de pintar las líneas impares), tienes poco más de 1ms para actualizar todo el frame buffer. El haz vuelve a la parte de arriba a la izquierda y empieza el proceso de nuevo, esta vez el DAC le pasa solo las líneas pares.

Pero es imposible que la ps1 renderize toda esa escena en poco más de 1 ms, ósea la ps1 tiene que estar pintando en el screen buffer a la misma vez que el dac le pasa la info para que el haz de electrones lo pinte en la TV, si dejas que en este momento la ps1 pinte en las líneas pares vas a estar corrompiendo la imagen, porque la ps1 va a rasterizar en puntos aleatorios del screen buffer, lo mismo empieza pintando en la esquina derecha cuando no se ha pasado por ahí al haz y termina escribiendo en la parte izquierda arriba cuando el haz ya ha mandado la imagen. Para eso principalmente existen los double buffer para que no pintes donde está leyendo la tele en ese momento.

Por eso pienso que es un riesgo innecesario dejar que actualice las líneas que el DAC está pasando a la tele, si además es la opción por defecto y visualmente el resultado va a ser el mismo.

He probado por ejemplo Tekken3 en no-cash (otro interlaced) y el resultado es el mismo, un screen buffer uniforme, lo que huele a que los emuladores solo se están facilitando el poder ofrecer estos en progresivo.

No sé si me estoy perdiendo algo.

Sogun escribió:

Misscelan escribió:Una vez el haz de electrones de la CRT llega a la esquina de abajo a la derecha de la tele (a terminado de pintar las líneas impares), tienes poco más de 1ms para actualizar todo el frame buffer. El haz vuelve a la parte de arriba a la izquierda y empieza el proceso de nuevo, esta vez el DAC le pasa solo las líneas pares.

Pero es imposible que la ps1 renderize toda esa escena en poco más de 1 ms

Pues tienes toda la razón. No había caído en eso. Últimamente me estoy empapando de cómo funcionan las consolas 2D y éstas sí que actualizan el frame durante el V-blank. Pueden hacerlo porque tienen todos los elementos previamente dibujados y "sólo" hay que ponerlos en su sitio. Pero para escenas 3D necesitas al menos doble buffer para tener algo que poner en pantalla por si no da tiempo a dibujar el nuevo frame para el siguiente refresco de pantalla.
El caso es que cuando subieron las dos imágenes comparativas de las VRAM ya me pareció raro que en la de Hi Spec sólo se mostrara un buffer. Pero luego mientras escribía el mensaje, que me llevó bastante tiempo, se me fue de la cabeza.

Mientras escribo esto estoy investigando acerca del "field rendering" y quizás es lo que están usando aquí y también explicaría lo que se ha hablado de los juegos de PS2 en los que no se puede forzar el progresivo. Aunque me hago una idea de cómo funciona, me surgen varias dudas. Así que espero que alguien me pueda corregir si lo que pongo no es correcto o es impreciso. Básicamente, el buffer de 320x480 contiene dos frames mezclados, con las líneas impares formando la imagen que se mostrará en el primer campo y las líneas pares formando la imagen del segundo campo. Creo que el proceso funciona de la siguiente manera:
-Se renderiza el primer frame a 320x480, pero sólo se dibujan en VRAM las líneas impares, dejando intervalos vacíos de 1 píxel. Teóricamente se tardaría lo mismo en renderizar esto que un frame para un juego en progresivo a 320x240 de resolución. Como directamente se sabe de antemano que no se van a mostrar la líneas pares, no se gastan recursos en calcular lo que hay ahí. A la hora de mostrarlo en pantalla, también se manda saltando la líneas de píxeles pares del buffer para coincidir con el campo de la televisión.
-Mientras se dibuja el primer campo se renderiza el segundo frame también a 320x480, pero esta vez sólo se dibujan en VRAM las líneas pares, rellenando los huecos que quedaban después de renderizar el primer frame. Y se manda a la televisión saltándose las líneas impares del buffer para que coincida con el segundo campo.
-Mientras se dibuja el segundo campo, se actualizan las líneas impares del buffer de 320x480 con el tercer frame. Y así todo el rato.

En las comparativas de VRAM que se postearon antes, hice zoom en la del Hi Spec para ver si había líneas repetidas como se estaba discutiendo en ese momento. Pero la imagen es genuinamente 320x480 (bueno, tiene bandas negras arriba y abajo y queda en 320x455). Sólo se aprecia doble línea en el cielo porque la textura está estirada para pasar de 240 píxeles de alto al equivalente de 480.

Como en ese momento no se mueve nada en el juego, es imposible saber si lo que se muestra son dos frames mezclados siguiendo el proceso que he descrito antes, o si es un único frame renderizado a 320x480. Si lo que he puesto más arriba funciona de esa manera, cuando el juego tuviera movimiento se verían los artefactos del entrelazado en el framebuffer. A ver si alguien puede mostrar una captura del frambuffer del Hi Spec mientras se toma una curva a gran velocidad. Cuanto más desplazamiento horizontal de la imagen, mejor.

Si intentáramos forzar el juego en progresivo mostrando las 480 líneas a la vez, como se podía hacer a partir de DreamCast con los medios adecuados, no podríamos evitar los artefactos del entrelazado. Creo que sería incluso peor, porque sería como ver dos vídeos corriendo a 30 fps superpuestos uno encima del otro. Con entrelazado se ve una imagen en cada refresco que se va actualizando con cada pasada, pero en progresivo se verían dos imágenes mezcladas que permanecerían durante 2 refrescos y que se actualizarían intermitentemente.

cirote3 escribió:

Sogun escribió:A ver si alguien puede mostrar una captura del frambuffer del Hi Spec mientras se toma una curva a gran velocidad. Cuanto más desplazamiento horizontal de la imagen, mejor.

Yo con el visor de VRAM del no$psx no consigo ver defectos de entrelazado cuando se toman curvas, la imagen de 320x480 se actualiza al completo en cada frame (a 60FPS).

EMaDeLoC escribió:

Misscelan escribió:

Sogun escribió:...El juego renderiza a 320x480 pero no los puede mostrar por las limitaciones del televisor.

Esta parte justo es la que no me cuadra (por lo demás excelente post). A lo mejor me estoy perdiendo algo pero sigo sin ver eso posible salvo que el juego tenga screen tearing, lo cual yo no noté por lo menos. O te refieres a que solo actualiza impares/pares en el screen buffer?

Quizá me equivoco, pero creo que lo que lleva a error es la captura mostrando un solo framebuffer de 320x480. Que yo sepa la consola siempre tiene dos, uno de un campo y otro de otro campo, o uno de un frame y el otro del siguiente frame si esta configurada a 240p. Vamos, tal cual sale en la captura anterior a la que digo.

La VRAM de PS1 puede leer a la vez que escribe en otra dirección de memoria. Por eso puede leer un frame/campo mientras renderiza otro.
Si realmente la consola maneja un solo framebuffer de 320x480 (que no lo creo), también podría leer líneas de un campo mientras dibuja líneas de otro. Pero como digo creo que tienen que ser dos regiones de memoria distintas con los datos continuos, no va preparada para saltar líneas (o direcciones de memoria) de un solo framebuffer.

El programa lo que hace es mostrar un solo framebuffer para resaltar que es una resolución superior.

Pero vamos, es lo que me cuadra a mí, quizá me equivoque.

Misscelan escribió:@EMaDeLoC
Creo que al final estamos todos hablando más o menos de lo mismo, pero es difícil ponerlo en palabras.
Esto es una captura de un manual de desarrollo de la PS1.


Lo que comenta es básicamente que cuando configuras entrelazado, el comportamiento por defecto es que tú puedes escribir en las líneas pares y tienes prohibido en las impares que son las que el DAC le pasa a tele, cuando empieza un nuevo frame el comportamiento par/impar se invierte.
Puedes alterar el comportamiento por defecto cambiando la flag que indican y renderizar todo, pero el DAC seguiría pasando pares en un frame a impares en otra (así que ahora mismo no le veo mucho sentido a activar esa flag).

La duda principal que plantea Cirote3 es porque todos los emuladores muestran la imagen entera en progresivo y ahí es donde cada uno tiene sus teorías.

La PS1 realmente está realizando el proceso de rasterizado de las dos líneas la pares y la impares en cada frame, pero el proceso no termina transfiriendo el contenido de la línea que tiene bloqueada para el DAC al buffer de pantalla. Desde el punto de vista de desempeño es prácticamente como si estuviese rellenando todo el buffer (los 320x480 píxels). Y aquí es donde empieza mi teoría, para que el emulador tenga unos timings parecidos a la GPU en la realidad, va hacer todo el proceso, solo que en el caso de los emuladores lo termina trasfiriendo porque así le permite mostrar en progresivo y no tener que gestionar el pitote que sería de la otra manera en pantallas actuales. Pero esto es solo mi teoría, pero no se me ocurre otra que no resultase con screen tearing.

La única manera que se me ocurre para salir de dudas, sería o preguntarle al creador de cualquier emulador, o usar Caetla en un Xplorer y hacer una dump de la VRAM mientras se juega.

Y creo que la gente que se queja del offtopic tiene razón. Así que este es mi último post sobre el interlaced en RR.

cirote3 escribió:La ventana de juego del no$psx muestra 240 líneas, sin filtros (los emuladores no$ no suelen llevar filtros). Es el visor de VRAM el que muestra la imagen de 320x480 actualizándose al completo en cada frame a 60FPS. Igual probando con el visor de VRAM de otros emuladores (no sé si hay más con visores de ese tipo) se puede sacar una conclusión.