Street Fighter 2 CE - Sega Megadrive - Sound driver patch

Se había entendido perfectamente la ironía..... no hacía falta explicarla jeje.

Yo solo digo que Manveru sabe de que habla...y no lo digo por decir

sgonzalez escribió:Se había entendido perfectamente la ironía..... no hacía falta explicarla jeje.

No sé dónde ves la ironía en:

Señor Ventura escribió:Tile a tile tal vez si, pero los sprites de los personajes no tienen nada que no pueda manejar una megadrive (o super nintendo).

De hecho, ya se han visto casos de personajes mas grandes que los del street fighter 2, desde luego que no será por poca capacidad de manejo de sprites.

kusfo79 escribió:Yo solo digo que Manveru sabe de que habla...y no lo digo por decir

Guiño guiño, pero vamos no sé nada que no me hayáis enseñado vosotros

Manveru Ainu escribió:

theelf escribió:Explicalo, que da curiosidad... si es con algun codigo mejor

Nada era simplemente porque había comentado que "Un street fighter 2 de cps1 corriendo en una megadrive, no tiene ningún misterio.." y me había sonado un poco mal y sobradete. ¿Es posible? no lo sé, pero esa opinión va demasiado a la ligera. Por no entrar demasiado en detalle, decir que la cantidad de ram y la velocidad de transferencia a ésta son limitadas, como todos más o menos sabremos. No es tan sencillo como "no tiene ningún misterio" hacer tragar a la mega sprites completamente animados tan grandes.

No se en que datos tecnicos se basan unos y otros...


Un sprite medio de Street Fighter 2 de CPS1, tiene 6x10 tiles de media, y unos 9x12 tiles maximo, eso son 108 tiles por frame de animacion maximos

Magias varias son unos 7x6 maximo, 42 tiles maximo

Barra de vida, contadores, etc otros 60 tiles como maximo, ademas, que no cuentan como sprite


Eso da 210 tiles por personaje, 420 tiles por los dos, maximo.. la megadrive puede almacenar en vram 1344 tiles si mal no recuerdo ahora mismo, incluyendo el espacio de fuente, lo que da unos 900 y pico tiles para los fondos

Y no se saturaria ningun limite de sprites tampoco


Realmente, de forma tecnica, no veo donde esta el problema

theelf escribió:Eso da 210 tiles por personaje, 420 tiles por los dos, maximo.. la megadrive puede almacenar en vram 1344 tiles si mal no recuerdo ahora mismo, incluyendo el espacio de fuente, lo que da unos 900 y pico tiles para los fondos

Y no se saturaria ningun limite de sprites tampoco


Realmente, de forma tecnica, no veo donde esta el problema

Eso está bien si quieres presentar una bonita pantalla con un fondo y dos sprites estáticos. Si quieres que se animen y muevan tendrás que actualizar esos 420 tiles de los personajes (son bastante menos de 420 por cierto) en la vram, aparte de actualizar los scrolls y demás.

Lucho ya lo demostró con su mini-demo de SF2 "arcade" en MD, ¿no?

hombreimaginario escribió:Lucho ya lo demostró con su mini-demo de SF2 "arcade" en MD, ¿no?

ejem, no

hombreimaginario escribió:Lucho ya lo demostró con su mini-demo de SF2 "arcade" en MD, ¿no?

Lo que hizo Lucho es cojonudo pero presentaba a Ryu y Ken con los frames de posición de pie parados que, si no me falla la memoria, eran unos 80 tiles por barba. El problema son los frames mayores, por no hablar de los frames gigantes de Sagat, Zangief y cía.

Manveru Ainu escribió:

hombreimaginario escribió:Lucho ya lo demostró con su mini-demo de SF2 "arcade" en MD, ¿no?

Lo que hizo Lucho es cojonudo pero presentaba a Ryu y Ken con los frames de posición de pie parados que, si no me falla la memoria, eran unos 80 tiles por barba. El problema son los frames mayores, por no hablar de los frames gigantes de Sagat, Zangief y cía.

Y hablamos con conocimiento de causa por que estamos con Lucho...

Ya estamos otra vez con el Pulstar en Megadrive full-equip ? xD

Manveru Ainu escribió:Eso está bien si quieres presentar una bonita pantalla con un fondo y dos sprites estáticos. Si quieres que se animen y muevan tendrás que actualizar esos 420 tiles de los personajes (son bastante menos de 420 por cierto) en la vram, aparte de actualizar los scrolls y demás.

Disculpame, si el cartucho es rom.. donde esta el problema?

FFantasy6 escribió:Ya estamos otra vez con el Pulstar en Megadrive full-equip ? xD

Y eso es??....

theelf escribió:

Manveru Ainu escribió:Eso está bien si quieres presentar una bonita pantalla con un fondo y dos sprites estáticos. Si quieres que se animen y muevan tendrás que actualizar esos 420 tiles de los personajes (son bastante menos de 420 por cierto) en la vram, aparte de actualizar los scrolls y demás.

Disculpame, si el cartucho es rom.. donde esta el problema?

En el ancho de banda para transmitir la información de la ROM a la VRAM, no da de sí en actualizar tantos tiles en un solo frame.

kusfo79 escribió:En el ancho de banda para transmitir la información de la ROM a la VRAM, no da de sí en actualizar tantos tiles en un solo frame.

Es que justamente, no son tantos tiles

Los mapas de tiles si que son mas jodidos, pero esos pocos sprites, no son problema

Si cogemos los sprites de la CPS1, a la que animamos el Ryu, que no es uno de los personajes más grandes, ya rozamos el límite. Si ponemos dos personajes, ya deja de funcionar.

kusfo79 escribió:

FFantasy6 escribió:Ya estamos otra vez con el Pulstar en Megadrive full-equip ? xD

Y eso es??....

Que la megadrive si la hubieran programado correctamente podría haber corrido sin problema ninjuno el Cadillacs and Dinosaurs (por ejemplo), probablemente incluso con más colores y nivel de detalle en los escenarios.
Que generalmente esto ocurrió por desidia o falta de talento de los programadores y no porque los pobres tenían que sacar 6 títulos AAA al año en diferentes plataformas.

#ironicmodeOFF

Pd. Expresando mi más profundo respeto por los enormes y geniales avances que ha hecho la escena, algunos de ellos habituales de este foro, sobre todo en Megadrive.

kusfo79 escribió:Si cogemos los sprites de la CPS1, a la que animamos el Ryu, que no es uno de los personajes más grandes, ya rozamos el límite. Si ponemos dos personajes, ya deja de funcionar.

El limite de que?

sgonzalez escribió:Que la megadrive si la hubieran programado correctamente podría haber corrido sin problema ninjuno el Cadillacs and Dinosaurs (por ejemplo), probablemente incluso con más colores y nivel de detalle en los escenarios.

Es que por cosas como esas, fuera bromas, que se mueve tanto la scene. La megadrive es un hard super generico, hay herramientas, hay SDK, y si hay tiempo y ganas, se pueden sacar cosas muy interesantes

FFantasy6 escribió:Ya estamos otra vez con el Pulstar en Megadrive full-equip ? xD

El pulstar es con el Master system converter, era el Blazing star!

Según palabras de los propios programadores del SF2, en el Champion Edition de CPS1 tuvieron que quitar la palmera del escenario de Sagat porque de otro modo se quedaban sin VRAM para poner 2 Zangief o 2 Sagat, pero que era por un problema del código original del World Warrior, o sea, si el juego lo hubiese diseñado desde un principio pensando en eso se hubiese podido hacer sin problemas.

Lo leí en los foros de Capcom y en Shoryuken.com en un artículo tiulado "10 cosas que no sabias acerca de SF" o algo asi.

theelf escribió:Es que justamente, no son tantos tiles

Los mapas de tiles si que son mas jodidos, pero esos pocos sprites, no son problema

Quizás hayas probado a 50hz donde el ancho de banda es mayor pero a 60hz tienes menos capacidad (la mitad o incluso menos según la resolución) para mandar tus datos a la vram. Si no me falla la memoria, el máximo número de tiles que puedes mandar de manera ordinaria durante el vblank son 240, pero claro eso suponiendo que sólo mandes los tiles pero de esel ancho de banda tienes que restar por ejemplo la gestión de los planos que no es poco. Además (de ésto hablo un poco sin saber pero me tiro a la piscina) que esas transferencias se hacen por dma y si se abusa demasiado de ella se pueden ver perjudicados otros procesos como el sonido.

O´Neill escribió:

FFantasy6 escribió:Ya estamos otra vez con el Pulstar en Megadrive full-equip ? xD

El pulstar es con el Master system converter, era el Blazing star!

Es verdad, lo recupero para el hilo de viñetas.

theelf escribió:

kusfo79 escribió:Si cogemos los sprites de la CPS1, a la que animamos el Ryu, que no es uno de los personajes más grandes, ya rozamos el límite. Si ponemos dos personajes, ya deja de funcionar.

El limite de que?

sgonzalez escribió:Que la megadrive si la hubieran programado correctamente podría haber corrido sin problema ninjuno el Cadillacs and Dinosaurs (por ejemplo), probablemente incluso con más colores y nivel de detalle en los escenarios.

Es que por cosas como esas, fuera bromas, que se mueve tanto la scene. La megadrive es un hard super generico, hay herramientas, hay SDK, y si hay tiempo y ganas, se pueden sacar cosas muy interesantes

Ya ha contestado el Manveru, pero bueno, eso, el límite de tiles que te da tiempo a mover de la ROM a la VRAM durante un blanqueo.

Pero eso sí, eso no quita que la versión de Capcom fuera un poco cutre para lo que podría haber sido. Podría haver lucido MUUUUUCHOOO mejor.

Este ejemplo lo habia echo tiempo atras, con solo un personaje, con un par de lineas mas agrego otro, se comparte la misma ram de video para las dos animaciones, pero cargo sprites independientes

No me voy a poner a meter nuevos frames, no tengo tiempo de sentarme a programar una hora, ni a corregir la mala animacion... era un ejemplo para mi web echo en basic, sin assembler, sin optimizar, y asi lo dejo


El personaje son 384 tiles, 24 sprites de 32x32, un total de 48 sprites en pantalla, y 5 frames de animacion


Si me suben un codigo o un binario, donde se vea el limite claramente, encantado de verlo





http://akihabara-online.com/tmp/ss/ejemplo.zip

theelf escribió:Este ejemplo lo habia echo tiempo atras, con solo un personaje, con un par de lineas mas agrego otro, se comparte la misma ram de video para las dos animaciones, pero cargo sprites independientes

No me voy a poner a meter nuevos frames, no tengo tiempo de sentarme a programar una hora, ni a corregir la mala animacion... era un ejemplo para mi web echo en basic, sin assembler, sin optimizar, y asi lo dejo


El personaje son 384 tiles, 24 sprites de 32x32, un total de 48 sprites en pantalla, y 5 frames de animacion


Si me suben un codigo o un binario, donde se vea el limite claramente, encantado de verlo





http://akihabara-online.com/tmp/ss/ejemplo.zip

Ahora estoy en el trabajo, y no puedo hacer un chequeo con el emulador, pero una pregunta, tienes todo cargado en la VRAM a la vez?

kusfo79 escribió:Ahora estoy en el trabajo, y no puedo hacer un chequeo con el emulador, pero una pregunta, tienes todo cargado en la VRAM a la vez?

Si no estuviera en vram, solo verias una pantalla en negro

theelf escribió:

kusfo79 escribió:Ahora estoy en el trabajo, y no puedo hacer un chequeo con el emulador, pero una pregunta, tienes todo cargado en la VRAM a la vez?

Si no estuviera en vram, solo verias una pantalla en negro

Me refiero, todos los frames de la animación a la vez?

No es imposible, son 384 tiles por frame de animacion, cargo el escenario, un frame, y el resto los leo de la rom

theelf escribió:No es imposible, son 384 tiles por frame de animacion, cargo el escenario, un frame, y el resto los leo de la rom

Vale, vale, es la parte que no me quedaba claro, si los 384 son por frame.

lo miraré con el kega en casa, que tengo curiosidad

Si los cargara todos en vram, aunque pudiera, no tendria sentido el ejemplo

Si, si, me había despistado lo que decías de que no tenías tiempo de añadirle más frames. Sorry!.

Me gustan éste tipo de debates porque siempre salen cosas interesantes

Lo que si no creo que sea posible hacer en MD o SNES es la escena de bonus de los barriles metálicos con fuego.

puch666 escribió:Lo que si no creo que sea posible hacer en MD o SNES es la escena de bonus de los barriles metálicos con fuego.

Es facil, porque son todos iguales, o sea, que no requeris mucha vram, solo reptir sprites

theelf escribió:Este ejemplo lo habia echo tiempo atras, con solo un personaje, con un par de lineas mas agrego otro, se comparte la misma ram de video para las dos animaciones, pero cargo sprites independientes

No me voy a poner a meter nuevos frames, no tengo tiempo de sentarme a programar una hora, ni a corregir la mala animacion... era un ejemplo para mi web echo en basic, sin assembler, sin optimizar, y asi lo dejo


El personaje son 384 tiles, 24 sprites de 32x32, un total de 48 sprites en pantalla, y 5 frames de animacion


Si me suben un codigo o un binario, donde se vea el limite claramente, encantado de verlo





http://akihabara-online.com/tmp/ss/ejemplo.zip

Como comenté antes, a 50hz se pueden mandar muchos más tiles. A 50hz se pueden mandar 560 tiles por blanqueo a diferencia de los unos 240 a 60hz (suponiendo 320x224). Si pruebas la demo verás que a 60hz se ralentiza bastante, lo que me ha llamado la atención que se ralentice en lugar de glitchear, eso realmente mola xD.

Para todos los Segueros es posible por el blast processing.

Manveru Ainu escribió:Como comenté antes, a 50hz se pueden mandar muchos más tiles. A 50hz se pueden mandar 560 tiles por blanqueo a diferencia de los unos 240 a 60hz (suponiendo 320x224). Si pruebas la demo verás que a 60hz se ralentiza bastante, lo que me ha llamado la atención que se ralentice en lugar de glitchear, eso realmente mola xD.

? no entiendo lo que queres decir

Mi rom es NTSC, no programo nada en PAL. Mando todas las nuevas instrucciones a las 224 lineas, y cada unidad de espera es de 16.67 ms

Sobre los tiles que puedo enviar en cada vblank. pues, en este viejo demo que hice

http://akihabara-online.com/tmp/mslug.zip


Cada aproximadamente 192 pixeles, cargo 512 tiles en memoria, para generar el scroll, y lo hago en un solo vblank, y es ntsc

(Ese codigo es viejo, luego reescribi la funcion, porque calculaba todo en base a 192 pixeles, y a veces me quedaban 194, y da algun salto, bueno, la cosa es que perdi el codigo, y no tengo ganas de volver a escribirlo)


El punto es, que cargo una cantidad de tiles bastante mayor a lo que comentas cada vblank, por eso, me extraña el limite que comentas

theelf escribió:? no entiendo lo que queres decir

Mi rom es NTSC, no programo nada en PAL. Mando todas las nuevas instrucciones a las 224 lineas, y cada unidad de espera es de 16.67 ms

Sobre los tiles que puedo enviar en cada vblank. pues, en este viejo demo que hice

http://akihabara-online.com/tmp/mslug.zip


Cada aproximadamente 192 pixeles, cargo 512 tiles en memoria, para generar el scroll, y lo hago en un solo vblank, y es ntsc

(Ese codigo es viejo, luego reescribi la funcion, porque calculaba todo en base a 192 pixeles, y a veces me quedaban 194, y da algun salto, bueno, la cosa es que perdi el codigo, y no tengo ganas de volver a escribirlo)


El punto es, que cargo una cantidad de tiles bastante mayor a lo que comentas cada vblank, por eso, me extraña el limite que comentas

Bueno son las especificaciones del VDP, el ancho de banda para la transferencia a la VRAM. Lo que sí te comentaba es que me sorprende que a 60hz se ralentice pero no glitchee. En unos test que hice al sobrepasar el límite de tiles enviados en el vblank me salían tiles glitcheados y basurilla varia, en cambio en tu ejemplo sólo se ralentiza. Es cierto que también se pueden enviar más información en el hblank, pero es más delicado y en cualquier caso es una cantidad menor.

No entiendo lo de que se relentize a 60hz, a que te referis? el binario es NTSC

Sobre los limited del VDP, no me acuerdo la documentacion de memoria, cuando tengo dudas, consulto los documentos, pero no me viene a la cabeza ese limite

theelf escribió:No entiendo lo de que se relentize a 60hz, a que te referis? el binario es NTSC

Sobre los limited del VDP, no me acuerdo la documentacion de memoria, cuando tengo dudas, consulto los documentos, pero no me viene a la cabeza ese limite

Puedes probarla en el kega. A 50hz va mucho más rápido que a 60hz.

Sobre las trasferencias, verás en la documentación del VPD que a 60hz y a 320x224 puedes mandar 7752 bytes en el vblank mientras que a 50hz y a 320x224 puedes mandar 18156 bytes.

Os pego un video comparativo de SF2CE de Megadrive con y sin los parches de audio (LINK) y color (LINK) No me di cuenta de quitar el efecto retro del Framemeister y por eso los lados están más oscuros pero bueno tiene más calidad que los que encontré por ahí:

http://www.youtube.com/watch?v=G0XvX9svODg

Ya sé que soy un paquete jugando pero el mando no tenía los botones bien configurados

Kei_Dash escribió:Os pego un video comparativo de SF2CE de Megadrive con y sin los parches de audio (LINK) y color (LINK) No me di cuenta de quitar el efecto retro del Framemeister y por eso los lados están más oscuros pero bueno tiene más calidad que los que encontré por ahí:

http://www.youtube.com/watch?v=G0XvX9svODg

Ya sé que soy un paquete jugando pero el mando no tenía los botones bien configurados

Ah buenisimo el video, el audio suena perfecto, mandale el link al creador del parche

Anda por sega16

Manveru Ainu escribió:...

No entendes, la demo es NTSC, programe pensando en 60fps, no programe pensando en PAL, y hago esperas fijas que dependen de los 60hz

Si programo con PAL y NTSC en mente, queda algo asi


http://www.akihabara-online.com/tmp/ss/PAL.rar

theelf escribió:No entendes, la demo es NTSC, programe pensando en 60fps, no programe pensando en PAL, y hago esperas fijas que dependen de los 60hz

Si programo con PAL y NTSC en mente, queda algo asi


http://www.akihabara-online.com/tmp/ss/PAL.rar

Yo sólo te digo lo que puede y no puede hacer la VDP a 50 y 60hz. A 60hz las especificaciones no permiten subir +240 tiles por vblank, no porque lo piense yo sino porque el hardware es así jejeje. Luego tirando de ingenio y trucos varios se puede hacer algo más y que parezca a la vista que se mueven más de esa capacidad claro.

Manveru Ainu escribió:Yo sólo te digo lo que puede y no puede hacer la VDP a 50 y 60hz. A 60hz las especificaciones no permiten subir +240 tiles por vblank, no porque lo piense yo sino porque el hardware es así jejeje. Luego tirando de ingenio y trucos varios se puede hacer algo más y que parezca a la vista que se mueven más de esa capacidad claro.

No, esa informacion es incorrecta, se pueden transferir bastantes mas que 240 tiles por vblank en NTSC, sin trucos

En megadrive, todo son limitaciones, pero todo se basa en buscar la vuelta a lo que no se puede hacer, y hacerlo, pero en este caso no, por efecto en NTSC, no recuerdo, creo q al menos 360 u 380 tiles por vblank

En el ejemplo del Metal Slug, uso compresion para mover los tiles, para transferir mas de los que puede, por ejemplo


No tomes las documentaciones al pie de la letra, lo mejor es hacer pruebas, porque no estan todas las documentaciones correctas

Ademas, en PAL tampoco es que pueda transferir mucho mas, porque muchas de las operaciones las hago durante los scanlines activos

theelf escribió:No, esa informacion es incorrecta, se pueden transferir bastantes mas que 240 tiles por vblank en NTSC, sin trucos

En megadrive, con las limitaciones, TODO se basa en buscar la vuelta a lo que no se puede hacer, y hacerlo, pero por efecto en NTSC, no recuerdo, creo q al menos 360 u 380 tiles por vblank. En el ejemplo del Metal Slug, uso compresion para mover los tiles, para transferir mas de los que puede, pro ejemplo

No te dijes en documentaciones, lo mejor es hacer pruebas, porque no estan todas las documentaciones correctas

Ademas, en PAL tampoco es que pueda transferir mucho mas, porque muchas de las operaciones las hago durante los scanlines activos

Claro que hice las pruebas (precisamente con el estrifa de cps1 xD) y efectivamente al pasar de 200 tiles empezaba a glitchear. Lo de que la documentación es incorrecta creo que lo dices demasiado a la ligera. Es cierto que está incompleta, pero está muy currada y bastante testeada.

Que tuvieras esos problemas, seguramente se devieron a algun error de tu codigo. Lo siento, tenes documentacion incorrecta, y de ahi, vendrian el error al basarte en ella

Pasame la documentacion para echarle un vistazo

Yo sólo digo que: http://md.squee.co/wiki/VDP#DMA_Bandwidth

theelf escribió:Que tuvieras esos problemas, seguramente se devieron a algun error de tu codigo. Lo siento, tenes documentacion incorrecta, y de ahi, vendrian el error al basarte en ella

Bueno la documentación es la que usan en los foros de programación megadrivera en todo el mundo, si dices que ellos se equivocan y tú no no te lo puedo rebatir . Me piro a sobar, buenas noches.

Paspallas escribió:Yo sólo digo que: http://md.squee.co/wiki/VDP#DMA_Bandwidth

Esa parece logica, en NTSC usando M68k, tenemos un total de 11556 bytes, 361 tiles

Pero Manveru Ainu, te entiendo ahora, tu te refieres al vblank unicamente, 7524 bytes en modo H40, yo cuento todo, incluido el hblank, desde el comienzo al final, ya que podes ejecutar codigo en todo momento. Mi error de no explayarme como era devido y explicarlo

Tu documentacion no aclaraba eso?

En mi codigo un ciclo completo, es algo asi

HBLANK * <-- indico numero de scanlines cada cuanto quiero quiero el hblank
on HBLANK <--- instrucciones
sleep tvblank <--- espero al vblank
on VBlankOn <--- instrucciones


Es logico, que si solo esperas al vblank para trabajar, en ntsc sea bastante corto, si no lo paras antes, y puedas tener problemas como los que comentabas, aunque no deveria suceder




Bueno, ya que estamos...que paso en este foro? antes hubieran saltado ya varios a decir que yo estabo equivocado, tu, ninguno... o los dos... se volaron todos los programadores? no queda nadie?

Ya comenté que hablaba de la trasferencia ordinaria en el vblank y que se podía transferir también en otros momentos pero que es más complejo porque tienes otras cosas activas como por ejemplo un scroll de 224 líneas que no deja espacio para mucho, pero de cualquier forma esas cantidades posibles son pequeñas comparado con el ancho de banda del vblank (la mitad como mucho si no tienes nada más activo).

Sobre dónde está la peña, a saber xD. Yo en cualquier caso no estoy para imponer nada, estoy para aportar lo que sé por mi experiencia y para aprender lo que pueda, mientras más gente mejor para todos

theelf escribió:Bueno, ya que estamos...que paso en este foro? antes hubieran saltado ya varios a decir que yo estabo equivocado, tu, ninguno... o los dos... se volaron todos los programadores? no queda nadie?

Jajajajaja esperabas que te saltaran al cuello y has podido hablar con total tranquilidad !!

Hasta el punto que te has hecho preguntar si ha pasado algo en el foro... Puede que sean las vacaciones.. Puede que no sepan decantarse hacia un lado o hacia otro.... Sencillamente puede que pasen de comentar.....

De cualquier modo, me ha hecho gracia tu reflexion. Respecto a lo que hablais no puedo hablar porque no entiendo ni jota de programación... Pero leyendo por aqui se aprenden una de cosas.....

La verdad es que el debate ha estado la mar de instructivo!

Estoy leyendo cosas muy interesantes sobre la transmisión de datos en MD y SNES.

No tengo tiempo para andarme con explicaciones, pero, básicamente:
-Megadrive baja el número de sprites simultáneos de 80 a 64 si se usa un modo de resolución de 256x224.
-En megadrive, el acceso a VSRAM y CRAM está en 16bits por transferencia, y a VRAM está en 8bits, por lo que, el mito ese de que el ancho de banda de megadrive es mas grande al de snes, tiene sus matices (en cuanto a la transferencia de gráficos a la VRAM, desde luego que no es así).
-La gran diferencia entre MD y snes, es que en snes, durante la visualización activa no es posible el acceso a VIDEO RAM y la tabla OAM, mientras que en megadrive no hay restricciones (puede transferir incluso sin forzar VBL), aunque la transferencia se vuelve excesivamente lenta en esos momentos.
- SNES tiene 8 DMA's, y un HDMA de 24 bits, por lo que, en términos generales, en espacios de acceso en VBL, el H32 es un poco mas rápido en snes que en megadrive (165.5 vs 161), y el H40 parece ser igual (no tengo el dato ahora, ni se realmente que es eso de H32 y H40 xD).


edito:
Megadrive:
Velocidad de transferencia: 7,2 KB de datos por frame, es decir, 432KB de datos por segundo. Y esa cantidad se reduce muchísimo fuera de los VBLANK, aunque no se cuánto.

SNES:
Velocidad de transferencia: 5.72 KB de datos por frame, es decir, 343KB de datos por segundo (compartido por sus 8 canales de DMA).
La cuestión es, que este dato es una media, y no el ancho de banda total de datos, puesto que el HDMA tiene una comunicación directa con la VRAM sin depender de la CPU, y que solo se interrumpe debido a que solo puede actuar un canal a la vez... pero ciertamente la capacidad de transportar sprites a la memoria de vídeo gracias a su canal de 24 bits, debería incluso asustar xD

De hecho, no le encuentro otra explicación a que el SFA2 solo estuviera en snes.