Sobre los tiempos de carga del street fighter alpha 2

Archivado
Me están diciendo que lo que causa el congelamiento es la transferencia de audio, que el sdd1 descomprime al vuelo y en tiempo real, y que no tiene nada que ver con los tiempos de carga.

Dice que con la rom con graficos descomprimidos pasa exactamente lo mismo.

Alguien puede documentarlo, o dar alguna explicación?
Es cierto que el audio es el causante de las pausas que se toma el juego. ¿Por que? Ni idea. Siempre he escuchado que es por una falta de optimización en la transferencia de datos del audio. Pero no sabría decírtelo con certeza.

Alguna vez he leído, y esto no creo que sea verdad, es que estas pausas deberían ser mas cortas. Pero cuando las programaron las alargaron para asegurarse que todo ya estaba cargado en memoria y listo para su ejecución.

Lo que me extraña es que en el Star Ocean esto no pase, o sea imperceptible. Así que dudo que sea problema del SDD-1, que no tendría sentido por lo que comentas.
Hola, unos amigos me comentaron que las cargas en principio no tienen mucho sentido, se basaron en que si, justo antes de acabar la carga del "Round 1 Fight", hacemos una mágia o movimiento, Super Nintendo lo registra, y el personaje lo ejecutará al empezar el round. Imagino que esto puede deberse a que el SDD descomprime por su cuenta, y en paralelo la CPU de Snes está libre para detectar los movimientos del pad, pero en mi ignorancia resulta bastante extraño.

Otro detalle relevante que me comentaron, es que una vez pasada la rom a disquetes, los "copiones" de Snes, como Pro Fighter, detectaban SFA2 como un juego de 28 Megas. Quizás la rom pasada a disquetes era menor porque faltaba el trabajo del SDD.

En su día se habló de que la versión final de SFA2 para Snes sufrió cambios importantes durante su desarrollo, que tal vez comprometieron la calidad del resultado final. Se dijo que la intención de Capcom era utilizar el chip de apoyo C4 (Megaman) o SA-1 (Kirby) en combinación con el SSD para descomprimir los datos.

http://www.unseen64.net/2009/09/28/stre ... snes-beta/

No tengo idea de qué descomprime el juego exactamente pero tal vez este embrollo de cambios tuvo alguna relación directa en el mantenimiento de unas cargas en principio innecesarias, en mi círculo de amistades es un tema muy recurrente y enigmático. Sólo en Super Juegos, creo que argumentaron las cargas por descompresión de la música, sabemos que sus redactores estaban infinitamente mejor documentados que los de Hobby Consolas, pero es dificil que supieran el motivo verdaero a ciencia cierta.

Gracias por abrir el hilo @Señor_Ventura, es un tema que a muchos nos sigue quitando el sueño :)


Saludos
El S-DD1 descomprime al "vuelo", es decir, cada vez que se pide un dato a la ROM, éste lo descomprime y lo devuelve a la memoria RAM o VRAM, y la CPU de la SNES no se entera de que el dato estaba originalmente comprimido. Todo esto se realiza haciendo DMA.

En cuanto a los tiempos de carga, efectivamente se producen por el driver de sonido, que tarda mucho en enviar todos los datos de sonido, pero esto me parece raro... Quizá el problema esté en que no se envían solo los datos del audio sino también los datos del programa que se ejecuta en la APU, que esto sí es lento de cojones.
Lo que no entiendo es porqué no se hizo esto durante el blanking, es decir, cuando ponen la pantalla en negro antes de empezar un round, hacen que dure un poco más y así tienen todo este tiempo para terminar las tareas que sean necesarias. Aunque se alargue el tiempo de la pantalla en negro, no queda tan mal como hacerlo justo antes del combate.
A mi lo que me ha hecho gracia siempre, es que le de por cargar justo despues del FIGHT y no antes, o durante la pantalla de Versus (que es cuando deberia cargar) esa carga es.. ¿un segundo? ¿uno y medio? apenas se notaría antes del Round One.... o en la pantalla de versus, pero despues del Fight es como un... STOP!!! XDDDDD

No me voy a quejar, porque el juego salió bien parido (con todos los personajes, escenarios y golpes especiales, incluso tenía a los personajes secretos -classic Chun Li y Evil Ryu-) y cuando nadie lo esperaba, fue un alegrón el Alpha 2 en SNES y es muy buen juego.
magno escribió:El S-DD1 descomprime al "vuelo", es decir, cada vez que se pide un dato a la ROM, éste lo descomprime y lo devuelve a la memoria RAM o VRAM, y la CPU de la SNES no se entera de que el dato estaba originalmente comprimido. Todo esto se realiza haciendo DMA.


De por si me parece un gran trabajo, y un port muy digno del juego, pero observo que la vram no se utiliza del todo ni de lejos, y hay escenarios a los que les falta algún detalle, por no hablar de los propios personajes (que tal vez, y solo tal vez, si el ancho de banda lo permite, podrían ser algo mas grandes gracias a que espacio físico en la vram queda de sobra para hacer una cosa u otra).

¿Que piensas del MSU1 en un port de este calibre, con su capacidad de comunicarse con la vram sin restricciones, y a 9 MBytes por segundo? (latencias aparte, aunque esto es residual).

magno escribió:En cuanto a los tiempos de carga, efectivamente se producen por el driver de sonido, que tarda mucho en enviar todos los datos de sonido, pero esto me parece raro... Quizá el problema esté en que no se envían solo los datos del audio sino también los datos del programa que se ejecuta en la APU, que esto sí es lento de cojones.


Es que es raro, porque de entrada hace cargas en todos los rounds, y siendo conocedores del problema lo que no tiene sentido es reiniciar el sonido todas las veces.
Además, que no me cuadra, porque los SFX y las músicas del juego no son ni mucho menos como para exigir al spc700. Algo pasa, como tu dices tiene que haber algo mas transfiriendose.

...ese driver de sonido, ¿se implementa por software? (desde el cartucho). No se hasta que punto es una limitación del hardware, y hasta que punto es el driver, pero si te paras a contar todos los parones hasta que comienza el combate, tienes por lo menos 5 segundos de congelamiento. Se me hace demasiado tiempo para cargar los 4 samples guarrindongos que tienen las músicas, y los pocos samples de efectos de sonido.
Es que si el congelamiento se debe al sonido, y no hay nada que interfiera en el proceso de transferencia, estaríamos hablando del juego peor optimizado (en esa tarea) de todo el catálogo, y si algo significa eso, es que entonces es innecesario.

magno escribió:Lo que no entiendo es porqué no se hizo esto durante el blanking, es decir, cuando ponen la pantalla en negro antes de empezar un round, hacen que dure un poco más y así tienen todo este tiempo para terminar las tareas que sean necesarias. Aunque se alargue el tiempo de la pantalla en negro, no queda tan mal como hacerlo justo antes del combate.


Pues si, porque a parte de ser mas rápido, se disimula mas... y ya de paso no reiniciar el sonido entre combate y combate, que ya es añadir mas problemas gratuítamente.
Señor Ventura escribió:De por si me parece un gran trabajo, y un port muy digno del juego, pero observo que la vram no se utiliza del todo ni de lejos, y hay escenarios a los que les falta algún detalle, por no hablar de los propios personajes (que tal vez, y solo tal vez, si el ancho de banda lo permite, podrían ser algo mas grandes gracias a que espacio físico en la vram queda de sobra para hacer una cosa u otra).

¿Que piensas del MSU1 en un port de este calibre, con su capacidad de comunicarse con la vram sin restricciones, y a 9 MBytes por segundo? (latencias aparte, aunque esto es residual).


Es que no limita el ancho de banda con la VRAM, sino la cantidad de sprites que puede mover la SNES y el famoso bug que no permite tener más de 31 sprites en el mismo scanline.

El MSU-1 transfiere datos pero de backgrounds, no de sprites, así que no creo que hubiera una mejora significativa.

Y efectivamente la VRAM está medio vacía porque así lo requiere este tipo de juegos, ya que solo se ha de cargar el escenario y sus pequeñas modificaciones por el movimiento, y los movimientos de los personajes, pero no todos de golpe, sino por ejemplo, los frames de respiración cuando están parados. No tendría sentido enviar todos los frames de todas las animaciones porque no cabrían y porque sería un desperdicio de tiempo.



Señor Ventura escribió:Es que es raro, porque de entrada hace cargas en todos los rounds, y siendo conocedores del problema lo que no tiene sentido es reiniciar el sonido todas las veces.
Además, que no me cuadra, porque los SFX y las músicas del juego no son ni mucho menos como para exigir al spc700. Algo pasa, como tu dices tiene que haber algo mas transfiriendose.

...ese driver de sonido, ¿se implementa por software? (desde el cartucho). No se hasta que punto es una limitación del hardware, y hasta que punto es el driver, pero si te paras a contar todos los parones hasta que comienza el combate, tienes por lo menos 5 segundos de congelamiento. Se me hace demasiado tiempo para cargar los 4 samples guarrindongos que tienen las músicas, y los pocos samples de efectos de sonido.
Es que si el congelamiento se debe al sonido, y no hay nada que interfiera en el proceso de transferencia, estaríamos hablando del juego peor optimizado (en esa tarea) de todo el catálogo, y si algo significa eso, es que entonces es innecesario.


Sí, tú puedes descargar un programa que se ejecute en la APU cuando quieras, por ejemplo, para que implemente una distorsión en las muestras, resampleado, generación de ruido, etc... Normalmente, en un juego eso lo haces al principio y nunca más, y cargas un programa (driver) en la APU que simplemente esté aceptando muestras que se envían desde la ROM. Pero si por ejemplo el programa/driver que gestiona el sonido de "Round 1" es diferente al que gestiona los sonidos durante la batalla (por ejemplo, unos son BRR, y otros samples a pelo), pues tienes que cambiar de driver por cojones justo tras que se reproduzca el sonido "Round 1".
Y es que transmitir el programa al dichoso chip de sonido es un puñetero infierno, ya que has de enviar byte a byte escribiendo en el registro correspondiente y luego leer de él para ver si se ha terminado de copiar dicho byte en la memoria de programa de la APU.
Hay un parche para poner star ocean descomprimido, igual cuando hagan lo mismo con éste salimos de dudas. El incentivo para que ésto ocurra será poder cargarlos en flashcart sin el chip específico.
magno escribió:Es que no limita el ancho de banda con la VRAM, sino la cantidad de sprites que puede mover la SNES y el famoso bug que no permite tener más de 31 sprites en el mismo scanline.


Según veo, un zangief vs zangief todavía está lejos de forzar ese límite, por lo que tal vez si sería posible apretar un poquito mas.

magno escribió:El MSU-1 transfiere datos pero de backgrounds, no de sprites, así que no creo que hubiera una mejora significativa.


Mi gozo en un pozo... ¿tiene su propio DMA que usa para fondos, y sin embargo usa el DMA de la consola para todo lo demás? (sprites, samples, o el mencionado driver de sonido). ¿Es una cuestión de configuración del SO del MSU1?, porque no creo que se deba a una limitación física. Creo que siendo un chip programable, como es un FPGA, tal vez las bases de funcionamiento del MSU1 deban plantearse un par de cambios...


Una posible solución tal vez sea transferir un fondo para el escenario, otro fondo para hacer del personaje de la izquierda, otro fondo para hacer del personaje de la derecha, y el cuarto fondo por hardware para elementos móviles como el avion de la fase de charlie... ya para las magias, y otros detalles, a base de sprites, y fuera. Seguiría siendo un monstruo gráfico gracias a la capacidad para animar todo eso, y sin restricción de tamaño, ¿no?. Tal vez incluso a resoluciones mayores que 256x224.

Pero bueno, sigue siendo muy interesante. Viendo el modo en que funcionan juegos como el wolfenstein, ¿significa eso que gracias al ancho de banda del msu1 no habría impedimento para transportar el plano a tope de resolución?, ¿o incluso a 512x400?... ¿o incluso no repetir bloques de información en los gráficos para que tengan mas detalle? (por ejemplo, que los muros no sean tan repetitivos).

Imagen


magno escribió:Y efectivamente la VRAM está medio vacía porque así lo requiere este tipo de juegos, ya que solo se ha de cargar el escenario y sus pequeñas modificaciones por el movimiento, y los movimientos de los personajes, pero no todos de golpe, sino por ejemplo, los frames de respiración cuando están parados. No tendría sentido enviar todos los frames de todas las animaciones porque no cabrían y porque sería un desperdicio de tiempo.


Vamos, que hubiese podido incrementarse la profundidad de color, el detalle de los escenarios, o incluso un aumento de sprites para hacer los personajes mas grandes... ya un aumento de frames en la animación de los personajes depende del ancho de banda, y por el momento sigue siendo una incógnita.

magno escribió:Sí, tú puedes descargar un programa que se ejecute en la APU cuando quieras, por ejemplo, para que implemente una distorsión en las muestras, resampleado, generación de ruido, etc... Normalmente, en un juego eso lo haces al principio y nunca más, y cargas un programa (driver) en la APU que simplemente esté aceptando muestras que se envían desde la ROM. Pero si por ejemplo el programa/driver que gestiona el sonido de "Round 1" es diferente al que gestiona los sonidos durante la batalla (por ejemplo, unos son BRR, y otros samples a pelo), pues tienes que cambiar de driver por cojones justo tras que se reproduzca el sonido "Round 1".
Y es que transmitir el programa al dichoso chip de sonido es un puñetero infierno, ya que has de enviar byte a byte escribiendo en el registro correspondiente y luego leer de él para ver si se ha terminado de copiar dicho byte en la memoria de programa de la APU.


Entonces el fallo es de diseño... ¿por qué no una única configuración del driver para todo?, lo cargas al principio, mientras se suceden la presentación de los logos, y fuera.

Se agradece la info, ignoraba completamente que el proceso fuese tan manual, la verdad.
Señor Ventura escribió:Según veo, un zangief vs zangief todavía está lejos de forzar ese límite, por lo que tal vez si sería posible apretar un poquito mas.


¿Estás seguro? Si lo has comprobado no tengo nada que decir, pero a mi me parece que el juego no debe de ir sobrado de sprites, teniendo en cuenta que un personaje lo forman muchos sprites de diferentes tamaños... Pensando en Treasure Hunter G, juego que me conozco bien, el personaje de Red lo forman hasta 8 sprites en según qué frame de animación esté, y el personaje es muy pequeño en comparación con estos. Ten en cuenta que las magias tb son sprites y que para evitar tener que controlar la cantidad de sprites por scanline, se suele limitar por diseño.
También está el factor de proporción... si los haces muy grandes, quedarían desproporcionados con respecto a los fondos, y hay que tener en cuenta la limitación de resolución de la SNES...



Señor Ventura escribió:Mi gozo en un pozo... ¿tiene su propio DMA que usa para fondos, y sin embargo usa el DMA de la consola para todo lo demás? (sprites, samples, o el mencionado driver de sonido). ¿Es una cuestión de configuración del SO del MSU1?, porque no creo que se deba a una limitación física. Creo que siendo un chip programable, como es un FPGA, tal vez las bases de funcionamiento del MSU1 deban plantearse un par de cambios...

Una posible solución tal vez sea transferir un fondo para el escenario, otro fondo para hacer del personaje de la izquierda, otro fondo para hacer del personaje de la derecha, y el cuarto fondo por hardware para elementos móviles como el avion de la fase de charlie... ya para las magias, y otros detalles, a base de sprites, y fuera. Seguiría siendo un monstruo gráfico gracias a la capacidad para animar todo eso, y sin restricción de tamaño, ¿no?. Tal vez incluso a resoluciones mayores que 256x224.

Pero bueno, sigue siendo muy interesante. Viendo el modo en que funcionan juegos como el wolfenstein, ¿significa eso que gracias al ancho de banda del msu1 no habría impedimento para transportar el plano a tope de resolución?, ¿o incluso a 512x400?... ¿o incluso no repetir bloques de información en los gráficos para que tengan mas detalle? (por ejemplo, que los muros no sean tan repetitivos).


A ver, a lo mejor no me he explicado bien con el MSU-1... éste tiene dos tareas fundamentales:

1) Reproducir música en PCM directamente desde una SD y, cuando se implementa en hardware, sacarla por los dos pines del conector del cartucho dedicados al audio analógico. Así haces by-pass por completo del chip de audio de la SNES poniendo en ADC en hardware.

2) Hacer streaming por DMA desde la tarjeta SD a la memoria de video (VRAM), dejando por tanto inutilizado casi todo el tiempo de blanking dependiendo de lo que envíes; por ejemplo, video a unos 18fps. Esto se hace a la velocidad del DMA de la SNES, es decir, 2.58MHz, y el MSU1 no mejora nada de esto. Lo que pasa es que al poder leer de un medio de almacenamiento de gran capacidad, se pueden meter los frames directamente en él y enviarlos tal cual se han de mostrar.



Señor Ventura escribió:Vamos, que hubiese podido incrementarse la profundidad de color, el detalle de los escenarios, o incluso un aumento de sprites para hacer los personajes mas grandes... ya un aumento de frames en la animación de los personajes depende del ancho de banda, y por el momento sigue siendo una incógnita.


Bueno, no necesariamente. El aumento de color no es posible porque limita la paleta y la cantidad de colores que se asigna para los sprites; esto ya está de por sí bastante bien explotado, quizá como mucho podrías mejorar el color del fondo, pero si haces un fondo de 8BPP, te quedas sin 2 planos para hacer scroll y dar sensación de profundidad.
El detalle de los escenarios depende de la resolución, porque al final meter más dibujos en las tiles no ocupa más espacio, teniendo en cuenta que una tile siempre se va a rellenar con algo, tenga colorines o sea negro ocupa lo mismo en VRAM.
El aumento de los frames de animación depende del ancho de banda de la VRAM, que no es mucho pero tampoco sería el cuello de botella aquí, y depende también de la velocidad con la que la CPU puede procesar colisiones y posiciones; en este tipo de juegos eso es primordial, por lo que se suele dedicar la CPU a eso antes que a actualizar en cada frame las animaciones.
Pero creo que ninguna de estas dos limitaciones se alcanzarán en el SFA2, y como siempre el problema estará en el almacenamiento en ROM; el SDD-1 logra un ratio de 2:1, lo cual quiere decir que el juego en total tendrá 64 megas de tamaño, y a lo mejor ahí no cabe un aumento de frames.


[/quote]
Entonces el fallo es de diseño... ¿por qué no una única configuración del driver para todo?, lo cargas al principio, mientras se suceden la presentación de los logos, y fuera.[/quote]

Esto es lo que se suele hacer en todos los juegos habidos de SNES, pero si quieres ser original y hacer cosas diferentes con el audio, no te queda más remedio que reprogramar la APU y eso es lento.
magno escribió:¿Estás seguro? Si lo has comprobado no tengo nada que decir, pero a mi me parece que el juego no debe de ir sobrado de sprites, teniendo en cuenta que un personaje lo forman muchos sprites de diferentes tamaños...


Zangief vs Zangief.

-La suma total de sprites de ambos personajes es de 58 sprites.
-El resto de "slots" están disponibles: 70 sprites.
-El número de sprites que mas llegan a coincidir en línea (en un movimiento concreto, aunque no los he mirado todos), en la suma de ambos personajes, es de máximo 18 sprites.
-Los tamaños de sprites están configurados a 8x8 y 16x16, y por lo tanto el número de tiles para sprites tampoco se puede decir que esté cerca de los 500 permitidos.
-Queda mínimo un 20% de la vram sin usar (tirando por lo bajo, aunque a la cuenta de la vieja).
-Se usan 14 sprites para dibujar unos pocos pixels de un codo, una mano, un pié... Vamos, que hubiera admitido optimizar el número de sprites con bastante margen.


En mi opinión, usando sprites de 32x32 podría ser que malgastes algunos tiles, y además necesitarías algunos sprites mas de 8x8 para completar un personaje, pero sería notablemente mas grande, pero...
-Con solo unos sprites obtienes el resultado, y no llegas al límite de 32 por scanline ni de lejos.
-El número de tiles dedicados a sprites tampoco alcanza los 500.
-El número de pixels por scanline tampoco alcanza los 256.


No se si se me escapa algo, pero básicamente parece bastante claro.

magno escribió:Pensando en Treasure Hunter G, juego que me conozco bien, el personaje de Red lo forman hasta 8 sprites en según qué frame de animación esté, y el personaje es muy pequeño en comparación con estos. Ten en cuenta que las magias tb son sprites y que para evitar tener que controlar la cantidad de sprites por scanline, se suele limitar por diseño.
También está el factor de proporción... si los haces muy grandes, quedarían desproporcionados con respecto a los fondos, y hay que tener en cuenta la limitación de resolución de la SNES...


Siempre puedes redibujar para que los personajes no se echen encima, y estén sin espacio.

De todos modos, por lo que observo todavía queda margen para las magias y otros detalles, incluso aumentando bastante el tamaño de los personajes. Otra cosa es la práctica, pero en un principio parece que es viable.

magno escribió:A ver, a lo mejor no me he explicado bien con el MSU-1... éste tiene dos tareas fundamentales:

1) Reproducir música en PCM directamente desde una SD y, cuando se implementa en hardware, sacarla por los dos pines del conector del cartucho dedicados al audio analógico. Así haces by-pass por completo del chip de audio de la SNES poniendo en ADC en hardware.

2) Hacer streaming por DMA desde la tarjeta SD a la memoria de video (VRAM), dejando por tanto inutilizado casi todo el tiempo de blanking dependiendo de lo que envíes; por ejemplo, video a unos 18fps. Esto se hace a la velocidad del DMA de la SNES, es decir, 2.58MHz, y el MSU1 no mejora nada de esto. Lo que pasa es que al poder leer de un medio de almacenamiento de gran capacidad, se pueden meter los frames directamente en él y enviarlos tal cual se han de mostrar.


Es decir, que cuando envías un background, inutilizas el tiempo de escritura que pudieras usar para sprites. Lo único, es que como envias el background tan rápido, en seguida podrías transferir los sprites los sprites, ¿no?.

La cuestión es que, ya que el msu1 es tan rápido transfiriendo planos, y que la snes puede manejar 4 por hardware, ¿no podría hacerse un "1 vs 1" usando únicamente planos?.

magno escribió:Bueno, no necesariamente. El aumento de color no es posible porque limita la paleta y la cantidad de colores que se asigna para los sprites; esto ya está de por sí bastante bien explotado, quizá como mucho podrías mejorar el color del fondo, pero si haces un fondo de 8BPP, te quedas sin 2 planos para hacer scroll y dar sensación de profundidad.
El detalle de los escenarios depende de la resolución, porque al final meter más dibujos en las tiles no ocupa más espacio, teniendo en cuenta que una tile siempre se va a rellenar con algo, tenga colorines o sea negro ocupa lo mismo en VRAM.
El aumento de los frames de animación depende del ancho de banda de la VRAM, que no es mucho pero tampoco sería el cuello de botella aquí, y depende también de la velocidad con la que la CPU puede procesar colisiones y posiciones; en este tipo de juegos eso es primordial, por lo que se suele dedicar la CPU a eso antes que a actualizar en cada frame las animaciones.
Pero creo que ninguna de estas dos limitaciones se alcanzarán en el SFA2, y como siempre el problema estará en el almacenamiento en ROM; el SDD-1 logra un ratio de 2:1, lo cual quiere decir que el juego en total tendrá 64 megas de tamaño, y a lo mejor ahí no cabe un aumento de frames.


Ando pillado de tiempo ahora mismo. De momento lo dejo así, pero luego comento alguna cosillas sobre esto.
Señor Ventura escribió:-El número de sprites que mas llegan a coincidir en línea (en un movimiento concreto, aunque no los he mirado todos), en la suma de ambos personajes, es de máximo 18 sprites.


Esto hay que verlo en el peor caso... si hay 18 en reposo, ¿qué ocurre cuando ambos personajes se golpean a la vez y caen? Estando en horizontal los dos personajes calculo que más de 32 van a haber casi seguro.


Señor Ventura escribió:-Los tamaños de sprites están configurados a 8x8 y 16x16, y por lo tanto el número de tiles para sprites tampoco se puede decir que esté cerca de los 500 permitidos.


¿500 permitidos? Esto no lo había oído nunca... De hecho, no hay límite para las tiles para sprites, solo que éstas van en bancos de 1024 direcciones en VRAM.


Señor Ventura escribió:-Se usan 14 sprites para dibujar unos pocos pixels de un codo, una mano, un pié... Vamos, que hubiera admitido optimizar el número de sprites con bastante margen.


Esto se hace por la detección de colisiones, ya que es más preciso hacer el cálculo en tiles 8x8 que en 16x16 o 32x32, y por tanto, es mejor tener sprites pequeños en el borde del personaje.


Señor Ventura escribió:En mi opinión, usando sprites de 32x32 podría ser que malgastes algunos tiles, y además necesitarías algunos sprites mas de 8x8 para completar un personaje, pero sería notablemente mas grande, pero...
-Con solo unos sprites obtienes el resultado, y no llegas al límite de 32 por scanline ni de lejos.
-El número de tiles dedicados a sprites tampoco alcanza los 500.
-El número de pixels por scanline tampoco alcanza los 256.


Si usas sprites 32x32, ya no puedes usar 8x8, ya que la configuración de sprites de la SNES no permite esta combinación. Igual que tampoco se ha usado nunca los 64x64 porque creo que hay un bug en la PPU. Luego está lo que te digo de la detección de colisiones, y que tampoco puedes superar 256 píxeles por scanline porque es la resolución nativa de la SNES XDDD


Señor Ventura escribió:Siempre puedes redibujar para que los personajes no se echen encima, y estén sin espacio.


¿Echar encima? No he entendido esto.




Señor Ventura escribió:Es decir, que cuando envías un background, inutilizas el tiempo de escritura que pudieras usar para sprites. Lo único, es que como envias el background tan rápido, en seguida podrías transferir los sprites los sprites, ¿no?.

La cuestión es que, ya que el msu1 es tan rápido transfiriendo planos, y que la snes puede manejar 4 por hardware, ¿no podría hacerse un "1 vs 1" usando únicamente planos?.


El tiempo que tienes para transferir datos a VRAM o PPU es el tiempo de blanking, así que si lo dedicas a transferir por DMA a través del MSU1, efectivamente te queda menos tiempo en ese frame para enviar el resto de cosas.
Y precisamente decía que el MSU1 no solo no es rápido, sino que es tan lento como la SNES, así que es como hacer un DMA desde ROM, igual.
Y lo de hacer un 1vs1 con planos solo tb lo había pensado yo alguna vez, pero no te creas que es fácil, ya que tendrías que "renderizar" toda la imagen antes de enviarla, calculando que parte de una tile 8x8 del fondo queda visible cuando pasa por delante el personaje, y eso es inviable.
magno escribió:Esto hay que verlo en el peor caso... si hay 18 en reposo, ¿qué ocurre cuando ambos personajes se golpean a la vez y caen? Estando en horizontal los dos personajes calculo que más de 32 van a haber casi seguro.


Pues había mirado unos cuántos movimientos, pero no se me había ocurrido mirarlo tumbado.
En el suelo, todo el personaje de zangief está formado por 20 sprites, pero por scanline no creo que lleguen a coincidir mas de 9 sprites.

De todos modos, reincido en lo ya dicho. Veo mucho desperdicio de sprites... ¡¡hay alguno que se usa para dibujar solo 6 pixels!!. Creo que se pudo haber optimizado algo mas.
En mi opinión, con toda esa cantidad sprites, y a tamaños de 32x32 y 16x16, se podría aumentar el tamaño de los personajes por un número parecido de sprites. Teniendo en cuenta que sobra VRAM, ese malgasto de tiles podría ser asumible.

El problema es el tamaño del cartucho, claro (y todo asumiendo que no habrán problemas de ancho de banda... que si tu dices que no, te creo, y pasamos a otra cosa XD).

NOTA: RETIRO LO DICHO. YA VEO CUAL ES EL OBJETIVO DE RODEAR EL PERSONAJE CON SPRITES DE 8x8 (tal y como comentas, un mejor desempeño en la detección de colisiones).

magno escribió:¿500 permitidos? Esto no lo había oído nunca... De hecho, no hay límite para las tiles para sprites, solo que éstas van en bancos de 1024 direcciones en VRAM.


¿Cada dirección = 1 tile?.

Entiendo entonces que no sería viable poner 128 sprites de 32x32, ¿puede ser?.

P.D: Hace poco se dijo por aquí. Me pareció bastante convincente la explicación, la verdad ^^

magno escribió:Esto se hace por la detección de colisiones, ya que es más preciso hacer el cálculo en tiles 8x8 que en 16x16 o 32x32, y por tanto, es mejor tener sprites pequeños en el borde del personaje.


Toma ya.

Intento hacerme una idea de a que se puede deber, pero no logro entender por qué puede ser eso. Al fín y al cabo, la tabla OAM dedica exactamente la misma cantidad de información para determinar cada sprite, independientemente de su tamaño. ¿Tal vez sea que se le da mas prioridad a los sprites pequeños, simplemente porque si?.

Por cierto, ya que hablamos del tema... siempre he tenido la siguiente duda:
El oam no es como dos tablas independientes, sino una sola tabla que se parte en dos (porque, digamoslo así, la información está interconectada). La primera tabla ocupa 512 bytes en la memoria de vídeo, y la segunda 32 bytes.

Es decir, que a parte de la información sobre la profundidad de color de los tiles en la vram, tenemos una primera tabla que determina:
-Byte 1: Posición X del sprite en la pantalla (0-255)
-Byte 2: Posición Y del sprite en la pantalla (0-255)
-Byte 3: Número de tile que representa al sprite. Este tercer byte conforma el aspecto final de los sprites.

-El cuarto byte está conformado por:

·1 bit para la posición horizontal
·1 bit para la posición vertical
·2 bits para la prioridad (superposición)
·3 bits para la paleta de colores
·1 bit para el número alto del tile (debe ser una cabecera que es usada de referencia en el tercer byte, para determinar con que otros se unen)


La segunda tabla proporciona 2 bits mas de información por sprite (128 sprites*2bits=256bits/8=32bytes), pero ahora mismo no se decir que funciones ocupan en ella, lo siento ^^u



¿Que hay con esto?.

magno escribió:
Señor Ventura escribió:Siempre puedes redibujar para que los personajes no se echen encima, y estén sin espacio.


¿Echar encima? No he entendido esto.


Si son demasiado grandes, estarían demasiado cerca xD

magno escribió:El tiempo que tienes para transferir datos a VRAM o PPU es el tiempo de blanking, así que si lo dedicas a transferir por DMA a través del MSU1, efectivamente te queda menos tiempo en ese frame para enviar el resto de cosas.
Y precisamente decía que el MSU1 no solo no es rápido, sino que es tan lento como la SNES, así que es como hacer un DMA desde ROM, igual.


No me refería a que físicamente hubiera algún bus con unas especificaciones superiores, sino a que transferir, transfiere a 9MB por segundo.

magno escribió:Y lo de hacer un 1vs1 con planos solo tb lo había pensado yo alguna vez, pero no te creas que es fácil, ya que tendrías que "renderizar" toda la imagen antes de enviarla, calculando que parte de una tile 8x8 del fondo queda visible cuando pasa por delante el personaje, y eso es inviable.


Eso tambien es verdad. Dibujar un plano es una tarea simple para la cpu, pero establecer un fondo que se anime con 7 cuadros de animación en un segundo, ya puede ser otra cosa... y mas aún cuando el otro plano que conforma al otro personaje tambien requiere de dibujar sus movimientos... y ya puestos, el resto del juego tambien requerirá su parte de ciclos de reloj. Puede que el MSU1 sea capaz de transferir todo eso a tiempo, pero la con la cpu no se ha probado nada parecido como para conocer cual su desempeño real en una tarea parecida.

Sobre la prioridad de los tiles para determinar cual queda visible, supongo que te refieres a cuando los personajes se acercan mucho, que la colisión detecta un obstáculo, pero los brazos suelen "clipear"... ¿no bastaría con que la propia prioridad de los planos determinen cual queda por delante, y cual por detrás?.



Esto es del otro post:

magno escribió:El aumento de los frames de animación depende del ancho de banda de la VRAM, que no es mucho pero tampoco sería el cuello de botella aquí, y depende también de la velocidad con la que la CPU puede procesar colisiones y posiciones; en este tipo de juegos eso es primordial, por lo que se suele dedicar la CPU a eso antes que a actualizar en cada frame las animaciones.


Quería preguntarte (antes de que se me olvidara xD)... hablando de buses, y de que el bus de datos de la snes es de 8 bits...

Me tiene sorprendido que con la mitad de ancho de banda, la tasa de transferencia quede tan razonablemente cerca de la megadrive. Es decir, que no debería rendir tanto, pero finalmente se equipara... ¿a que se debe?.
Magno escribió:¿500 permitidos? Esto no lo había oído nunca... De hecho, no hay límite para las tiles para sprites, solo que éstas van en bancos de 1024 direcciones en VRAM.

Sí existe limite, y es de 512. Es porque la variable que define el numero de tile que usará el sprite es de 9 bit(que puede ser de 0 a 511), esta "dividido" en dos partes: un byte completo define los 8 bits mas bajos y en otro byte se usa un bit adicional para el noveno bit). Lo de los "bancos", creo que te refieres al registro que define el "base addres" de los sprites, que es el lugar en Vram en donde estarán los sprites, pero esto no hace que se puedan usar mas de 512 tiles.

Y si alguien aun no me cree:
https://en.wikibooks.org/wiki/Super_NES ... ed_Sprites

De allí saqué esto:
By default, the SNES is limited to 16kB of sprite patterns, which is the same as: 512 8x8 sprites 128 16x16 sprites 32 32x32 sprites 8 64x64 sprites

Y se traduce mas o menos así: "por defecto Snes esta limitado a 16kB para sprites patterns, que es lo mismo que: 512 8x8 sprites, 128 16x16 sprites, 32 32x32 sprites, 8 64x64 sprites."

Señor Ventura la tabla OAM de sprites es así (esto ya lo había dicho antes en otro hilo pero... :-| ):

En total hay 544 bytes de una Ram interna para los sprites, primero hay 512 bytes que contienen 4 bytes por sprite que son:

byte 0 = X coordenada (8 bit)
byte 1 = Y coordenada (8 bit)
byte 2 = tile number (8 bit)
byte 3 = atributos: bit7 y-flip, bit 6 x-flip, bit 5-4 prioridad, bit 3-1 paleta numero, bit 0 = el noveno bit del "tile number" (con este bit se obtienen los 512 tiles).

Despues de los 512 bytes, hay otros 32 bytes adicionales, en donde se usan 2 bits por sprite, aqui esta el bit que define el tamaño del sprite y el noveno bit de la coordenada x, y como se usan 2 bits por sprite, en un byte estaran 4 sprites:

bit 7 = obj 3 size (0 = pequeño, 1 = grande)
bit 6 = obj 3 x coordenada (bit 9 de la coordenada x) con este bit se tienen los 512 valores para la posicion x del sprite.

bit 5 = obj 2 size (0 = pequeño, 1 = grande)
bit 4 = obj 2 x coordenada (bit 9 de la coordenada x)

bit 3 = obj 1 size (0 = pequeño, 1 = grande)
bit 2 = obj 1 x coordenada (bit 9 de la coordenada x)

bit 1 = obj 0 size (0 = pequeño, 1 = grande)
bit 0 = obj 0 x coordenada (bit 9 de la coordenada x)

siguiente byte:
bit 7 = obj 7 size (0 = pequeño, 1 = grande)
bit 6 = obj 7 x coordenada (bit 9 de la coordenada x)

bit 5 = obj 6 size (0 = pequeño, 1 = grande)
bit 4 = obj 6 x coordenada (bit 9 de la coordenada x)

....etc

Como podran ver la coordenada "Y" es de 8 bit, esto significa que solo puede variar de 0 a 255.


Y sobre el tema del hilo, los tiempos de carga se debe al sonido, antes de comenzar la pelea se cargan samples para las voces y luego se cargan los samples que se usara durante el juego y probablemente también la musica.
La imagen se "congela" porque el cpu debe dedicar todo su tiempo a cargar datos al APU, sobre esto ya habia escrito en otro hilo, asi que solo voy a copiar/pegar:
Esto se debe al sonido. Es porque cargar datos a la ram del chip de sonido es extremadamente lento, debido al (ridiculo) protocolo de transferencia que fue diseñado en el snes, que puede tardar hasta unos 2 segundos en cargar toda la ram (64kBytes).
Este es un ejemplo de como se hace la transferencia: primero existen 4 registros en los que el CPU se puede comunicar con el APU(cpu de sonido), al principio el CPU debe esperar a que el APU este listo para poder recibir datos(leyendo uno de los 4 registros), cuando esté listo el CPU envia un cero(este sería el contador de bytes) a uno de los registros y tambien envia el primer dato a otro registro, en este momento queda esperando la confirmacion de que el APU recibió el dato leyendo uno de los registros hasta que sea cero (en el lado del APU se lee el dato y se envía un cero para que el CPU sepa que ya recibió el dato), luego se envia el siguiente dato a un registro y ahora se envia un uno al otro registro(el "contador") indicando que es el siguiente dato,... se repetirá todo este proceso hasta completar todos datos que se enviaran(que pudiera ser hasta 64KB), la lentitud tambien se debe a que el APU funciona a 1MHZ y el CPU debe esperar mucho tiempo entre bytes que envía.
@gasega68k Gracias por la explicación, a veces paso por alto algún tipo de información porque no se puede estar a todo, pero muchas gracias por tomarte la molestia de explicar las cosas. Se agradece [oki]

Por cierto, una pregunta que quería hacerte sobre la capacidad del 68000 de la megadrive para descomprimir al vuelo, ¿conoces cual es el ratio aproximado por el que es capaz de descomprimir gráficos, siendo el del SDD-1 de 2:1?.
Señor Ventura escribió:@gasega68k Gracias por la explicación, a veces paso por alto algún tipo de información porque no se puede estar a todo, pero muchas gracias por tomarte la molestia de explicar las cosas. Se agradece [oki]

Por cierto, una pregunta que quería hacerte sobre la capacidad del 68000 de la megadrive para descomprimir al vuelo, ¿conoces cual es el ratio aproximado por el que es capaz de descomprimir gráficos, siendo el del SDD-1 de 2:1?.


Señor Ventura, a lo mejor se te paso por alto porque escribes demasiado [sonrisa] ... me he fijado que ambos nos registramos en enero de 2014... :O

Sobre la capacidad de descompresión eso depende, si quieres una gran compresión será mas lento, o poca compresión mas rápido (obvio), cada compañia hace su propio código de compresión. Ya el primer Sonic de MD/ Gen. tenía varias rutinas de descompresión para varios tipos de datos(gráficos, mapas, etc), incluso algunos juegos de Nes ya tenían compresión. Creo que el SDD-1 descomprime al momento, es decir sin esperar, pero no estoy muy seguro.
gasega68k escribió:Sí existe limite, y es de 512. Es porque la variable que define el numero de tile que usará el sprite es de 9 bit(que puede ser de 0 a 511), esta "dividido" en dos partes: un byte completo define los 8 bits mas bajos y en otro byte se usa un bit adicional para el noveno bit). Lo de los "bancos", creo que te refieres al registro que define el "base addres" de los sprites, que es el lugar en Vram en donde estarán los sprites, pero esto no hace que se puedan usar mas de 512 tiles.

Y si alguien aun no me cree:
https://en.wikibooks.org/wiki/Super_NES ... ed_Sprites


Eso que cuentas es para un sprite, pero nada impide que puedas usar toda la VRAM para hacer una animación. Para hacer una animación completa podrías usar dos páginas ("Name Base Address") y solo tendrías que cambiar 1 registro de la PPU. Por tanto, para hacer animación de personaje tienes teóricamente toda la VRAM disponible, ya que en cada frame puedes hacer un "doble buffer".




gasega68k escribió:Y sobre el tema del hilo, los tiempos de carga se debe al sonido, antes de comenzar la pelea se cargan samples para las voces y luego se cargan los samples que se usara durante el juego y probablemente también la musica.
La imagen se "congela" porque el cpu debe dedicar todo su tiempo a cargar datos al APU, sobre esto ya habia escrito en otro hilo, asi que solo voy a copiar/pegar:
Esto se debe al sonido. Es porque cargar datos a la ram del chip de sonido es extremadamente lento, debido al (ridiculo) protocolo de transferencia que fue diseñado en el snes, que puede tardar hasta unos 2 segundos en cargar toda la ram (64kBytes).
Este es un ejemplo de como se hace la transferencia: primero existen 4 registros en los que el CPU se puede comunicar con el APU(cpu de sonido), al principio el CPU debe esperar a que el APU este listo para poder recibir datos(leyendo uno de los 4 registros), cuando esté listo el CPU envia un cero(este sería el contador de bytes) a uno de los registros y tambien envia el primer dato a otro registro, en este momento queda esperando la confirmacion de que el APU recibió el dato leyendo uno de los registros hasta que sea cero (en el lado del APU se lee el dato y se envía un cero para que el CPU sepa que ya recibió el dato), luego se envia el siguiente dato a un registro y ahora se envia un uno al otro registro(el "contador") indicando que es el siguiente dato,... se repetirá todo este proceso hasta completar todos datos que se enviaran(que pudiera ser hasta 64KB), la lentitud tambien se debe a que el APU funciona a 1MHZ y el CPU debe esperar mucho tiempo entre bytes que envía.


Eso es lo que comentaba arriba XD


gasega68k escribió:Sobre la capacidad de descompresión eso depende, si quieres una gran compresión será mas lento, o poca compresión mas rápido (obvio), cada compañia hace su propio código de compresión. Ya el primer Sonic de MD/ Gen. tenía varias rutinas de descompresión para varios tipos de datos(gráficos, mapas, etc), incluso algunos juegos de Nes ya tenían compresión. Creo que el SDD-1 descomprime al momento, es decir sin esperar, pero no estoy muy seguro.


El ratio de compresión depende del algoritmo elegido y el tipo de datos que haya que comprimir. Muchos juegos de SNES tienen algoritmos de compresión software basados en RLE, LZ o más específicos para codificar planos de cada tile (como Seiken Densetsu 3, que tiene 3 tipos de algoritmos dependiendo de si codificas sprites, backgrounds y dependiendo de cómo sean estos).
El S-DD1 implementa un algoritmo aritmético que difícilmente es implementable por software sin comerte casi todo el tiempo de proceso de la CPU de estas consolas y bastante RAM. Este algoritmo va ajustando "dinámicamente" la probabilidad de aparición de cada bit, por lo que teóricamente podrías estar sacando bits a la salida sin tener bits de entrada (caso en el que la probabilidad de salida del mismo bit que el anterior fuera de 1) o muchos bits de salida con poquísimos de entrada (conforme la probabilidad de un bit tiende a 1).
Que gozada es leeros, @magno y @gasega68k, dan ganas de encadenaros al foro para que no os vayais muy lejos XD
Señor Ventura escribió:Que gozada es leeros, @magno y @gasega68k, dan ganas de encadenaros al foro para que no os vayais muy lejos XD


+1
magno escribió:Eso que cuentas es para un sprite, pero nada impide que puedas usar toda la VRAM para hacer una animación. Para hacer una animación completa podrías usar dos páginas ("Name Base Address") y solo tendrías que cambiar 1 registro de la PPU. Por tanto, para hacer animación de personaje tienes teóricamente toda la VRAM disponible, ya que en cada frame puedes hacer un "doble buffer".

Es que lo que dices no tiene sentido, si cambias este registro, que en realidad se llama "OBSEL" (es para "Object Size" y "Object Base") estarias modificando TODOS los sprites porque es un registro GLOBAL. Al cambiar el "base address" igualmente tendras 512 tiles al mismo tiempo, es decir seleccionas uno u otro "bloque" de 512 tiles.

El limite de 512 tiles, el tamaño de sprites y otras limitaciones, son algunas cosas que personas que conocen la consola(mucho mas que yo) y que incluso HAN programado en Snes se quejan:

http://forums.nesdev.com/viewtopic.php? ... es#p141206

Yo visito periodicamente "nesdev" para estar "al dia" con el desarrollo del homebrew en nes y snes, es un lugar dedicado principalmente a programacion de nes snes y gb, también he aprendido muchas cosas que antes no sabia de estas consolas, es muy recomendable para los fanáticos del "homebrew", sobretodo de nintendo. :)

magno escribió:El ratio de compresión depende del algoritmo elegido y el tipo de datos que haya que comprimir. Muchos juegos de SNES tienen algoritmos de compresión software basados en RLE, LZ o más específicos para codificar planos de cada tile (como Seiken Densetsu 3, que tiene 3 tipos de algoritmos dependiendo de si codificas sprites, backgrounds y dependiendo de cómo sean estos).
El S-DD1 implementa un algoritmo aritmético que difícilmente es implementable por software sin comerte casi todo el tiempo de proceso de la CPU de estas consolas y bastante RAM. Este algoritmo va ajustando "dinámicamente" la probabilidad de aparición de cada bit, por lo que teóricamente podrías estar sacando bits a la salida sin tener bits de entrada (caso en el que la probabilidad de salida del mismo bit que el anterior fuera de 1) o muchos bits de salida con poquísimos de entrada (conforme la probabilidad de un bit tiende a 1).

La compresion basado en RLE es el mas simple de hacer, aunque existen variaciones al final es el mismo principio: varios números consecutivos que sean iguales se reemplazan por uno solo y un numero que indica cuantas veces se repite ese numero. En wolfenstein 3d se usa una especie de RLE mas avanzado para los niveles(y que ellos llaman Carmack, no se porqué :p ) que también he implementado en la versión de Gen/MD.

El LZ ya es un poco mas complicado, también existen variaciones, pero sin ir muy a fondo se basa en "guardar" bloques de datos que se repetirán en un "diccionario"(así es llamado, es un espacio en ram) y que luego se asigna a un código que representará este bloque de datos, es decir este código que es el que quedará en el archivo representará un bloque de datos. Mas detalles sobre el LZ: https://es.wikipedia.org/wiki/LZW
En sonic incluso usan algoritmos basados en huffman que es mucho mas complejo y que ofrecen mayor compresión, la compresión basada en huffman se usa en diferentes tipos de archivos, se usa por ejemplo en el formato de imagen PNG que está basado en huffman y LZ77.
gasega68k escribió:Es que lo que dices no tiene sentido, si cambias este registro, que en realidad se llama "OBSEL" (es para "Object Size" y "Object Base") estarias modificando TODOS los sprites porque es un registro GLOBAL. Al cambiar el "base address" igualmente tendras 512 tiles al mismo tiempo, es decir seleccionas uno u otro "bloque" de 512 tiles.


No has entendido nada por lo que veo, porque no lees bien. Estoy hablando desde el principio de una ANIMACIÓN para un juego de luchas 1 vs 1, por lo que al cambiar el registro OBSEL cambias todos los sprites al mismo tiempo, exactamente lo que quieres para el siguiente frame de animación. Y sí, tienes 512 al mismo tiempo, pero puedes usar virtualmente toda la VRAM para sprites, que es lo que hablaba desde el principio.
Esto se usa en el menú del Romacing Saga 3, por si quieres saber que esto SÍ tiene sentido.



gasega68k escribió:El limite de 512 tiles, el tamaño de sprites y otras limitaciones, son algunas cosas que personas que conocen la consola(mucho mas que yo) y que incluso HAN programado en Snes se quejan:

http://forums.nesdev.com/viewtopic.php? ... es#p141206

Yo visito periodicamente "nesdev" para estar "al dia" con el desarrollo del homebrew en nes y snes, es un lugar dedicado principalmente a programacion de nes snes y gb, también he aprendido muchas cosas que antes no sabia de estas consolas, es muy recomendable para los fanáticos del "homebrew", sobretodo de nintendo. :)


¿¿No me digas?? Qué bien que pases por nesdev, igual si de verdad te leyeras los hilos verías quién postea por allí también.
Y sí, los que programamos juegos, entre los que me encuentro desde hace años, nos quejamos de muchas cosas, pero también aprendemos de otros para ir superando los límites técnicos de las consolas y no vamos de listo contestando cosas en los foros que solo hemos leído.


gasega68k escribió:La compresion basado en RLE es el mas simple de hacer, aunque existen variaciones al final es el mismo principio: varios números consecutivos que sean iguales se reemplazan por uno solo y un numero que indica cuantas veces se repite ese numero. En wolfenstein 3d se usa una especie de RLE mas avanzado para los niveles(y que ellos llaman Carmack, no se porqué :p ) que también he implementado en la versión de Gen/MD.

El LZ ya es un poco mas complicado, también existen variaciones, pero sin ir muy a fondo se basa en "guardar" bloques de datos que se repetirán en un "diccionario"(así es llamado, es un espacio en ram) y que luego se asigna a un código que representará este bloque de datos, es decir este código que es el que quedará en el archivo representará un bloque de datos. Mas detalles sobre el LZ: https://es.wikipedia.org/wiki/LZW
En sonic incluso usan algoritmos basados en huffman que es mucho mas complejo y que ofrecen mayor compresión, la compresión basada en huffman se usa en diferentes tipos de archivos, se usa por ejemplo en el formato de imagen PNG que está basado en huffman y LZ77.



¿Y todo esto a qué viene?
magno escribió:No has entendido nada por lo que veo, porque no lees bien. Estoy hablando desde el principio de una ANIMACIÓN para un juego de luchas 1 vs 1, por lo que al cambiar el registro OBSEL cambias todos los sprites al mismo tiempo, exactamente lo que quieres para el siguiente frame de animación. Y sí, tienes 512 al mismo tiempo, pero puedes usar virtualmente toda la VRAM para sprites, que es lo que hablaba desde el principio.
Esto se usa en el menú del Romacing Saga 3, por si quieres saber que esto SÍ tiene sentido.


Bueno, creo que no me he explicado bien, y me disculpo por ello. Si he entendido, y no estoy diciendo que no puedes hacer eso, y cuando digo que no tiene sentido es que no necesitas hacer eso, y mas aun para un juego de luchas 1 vs 1 en donde realmente no necesitas tantos tiles para sprites ni siquiera 256 tiles, pero aun en el caso de que quisieras hacer un juego de lucha en donde usarías 512 tiles para los personajes(la mitad para cada uno), aun así no necesitas usar otros 512 tiles para hacer un "doble buffer" y voy a explicar detalladamente porqué. En el caso que quieras hacer esto con dos bloques de 512 tiles y ademas suponiendo que necesitaras todos los 512 tiles(aunque no creo que se necesiten tantos) para hacer la animación necesitarías 3 frames para ello y obtendrías un máximo de 20 cuadros por segundo, ya que como sabes solo se pueden transferir un poco mas de 6KB con DMA por frame durante VBLK, y 512 tiles son 16KB, pero también pudieras extender un poco el vblk(unas 16 lineas) y así solo necesitarías 2 frames para transferir y obtendrías 30 cuadros por segundo de animación.
Ahora puedes hacer exactamente lo mismo sin usar dos bloques de 512 tiles de esta manera: extendiendo también el VBLK y usando 256 tiles para cada personaje, solo necesitarías transferir un bloque de 256 tiles(que sería un personaje) en un frame y los otros 256 tiles en otro frame y así obtendrías 30 cuadros de animación para cada personaje usando solo 512 tiles. Ademas con el método del "doble buffer" siempre tendrías que actualizar todo el espacio de 512 tiles aun cuando solo uno de los personajes necesitara cambiar la animación, a diferencia del ejemplo que puse en el que solo necesitarías actualizar cuando sea necesario.
Entonces, ¿malgastarías 512 tiles para hacer un "doble buffer" cuando pudieras hacer lo mismo con solo 512 tiles, y solo con el pequeño sacrificio de restarle solo un poco el tamaño de la imagen? esto lo hacen (forzar el vblank para obtener un poco mas de DMA) todos los Street Fighter y varios beat'em up como los Final Fight, Combatribes, etc, es algo común de hacer.

En donde sí pudieras usar el registro OBSEL para obtener mas tiles es en juegos con pantalla dividida, en donde tendrías otro grupo de 512 tiles y de hecho en SMK lo hacen aunque no modificando el base address sino el obj GAP, que es para "separar" los dos bloques de 256 tiles, en la "pantalla" superior el Gap está en 0 y en la de abajo lo cambian a $1000, y así obtienen tres bloques de 256 tiles, uno es común para ambas divisiones de pantalla, y los otros dos bloques son para cada una de las "pantallas".

Y sobre el Romacing Saga 3, no se exactamente en donde dices, probé el juego en el no$sns, vi en los menús, no vi nada que me indique que se esté haciendo esto, también vi durante las peleas y lo que observé es que usan un background en lugar de sprites cuando es un enemigo grande, no se si es a esto que te refieres.


magno escribió:¿¿No me digas?? Qué bien que pases por nesdev, igual si de verdad te leyeras los hilos verías quién postea por allí también.

Si, aunque no lo creas visito MUY periódicamente nesdev y leo mucho también, y estoy seguro que bastante mas que muchos que están registrados allí. Ademas no sabía que estabas registrado allí, porque realmente es muy difícil recordar nombres y si me dices en que temas o hilos has escrito seguramente recordaré haberlo leído. Quizás no sabia que estabas en nesdev porque he visto que no estas muy activo allí (166 mensajes en 9 años), ademas si visitaras algunos de los foros en los que estoy registrado seguramente no sabrías que estoy allí porque tampoco estoy muy activo. :)
Uno puede recordar nombres de personas que hayan hecho cosas que sobresalen o que se los vea muy activo en el foro, por ejemplo puedo recordar nombres de personas como "Tepples"(uno de los administradores del sitio) y que recuerdo que publicó a principios de año un demo de scaling de sprites para Nes, tambien se que esta desarrollando un juego para nes con alguien que lo contrato, también recuerdo a "Psycopathicten" que fue el que hizo el demo del bad aple para snes (con la ayuda de Tepples) y también mostró un demo de un "Gunstar heroes" para Snes, recuerdo a "Khaz" porque hizo un demo de un video de Sonic cd con el MSU y que publico recientemente un video, y que también esta haciendo un juego al estilo Sonic para Snes aunque nunca ha publicado un demo, también recuerdo a "Tokumaru" que programa para Nes y que hace un buen tiempo hizo un demo de raycast para nes, y que también mostró imágenes de gráficos de sonic para nes que él hizo, esta tambien "Espozo" que aunque no ha hecho muchas cosas está muy activo en el foro, también se que le gusta Doom porque lo ha dicho varias veces [carcajad] , está "rainwarrior" que programa para Nes, también recuerdo a "undisbeliver"(o algo así)que ha hecho varias cosas en Snes, Cris covell esta allí también, muy conocido en este mundo del homebrew...etc, etc, etc y pudiera continuar mencionando a mas personas y cosas que he visto allí, para demostrarte que si visito muy seguido nesdev, porque simplemente me gusta el homebrew, sobretodo de consolas de 8 y 16 bit. :)

magno escribió:Y sí, los que programamos juegos, entre los que me encuentro desde hace años, nos quejamos de muchas cosas, pero también aprendemos de otros para ir superando los límites técnicos de las consolas y no vamos de listo contestando cosas en los foros que solo hemos leído.

Bueno, como dije anteriormente no sabía que estabas registrado en nesdev, y realmente me interesaría saber que cosas has programado. Y aunque me quejo de cosas del Snes, también me quejo de cosas del Genesis/MD, y es que es precisamente como dices, conociendo los limites de la maquina es que puedes ir superándolos o al menos buscar la manera de que no se "noten" estos limites o buscar maneras diferentes de hacer las cosas. Yo he visto gente "contestando cosas" en muchos foros, aun sin haber programado nada simplemente porque tienen conocimientos, ademas creo que conozco lo suficiente sobre algunas cosas y no veo nada de malo en ello ¿acaso algo de lo que he dicho sobre el Snes no es verdad?

magno escribió:
gasega68k escribió:La compresion basado en RLE es el mas simple de hacer, aunque existen variaciones al final es el mismo principio: varios números consecutivos que sean iguales se reemplazan por uno solo y un numero que indica cuantas veces se repite ese numero. En wolfenstein 3d se usa una especie de RLE mas avanzado para los niveles(y que ellos llaman Carmack, no se porqué :p ) que también he implementado en la versión de Gen/MD.

El LZ ya es un poco mas complicado, también existen variaciones, pero sin ir muy a fondo se basa en "guardar" bloques de datos que se repetirán en un "diccionario"(así es llamado, es un espacio en ram) y que luego se asigna a un código que representará este bloque de datos, es decir este código que es el que quedará en el archivo representará un bloque de datos. Mas detalles sobre el LZ: https://es.wikipedia.org/wiki/LZW
En sonic incluso usan algoritmos basados en huffman que es mucho mas complejo y que ofrecen mayor compresión, la compresión basada en huffman se usa en diferentes tipos de archivos, se usa por ejemplo en el formato de imagen PNG que está basado en huffman y LZ77.



¿Y todo esto a qué viene?

Quizás cometí un error al quotear tu mensaje, pero simplemente quería comentar un poco sobre algunos tipos de compresión y un poco sobre mi experiencia en ese tema para la gente que no tiene idea de lo que se esta hablando aquí, eso es todo. ;)


Finalmente quisiera aclarar a todos que aunque me conozcan como "Gasega68k", no significa que sea un "anti-nintendo", he programado algunas cosas para Nes y no descarto también programar algo para Snes en un futuro, sobretodo con el chip Sfx, no quisiera que se hiciera una idea errada de mi, como si por haber programado para la consola de Sega entonces "estoy en contra de nintendo", como algunos pudieran pensar.

Saludos a todos.
Esta muy bien eso de entrada en nesdev, ver el nick de 4 personas y decir que entras mucho... Yo he posteado 166 mensajes en 9 años, y sí soy activo, entro 5 veces por semana, pero no voy contestando tonterías como otros.

Y para zanjar tu "sobrada" de contestación, simplemente visita mi página http://magno.romhackhispano.org/ y me dices lo que he programado o no para SNES, a parte del juego de RPG que tengo en fase de desarrollo. Y ya de paso, buscas el código ASM que liberé del Romancing Saga 3 (no está en mi página, pero como eres "tan activo" en la escena, lo encontrarás sin problemas) y así verás como hace lo que te digo, no solo en los sprites, sino en los BGs también cuando se entra en los submenús.
magno escribió:Esta muy bien eso de entrada en nesdev, ver el nick de 4 personas y decir que entras mucho... Yo he posteado 166 mensajes en 9 años, y sí soy activo, entro 5 veces por semana, pero no voy contestando tonterías como otros.

Y para zanjar tu "sobrada" de contestación, simplemente visita mi página http://magno.romhackhispano.org/ y me dices lo que he programado o no para SNES, a parte del juego de RPG que tengo en fase de desarrollo. Y ya de paso, buscas el código ASM que liberé del Romancing Saga 3 (no está en mi página, pero como eres "tan activo" en la escena, lo encontrarás sin problemas) y así verás como hace lo que te digo, no solo en los sprites, sino en los BGs también cuando se entra en los submenús.


Primero quiero comenzar pidiéndote disculpas si te ofendí de alguna manera por alguno de mis mensajes.
Y sobre nesdev, no puedo entrar y ver el nick de la gente para ver lo que ha publicado porque tengo que estar registrado y lo digo de nuevo, si entro muy frecuentemente a nesdev(casi todos los dias), y cuando mencioné lo de los mensajes que tienes allí es porque precisamente es por eso que es difícil para mi poder ver lo que has escrito porque tengo que estar registrado.
Cuando te pedí que me dijeras que habías programado no estaba dudando de ti, fue una petición sincera simplemente quería saber un poco que has hecho, bueno y sobre el RS3 tampoco estaba dudando de lo que decías, simplemente que no pude ver en donde se hacia esto.

En fin, creo que debemos dejar esto por la paz, esto creo que ya se convirtió en una discusión sin sentido que ya se desvió demasiado del tema original del hilo, otra vez te pido disculpas si te ofendí de alguna manera, también a veces es difícil interpretar los mensajes cuando son escritos y se pueden prestar a malos entendidos.
[bye]
gasega68k escribió:En fin, creo que debemos dejar esto por la paz, esto creo que ya se convirtió en una discusión sin sentido que ya se desvió demasiado del tema original del hilo, otra vez te pido disculpas si te ofendí de alguna manera, también a veces es difícil interpretar los mensajes cuando son escritos y se pueden prestar a malos entendidos.
[bye]


100% de acuerdo :)
24 respuestas
Archivado
Volver a Consolas clásicas