Nueva demo del bad apple para SNES con streaming a 32Khz...

super nintendo siempre necesitando chips ...

Tu necesitas aprender a leer.

SUPER_ARU escribió:super nintendo siempre necesitando chips ...

Pero puede

Señor Ventura escribió:Si la scene de la megadrive tuviera algo como esto ya habríamos visto los resultados

Realmente es una pena que no esté portado para la mega, y mas teniendo en cuenta que es uno de los pocos casos donde prácticamente no tendría problemas con la paleta de colores

Señor Ventura escribió:P.D:
La versión MSU1 también tiene su logro, o mejor dicho, se han buscado las vueltas para mejorar los números en resolución que suelen dar los vídeos reproducidos por el MSU1.
Funciona a 512x448, e IMAGINO que eso es posible porque el bad apple del MSU1 no es un vídeo, sino una transferencia de tiles a un plano normal y corriente. Es decir, que los gráficos no los reproduce el MSU1 como suele ocurrir con os vídeos, sino el sistema de vídeo de la super nintendo con los tiles que le llegan a la VRAM... el sonido ya si es cosa del MSU1, aunque del mismo modo que el original también podría haberse encargado el SPC700.

Esto ya lo habíamos hablado tú y yo, @Señor Ventura....

TODO en la SNES es una transferencia de tiles a un plano normal y corriente (incluso MODO 7) y eso es lo que da la sensación de video. El MSU-1 no "crea" hardware para video en ningún caso ni "reproduce" nada de video, lo único que hace es enviar las tiles y el tilemap a VRAM y lo que se representa en pantalla es un plano de tiles normal y corriente.
Lo que sí hace el MSU-1, en cambio, es incorporar un DAC de audio para dos canales, de modo que SÍ genera audio analógico que luego aprovecha el mezclador de salida de la SNES para reproducirlo en pantalla de la TV. Esto se puede hacer gracias a que Nintendo reservó dos pines del conector para audio analógico, con sus canales L y R independientes, que se suman mediante un sencillo sumador a la salida del SPC700 que tiene la SNES, así puedes superponer los efectos sonores que genere éste con la música de fondo que genera el MSU-1

Señor Ventura escribió:Esto es posible porque gracias al ancho de banda que proporciona el MSU1 para tiles de planos (los tiles de sprites se transfieren a la velocidad normal a través del DMA), no hace falta descomprimirlos, ya que pueden viajar hasta a 9MB de datos por segundo de forma autónoma. El frame buffer solo tiene que conformar los scanlines con los tiles que llegan sin coste de procesamiento a velocidades de vértigo.

Uf, esto ha sonado totalmente comercial... ¿tú no serías el que hacías las descripciones de las cajas de las consolas de Nintendo en los 90?
En serio, esto también es erróneo totalmente. El MSU-1 no "proporciona" ningún ancho de banda, puesto que solo se puede comunicar con el resto de la SNES como cualquier ROM: a través del bus A. Esto implica que cualquier acceso a la PPU se tiene que hacer por un DMA que comunica los buses A (el del conector del cartucho) y el B (el de acceso a la PPU, que se ve desde fuera como los famosos "registros" en la zona $21XX y $42XX).
Así que el ancho de banda para planos y para tiles es el mismo, el que permita el DMA, que te recuerdo que funciona a 2.58MHz (aunque va a 1 byte por ciclo, es decir 2.58MBytes por segundo como mucho, no sé de dónde sacas el 9MB...). Obviamente, si estás enviando desde la ROM a la VRAM, tienes que hacerlo descomprimido, porque si estuviera comprimido primero hay que almacenarlo en RAM para el proceso de descompresión.
Como se suele usar el MSU-1 (y esto recuerdo que también te lo comenté) es crear un tilemap fijo en VRAM que no se toca nunca y que determina la zona visible en pantalla que tendrá el video. Luego por DMA vas enviando las tiles con los gráficos que forman el video desde el MSU-1.

Señor Ventura escribió: aunque con la ventaja de que a 5,72KB por frame ahora solo viajan los tiles de los sprites, en vez de tener que compartirlo con los tiles de los planos (que ahora van aparte).

¿De dónde has sacado toda esa información que has puesto? Es bastante errónea en su conjunto...

puch666 escribió:Realmente es una pena que no esté portado para la mega, y mas teniendo en cuenta que es uno de los pocos casos donde prácticamente no tendría problemas con la paleta de colores

Sí que está, yo lo vi hace tiempo ya:

Bad Apple Demo para Genesis

Efectivamente, la Mega aquí no sufre con la paleta Lo que me parece raro es que para hacer la demo en SNES hayan usado 2BPP, es decir, 4 colores por píxeles, ya que la gracia de la demo es utilizar el blanco y negro... la escala de grises es poco visible debido a la cantidad de movimiento del video.
EDITO: ya sé por qué lo de 2BPP, es porque querían reproducir las sombras en el suelo que aparecen en el video original de la demo.

puch666 escribió:Realmente es una pena que no esté portado para la mega, y mas teniendo en cuenta que es uno de los pocos casos donde prácticamente no tendría problemas con la paleta de colores

Está en Mega Drive y en la mayoría de plataformas.

https://www.youtube.com/watch?v=BnYedfyCVug

ROM: http://www.sega-16.com/forum/showthread ... emo-thread

Tienes versión incluso en NES:

https://www.youtube.com/watch?v=qRdGhHEoj3o

ROM: http://www.geocities.jp/littlimi/arc/fc ... -03-22.zip

¡Y hasta en Atari 2600!

https://www.youtube.com/watch?v=Ko9ZA50X71s

ROM: http://atariage.com/forums/topic/226949 ... ?p=3119932

Diskover escribió:

puch666 escribió:Realmente es una pena que no esté portado para la mega, y mas teniendo en cuenta que es uno de los pocos casos donde prácticamente no tendría problemas con la paleta de colores

Está en Mega Drive y en la mayoría de plataformas.

https://www.youtube.com/watch?v=BnYedfyCVug

ROM: http://www.sega-16.com/forum/showthread ... emo-thread

Tienes versión incluso en NES:

https://www.youtube.com/watch?v=qRdGhHEoj3o

ROM: http://www.geocities.jp/littlimi/arc/fc ... -03-22.zip

¡Y hasta en Atari 2600!

https://www.youtube.com/watch?v=Ko9ZA50X71s

ROM: http://atariage.com/forums/topic/226949 ... ?p=3119932

Sólo hay que comparar la versión de NES con la de Megadrive para darse cuenta de la evolución que hubo entre esos 2 sistemas en todo. Es que se leen algunas cosas, que tela..

No hay versión para 32X o Mega CD, ya puestos a meterle hardware extra al asunto?

Señor Ventura escribió:Esto es posible porque gracias al ancho de banda que proporciona el MSU1 para tiles de planos (los tiles de sprites se transfieren a la velocidad normal a través del DMA), no hace falta descomprimirlos, ya que pueden viajar hasta a 9MB de datos por segundo de forma autónoma. El frame buffer solo tiene que conformar los scanlines con los tiles que llegan sin coste de procesamiento a velocidades de vértigo.

Con un rendimiento así, un juego con unos escenarios como los de un metal slug serían coser y cantar. Eso si, los sprites ya estarían contenidos a las limitaciones de siempre, aunque con la ventaja de que a 5,72KB por frame ahora solo viajan los tiles de los sprites, en vez de tener que compartirlo con los tiles de los planos (que ahora van aparte).

¿No estás muy fino estos días verdad xD? Resident Evil de Saturn cómo primera versión, Final Fantasy Tactics en Snes, y ahora ésto; espero que estés en mejor forma para el debate de Gamecube

Magno lo ha aclarado todo, y hasta cosas de las que yo no tenía ni puta idea, muchísimas gracias.

Te doy un positivo de cualquier forma, ya que cómo a mí la scene de Super Nintendo no me interesa lo suficiente cómo para seguirla a diario, agradezco que alguien llene el hueco en EOL y me de la info masticadita.

Eso sí macho; duerme más horas, o tómate un café antes de postear, que echo de menos al Ventura con atención al detalle xDD. O es éso; o bien tienes que aprender a refrenar tus emociones y contrastar la info antes de sacar pecho por la Snes, yo en el pasado he tenido muchas cagadas por esto último (con la MD xD).

Te se quiere, pero en mejor forma.

Gammenon escribió:No hay versión para 32X o Mega CD, ya puestos a meterle hardware extra al asunto?

Troll xDD

@magno

Uff, es que a esas horas estaba como para hacer simposios sobre nada mas complicado que un chiste de chiquito. De hecho, lo raro es que no acabase el mensaje balbuceando xD

Es impresionante como afecta a los procesos mentales el estrés y la falta de descanso

magno escribió:Esto ya lo habíamos hablado tú y yo, @Señor Ventura....

TODO en la SNES es una transferencia de tiles a un plano normal y corriente (incluso MODO 7) y eso es lo que da la sensación de video. El MSU-1 no "crea" hardware para video en ningún caso ni "reproduce" nada de video, lo único que hace es enviar las tiles y el tilemap a VRAM y lo que se representa en pantalla es un plano de tiles normal y corriente.
Lo que sí hace el MSU-1, en cambio, es incorporar un DAC de audio para dos canales, de modo que SÍ genera audio analógico que luego aprovecha el mezclador de salida de la SNES para reproducirlo en pantalla de la TV. Esto se puede hacer gracias a que Nintendo reservó dos pines del conector para audio analógico, con sus canales L y R independientes, que se suman mediante un sencillo sumador a la salida del SPC700 que tiene la SNES, así puedes superponer los efectos sonores que genere éste con la música de fondo que genera el MSU-1

Bueno, al menos he acertado diciendo que la demo a 512x448 funciona así. En realidad todo funciona así, claro, pero ese es el detalle ^^

magno escribió:Uf, esto ha sonado totalmente comercial... ¿tú no serías el que hacías las descripciones de las cajas de las consolas de Nintendo en los 90?

No era capaz de expresarme ni a martillazos... bastante es que no mezclé palabras con otros idiomas

No quiero ni leerme xD

magno escribió:En serio, esto también es erróneo totalmente. El MSU-1 no "proporciona" ningún ancho de banda, puesto que solo se puede comunicar con el resto de la SNES como cualquier ROM: a través del bus A. Esto implica que cualquier acceso a la PPU se tiene que hacer por un DMA que comunica los buses A (el del conector del cartucho) y el B (el de acceso a la PPU, que se ve desde fuera como los famosos "registros" en la zona $21XX y $42XX).
Así que el ancho de banda para planos y para tiles es el mismo, el que permita el DMA, que te recuerdo que funciona a 2.58MHz (aunque va a 1 byte por ciclo, es decir 2.58MBytes por segundo como mucho, no sé de dónde sacas el 9MB...). Obviamente, si estás enviando desde la ROM a la VRAM, tienes que hacerlo descomprimido, porque si estuviera comprimido primero hay que almacenarlo en RAM para el proceso de descompresión.
Como se suele usar el MSU-1 (y esto recuerdo que también te lo comenté) es crear un tilemap fijo en VRAM que no se toca nunca y que determina la zona visible en pantalla que tendrá el video. Luego por DMA vas enviando las tiles con los gráficos que forman el video desde el MSU-1.

No me hagas caso, lo de los 9MB es un bus interno del MSU1 para tansferir las roms de la tarjeta SD a la memoria del cartucho. Podemos correr un tupido velo xD

Netamente, la demo a 256x224, y la demo a 512x448, resultan ser exactamente lo mismo, solo que la segunda emplea todo el ancho de banda para transferir tiles, porque el audio esta vez no necesita transferirse a la ram del spc700 (ya que es audio analógico a través del MSU1).

Si me gustaría preguntar algo sobre el DMA de la snes... ¿la frecuencia a la que funciona en realidad viene impuesta por las especificaciones de la VRAM?, o es nominal.

magno escribió:¿De dónde has sacado toda esa información que has puesto? Es bastante errónea en su conjunto...

Eran conclusiones basadas en premisas erróneas sobre un supuesto hipotético de manejar sprites y fondos a la vez en... no se, un juego.

En realidad, si el MSU1 aportase su propio DMA para transferir tiles de fondos ( y para ello se tendría que puentear a todo el sistema de vídeo por completo aportando uno enterito desde el cartucho), los tiles de los sprites no se podrían transferir por medio del DMA de los PPU's, así que ni por esas sería coherente.

Es una imposibilidad, mejor olvidarlo.

magno escribió:Efectivamente, la Mega aquí no sufre con la paleta Lo que me parece raro es que para hacer la demo en SNES hayan usado 2BPP, es decir, 4 colores por píxeles, ya que la gracia de la demo es utilizar el blanco y negro... la escala de grises es poco visible debido a la cantidad de movimiento del video.
EDITO: ya sé por qué lo de 2BPP, es porque querían reproducir las sombras en el suelo que aparecen en el video original de la demo.

Juraría que el sombreado ha estado presente en todas las versiones a 1BPP, así que lo de usar 2BPP es solo conseguir el logro de aportar mas información a la imagen.

Si lo de que el frame rate lo está causando un problema con la descompresión por LZ2, pero realmente pinta subsanable para mejorar la tasa de refresco, hablamos de un salto cualitativo (en lo técnico) muy importante, al aportar no solo 2BPP, sino también streaming de audio a 32Khz.

La cuestión es que a 2BPP podría permitirte incluso aumentar la complejidad (en la demo del bad apple ese "upgrade" no se aprecia, por motivos evidentes).

Sexy MotherFucker escribió:¿No estás muy fino estos días verdad xD? Resident Evil de Saturn cómo primera versión, Final Fantasy Tactics en Snes, y ahora ésto; espero que estés en mejor forma para el debate de Gamecube

Magno lo ha aclarado todo, y hasta cosas de las que yo no tenía ni puta idea, muchísimas gracias.

Te doy un positivo de cualquier forma, ya que cómo a mí la scene de Super Nintendo no me interesa lo suficiente cómo para seguirla a diario, agradezco que alguien llene el hueco en EOL y me de la info masticadita.

Eso sí macho; duerme más horas, o tómate un café antes de postear, que echo de menos al Ventura con atención al detalle xDD. O es éso; o bien tienes que aprender a refrenar tus emociones y contrastar la info antes de sacar pecho por la Snes, yo en el pasado he tenido muchas cagadas por esto último (con la MD xD).

Te se quiere, pero en mejor forma.

No, si lo jodido es que encima lo dije bien. La demo del bad apple a través del MSU1 funciona a 512x448 de la misma forma que la versión normal, solo que el audio si es reproducido aparte (no por el SPC700).

Lo que pasa es que de alguna manera tenía sentido el resto de datos. Cuando te atascas, te atascas.

Alucino:

https://www.youtube.com/watch?v=_aFXvoTnsBU

Señor Ventura escribió:No me hagas caso, lo de los 9MB es un bus interno del MSU1 para tansferir las roms de la tarjeta SD a la memoria del cartucho. Podemos correr un tupido velo xD

Efectivamente, usa un bus SPI desde la FPGA a la SDCard que se suele hacer funcionar entre 25 y 50MHz, y esta gente lo hará funcionar a 9MHz, que debe de ser un divisor del reloj que usen.

Señor Ventura escribió:Si me gustaría preguntar algo sobre el DMA de la snes... ¿la frecuencia a la que funciona en realidad viene impuesta por las especificaciones de la VRAM?, o es nominal.

La frecuencia de 2.68MHz viene impuesta por muchos factores; sabes que el micro de la SNES puede funcionar a 2.68MHz o a 3.85MHz, ambos vienen derivados del master clock de la SNES, que es de entorno a los 21MHz.
A su vez, estas frecuencias se derivan de hacer accesos a memoria de 6 ciclos de master clock (es cuando funciona a 3.85MHz) o 8 ciclos (cuando funciona a 2,68MHz).
La PPU de la SNES funciona a esos 21MHz, y necesita de 8 ciclos para completar las operaciones sobre cada píxel, por lo que digamos que se comportaría como si funcionara a 2.68MHz. Esto hace que para comunicarte con ella has de usar un reloj de 2.68MHz. Por tanto, el DMA de la SNES ha de funcionar a esa velocidad de modo que en cada ciclo de reloj haya un nuevo dato en la PPU.
Si la PPU hubiera sido menos compleja, o bien se hubiera diseñado en una electrónica más óptima (y mucho más cara), quizá podría haber realizado las operaciones en 2 o 3 ciclos de reloj, y hubiéramos tenido una CPU funcionando a 10 o 7 MHz.

Señor Ventura escribió:En realidad, si el MSU1 aportase su propio DMA para transferir tiles de fondos ( y para ello se tendría que puentear a todo el sistema de vídeo por completo aportando uno enterito desde el cartucho), los tiles de los sprites no se podrían transferir por medio del DMA de los PPU's, así que ni por esas sería coherente.

Es una imposibilidad, mejor olvidarlo.

Efectivamente, es totalmente imposible porque el DMA está centralizado en la SNES y ha de ser así, por lo que no hay nada que especular al respecto

Señor Ventura escribió:Juraría que el sombreado ha estado presente en todas las versiones a 1BPP, así que lo de usar 2BPP es solo conseguir el logro de aportar mas información a la imagen.

Sí, es posible que ya lo estuviera y hubieran simulado el efecto de sombras como ya se ha comentado alguna vez: se altnernan líneas o píxeles entre blanco y negro y eso da la sensación de gris y por tanto, de sombra.

Señor Ventura escribió:Si lo de que el frame rate lo está causando un problema con la descompresión por LZ2, pero realmente pinta subsanable para mejorar la tasa de refresco, hablamos de un salto cualitativo (en lo técnico) muy importante, al aportar no solo 2BPP, sino también streaming de audio a 32Khz.

Esa compresión no existe realmente, es una denominación que han usado ellos, y supongo por el nombre que se basa en considerar que el segundo plano de color siempre está inutilizado. Pero claro, si tienes que pasar por RAM para descomprimir, has perdido toda la capacidad de poner frames en pantalla que te permite hacer DMA desde el MSU directamente a VRAM.
Eso es lo mágico del S-DD1, que te permite hacer DMA desde la ROM a VRAM descomprimiendo al vuelo. Creo que el SA-1 también permite descomprimir y hacer DMA desde su RAM (la del cartucho) a la VRAM.

VaNiL escribió:Alucino:

https://www.youtube.com/watch?v=_aFXvoTnsBU

Si siguen así al final van a hacer versión del Bad Apple hasta para ábacos.

A mi me gustaría verla en Virtual Boy...

@Señor Ventura
estate mas tranquilo tio

la mejor versión de bad apple sin duda

https://www.youtube.com/watch?v=240Vq6tIxio

magno escribió:La frecuencia de 2.68MHz viene impuesta por muchos factores; sabes que el micro de la SNES puede funcionar a 2.68MHz o a 3.85MHz, ambos vienen derivados del master clock de la SNES, que es de entorno a los 21MHz.
A su vez, estas frecuencias se derivan de hacer accesos a memoria de 6 ciclos de master clock (es cuando funciona a 3.85MHz) o 8 ciclos (cuando funciona a 2,68MHz).
La PPU de la SNES funciona a esos 21MHz, y necesita de 8 ciclos para completar las operaciones sobre cada píxel, por lo que digamos que se comportaría como si funcionara a 2.68MHz. Esto hace que para comunicarte con ella has de usar un reloj de 2.68MHz. Por tanto, el DMA de la SNES ha de funcionar a esa velocidad de modo que en cada ciclo de reloj haya un nuevo dato en la PPU.
Si la PPU hubiera sido menos compleja, o bien se hubiera diseñado en una electrónica más óptima (y mucho más cara), quizá podría haber realizado las operaciones en 2 o 3 ciclos de reloj, y hubiéramos tenido una CPU funcionando a 10 o 7 MHz.

Casi que me hubiera conformado con que la cpu permitiese buses de 16 bits, teniendo eso por mi parte todo lo demás podría quedarse como está.

O bueno, ya que estamos, no limitar tanto el HDMA, que no necesita mas para ejecutar instrucciones de los PPU's, pero teniendo en cuenta que puede usarse para transferir datos a la RAM del spc700, tener un segundo bus simultáneo para descargar de trabajo al DMA hubiera sido impagable.

Ya veremos a ver que pasa con esta segunda demo. Para mi, sin duda la mejor noticia es el streaming de audio a 32Khz mientras se procesan los gráficos. Ese nivel de depuración con el uso de la RAM del spc700 valdría oro en cualquier juego comercial.
Lo que no se es si sería viable alcanzar los 30fps, a ver en que queda todo...

magno escribió:Esa compresión no existe realmente, es una denominación que han usado ellos, y supongo por el nombre que se basa en considerar que el segundo plano de color siempre está inutilizado. Pero claro, si tienes que pasar por RAM para descomprimir, has perdido toda la capacidad de poner frames en pantalla que te permite hacer DMA desde el MSU directamente a VRAM.
Eso es lo mágico del S-DD1, que te permite hacer DMA desde la ROM a VRAM descomprimiendo al vuelo. Creo que el SA-1 también permite descomprimir y hacer DMA desde su RAM (la del cartucho) a la VRAM.

Para ser sincero, nunca he terminado de ver la ventaja de descomprimir en la WRAM si luego no puedes transferir desde ahí mientras que al mismo tiempo transfieres desde la ROM. De ser así aumentarías virtualmente la tasa del ancho de banda, pero al parecer el DMA totalmente secuencial, y hasta que no termina de transferir desde la WRAM, no empieza a transferir desde la ROM. Y con el sonido por lo visto también sucede lo mismo, tiene que esperar su turno.

Con respecto al SDD1, supongo que por el mismo motivo, descomprime tiles antes de enviarlos de la ROM a la VRAM a través del bus de datos, ¿no?. A menos que pueda acceder a las direcciones de memoria de la VRAM para meter mano a los tiles comprimidos desde ahí... de ser así, sería como tener un ancho de banda de casi 11KB por frame.

¿Cual es el método entonces?, ¿descomprime antes de enviar?, o una vez enviado.

SUPER_ARU escribió:@Señor Ventura
estate mas tranquilo tio

Como un ocho. Lo que digo es que ambas demos del bad apple (la normal a 256x224, y la del MSU1 a 512x448), desempeñan las labores de vídeo sin ningún tipo de ayuda.

Y uno se molesta en escribirlo para que luego no parezca que a la gente le da igual lo que se ponga.

Señor Ventura escribió:O bueno, ya que estamos, no limitar tanto el HDMA, que no necesita mas para ejecutar instrucciones de los PPU's, pero teniendo en cuenta que puede usarse para transferir datos a la RAM del spc700, tener un segundo bus simultáneo para descargar de trabajo al DMA hubiera sido impagable..

El HDMA es como es, no es que esté limitado. el HDMA es Horizontal DMA y lo que hace es aprovechar el tiempo de HBlank de la señal de video para actualizar valores de la PPU. Esto hay que verlo así: la PPU es un subsistema formado por un micro que lee una memoria (la VRAM) para formar una imagen en pantalla. Mientras está dibujando píxeles (parte activa de la señal de video NTSC/PAL) no le puedes tocar la memoria ni su configuración, porque estarías cambiando los datos que en ese instante está "consumiendo" de VRAM. Por tanto te tienes que esperar que no hay zona activa para actualizar tanto los datos de VRAM como el resto de configuración de la PPU, y esto ocurre en el VBlank, que dura bastante y ocurre una vez cada frame, y ocurre también en el HBlank, que dura 4.7us y es muy corto, aunque se repite cada línea.

Señor Ventura escribió:Para ser sincero, nunca he terminado de ver la ventaja de descomprimir en la WRAM si luego no puedes transferir desde ahí mientras que al mismo tiempo transfieres desde la ROM. De ser así aumentarías virtualmente la tasa del ancho de banda, pero al parecer el DMA totalmente secuencial, y hasta que no termina de transferir desde la WRAM, no empieza a transferir desde la ROM. Y con el sonido por lo visto también sucede lo mismo, tiene que esperar su turno.

Todos los DMA del mundo mundial son secuenciales, ya que el bus a una memoria RAM suele ser único; por ejemplo en los ordenadores, el DMA se hace directamente sobre el bus de datos de la RAM normalmente con el northbridge de la placa base. Aquí pasa lo mismo y además, como el micro ya tiene las interrupciones usadas para otras cosas, el DMA ha de detener al micro durante su ejecución, porque si no podría haber colisión y estar haciendo un DMA lyendo de RAM y a la vez la CPU escribiendo en la misma posición de RAM.
En estos sistemas que no son multitarea ni multihilo (vamos, que no tienen scheluder), todo tiene que esperar su turno; la forma en la que lo hagas es lo que hará que incremente el rendimiento o no de tu juego.
Y la ventana de descomprimir en WRAM es que no hay más narices: lees la entrada comprimida de ROM, procesas esos datos y los dejas en WRAM; si esos datos son tiles, les haces un DMA a VRAM; si es una paleta, pues los escribes en CGRAM, o si simplemente es el mapa de acción de una escena, los dejas donde están. No podrías descomprimir directamente a VRAM por varios motivos:
1) Es lento, ya que tienes que escribir en $2118/29 los dos bytes y estos registros se acceden en el banco $00 por lo que entonces el bucle de lectura desde ROM lo tendrías que hacer con direccionamiento largo
2) Es lento porque solo lo puedes hacer en el NMI (único momento en el que se puede escribir en VRAM), o bien poner la consola en forced vblank y entonces dejar la pantalla del juego en negro.
3) No es práctico porque normalmente la descompresión de bloques grandes puede durar un par de frames, por lo que por fuerza entonces tendrías que tener la pantalla en forced blank, si no irías viendo cómo se va actualizando la pantalla frame a frame y eso queda raro.
4) No es práctico porque los algoritmos de compresión se suelen basar en la repetitividad de los datos, por lo que tienes que ir a buscar datos repetidos a otras direcciones de memoria, y eso es muy incómodo y lento de hacer con la VRAM.

Señor Ventura escribió:Con respecto al SDD1, supongo que por el mismo motivo, descomprime tiles antes de enviarlos de la ROM a la VRAM a través del bus de datos, ¿no?. A menos que pueda acceder a las direcciones de memoria de la VRAM para meter mano a los tiles comprimidos desde ahí... de ser así, sería como tener un ancho de banda de casi 11KB por frame.

¿Cual es el método entonces?, ¿descomprime antes de enviar?, o una vez enviado.

Se podría acceder a las direcciones de VRAM, pero no es práctico ni sencillo. El SDD-1 no descomprime ni antes ni después de enviar, sino durante. Es la magia de ese chip. Desde el punto de vista del programador, éste programa un DMA para traerse unos datos desde ROM, ponte que es un escenario del SF2A; el chip SDD-1 monitoriza el bus y se da cuenta de que quieres hacer un DMA desde una dirección de ROM y entonces intercepta el DMA y empieza a traerse datos desde ROM, que está comprimidos. Los va descomprimiendo byte a byte y en cada ciclo de DMA, pone en el bus de datos un byte ya descomprimido. Como te comenté, el DMA es a 2,64MHz y el S-DD1 funciona con el master clock de 21,47MHz, así que antes de que tenga que pone el dato en el bus tiene 8 ciclos de reloj para descomprimir el dato. Además, trabaja con bus de 16 bits de cara a la ROM, eso quiere decir que en cada ciclo de lectura de datos comprimidos se trae 2 bytes y, en el peor de los casos, tendría que poner 1 de ellos en el bus de datos como byte descomprimido, así que virtualmente va 16 veces más rápido que el resto del sistema durante ese DMA.

Aprovecho para preguntar una cosilla sobre el msu1.
¿Hay algun tutorial en español de programación ?
Me gustaria hacer unas pruebas con alguna rom pero no tengo ni idea de por donde empezar.

titorino escribió:Aprovecho para preguntar una cosilla sobre el msu1.
¿Hay algun tutorial en español de programación ?
Me gustaria hacer unas pruebas con alguna rom pero no tengo ni idea de por donde empezar.

No lo hay casi ni en inglés; byuu tenía en su página toda la información necesaria para programar en él, pero por algún motivo, esa información ha desaparecido desde hace un tiempo. En NesDev tienes algunos post sobre el tema, pero en inglés.

Matadme si quereis, pero no deberian sacar el bad apple SIN msu1?

Es como hacer trampa, yo quiero sonidos y graficos de la snes original....si no que chiste tiene.

carlosyeah escribió:Matadme si quereis, pero no deberian sacar el bad apple SIN msu1?

Es como hacer trampa, yo quiero sonidos y graficos de la snes original....si no que chiste tiene.

Eso ya existe. Lo único que han añadido aquí es el audio a 32KHz directamente digitalizado, sin pasar por el SPC, y han comprimido el video (no sé si es necesario, ya que con el MSU1 no tienes limitaciones de espacio hasta los 96 megas que puede direccionar la SNES) lo cual da 15fps en vez de los 30fps de la versión sin MSU1.

Ya me extrañaba a mi. Retiro lo dicho

SUPER_ARU escribió:@Señor Ventura
estate mas tranquilo tio

la mejor versión de bad apple sin duda

https://www.youtube.com/watch?v=240Vq6tIxio

Hay gente con muuuucho tiempo libre

Una duda técnica:

magno escribió:La PPU de la SNES funciona a esos 21MHz, y necesita de 8 ciclos para completar las operaciones sobre cada píxel, por lo que digamos que se comportaría como si funcionara a 2.68MHz.

¿Podría ser este uno de los motivos por los que decidieron no dotar a la Snes de un outpout progresivo superior a los 256x224/39? ¿Porque no les salía "rentable" teniendo en cuenta la relativa lentitud de proceso? Después de todo a mayor número de pixels más operaciones sobre estos.

Al modo entrelazado de 512x448 sí le encuentro razón de ser para pantallas de inicio, menús, etc. Las 239 líneas de la vertical entiendo que "rascan" valioso tiempo de proceso en la C.P.U y que por eso apenas se usó ese ratio; de hecho juegos cómo Rendering Ranger R 2 usan ese outpout pero dejando líneas horizontales vacías...

magno escribió:El HDMA es como es, no es que esté limitado. el HDMA es Horizontal DMA y lo que hace es aprovechar el tiempo de HBlank de la señal de video para actualizar valores de la PPU. Esto hay que verlo así: la PPU es un subsistema formado por un micro que lee una memoria (la VRAM) para formar una imagen en pantalla. Mientras está dibujando píxeles (parte activa de la señal de video NTSC/PAL) no le puedes tocar la memoria ni su configuración, porque estarías cambiando los datos que en ese instante está "consumiendo" de VRAM. Por tanto te tienes que esperar que no hay zona activa para actualizar tanto los datos de VRAM como el resto de configuración de la PPU, y esto ocurre en el VBlank, que dura bastante y ocurre una vez cada frame, y ocurre también en el HBlank, que dura 4.7us y es muy corto, aunque se repite cada línea.

Entiendo, básicamente se trata de un excedente de tiempo que puedes emplear, y no un bus virtual adicional (excepto para transportar tiles, puesto que ya queda conformada la imagen del scanline pertinente en el frame buffer y no se puede alterar, aunque deduzco que si puedes traer tiles que si puedan servir para el siguiente frame, siempre y cuando el sistema de vídeo exija que el frame buffer se construya con todo lo que hay en la VRAM, sin zonas reservadas).

Entonces, el tiempo de HDMA para actuaizar datos puede servir para cambiar los parámetros de las PPU's, por ejemplo para calcular la posición de un plano en modo 7... pero ese tiempo tras cada dibujado de cada línea también se puede usar para comunicarse con el spc700 y su RAM en lugar de otras tareas, ¿no?.

La cuestión sería acortar el tiempo que requiere el dibujado de cada scanline, ya que eso dejaría mas tiempo para transferir mas por HDMA... pero como el sistema de vídeo funciona a la frecuencia a la que funciona, ¿no hubiera sido interesante interpretar por ejemplo los píxeles negros como "ausentes", y saltarse ese paso?, de ese modo llegas antes al final de cada línea, y te queda mas tiempo para lo que demandes.

¿Podría ser esta la manera en que la demo del bad apple consigue hacer streaming de audio a 32Khz por HDMA? (ya que casi todo es negro). Y si es así, ¿significa que puedes "escribir" un driver para que el sistema gráfico cambie su forma de funcionar?.

magno escribió:Todos los DMA del mundo mundial son secuenciales, ya que el bus a una memoria RAM suele ser único; por ejemplo en los ordenadores, el DMA se hace directamente sobre el bus de datos de la RAM normalmente con el northbridge de la placa base. Aquí pasa lo mismo y además, como el micro ya tiene las interrupciones usadas para otras cosas, el DMA ha de detener al micro durante su ejecución, porque si no podría haber colisión y estar haciendo un DMA lyendo de RAM y a la vez la CPU escribiendo en la misma posición de RAM.
En estos sistemas que no son multitarea ni multihilo (vamos, que no tienen scheluder), todo tiene que esperar su turno; la forma en la que lo hagas es lo que hará que incremente el rendimiento o no de tu juego.
Y la ventana de descomprimir en WRAM es que no hay más narices: lees la entrada comprimida de ROM, procesas esos datos y los dejas en WRAM; si esos datos son tiles, les haces un DMA a VRAM; si es una paleta, pues los escribes en CGRAM, o si simplemente es el mapa de acción de una escena, los dejas donde están. No podrías descomprimir directamente a VRAM por varios motivos:
1) Es lento, ya que tienes que escribir en $2118/29 los dos bytes y estos registros se acceden en el banco $00 por lo que entonces el bucle de lectura desde ROM lo tendrías que hacer con direccionamiento largo
2) Es lento porque solo lo puedes hacer en el NMI (único momento en el que se puede escribir en VRAM), o bien poner la consola en forced vblank y entonces dejar la pantalla del juego en negro.
3) No es práctico porque normalmente la descompresión de bloques grandes puede durar un par de frames, por lo que por fuerza entonces tendrías que tener la pantalla en forced blank, si no irías viendo cómo se va actualizando la pantalla frame a frame y eso queda raro.
4) No es práctico porque los algoritmos de compresión se suelen basar en la repetitividad de los datos, por lo que tienes que ir a buscar datos repetidos a otras direcciones de memoria, y eso es muy incómodo y lento de hacer con la VRAM.

¿Eso significa que el super mario world no descomprime directamente a la VRAM, sinoq ue descomprime a la WRAM, y de ahí a la VRAM?.

Sobre el papel te da igual tener tiles en WRAM y ROM que transferir a la VRAM, porque siempre le van a llegar datos a 2,68 mbits por segundo, hagas lo que hagas, ¿no?. La única diferencia que te podría dar un poco mas de rendimiento, es la que permita a dos memorias comunicarse con menos lag (si usas una ROM lenta, tal vez te resultaría mejor enviar comprimidos los datos a la WRAM, descomprimirlos, y luego enviarlos a la VRAM).


Sea como sea, para mi es un chasco, nada le va a llegar a la VRAM a una tasa mas rápida que 5,72KB/f (sin tocar los scanlines, se eniende).

magno escribió:Se podría acceder a las direcciones de VRAM, pero no es práctico ni sencillo. El SDD-1 no descomprime ni antes ni después de enviar, sino durante. Es la magia de ese chip. Desde el punto de vista del programador, éste programa un DMA para traerse unos datos desde ROM, ponte que es un escenario del SF2A; el chip SDD-1 monitoriza el bus y se da cuenta de que quieres hacer un DMA desde una dirección de ROM y entonces intercepta el DMA y empieza a traerse datos desde ROM, que está comprimidos. Los va descomprimiendo byte a byte y en cada ciclo de DMA, pone en el bus de datos un byte ya descomprimido. Como te comenté, el DMA es a 2,64MHz y el S-DD1 funciona con el master clock de 21,47MHz, así que antes de que tenga que pone el dato en el bus tiene 8 ciclos de reloj para descomprimir el dato. Además, trabaja con bus de 16 bits de cara a la ROM, eso quiere decir que en cada ciclo de lectura de datos comprimidos se trae 2 bytes y, en el peor de los casos, tendría que poner 1 de ellos en el bus de datos como byte descomprimido, así que virtualmente va 16 veces más rápido que el resto del sistema durante ese DMA.

Entiendo, con el SDD1 los datos ya están descomprimidos cuando viajan a través del bus.

Sexy MotherFucker escribió:¿Podría ser este uno de los motivos por los que decidieron no dotar a la Snes de un outpout progresivo superior a los 256x224/39? ¿Porque no les salía "rentable" teniendo en cuenta la relativa lentitud de proceso? Después de todo a mayor número de pixels más operaciones sobre estos.

Al modo entrelazado de 512x448 sí le encuentro razón de ser para pantallas de inicio, menús, etc. Las 239 líneas de la vertical entiendo que "rascan" valioso tiempo de proceso en la C.P.U y que por eso apenas se usó ese ratio; de hecho juegos cómo Rendering Ranger R 2 usan ese outpout pero dejando líneas horizontales vacías...

A 512 de resolución horizontal sigues teniendo disponible 224 pixels de resolución vertical.

a esa resolución vertical la cpu no se involucra mas solo porque ahora el PPU1 tenga que dibujar líneas mas largas... de hecho, si hubiese un cuello de botella en comparación con la resolución de 256x224, sería el sistema de vídeo quien la provoca.

Si a esa resolución se tarda lo mismo en conformar el frame buffer, entonces la composición de cada scanline es simplemente mas disperso. El DMA conservaría todo su tiempo para transferir datos, así que eso lleva a la conclusión de que a 512 de resolución horizonta pinta los pixels mas rápido que a 256, y este es el motivo por el que en esas condiciones hay un downgrade en cuánto a la profundidad de color. Siempre emplea 166 bytes por línea, a cuaquier resolución.

Esto sería así si la CGRAM es la responsable del número de ciclos que tarde el PPU1 en pintar cada pixels. Si no me equivoco, basta con reducir el número de colores (que casualmente es lo que ocurre), y por lo tanto no se debería perder tanto rendimiento como se presupone a 512x224).

La cuestión es si a 512x448 ya interviene la cpu, y cuánto.

Señor Ventura escribió:de hecho, si hubiese un cuello de botella en comparación con la resolución de 256x224, sería el sistema de vídeo quien la provoca.

Si precisamente eso es lo que estoy preguntando en el primer párrafo...

512x224

¿Este modo progresivo es viable? Es que no quiero caer en el típico argumento de que "en 16 años de scene nadie lo ha usado"; pero es que realmente desde 1990 entiendo que nadie lo ha usado en contexto de juego, si acaso para pantallas de presentación y poco más; ¿me estoy equivocando?

¿ @magno ?

En serio; me flipa tu capacidad para ver el vaso siempre medio lleno después de que te den jarrazos de agua fría una y otra vez; y sabes que yo te lo digo sin maldad xDD

Sexy MotherFucker escribió:

Señor Ventura escribió:de hecho, si hubiese un cuello de botella en comparación con la resolución de 256x224, sería el sistema de vídeo quien la provoca.

Si precisamente eso es lo que estoy preguntando en el primer párrafo...

Hombre, es que a 448p ahora la cpu tendría que controlar mas coordenadas para el desempeño de un juego, con sprites, etc.

Pero también el sistema de vídeo tiene que dibujar el doble de líneas reales, y de nuevo tendría que downgradear para tardar menos de los 8 ciclos por pixel que comenta magno.

Ahora, hay que decir también que en lo 8 ciclos que tarda por pixel, la PPU1 puede realizar 4 operaciones por pixel. Tal vez ese sea el tipo de requerimientos que se rebaja para pasar al siguiente pixel mas rápido.

Sexy MotherFucker escribió:¿Este modo progresivo es viable? Es que no quiero caer en el típico argumento de que "en 16 años de scene nadie lo ha usado"; pero es que realmente desde 1990 entiendo que nadie lo ha usado en contexto de juego, si acaso para pantallas de presentación y poco más; ¿me estoy equivocando?

En serio; me flipa tu capacidad para ver el vaso siempre medio lleno después de que te den jarrazos de agua fría una y otra vez; y sabes que yo te lo digo sin maldad xDD

Solo hay un juego que ha usado in game la resolución de 512x448. Podrían haberlo usado mas juegos, o directamente ninguno.

Lo que ya sería raro es que un sistema que usa una resolución entrelazada, no permita la mitad en progresivo.


Pero si quieres apostar...


P.D: No siempre me equivoco, me rompes el corazón xDD

@Señor Ventura que me estoy refiriendo a que si debido a que el PPU tarda 8 ciclos en completar operaciones por pixel; quizás debieron pensar que un outpout de 320x224 habría supuesto demasiado downgrade, y no querían tentar a los developers. El ejemplo de los 512x448 lo he puesto DE PASADA ya que estaba.

El resto son flipes emocionales tuyos defendiendo la Snes xDD

Esa es mi duda, y me gustaría que se me contestase en modo Snes-Defense-OFF para evitar impurezas.

Sexy MotherFucker escribió:@Señor Ventura que me estoy refiriendo a que si debido a que el PPU tarda 8 ciclos en completar operaciones por pixel; quizás debieron pensar que un outpout de 320x224 habría demasiado downgrade cómo para considerarlo aceptable. El ejemplo de los 512x448 lo he puesto DE PASADA ya que estaba.

El resto son flipes emocionales tuyos defendiendo la Snes xDD

Esa es mi duda, y me gustaría que se me contestase en modo Snes-Defense-OFF para evitar impurezas.

Coño, pues di 320x224 xDDD

A 320 pixels la información por cada scanline presumiblemente seguiría siendo de 166 bytes, dado que a 256 y a 512 cada scanline es conformada con 166 bytes de información.

Por lo tanto, lo que es seguro es que habría un downgrade gráfico, pero presumiblemente no de cpu.


editado: Necesitaría requerir menos de 8 ciclos por pixel, y para eso en teoría bastaría con no dedicar 4 operaciones por cada uno (por cada pixel).

Señor Ventura escribió:No siempre me equivoco, me rompes el corazón xDD

Que ya lo sé tonto, si de vez en cuando te envío pm's preguntándote paranoias de la Snes, y fisgoneo tu perfil en plan quien-tú-sabes para ver si has abierto algún hilo "techie" que me pueda interesar; es evidente que algún crédito personal te doy.

Coño, pues di 320x224 xDDD

Pensé que se sobreentendía xD. Y es que una de las pocas, poquísimas cosas, que yo siempre he valorado del hardware de la Snes es la alta frecuencia de reloj de sus PPUs; 21 megaherciacos, y ahora resulta que es una cifra algo engañosa. ¡Si el jarrazo de agua fría también ha sido pa mí! xDD

Visto el percal, cómo mínimo me planteo que si tuviese que cargar con 64 líneas de pixels más en la horizontal; pues a lo mejor se van al carajo, yo que sé, "colorines" y tal; y quizás eso a nivel comercial no le interesaba a Nintendo, así que sentenció a los developers a una cárcel de 256x224/39.

Son diarreas mentales dignas de ti, no me mires por encima del hombro (ni desde debajo) xDDD

La diferencia es que yo soy pesimista en lo referente a Snes, y tú optimista.

Oigan, las dos demos tienen el codigo fuente disponible, especialmente la de github, parece un paso a paso de lo bien explicada que esta

No es mas logico en vez de intentar adivinar que hicieron... ver el codigo, y hablar de "lo que se hizo"?

Sexy MotherFucker escribió:Pensé que se sobreentendía xD. Y es que una de las pocas, poquísimas cosas, que yo siempre he valorado del hardware de la Snes es la alta frecuencia de reloj de sus PPUs; 21 megaherciacos, y ahora resulta que es un cifra algo engañosa. ¡Si el jarrazo de agua fría también ha sido pa mí! xDD

No te fijes en eso, el resultado sigue estando ahí.

No sabía cuántos ciclos de reloj necesitaba para dibujar un pixel, aunque fíjate que yo siempre me había hecho a la idea de que serían unos 6, haciendo cálculos. Algo he hecho mal.

Lo que si sabía es que por cada pixel dibujado, el sistema de vídeo puede ejecutar 4 operaciones.

theelf escribió:Oigan, las dos demos tienen el codigo fuente disponible, especialmente la de github, parece un paso a paso de lo bien explicada que esta

No es mas logico en vez de intentar adivinar que hicieron... ver el codigo, y hablar de "lo que se hizo"?

Es que la conversación ha derivado un poquito xD

Sexy MotherFucker escribió:Una duda técnica:
¿Podría ser este uno de los motivos por los que decidieron no dotar a la Snes de un outpout progresivo superior a los 256x224/39? ¿Porque no les salía "rentable" teniendo en cuenta la relativa lentitud de proceso? Después de todo a mayor número de pixels más operaciones sobre estos.

Seguramente; ten en cuenta que si hay que procesar más píxeles en los 64 us que dura cada frame (esto viene impuesto por el sistema de TV) que dura una línea si quieres aumentar la resolución horizontal, o más líneas en cada frame de 16.6 mseg. La única forma de hacerlo es mejorar el pipeline de la PPU y hacer más operaciones por ciclo, o aumentar la frecuencia de reloj, normalmente a un múltiplo de los 21,44MHz y hacerlo funcionar a 42,88MHz.

Señor Ventura escribió:Entiendo, básicamente se trata de un excedente de tiempo que puedes emplear, y no un bus virtual adicional (excepto para transportar tiles, puesto que ya queda conformada la imagen del scanline pertinente en el frame buffer y no se puede alterar, aunque deduzco que si puedes traer tiles que si puedan servir para el siguiente frame, siempre y cuando el sistema de vídeo exija que el frame buffer se construya con todo lo que hay en la VRAM, sin zonas reservadas).

Exacto, de hecho usa el mismo controlador que el DMA para hacer la transferencia, por eso no puede haber un DMA y HDMA a la vez; esto no es un gran problema porque el DMA para enviar a VRAM solo se puede usar en el NMI, y durante el NMI no ocurren HBlanks, por lo que nunca saltaría el HDMA.

Señor Ventura escribió:Entonces, el tiempo de HDMA para actuaizar datos puede servir para cambiar los parámetros de las PPU's, por ejemplo para calcular la posición de un plano en modo 7... pero ese tiempo tras cada dibujado de cada línea también se puede usar para comunicarse con el spc700 y su RAM en lugar de otras tareas, ¿no?.

Exacto.

Señor Ventura escribió:La cuestión sería acortar el tiempo que requiere el dibujado de cada scanline, ya que eso dejaría mas tiempo para transferir mas por HDMA... pero como el sistema de vídeo funciona a la frecuencia a la que funciona, ¿no hubiera sido interesante interpretar por ejemplo los píxeles negros como "ausentes", y saltarse ese paso?, de ese modo llegas antes al final de cada línea, y te queda mas tiempo para lo que demandes.

No, no se puede acortar el tiempo de dibujado de un scanline: el estándar PAL define una duración de línea de pantalla de 64us siempre, de los cuales 52us son activos (píxeles que se ven en pantalla, tiempo en el que está la PPU trabajando) y 12us de borrado horizontal (pórticos, pulso de sincronismo, burst de color...). Así que el HDMA es una "ventana" de tiempo que se abre de 12 us cada 64us que tú puedes usar o no para hacer una transferencia.
Como es poco tiempo, el HDMA se deja programado al principio de cada frame y salta automáticamente cuando ocurre el HBlank, sin intervención de la CPU principal, que se queda en estado "stall" (parada con una instrucción metida en su pipeline).
De hecho, esto originaba el glitch del mapamundi que solucioné en el FF6 en PAL: el HDMA se configuraba en el NMI ya que éste en PAL dura más que en NTSC, y por tanto al principio del frame siguiente ya había saltado un HBlank que modificaba el scroll del mapa. Retrasándolo para que se configurara en la línea 0 del frame siguiente quedaba solucionado.

Señor Ventura escribió:¿Podría ser esta la manera en que la demo del bad apple consigue hacer streaming de audio a 32Khz por HDMA? (ya que casi todo es negro). Y si es así, ¿significa que puedes "escribir" un driver para que el sistema gráfico cambie su forma de funcionar?.

No, un pixel negro sigue siendo negro. El HBlank o VBlank no son píxeles negros, son "no-píxeles": es el tiempo que el haz de electrones tardaba en posicionarse al principio de una nueva línea o de un nuevo frame. El haz permanecía apagado durante ese tiempo, por lo que ningún pixel se iluminaba en pantalla.

Señor Ventura escribió:¿Eso significa que el super mario world no descomprime directamente a la VRAM, sinoq ue descomprime a la WRAM, y de ahí a la VRAM?.

No lo sé seguro, pero si hay que descomprimir TODOS los juegos que me he encontrado hasta ahora lo hacen primero a RAM y de ahí a VRAM.

Señor Ventura escribió:Sobre el papel te da igual tener tiles en WRAM y ROM que transferir a la VRAM, porque siempre le van a llegar datos a 2,68 mbits por segundo, hagas lo que hagas, ¿no?. La única diferencia que te podría dar un poco mas de rendimiento, es la que permita a dos memorias comunicarse con menos lag (si usas una ROM lenta, tal vez te resultaría mejor enviar comprimidos los datos a la WRAM, descomprimirlos, y luego enviarlos a la VRAM).

Exacto. Aunque hay un matiz: la ROM más lenta va a la misma velocidad del DMA. SlowROM requiere de 200ns de tiempo de acceso, es decir, 2.68MHz de reloj. Un juego FastROM requiere 120 ns como máximo de tiempo de acceso, es decir, 3.85MHz.

Señor Ventura escribió:Sea como sea, para mi es un chasco, nada le va a llegar a la VRAM a una tasa mas rápida que 5,72KB/f (sin tocar los scanlines, se eniende).

A la VRAM no le llega nada hasta que no ocurre un NMI, y durante ese tiempo, le llegarán datos con el DMA que programes.

Señor Ventura escribió:A 512 de resolución horizontal sigues teniendo disponible 224 pixels de resolución vertical.

a esa resolución vertical la cpu no se involucra mas solo porque ahora el PPU1 tenga que dibujar líneas mas largas... de hecho, si hubiese un cuello de botella en comparación con la resolución de 256x224, sería el sistema de vídeo quien la provoca.

Si a esa resolución se tarda lo mismo en conformar el frame buffer, entonces la composición de cada scanline es simplemente mas disperso. El DMA conservaría todo su tiempo para transferir datos, así que eso lleva a la conclusión de que a 512 de resolución horizonta pinta los pixels mas rápido que a 256, y este es el motivo por el que en esas condiciones hay un downgrade en cuánto a la profundidad de color. Siempre emplea 166 bytes por línea, a cuaquier resolución.

Esto sería así si la CGRAM es la responsable del número de ciclos que tarde el PPU1 en pintar cada pixels. Si no me equivoco, basta con reducir el número de colores (que casualmente es lo que ocurre), y por lo tanto no se debería perder tanto rendimiento como se presupone a 512x224).

La cuestión es si a 512x448 ya interviene la cpu, y cuánto.

Siento decir que no he entendido nada; no entiendo muy bien qué pinta la CGRAM en la resolución, ya que la CGRAM solo es una paleta de colores de donde cada tile elige un color para pintar cada píxel.
No sé si esto resuelve vuestras dudas, @Señor Ventura y @Sexy MotherFucker, pero os explico cómo se consigue la máxima resolución en SNES (512x448)
* Para conseguir la máxima resolución horizontal (512 píxeles), la PPU coge píxeles de la mainscreen para dibujar los píxeles en posiciones impares y de la sub-screen en posiciones pares. Si se quiere usar bien, la mainscreen tiene que ser una BG (BG1, por ejemplo) y la sub-screen otra DIFERENTE (BG2, por ejemplo). Podrían ser la misma BGx, pero no tendría sentido que para crear una zona de imagen más amplia tuvieras el mismo tilemap. Esto no hace que la PPU vaya más lenta, en esos 8 ciclos por píxel hace TODAS las operaciones que se le pidan, cualquier que se pueda programar a través de los registros. Lo único es que pierdes un BG para meter fondo de pantalla.

* Para extender la máxima resolución vertical (448 líneas), creo recordar que el tilemap se hacía el doble de alto, de modo que en vez de 32 tiles de alto, tiene 64 tiles. La PPU envía las líneas pares en un campo y las impares en otro, pero está limitado a usarlo en modo 5, que solo tiene BG1 de 16 colores y BG2 de 4 colores. Esto lo hace indicado solo para pantallas de intro o menús, como se usa en el menú del Seiken Densetsu 3 y del Romancing Saga 3, tendría que mirar cómo estaban hecho y ver qué otras implicaciones tiene.

@magno muchísimas gracias por atender las dudas, ahora las piezas de ese puzzle que es la Snes me encajan un poquito más.

Sólo una última cosa: Me queda claro que los PPU penalizarían bastante al subir de 256 hasta 320 líneas en progresivo en el caso de que se pudiese. Me queda claro cómo funciona el entrelazado de 512x448. Ahora bien; ¿entonces cómo dice Ventura la Snes puede generar un outpout progresivo de 512x224? Y de ser así; ¿a un coste menor o mayor que el del modo entrelazado?

Lo digo porque según entiendo yo el mundo analógico, debería costar lo mismo o más a nivel de PPU un ratio de 512x224p que uno de 512x448i; ya que después de todo los modos entrelazados desahogan bastante a las CPU/ GRÁFICAS al hacer dos muestreos de imagen para componerla; el primero, y luego el segundo sobre las líneas vacías que quedaron tras el primero llenando todo el espacio que daba forma a las scanlines.

Vamos que en entrelazado se reparte el trabajo en dos tandas, mientras que en progresivo se fuerza la maquinaria en un tiempo.

¿Cómo le influye eso a la Snes en un hipotético 512x224p VS 512x448i?

@magno gracias intentaré apañarme en inglés.
A ver si hago algo.

magno escribió:Siento decir que no he entendido nada; no entiendo muy bien qué pinta la CGRAM en la resolución, ya que la CGRAM solo es una paleta de colores de donde cada tile elige un color para pintar cada píxel.

En realidad nada, era una suposición basándome en la cantidad de memoria que es empleada por cada scanline, siendo que a mayor resolución esta permanece inalterable, y de ahí a interpretar que el decremento en el número de colores se debe tener mas pixeles para la misma información.

Pero no había tenido en cuenta que en el modo 5 cuentas con menos planos, que al fín y al cabo es equivalente a tener los 4 planos (superpuestos) del modo 0 a 256 pixels de resolución horizontal. Eso lo explica todo.

La cuestión es que a 512 de resolución horizontal el desempeño del sistema de vídeo es exactamente el mismo.

Sexy MotherFucker escribió:Ahora bien; ¿entonces cómo dice Ventura la Snes puede generar un outpout progresivo de 512x224? Y de ser así; ¿a un coste menor o mayor que el del modo entrelazado?

Y otro a 256x448.

448 entrelazado no deja de ser 224 en un frame, y los otros 224 en el siguiente, por lo que la cpu solo tiene en cuenta 224... pero la escena si tiene internamente una altura de 448 pixels, por lo que presumiblemente ciertas condiciones de un programa podría exigir tener en cuenta una mayor cantidad de coordenadas/colisiones, etc.

Algo debería influir, pero a saber...

Sexy MotherFucker escribió:¿Cómo le influye eso a la Snes en un hipotético 512x224p VS 512x448i?

Tendríamos que definir correctamente qué es para cada uno de nosotros los modos progresivos 512x224p y entrelazados 512x448i.
Un modo progresivo quiere decir que en cada frame se muestran todas las líneas posibles del dispositivo de visualización: en las TV analógicas, sería mostrar las 576 líneas 50 veces por segundo (PAL) o 480 líneas 60 veces por segundo (NTSC).
Según esta definición, 512x224p implica que la SNES dibuja las 224 líneas de un frame 60 veces por segundo (o 50 veces por segundo el PAL), y eso es exactamente lo que hace la SNES siempre en los modos normales: mostrar 224 líneas cada frame.
El modo 512x448i implica que la SNES muestra las 224 líneas pares 30 veces por segundo y las 224 líneas impares otras 30 veces por segundo, de modo intercalado. Esto es lo que hace en el modo interlaced que hablaba antes; este método es más complejo porque has de actualizar todo el contenido de VRAM cada NMI (que ocurre 60 veces por segundo en NTSC y 50 en PAL) y este contenido es aproximadamente 4 veces superior al del modo estándar 256x224p: has de transferir un tilemap el doble de grande (porque este tilemap ha de llevar las 224 líneas) y has de actualizar un background extra para conseguir la anchura de 512 píxeles. El problema de que tengas que actualizar dos BG puede ser un problemón si no te caben todas las tiles de gráficos en VRAM (aunque eso con un buen diseño de la escena se puede subsanar) y es un problemón porque los dos BG tienen un tilemap el doble de grande (por las 448 líneas).
Por eso este modo no es práctico para ningún juego con scroll y mucho despliegue gráfico.

@magno gracias de nuevo.

Siempre seguirá costando más el entrelazado porque rellena más en la vertical y entre otras cosas el espacio en vram es muy limitado.

De todas formas por lo que me has contestado antes entiendo que un modo pogresivo de 512x224 también penalizaría de la hostia a nivel de rendimiento gráfico; ya que habría que procesar más pixels por frame con un procesador de vídeo que tarda 8 ciclos en completar las operaciones en éstos. Vamos; que no veo un Contra III, un Street Fighter II Turbo, o un Earth Worm Jim a 512x224p con una calidad aceptable. De hecho a 320 ya habría que realizarles un downgrade en el caso que fuese posible ese outpout.

Muy posiblemente le pusieron el tope "realista" en 256x224/39 por si deslucía mucho a 320, y también supondrían que 512 en progresivo era una utopía en un juego de calidad media; por lo que nadie lo intentaría siquiera utilizarlo (cómo de hecho pasó).

Me imagino que le pusieron ese estandar para que la cpu fuese mas desaogada.
Un contra a 320 *224 a lo mejor recortando la paleta grafica podria haber sido posible.
Pero yo creo sexy que no le hace falta esa resolución para lucir bien.
Si te apañas bien y haces unos sprites adaptados puedes tener el campo de visión como quieras.
Te lo digo porque estoy jugando a ambos contras y no hecho en falta ese campo extra.
Me encantaría que compararas ambos juegos en una crt para ver las diferencias.
Creo que los desarrolladores sabian perfectamente las carencias de snes en ese apartado y supieron paliarlas muy bien.
Unos mejor que otros.

titorino escribió:Me imagino que le pusieron ese estandar para que la cpu fuese mas desaogada.

Hombre, en temas de resolución la C.P.U sólo sufre en la vertical, pero claro hay que tener en cuenta las colisiones (los pixels serían más pequeños a 320), refresco de animaciones, etc. Si a 256x224 la Snes ya sufre para mantener el campo de los sprites a 60 fps (no confundir con refresco de pantalla, que siempre será 50/60 hz), o tiene algunos problemas con las colisiones en sprites de 64x64 (según dicen, no lo afirmo del todo); no me quiero ni imaginar a 320x224, tanto por C.P.U, cómo por PPU.

Ya digo; si Nintendo puso el "stop" en 256x224/39 cómo contexto realista sería por algo. Si en los casi ¿2000? Juegos del catálogo de Snes no existe ninguno a 512x224p es por algo. Si en 16 años de scene nadie desarrolla a 512x224 es por algo.

Y estoy de acuerdo: A Contra III no le hace falta más resolución para ser un juegazo. Ni a ése, ni a muchísimos otros del espectacular catálogo de la Snes. De hecho uno de mis juegos favoritos 2D de la historia es Castlevania: Symphony of the Night, y rula a 256x240p nativos, hasta dejándose líneas en negro, y no veràs que nadie le critique la resolución horizontal.

Si te apañas bien y haces unos sprites adaptados puedes tener el campo de visión como quieras.

No estoy de acuerdo; SIEMPRE hay que renunciar a algo cuando conversionas un juego desde una resolución superior: O bien cierta nitidez, o bien los objetos son más "delgados" (o gordos), o bien líneas en negro y arriba y abajo. Todo lo que ganes (tiempo de proceso de la C.P.U), SIEMPRE es a cambio de algo. Pasa en la Saturn desde CPS-II, y pasa en Snes desde MD.

Sí, voy a abrir un hilo (se me acumulan xD), pero me falta equipo: CRTs gemelos, capturadoras de vídeo analógicas/digitales (porque eso de hacer fotos desde el móvil cómo que no), cable CSYNC para Snes, Snes 1-chip, etc. Me va a llevar algún tiempo.

@Sexy MotherFucker
Bueno pues quedamos a la espera.
Como tu mismo dices un ejemplo seria soft de psx.
No tenia ni idea de que corria a esa resolución y se ve del carajo con un margen de visión bastante amplio.

@titorino tambièn hay que tener en cuenta que la PS maneja infinidad de patrones distintos para los "sprites" (que en este caso se forman a partir de triàngulos), y que aunque no rellene todas las líneas en la vertical el tamaño del pixel es algo màs pequeño (nítido) que en Snes, ya que el frame-buffer es 240p literal nativo.

Hay muchos juegos a 256 en PS, empezando por los ports de Snes (FF VI, Chrono Trigger) etc.

Sexy MotherFucker escribió:De todas formas por lo que me has contestado antes entiendo que un modo pogresivo de 512x224 también penalizaría de la hostia a nivel de rendimiento gráfico; ya que habría que procesar más pixels por frame con un procesador de vídeo que tarda 8 ciclos en completar las operaciones en éstos. Vamos; que no veo un Contra III, un Street Fighter II Turbo, o un Earth Worm Jim a 512x224p con una calidad aceptable. De hecho a 320 ya habría que realizarles un downgrade en el caso que fuese posible ese outpout.

Muy posiblemente le pusieron el tope "realista" en 256x224/39 por si deslucía mucho a 320, y también supondrían que 512 en progresivo era una utopía en un juego de calidad media; por lo que nadie lo intentaría siquiera utilizarlo (cómo de hecho pasó).

En mi opinión, 16 tonalidades para un plano, y 4 para el segundo, no es una cosa tan mala para según que estilos gráficos. De hecho megadrive tiene 2 planos de 16 colores, y mira que bien le va en juegos como comix zone, por ejemplo.

Lo que si obligaría una resolución tan bestia como 512x224, es a vigilar el uso de la VRAM, pero lo cierto es que nunca se le sacó partido, y se puede, claro que se puede... con estilos visuales mas minimalistas que otra cosa, pero con una nitidez bastante brutita.

Para el que no sepa de donde viene esto como yo al principio
https://youtu.be/A4gETEv9o2s?t=6m7s