Xenocrisis para Super Nintendo/Famicom

Señor Ventura escribió:"Esto no se puede hacer porque no se puede hacer" no es una explicación válida. Lo que te estoy diciendo es que para poder decir que conoces a la perfección el funcionamiento de algo hasta el punto de reirte de alguien, lo mínimo esperable es, ya ni siquiera un diagrama pormenorizado, sino que dejes claro cuales son sus conceptos básicos como para explicar por qué no es posible, pero en lugar de eso incluso tu explicación sobre lo que es el hdma es MUY vaga.

Con estos preámbulos te permites dar lecciones. Yo no puedo dar lecciones, y aún así puedo dejar en evidencia que has sido arrogante sin podértelo permitir.


HDMA es un bus que comparte físicamente su espacio con el DMA, pero entra en funcionamiento mediante un registro indicado en su propia tabla ($420C). Basta con cambiar el valor de un bit para activar una "cola de tareas" al final de cada scanline, y es el principal responsable de que el primer scanline de la snes no forme parte de la particuar resolución activa (256x239), ya que es el período de tiempo en que esa tabla está siendo formateada para su utilización al principio de cada frame,

Las transferencias quedan programadas al principio de la pantalla activa, y cada una de las 224 o 239 transferencias se realizan mediante 8 canales, lo que permite cambiar el estado de 8 registros de los ppu's en una sola transferencia horizontal, y la clave para el efecto que comento podría estar en la capacidad del HDMA de cambiar sus registros con una IRQ vertical.

Mal explicado, pero a nada que entiendas de que va esto una vez que he mencionado las IRQs, a grandes rasgos lo único que te distancia de hacer cosas extremadamente complejas, es la capacidad de la cpu para hacer interrupciones... PERO, eso se soluciona con un procesador de apoyo.



¿Quieres un ejemplo de un juego comercial, que no es lo que estoy comentando de la serpiente del xeno crisis, pero que comparte concepto?. Ahí va:

Imagen

Si entendieras la explicación que acabas de dar, entenderías por qué es imposible el invento que propones.

Como tú dices, "esa tabla está siendo formateada para su utilización al principio de cada frame". Para duplicar fondos en la misma horizontal, habría que "formatear la tabla" varias veces por horizontal, mientras la PPU pinta el fondo en pantalla. Como tú dices, HDMA no lo permite.

Pero repito, aunque fuera posible, las secciones de la serpiente se superponen, por lo que la PPU tendría que "rebobinar" (volver hacia atrás) para pintar todas las secciones con el mismo fondo. Una burrada, un rebuzno.

El gif que has puesto por poner algo no superpone dos o más secciones de un mismo plano en la misma horizontal con HDMA, ni "comparte concepto" porque no se puede.

Una vez más, no has sido capaz de aportar ejemplos de juegos existentes ni de hacer una demo que demuestre lo que afirmas.
Por favor, deja el tema y para de inventar.
Todo esto es culpa de la serpiente y no hablo de Eva... :-|
VempireX escribió:Totalmente, y no, ahora te quedas corto, XD, seguramente esté por allá en el 70% , más o menos , en cuestión de VS, y no solo en VS, en muchos estilos más del catálogo, es una evidencia , en varios casos, muy visual; solo quería especificar, no era nada de tocar las "canicas" ni nada por el estilo, solo informar un poco más, y compartir 😉
Postdata:
Por cierto, siguiendo el tema "parones", la versión de mega de Xenocrisis, también los tiene, muy bien camuflados pero que , para mí, no le quitan calidad a dicha versión, me quejo más de esta del hilo, entre otras cosas, por qué barata no me a salido, 😅


Para serte honesto, lo sabia :) por eso inicialmente redondeé al alza con el 95%, quedando fatal por el camino al ser un porcentaje más reducido [cartman]

Como bien dices esas microparadas se producen en otros géneros del catálogo al margen de los de lucha Vs, pero Super es junto con Master la consola de mi vida y me cuesta horrores señalar aspectos que puedan ser considerados como carencias. Seguro que no conozco su catálogo tan bien como tú, ni en lo técnico sé la cuarta parte de lo que sabes, pero tiendo a ser observador. Por ejemplo recuerdo que en T.M.N.H.T in Time y en Jurassic Park, durante las transiciones de pantalla/fundidos a negro, se apreciaban tramas y 'rejillas grises' muy tenues, bastante similares a la 'basura gráfica' que se muestra al arrancar el juego Arcade E.D.F, junto a un sonido/murmullo muy bajo, como un 'mmmmmm', nunca ví esto en MD, y desde mi total ignorancia lo achaqué a que internamente SNES tiene que realizar más procesos -tal vez de descompresión- y que la circulación y transmisión de la información es más 'enrevesada', todo es mas caótico, cuando en MD pudiera resulta mas directo y simple. Es llamativo que ocurría en la consola original, en el emu que utilizo -ZSNES- no queda rastro de esas 'cargas', suponiendo que lo fuesen.

@RiffRaff, haciendo el burro con Google vi alguna cosilla sobre el HDMA que debatís, aunque no tengo idea alguna [tomaaa] igual arroja algo de luz..

https://floating.muncher.se/bot/manual/book2_text.pdf

http://gendev.spritesmind.net/forum/viewtopic.php?t=719
(A mediación de la página)

https://github.com/gilligan/snesdev/blo ... isters.txt

https://www-copetti-org.translate.goog/ ... _tr_pto=sc

https://wiki-superfamicom-org.translate ... isters-141

Horizontal DMA (HDMA) realiza una pequeña transferencia después de cada escaneo horizontal (mientras el haz CRT se prepara para dibujar la siguiente fila). Esto evita interrumpir la CPU durante largos intervalos, pero las transferencias están limitadas a 4 bytes por línea de exploración.

= Entrelazado de pantalla. Cuando se configura en el modo BG 5 (y probablemente 6), el
La altura efectiva de la pantalla será de 448 (o 478) píxeles, en lugar de
224 (o 239). Cuando se configura en cualquier otro modo, la pantalla simplemente aparecerá
un poco nervioso. Sin embargo, alternar el mapa de mosaicos en cada campo
simular el aumento de la altura de la pantalla (al igual que las pseudocontrataciones
contrataciones similares).

En hardware, configurar este bit hace que la salida de SNES sea normal.
entrelazar la señal en lugar de forzar siempre un fotograma.

Consulte las secciones "FONDOS" y "SPRITES" a continuación para obtener más detalles.

Sobreexploración: el bit sólo importa al final del cuadro, si
cambie la configuración en la línea 0xE0 antes del punto de activación NMI normal
entonces es igual que si lo tuvieras en todos los fotogramas. Tenga en cuenta que esto
afecta tanto al punto de activación NMI como cuando HDMA se detiene durante el
marco.

Si apaga el bit al comienzo de la línea de exploración X (por
0xE1<=X<=0xF0), NMI ocurrirá en la línea X y la última transferencia HDMA
ocurrirá en la línea X-1. Sin embargo, al menos en mi televisor, la pantalla
permanece en la posición normal sin sobreexploración para las líneas E1-EC,
suba solo un píxel para la línea ED y perderá la sincronización vertical
para líneas EF-F4!

Al activar el bit, solo la línea E1 produce algún efecto: NMI ocurrirá en
línea E2, aunque el último HDMA todavía ocurrirá en la línea E0.
Cualquier otra cosa actúa como si hubieras dejado la parte apagada todo el tiempo. Nota,
Sin embargo, si espera demasiado después del comienzo del
scanline entonces no obtendrá ningún efecto.

Incluso si no hay ningún efecto visible, la configuración de sobreexploración aún
afecta las escrituras de VRAM. En particular, ejecutar "LDA #'-' / STA $2118
/ LDA r2133 / STA $2133 / LDA #'+' / STA $2118" durante el E1-F0
El período escribirá solo + o solo - en VRAM, dependiendo de si el
El bit de sobreexploración se estableció en 0 o 1.


----------------------------------------------------------------------------------------------------

The basic process seems to be:
1. Get byte and write it to the destination.
- The DMA seems to take advantage of the SNES's two address busses with one
shared data bus. AAddress is pushed out Bus A, Port is pushed out bus B,
and the read/write signals are sent according to Direction. The bus
marked read obligingly put data on the bus, while the bus marked write
obligingly writes that value.
- Thus, since the PPU/APU/WRAM registers are only accessible via Bus B,
attempts to access them via AAddress will result in Open Bus accesses.
- Attempts to access WRAM via both Bus A and Bus B (registers 2180-3) will
fail, with the 2180-3 access being Open Bussed.
- Also, DMA cannot access the $4300-$437f registers nor $420b nor $420c.
Writes will have no effect, and reads will return Open Bus.
2. Adjust AAddress.
- If Fixed is set, do nothing. Else if Increment is set, subtract one,
else add one.
- Note that the bank byte is not modified.
3. Decrement Count. If count is not zero, then go to step 1.
- Thus, if Count is initially zero, it wraps to 65535 before being
tested. So you end up transferring 65536 bytes.

------------------------------------------------------------------------
V va (number of the raster used to display a horizontal
line) indicates the border between background environ-
ments such as sky or cloud and a horizontal plane such
as earth or sea. For raster numbers larger than V va (rep-
resenting the area below the horizon line), a horizontal
plane is displayed on the screen, but the matrix ele-
ments for each raster are calculated individually using
the RASTER command.

----------------------------------------------------------------------------------------------
[i]Para encontrar la entrada de un registro en particular, busque el número de registro (es decir, '2100') al principio de la línea. Tenga en cuenta que los registros DMA están combinados, por lo que, por ejemplo, para encontrar $4300, $4310, $4320, $4330, $4340, $4350, $4360 o $4370, buscará '43x0'.

Para la mayoría de los registros (y la mayoría de los bits indefinidos de registros legibles), el valor devuelto es Open Bus, que es el último valor leído en el bus principal desde la ROM (normalmente parte de los argumentos del código de operación o la dirección base indirecta).

Los registros que coinciden con $21x4-6 o $21x8-A (donde x es 0-2) devuelven el último valor leído de cualquiera de los registros PPU1 $2134-6, $2138-A o $213E. Esto se conoce como bus abierto PPU1. De manera similar, PPU2 Open Bus implica leer registros $213BD o $213F (aunque NO $21xB-D).

Tenga en cuenta que es posible escribir registros en cualquier momento incluso si están marcados con '-', pero hasta que tengamos pruebas, '-' es una mejor suposición.


https://rasterscroll-com.translate.goog ... _tr_pto=sc[/i]
No sé como hemos llegado a hablar de los motivos de los parones,en algunos juegos,en el hilo de xenocrisis,cuando en esta versión no los hay.
En megadrive sí los hay(tema de compresión del audio?).
Que yo recuerde,alien 3 de snes,se quedaba "cargando" el nivel,un buen rato.
@I-rem creo que con el visor de eventos del Mesen se puede entender mejor.

El F-Zero utiliza HDMA para cambiar la rotación y la escala del fondo del modo 7 en cada horizontal, entre otras cosas:

Imagen

Los puntitos rosas a la derecha de la imagen son escrituras en los registros del fondo del modo 7.
Como se puede ver, HDMA funciona entre el final de un escaneo horizontal y el principio del siguiente.

Para que el invento de Ventura funcionara, habría que escribir en los registros del fondo varias veces por horizontal, mientras la PPU pinta el fondo en pantalla: tendrían que salir puntitos rosas en el medio de la pantalla.

Como dices, HDMA no lo permite, ya que sólo funciona entre escaneos horizontales:

I-rem escribió:Horizontal DMA (HDMA) realiza una pequeña transferencia después de cada escaneo horizontal (mientras el haz CRT se prepara para dibujar la siguiente fila). Esto evita interrumpir la CPU durante largos intervalos, pero las transferencias están limitadas a 4 bytes por línea de exploración.
VempireX está baneado del subforo por "flames"
@I-rem
Buenos días

Offtopic:

Te quería comentar que a modo de uso de emuladores, no te recomiendo para nada Zsnes, ya que se queda bastante corto en representar el hardware de SNES, sobretodo en audio, anda muy desfasado, saludos.
McFly escribió:No sé como hemos llegado a hablar de los motivos de los parones,en algunos juegos,en el hilo de xenocrisis,cuando en esta versión no los hay.
En megadrive sí los hay(tema de compresión del audio?).
Que yo recuerde,alien 3 de snes,se quedaba "cargando" el nivel,un buen rato.


Sin querer darme protagonismo temo que en parte fué cosa mía al sacar el tema del sonido (paradas justo antes de ciertas digitalizaciones de voz), disculpad, no era mi intención, sólo lo dije porque el debate se desvió un poco por el audio y ví una conexión, al margen de resultarme muy curioso desde pequeño... cuando tuve mi SNES (Pack Mario y SF II), SF II y luego SF II Turbo me fliparon. Pocos días después encontré decenas de diferencias respecto al Arcade, la 'parada' de SF II Turbo me impactó especialmente, y sí, es una tontería mayúscula, pero tengo esa forma de ser con todo :) le doy a veces una importancia desmedida a detalles y menudencias que a priori son neutros, sin ir más lejos, el olor de las consolas recién sacadas por primera vez de su embalaje, lo tengo marcado a fuego en la memoria, una vez en un centro comercial me vino un olor a plástico como el de la Master recién estrenada y parecía un perro policía olisqueando por los rincones [looco]

RiffRaff escribió:@I-rem creo que con el visor de eventos del Mesen se puede entender mejor.

El F-Zero utiliza HDMA para cambiar la rotación y la escala del fondo del modo 7 en cada horizontal, entre otras cosas:

Imagen

Los puntitos rosas a la derecha de la imagen son escrituras en los registros del fondo del modo 7.
Como se puede ver, HDMA funciona entre el final de un escaneo horizontal y el principio del siguiente.

Para que el invento de Ventura funcionara, habría que escribir en los registros del fondo varias veces por horizontal, mientras la PPU pinta el fondo en pantalla: tendrían que salir puntitos rosas en el medio de la pantalla.

Como dices, HDMA no lo permite, ya que sólo funciona entre escaneos horizontales:

I-rem escribió:Horizontal DMA (HDMA) realiza una pequeña transferencia después de cada escaneo horizontal (mientras el haz CRT se prepara para dibujar la siguiente fila). Esto evita interrumpir la CPU durante largos intervalos, pero las transferencias están limitadas a 4 bytes por línea de exploración.


Gracias por explicármelo, lo entiendo, es una puñeta. En SNES el enfoque de trabajo en ese sentido como sabemos es un tanto inamovible, mientras que en MegaDrive con imaginación, talento y tiempo puedes hacer una ensalada de tomate y lechuga utilizando una manzana y rosquillas de pan.. es su fortaleza principal a mi modo de ver.

Siempre pongo el mismo ejemplo pero pienso que puede ser el que con mayor claridad ilustra la libertad que ofrece MD a la hora de programar florituras gráficas,





Como se ha explicado, en Super la forma mas sencilla de portar el juego por muchos motivos era hacerlo con ayuda externa, si bien es algo que hasta yo tenía claro desde el principio al conocer la complejidad que tiene SNES para ser programada, el debate era otro, y opino que aunque signifique acabar dando vueltas en círculo o pueda parecer innecesario, tiene su parte didáctica y su encanto si te gustan los videojuegos (aún siendo un cenutrio como yo para comprender código :))

VempireX escribió:@I-rem
Buenos días

Offtopic:

Te quería comentar que a modo de uso de emuladores, no te recomiendo para nada Zsnes, ya que se queda bastante corto en representar el hardware de SNES, sobretodo en audio, anda muy desfasado, saludos.


Buenos días Compañero, te lo agradezco :) en verdad lo sé (desde hace poco), no tengo demasiado tiempo para jugar pero ya estuve investigando, al parecer Snes9x y Bsnes son los considerados mejores emus de Super, lo que pasa es que me cuesta un mundo abandonar ZSNES tras 25 años utilizándolo, y así con todo me temo, llevo 24 años con la misma maquinilla de afeitar, Gillette Mach3, porque me vá muy bien con ella.. es la misma, misma, quiero decir, llevo 24 años sin cambiarla ni siquiera dentro del mismo sistema/modelo [looco] está que dá pena verla, pero sigue pudiendo enganchar los recambios.

Sin embargo en emus, es renovarse o.. perder experiencia de juego.. quizás este pasotismo también venga por el hecho de que soy de esas personas que cargan con la desgracia de ser incapaces de disfrutar a través de emuladores de la experiencia real. Para mi jugar en una SNES física en un CRT es un mundo a parte e infinitamente mas satisfactorio, la emulación te quita el hambre y es una auténtica bendición, pero es como tomarte un Whopper cuando lo que deseas es un Osso bucco con Risotto y una Lubina napada al Eneldo en el restaurante de Karlos Arguiñano, son dos mundos muy diferentes para mí, ahora tienes toda la razón, ya que tengo que agarrarme a ese clavo, porque mi SNES funciona fatal, que sea de la mejor forma posible.


Saludos
I-rem escribió:Como bien dices esas microparadas se producen en otros géneros del catálogo al margen de los de lucha Vs, pero Super es junto con Master la consola de mi vida y me cuesta horrores señalar aspectos que puedan ser considerados como carencias. Seguro que no conozco su catálogo tan bien como tú, ni en lo técnico sé la cuarta parte de lo que sabes, pero tiendo a ser observador. Por ejemplo recuerdo que en T.M.N.H.T in Time y en Jurassic Park, durante las transiciones de pantalla/fundidos a negro, se apreciaban tramas y 'rejillas grises' muy tenues, bastante similares a la 'basura gráfica' que se muestra al arrancar el juego Arcade E.D.F, junto a un sonido/murmullo muy bajo, como un 'mmmmmm', nunca ví esto en MD, y desde mi total ignorancia lo achaqué a que internamente SNES tiene que realizar más procesos -tal vez de descompresión- y que la circulación y transmisión de la información es más 'enrevesada', todo es mas caótico, cuando en MD pudiera resulta mas directo y simple. Es llamativo que ocurría en la consola original, en el emu que utilizo -ZSNES- no queda rastro de esas 'cargas', suponiendo que lo fuesen.


En Megadrive se ve menos porque es mucho más rápida copiando y luego tiene más facilidad para descomprimir datos al vuelto con el juego ya en marcha, al contrario que Snes que tienes que precargar casi todo de inicio, incluyendo lo que comentaba de todos los samples para tener sonido.

Pero es muy fácil encontrar microparones en juegos de primera hornada, cuando descomprimía y copiaba muchos datos de golpe sin que hubiesen escalonado la carga, como se haría ya por sistema más adelante. Por ejemplo, en el Golden Axe, cuando llegabas a los jefes de final de nivel y te cargaba las tiles del escenario y los propios jefes, te comías un par de frames de parón:



También en las transiciones entre rondas en los Street Fighters, es fácil oír que la música, si bien no estaban obligados a reiniciarla como en Snes, podía rascar un poco mientras el DMA estaba a toda mecha recargando tiles:



¿Por qué pasa eso en el caso de Megadrive?
Porque los samples en Megadrive se copian al vuelo desde la ROM. De ahí viene la gran variabilidad en calidad de reproducción de samples en los diferentes juegos de Megadrive. Si ocupabas el bus con DMAs haciendo copias de cualquier otra cosa de modo que dejabas al Yamaha sin muestra nueva, repetía la anterior y por eso tantas veces sonaban así de mal.

En la época se mitigaba, quien lo hacía, a base de depurar código para no congelar el bus demasiado durante la reproducción de samples. Sin embargo, en desarrollos modernos lo que se ha hecho, gracias a la idea de Stef, es usar parte de los 8kb de RAM del Z80 como buffer, como en un sistema moderno. Así, cuando el DMA congela el bus principal, el Z80 puede seguir alimentando al Yamaha sin interrupciones, ya que como comenté antes el Z80 puede seguir funcionando autónomamente mientras no intente acceder al bus principal, mejorando sobremanera la calidad de reproducción:



Sin salir del Street Fighter, y continuando con lo del Street Fighter Alpha 2, también es curioso ver como en cada versión utilizan una aproximación diferente para una misma limitación.

En los primeros SFII de Snes habían más voces del anunciador a costa de la instrumentación u otros efectos. En el SFA2 ya sabemos que optaron por reproducir todas las voces posibles aún a costa de los parones, de eso no tiene ninguna culpa 'el driver' de sonido sino la arquitectura de la máquina. Sin embargo, pocos comentan como en el SSF2 se fumaron los anuncios de ronda y el Fight! directamente:



Y al final de ronda microparón para el You win! (y el Perfect!), que como es pequeño apenas se nota, y arreando.

Con las máquinas antiguas siempre es fascinante ver como sorteaban las limitaciones, la mayoría de veces con más ingenio que código.

Un saludo.
dr apocalipsis escribió:
I-rem escribió:Como bien dices esas microparadas se producen en otros géneros del catálogo al margen de los de lucha Vs, pero Super es junto con Master la consola de mi vida y me cuesta horrores señalar aspectos que puedan ser considerados como carencias. Seguro que no conozco su catálogo tan bien como tú, ni en lo técnico sé la cuarta parte de lo que sabes, pero tiendo a ser observador. Por ejemplo recuerdo que en T.M.N.H.T in Time y en Jurassic Park, durante las transiciones de pantalla/fundidos a negro, se apreciaban tramas y 'rejillas grises' muy tenues, bastante similares a la 'basura gráfica' que se muestra al arrancar el juego Arcade E.D.F, junto a un sonido/murmullo muy bajo, como un 'mmmmmm', nunca ví esto en MD, y desde mi total ignorancia lo achaqué a que internamente SNES tiene que realizar más procesos -tal vez de descompresión- y que la circulación y transmisión de la información es más 'enrevesada', todo es mas caótico, cuando en MD pudiera resulta mas directo y simple. Es llamativo que ocurría en la consola original, en el emu que utilizo -ZSNES- no queda rastro de esas 'cargas', suponiendo que lo fuesen.


En Megadrive se ve menos porque es mucho más rápida copiando y luego tiene más facilidad para descomprimir datos al vuelto con el juego ya en marcha, al contrario que Snes que tienes que precargar casi todo de inicio, incluyendo lo que comentaba de todos los samples para tener sonido.

Pero es muy fácil encontrar microparones en juegos de primera hornada, cuando descomprimía y copiaba muchos datos de golpe sin que hubiesen escalonado la carga, como se haría ya por sistema más adelante. Por ejemplo, en el Golden Axe, cuando llegabas a los jefes de final de nivel y te cargaba las tiles del escenario y los propios jefes, te comías un par de frames de parón:



También en las transiciones entre rondas en los Street Fighters, es fácil oír que la música, si bien no estaban obligados a reiniciarla como en Snes, podía rascar un poco mientras el DMA estaba a toda mecha recargando tiles:



¿Por qué pasa eso en el caso de Megadrive?
Porque los samples en Megadrive se copian al vuelo desde la ROM. De ahí viene la gran variabilidad en calidad de reproducción de samples en los diferentes juegos de Megadrive. Si ocupabas el bus con DMAs haciendo copias de cualquier otra cosa de modo que dejabas al Yamaha sin muestra nueva, repetía la anterior y por eso tantas veces sonaban así de mal.

En la época se mitigaba, quien lo hacía, a base de depurar código para no congelar el bus demasiado durante la reproducción de samples. Sin embargo, en desarrollos modernos lo que se ha hecho, gracias a la idea de Stef, es usar parte de los 8kb de RAM del Z80 como buffer, como en un sistema moderno. Así, cuando el DMA congela el bus principal, el Z80 puede seguir alimentando al Yamaha sin interrupciones, ya que como comenté antes el Z80 puede seguir funcionando autónomamente mientras no intente acceder al bus principal, mejorando sobremanera la calidad de reproducción:



Sin salir del Street Fighter, y continuando con lo del Street Fighter Alpha 2, también es curioso ver como en cada versión utilizan una aproximación diferente para una misma limitación.

En los primeros SFII de Snes habían más voces del anunciador a costa de la instrumentación u otros efectos. En el SFA2 ya sabemos que optaron por reproducir todas las voces posibles aún a costa de los parones, de eso no tiene ninguna culpa 'el driver' de sonido sino la arquitectura de la máquina. Sin embargo, pocos comentan como en el SSF2 se fumaron los anuncios de ronda y el Fight! directamente:



Y al final de ronda microparón para el You win! (y el Perfect!), que como es pequeño apenas se nota, y arreando.

Con las máquinas antiguas siempre es fascinante ver como sorteaban las limitaciones, la mayoría de veces con más ingenio que código.

Un saludo.

Pues poco habrás leído sobre el ssf de snes.Se ha comentado lo de la falta de los samples de audio y el frame de la animación de la intro,hasta la saciedad.Se comenta lo.bueno y lo malo.Tienes comparativas para aburrir,en los canales habituales.
mcfly escribió:Pues poco habrás leído sobre el ssf de snes.Se ha comentado lo de la falta de los samples de audio y el frame de la animación de la intro,hasta la saciedad.Se comenta lo.bueno y lo malo.Tienes comparativas para aburrir,en los canales habituales.


Yo hablo aquí y ahora, con gente que está aquí y ahora culpando a Capcom por pereza o dejadez con el SFA2.
dr apocalipsis escribió:
mcfly escribió:Pues poco habrás leído sobre el ssf de snes.Se ha comentado lo de la falta de los samples de audio y el frame de la animación de la intro,hasta la saciedad.Se comenta lo.bueno y lo malo.Tienes comparativas para aburrir,en los canales habituales.


Yo hablo aquí y ahora, con gente que está aquí y ahora culpando a Capcom por pereza o dejadez con el SFA2.

En el caso de los samples de audio de ssf,no creo que sea dejadez o pereza.Más bien falta de espacio.Como ocurre en el sf2.

Por cierto,en holandés,también flickea una casilla del menú.
Tenemos flickeo en:

Español,francés,italiano y holandés.En inglés,japonés(que la parte de armas está en inglés) y alemán,no.
Dr Apocalípsis escribió:En Megadrive se ve menos porque es mucho más rápida copiando y luego tiene más facilidad para descomprimir datos al vuelto con el juego ya en marcha, al contrario que Snes que tienes que precargar casi todo de inicio, incluyendo lo que comentaba de todos los samples para tener sonido.

Pero es muy fácil encontrar microparones en juegos de primera hornada, cuando descomprimía y copiaba muchos datos de golpe sin que hubiesen escalonado la carga, como se haría ya por sistema más adelante. Por ejemplo, en el Golden Axe, cuando llegabas a los jefes de final de nivel y te cargaba las tiles del escenario y los propios jefes, te comías un par de frames de parón:



También en las transiciones entre rondas en los Street Fighters, es fácil oír que la música, si bien no estaban obligados a reiniciarla como en Snes, podía rascar un poco mientras el DMA estaba a toda mecha recargando tiles:



¿Por qué pasa eso en el caso de Megadrive?
Porque los samples en Megadrive se copian al vuelo desde la ROM. De ahí viene la gran variabilidad en calidad de reproducción de samples en los diferentes juegos de Megadrive. Si ocupabas el bus con DMAs haciendo copias de cualquier otra cosa de modo que dejabas al Yamaha sin muestra nueva, repetía la anterior y por eso tantas veces sonaban así de mal.

En la época se mitigaba, quien lo hacía, a base de depurar código para no congelar el bus demasiado durante la reproducción de samples. Sin embargo, en desarrollos modernos lo que se ha hecho, gracias a la idea de Stef, es usar parte de los 8kb de RAM del Z80 como buffer, como en un sistema moderno. Así, cuando el DMA congela el bus principal, el Z80 puede seguir alimentando al Yamaha sin interrupciones, ya que como comenté antes el Z80 puede seguir funcionando autónomamente mientras no intente acceder al bus principal, mejorando sobremanera la calidad de reproducción:



Sin salir del Street Fighter, y continuando con lo del Street Fighter Alpha 2, también es curioso ver como en cada versión utilizan una aproximación diferente para una misma limitación.

En los primeros SFII de Snes habían más voces del anunciador a costa de la instrumentación u otros efectos. En el SFA2 ya sabemos que optaron por reproducir todas las voces posibles aún a costa de los parones, de eso no tiene ninguna culpa 'el driver' de sonido sino la arquitectura de la máquina. Sin embargo, pocos comentan como en el SSF2 se fumaron los anuncios de ronda y el Fight! directamente:



Y al final de ronda microparón para el You win! (y el Perfect!), que como es pequeño apenas se nota, y arreando.

Con las máquinas antiguas siempre es fascinante ver como sorteaban las limitaciones, la mayoría de veces con más ingenio que código.

Un saludo.


Muchas gracias Compa por currarte una explicación con esa calidad, al final casi dí al larguero [tomaaa] es muy muy interesante, lástima no tener la base necesaria para poder debatirlo y preguntarte más cosas.

Creo que las paradas que bien señalas en Golden Axe se producían también en Alien Storm, mientras que en Altered Beast cada vez que absorbíamos un orbe y perdíamos una vida, se daba un reinicio completo de la música, aunque Altered fue al parecer el primer juego programado para Mega, está justificadísimo.

Recuerdo que en los títulos de primera hornada, el test de sonido no permitía reproducir música y FX a la vez, pero en juegos ya de 1994 o 1995 si se podía, optimización de código power :)

Siempre se dijo que Strider II de MD era un juego pésimo pero con las mejores voces escuchadas en una MegaDrive, y esto lleva tiempo dándome qué pensar, en el sentido de que tanto en Mega como en Super, pareciera que en contadas ocasiones, a mayor complejidad del juego, peor sonido (Super Street Fighter II de MD pejem), e incluso SFA2 de SNES..

Sin duda es fascinante como sorteaban las limitaciones los programadores, y a mas se retrocede, mas alucinante resulta, recuerdo Manic Miner si no me falla la neurona, para hacer musica y FX a la vez (crear esa ilusión) en Spectrum 48K Matthew Smith utilizó un inteligente e ingenioso sistema de interrupciones. De hecho tengo entendido que este sistema es lo que utiliza Windows para gestionar la multaréa -tener muchas aplicaciones abiertas a la vez-, parece que todo se ejecuta a la vez cuando es sólo una ilusión generada por múltiples interrupciones hechas a una velocidad vertiginosa.

he sido una de las personas que más a criticado los trabajos de Capcom en SNES cuando no tendría que haberlo hecho debido a mi ignorancia, sin embargo creí ver detalles globales y en juegos concretos que me hicieron prejuzgar a la empresa, quizás sobretodo el tema de los marcadores monocromo (cuando en MD son a color, dentro incluso de juegos comunes o multiplataforma de Capcom y otras compañías), algo que, de nuevo, desde pequeñito encontraba en exceso molesto y absurdo. De la misma forma que has tenido a bien explicarnos todo esto, gracias al Compañero Magno pudimos entender porqué los rostros del HUD de bastantes juegos de SN son monocromos,

Lo que no quita que sí hubiera un poco de flojera por parte de Capcom [666] porque en otros juegos son a color, interpreto que porque lo trabajaron un poco más en lugar de aprovechar esa facilidad que ofrece la consola


Ocurre porque dichos juegos suelen usar el modo 1, que permite 16 colores en BG1 y BG2 y 4 en BG3, de modo que el marcador y las "caras" se ponen en esa capa con menos colores. Luego le dan a las tiles prioridad 1 con un flag específico para BG3 y así esta capa queda encima de todas las demás y nunca puede ser tapada ni por un sprite, dando la sensación que siempre está visible en primer plano.



Saludos
I-rem escribió:
Dr Apocalípsis escribió:En Megadrive se ve menos porque es mucho más rápida copiando y luego tiene más facilidad para descomprimir datos al vuelto con el juego ya en marcha, al contrario que Snes que tienes que precargar casi todo de inicio, incluyendo lo que comentaba de todos los samples para tener sonido.

Pero es muy fácil encontrar microparones en juegos de primera hornada, cuando descomprimía y copiaba muchos datos de golpe sin que hubiesen escalonado la carga, como se haría ya por sistema más adelante. Por ejemplo, en el Golden Axe, cuando llegabas a los jefes de final de nivel y te cargaba las tiles del escenario y los propios jefes, te comías un par de frames de parón:



También en las transiciones entre rondas en los Street Fighters, es fácil oír que la música, si bien no estaban obligados a reiniciarla como en Snes, podía rascar un poco mientras el DMA estaba a toda mecha recargando tiles:



¿Por qué pasa eso en el caso de Megadrive?
Porque los samples en Megadrive se copian al vuelo desde la ROM. De ahí viene la gran variabilidad en calidad de reproducción de samples en los diferentes juegos de Megadrive. Si ocupabas el bus con DMAs haciendo copias de cualquier otra cosa de modo que dejabas al Yamaha sin muestra nueva, repetía la anterior y por eso tantas veces sonaban así de mal.

En la época se mitigaba, quien lo hacía, a base de depurar código para no congelar el bus demasiado durante la reproducción de samples. Sin embargo, en desarrollos modernos lo que se ha hecho, gracias a la idea de Stef, es usar parte de los 8kb de RAM del Z80 como buffer, como en un sistema moderno. Así, cuando el DMA congela el bus principal, el Z80 puede seguir alimentando al Yamaha sin interrupciones, ya que como comenté antes el Z80 puede seguir funcionando autónomamente mientras no intente acceder al bus principal, mejorando sobremanera la calidad de reproducción:



Sin salir del Street Fighter, y continuando con lo del Street Fighter Alpha 2, también es curioso ver como en cada versión utilizan una aproximación diferente para una misma limitación.

En los primeros SFII de Snes habían más voces del anunciador a costa de la instrumentación u otros efectos. En el SFA2 ya sabemos que optaron por reproducir todas las voces posibles aún a costa de los parones, de eso no tiene ninguna culpa 'el driver' de sonido sino la arquitectura de la máquina. Sin embargo, pocos comentan como en el SSF2 se fumaron los anuncios de ronda y el Fight! directamente:



Y al final de ronda microparón para el You win! (y el Perfect!), que como es pequeño apenas se nota, y arreando.

Con las máquinas antiguas siempre es fascinante ver como sorteaban las limitaciones, la mayoría de veces con más ingenio que código.

Un saludo.


Muchas gracias Compa por currarte una explicación con esa calidad, al final casi dí al larguero [tomaaa] es muy muy interesante, lástima no tener la base necesaria para poder debatirlo y preguntarte más cosas.

Creo que las paradas que bien señalas en Golden Axe se producían también en Alien Storm, mientras que en Altered Beast cada vez que absorbíamos un orbe y perdíamos una vida, se daba un reinicio completo de la música, aunque Altered fue al parecer el primer juego programado para Mega, está justificadísimo.

Recuerdo que en los títulos de primera hornada, el test de sonido no permitía reproducir música y FX a la vez, pero en juegos ya de 1994 o 1995 si se podía, optimización de código power :)

Siempre se dijo que Strider II de MD era un juego pésimo pero con las mejores voces escuchadas en una MegaDrive, y esto lleva tiempo dándome qué pensar, en el sentido de que tanto en Mega como en Super, pareciera que en contadas ocasiones, a mayor complejidad del juego, peor sonido (Super Street Fighter II de MD pejem), e incluso SFA2 de SNES..

Sin duda es fascinante como sorteaban las limitaciones los programadores, y a mas se retrocede, mas alucinante resulta, recuerdo Manic Miner si no me falla la neurona, para hacer musica y FX a la vez (crear esa ilusión) en Spectrum 48K Matthew Smith utilizó un inteligente e ingenioso sistema de interrupciones. De hecho tengo entendido que este sistema es lo que utiliza Windows para gestionar la multaréa -tener muchas aplicaciones abiertas a la vez-, parece que todo se ejecuta a la vez cuando es sólo una ilusión generada por múltiples interrupciones hechas a una velocidad vertiginosa.

he sido una de las personas que más a criticado los trabajos de Capcom en SNES cuando no tendría que haberlo hecho debido a mi ignorancia, sin embargo creí ver detalles globales y en juegos concretos que me hicieron prejuzgar a la empresa, quizás sobretodo el tema de los marcadores monocromo (cuando en MD son a color, dentro incluso de juegos comunes o multiplataforma de Capcom y otras compañías), algo que, de nuevo, desde pequeñito encontraba en exceso molesto y absurdo. De la misma forma que has tenido a bien explicarnos todo esto, gracias al Compañero Magno pudimos entender porqué los rostros del HUD de bastantes juegos de SN son monocromos,

Lo que no quita que sí hubiera un poco de flojera por parte de Capcom [666] porque en otros juegos son a color, interpreto que porque lo trabajaron un poco más en lugar de aprovechar esa facilidad que ofrece la consola


Ocurre porque dichos juegos suelen usar el modo 1, que permite 16 colores en BG1 y BG2 y 4 en BG3, de modo que el marcador y las "caras" se ponen en esa capa con menos colores. Luego le dan a las tiles prioridad 1 con un flag específico para BG3 y así esta capa queda encima de todas las demás y nunca puede ser tapada ni por un sprite, dando la sensación que siempre está visible en primer plano.



Saludos


El todopoderoso thunder force IV,tiene paradas durante el juego,cada vez que cambias de arma.
Ya que comentas casos de md.

Muchos juegos en cd rom,hacen paradas,con el cambio de música.En los de naves,al salir el boss,hay muchos ejemplos.
VempireX está baneado del subforo por "flames"
@mcfly
Garou densetsu 2 tiene tanto en la música cuando cambia de round (a lo ssf2), como al iniciar el combate, son unos cuantos, que lo hacen.

Volviendo al Xenocrisis de SNES...
Te quería preguntar si te has dado cuenta, de que la música del Jefe 2, los 2 primeros segundos, suena mal, con fallos.
mcfly escribió:El todopoderoso thunder force IV,tiene paradas durante el juego,cada vez que cambias de arma.
Ya que comentas casos de md.

Muchos juegos en cd rom,hacen paradas,con el cambio de música.En los de naves,al salir el boss,hay muchos ejemplos.


Lo de que en el Thunder Force IV se pare toda la música FM más bien por decisión artística, eso está específicamente programado así y no es por ninguna particularidad del hardware. Se la sopla pasar de un sample de percusión a otro de una voz.

Y los juegos en CD, pues porque el lector tiene que cambiar de pista y tarda. Eso pasaba hasta en las máquinas de 32 bits.
dr apocalipsis escribió:
mcfly escribió:El todopoderoso thunder force IV,tiene paradas durante el juego,cada vez que cambias de arma.
Ya que comentas casos de md.

Muchos juegos en cd rom,hacen paradas,con el cambio de música.En los de naves,al salir el boss,hay muchos ejemplos.


Lo de que en el Thunder Force IV se pare toda la música FM más bien por decisión artística, eso está específicamente programado así y no es por ninguna particularidad del hardware. Se la sopla pasar de un sample de percusión a otro de una voz.

Y los juegos en CD, pues porque el lector tiene que cambiar de pista y tarda. Eso pasaba hasta en las máquinas de 32 bits.

Afirmas las cosas con mucha decisión.No puedes pensar que sea por otro motivo?.Para que se oiga de forma nítida el sample de audio,por ejemplo.Y no pase como en la mayoría de juegos de md,que suena la voz cazallera cuando la mezclas con musica y fx?.
Hay que disfrutar de las máquinas retro,aún con sus limitaciones.

@VempireX lo he probado,sin disparar,para oir mejor.Y sí,tiene como una distorsión,durante un breve instante del inicio de la canción.
mcfly escribió:Afirmas las cosas con mucha decisión.No puedes pensar que sea por otro motivo?.Para que se oiga de forma nítida el sample de audio,por ejemplo.Y no pase como en la mayoría de juegos de md,que suena la voz cazallera cuando la mezclas con musica y fx?.
Hay que disfrutar de las máquinas retro,aún con sus limitaciones.


La voz suena mal igualmente, y parar el FM no ayuda en absolutamente nada a la reproducción de samples en ese Yamaha.
No es un rasgo del Yamaha 2612 que haga por defecto, todo lo contrario. El silenciamiento y vuelta a la reproducción de los canales FM están claramente cocinados para que suenen así en ese juego.

Si fuese por mejorar la calidad de reproducción estaría parando la acción, no silenciando los canales FM.

Mira que es fácil.
VempireX está baneado del subforo por "flames"
mcfly escribió:Afirmas las cosas con mucha decisión.No puedes pensar que sea por otro motivo?.Para que se oiga de forma nítida el sample de audio,por ejemplo.Y no pase como en la mayoría de juegos de md,que suena la voz cazallera cuando la mezclas con musica y fx?.
Hay que disfrutar de las máquinas retro,aún con sus limitaciones.

@VempireX lo he probado,sin disparar,para oir mejor.Y sí,tiene como una distorsión,durante un breve instante del inicio de la canción.

Usa el sound test para escucharlo, cambiando de "pista" del Boss 1 al Boss 2...da grima...
dr apocalipsis escribió:
mcfly escribió:Afirmas las cosas con mucha decisión.No puedes pensar que sea por otro motivo?.Para que se oiga de forma nítida el sample de audio,por ejemplo.Y no pase como en la mayoría de juegos de md,que suena la voz cazallera cuando la mezclas con musica y fx?.
Hay que disfrutar de las máquinas retro,aún con sus limitaciones.


La voz suena mal igualmente, y parar el FM no ayuda en absolutamente nada a la reproducción de samples en ese Yamaha.
No es un rasgo del Yamaha 2612 que haga por defecto, todo lo contrario. El silenciamiento y vuelta a la reproducción de los canales FM están claramente cocinados para que suenen así en ese juego.

Si fuese por mejorar la calidad de reproducción estaría parando la acción, no silenciando los canales FM.

Mira que es fácil.

Cuando dices que suena mal igualmente,te refieres a en ese juego en concreto, o en los juegos de mega,en general?.Aquí siempre se ha dicho que,si no se oían bien los samples de voz en md,era por el driver.Pero se me hace difícil,pensar en un juego,en el que suenen sin carraspeo,las voces+fx+fm.A día de hoy,xenocrisis,es un ejemplo de lo que digo.Sin embargo,tienes la versión con parche de audio de sf2,que intenta disimular ese carraspeo en los samples y en los fx.

@VempireX parece que la cinta estaba arrugada,al principio de la canción.Durante el.juego,al.menos yo,no lo había notado.En el menú de audio,se nota.

Lo de que guarde record(algo básico en un arcade) y la configuración(idioma,controles,dificultad),es un punto a favor,por otro lado.
@I-rem

Los parones del street fighter alpha 2 SI son culpa del driver.

No hay ni un solo parón durante los combates a pesar de estar plagados de samples para voces y efectos de sonido, y todo lo que se escucha durante todo el juego estransferido al vuelo exactamente igual que todo lo demás.

El driver es ineficiente, pesado, y presumiblemente se transfiere a la ARAM en un solo bloque. Siendo la ventana para transferencias durante un período v-blank extremadamente pequeña, causa un parón en el programa porque necesita usar muchas de ellas consecutivamente.

El programa reescribe el driver antes de cada combate, y durante sus transiciones para reiniciar el control. Esto es innecesario. El autor de esta correción lo que ha hecho es dividir la esctitura de este driver en micro cargas, de forma que no paren nada, pero seguramente ha optimizado el propio driver, si.

Además, los samples no son descomprimidos por el SDD-1, solo los gráficos. Los samples son siempre transferidos en formato comprimido, en cualquier juego, y el spc700 los descomprime en su aram. La descompresión de audio nunca afecta al programa. Nunca. En ningún caso.
McFly escribió:El todopoderoso thunder force IV,tiene paradas durante el juego,cada vez que cambias de arma.
Ya que comentas casos de md.

Muchos juegos en cd rom,hacen paradas,con el cambio de música.En los de naves,al salir el boss,hay muchos ejemplos.


Sí, creo que este caso concreto lo investigué -junto con otros-, pero no recuerdo lo que leí.
Desde mi ignorancia siempre pensé que la música se detenía por el mismo motivo que se reinicia en Altered al sonar las voces de potencionamiento y muerte; ser juegos programados en un momento en el que la consola aún no estaba siendo aprovechada del todo, porque su hard necesitaba explorarse más, o por falta de herramientas pulidas que llegaron más tarde. Además, de porque en la versión Arcade del juego (Thunder Force AC, de 1990), música y voces cohexisten sin problemas. Como sabréis, funciona bajo la placa System C-2, que es una MegaDrive con un Motorola mas subido de reloj, VDP un poco más 'dopado' y un sistema de audio que incluye un chip extra.

Sound chip : YM3438 @ 7.670453, SN76496 @ 3.579545
Optional Sound Chip : UPD7759 @ 640 kHz


Paradójicamente podríamos encontrarnos ante un caso similar al de Xeno Crisis pero treinta y cuatro años antes, y es que esta placa Arcade hace, en apariencia por 'fuerza bruta', lo que una MegaDrive podría haber hecho años después a base de mayor optimización,



Aunque este ejemplo me demuestra estar seguramente algo errado :)
https://youtu.be/aJNEfPimU40?si=7b3BI--3Mg2juc81&t=331

Señor Ventura escribió:@I-rem

Los parones del street fighter alpha 2 SI son culpa del driver.

No hay ni un solo parón durante los combates a pesar de estar plagados de samples para voces y efectos de sonido, y todo lo que se escucha durante todo el juego estransferido al vuelo exactamente igual que todo lo demás.

El driver es ineficiente, pesado, y presumiblemente se transfiere a la ARAM en un solo bloque. Siendo la ventana para transferencias durante un período v-blank extremadamente pequeña, causa un parón en el programa porque necesita usar muchas de ellas consecutivamente.

El programa reescribe el driver antes de cada combate, y durante sus transiciones para reiniciar el control. Esto es innecesario. El autor de esta correción lo que ha hecho es dividir la esctitura de este driver en micro cargas, de forma que no paren nada, pero seguramente ha optimizado el propio driver, si.

Además, los samples no son descomprimidos por el SDD-1, solo los gráficos. Los samples son siempre transferidos en formato comprimido, en cualquier juego, y el spc700 los descomprime en su aram. La descompresión de sudio nunca afecta sl programa, nunca. En ningún caso.


Te agradezco la explicación Compañero :) sabía, o mejor dicho, creía saberlo, que lo que descomprime el SDD-1 son los gráficos en lugar del sonido.

Dentro de lo que Googleé en los últimos dos años apunta a que en gran medida ocurrió como explicas, Capcom hizo un trabajo muy aceptable en global, pero en este aspecto parece que dejaron flecos sueltos, me figuro que la conversión fué muy compleja, redibujar todos los gráficos, el trasvase del motor, con todos los combos, animaciones, ect, el uso del Chip para comprimir la info, todo esto en 1996, sin tener la certeza de si el cartucho podría ser amortizado convenientemente o no, es 'normal' dentro de lo que cabe que Capcom tuviera cierta premura a la hora de lanzar el juego, a la Super en ese entonces ya le quedaba menos de un año de vida comercial 'práctica'.

Tanto es como has dicho, que si hacemos la prueba de ejecutar un movimiento especial en el pad durante la parada de Fight, o bien tan sólo pulsamos un botón en el momento preciso (justo cuando queda un segundo para que inicie el combate), veremos que la orden que hemos dado se ejecuta de forma retardada, es decir, el sistema se encuentra lo bastante libre durante la parada como para procesar esa orden y ejecutarla nada más la secuencia del juego lo permita.


Os pido disculpas por tanto offtopic.
Señor Ventura escribió:@I-rem

Los parones del street fighter alpha 2 SI son culpa del driver.

No hay ni un solo parón durante los combates a pesar de estar plagados de samples para voces y efectos de sonido, y todo lo que se escucha durante todo el juego estransferido al vuelo exactamente igual que todo lo demás.

El driver es ineficiente, pesado, y presumiblemente se transfiere a la ARAM en un solo bloque. Siendo la ventana para transferencias durante un período v-blank extremadamente pequeña, causa un parón en el programa porque necesita usar muchas de ellas consecutivamente.

El programa reescribe el driver antes de cada combate, y durante sus transiciones para reiniciar el control. Esto es innecesario. El autor de esta correción lo que ha hecho es dividir la esctitura de este driver en micro cargas, de forma que no paren nada, pero seguramente ha optimizado el propio driver, si.

Además, los samples no son descomprimidos por el SDD-1, solo los gráficos. Los samples son siempre transferidos en formato comprimido, en cualquier juego, y el spc700 los descomprime en su aram. La descompresión de audio nunca afecta al programa. Nunca. En ningún caso.

Solo he visto,sin parones,la versión msu-1.
Luego,por lógica,tiene que ver con un tema de compresión de audio.
mcfly escribió:
dr apocalipsis escribió:
mcfly escribió:Afirmas las cosas con mucha decisión.No puedes pensar que sea por otro motivo?.Para que se oiga de forma nítida el sample de audio,por ejemplo.Y no pase como en la mayoría de juegos de md,que suena la voz cazallera cuando la mezclas con musica y fx?.
Hay que disfrutar de las máquinas retro,aún con sus limitaciones.


La voz suena mal igualmente, y parar el FM no ayuda en absolutamente nada a la reproducción de samples en ese Yamaha.
No es un rasgo del Yamaha 2612 que haga por defecto, todo lo contrario. El silenciamiento y vuelta a la reproducción de los canales FM están claramente cocinados para que suenen así en ese juego.

Si fuese por mejorar la calidad de reproducción estaría parando la acción, no silenciando los canales FM.

Mira que es fácil.

Cuando dices que suena mal igualmente,te refieres a en ese juego en concreto, o en los juegos de mega,en general?.Aquí siempre se ha dicho que,si no se oían bien los samples de voz en md,era por el driver.Pero se me hace difícil,pensar en un juego,en el que suenen sin carraspeo,las voces+fx+fm.A día de hoy,xenocrisis,es un ejemplo de lo que digo.Sin embargo,tienes la versión con parche de audio de sf2,que intenta disimular ese carraspeo en los samples y en los fx.


Para mí es al revés.

Cuando un sample de sonido suena limpio en Megadrive durante el juego, es gracias a que alguien se ha currado bien el driver. Eso sin entrar en comparaciones con otras máquinas.

Y no, SFA2, ni ningún otro juego de SNES, reproduce los samples al vuelo desde la ROM, eso es completamente falso. Se ha conseguido hacer streaming de audio al SPC700 matando completamente al 5A22 o sobreescribiendo la RAM del SPC700 a lo bruto a costa de una calidad de sonido horrible (intro del Tales of Phantasia). Pero jamás en mitad de un juego.

La comunicación entre el 5A22 y el SPC700 es terriblemente precaria, a lo que hay que sumar que son 2 chips con ningún tipo de sincronía posible, usando 2 cristales distintos y sin posibilidad de comunicación de retorno.

Lo que hace el SDD-1 es entregar los tiles ya descomprimidos desde la ROM, donde están almacenados comprimidos, de manera que la SNES los pueda recuperar como si estuviesen almacenados sin comprimir. La SNES ni se entera, es transparente para ella.

Vamos a respetarnos.

I-rem escribió:Aunque este ejemplo me demuestra estar seguramente algo errado :)
https://youtu.be/aJNEfPimU40?si=7b3BI--3Mg2juc81&t=331


Muy bien traido ese ejemplo.

Te hace el corte artístico de música y acción con los powerups, y sin embargo el resto de voces suenan sin cortes. Con misma calidad y duración de los samples.
mcfly escribió:Solo he visto,sin parones,la versión msu-1.
Luego,por lógica,tiene que ver con un tema de compresión de audio.


Es que la versión msu1 es la única que corrige el driver.

No tiene sentido que sean los samples los que crean los parones, pero que durante el juego no lo hagan.

Todos los juegos de snes tienen el audio comprimido, son nueve niveles por hardware, y es el spc700 quien los descomprime. En todo caso.

Luego tienes el parodius 3, que lleva un SA1, y aunque no estoy seguro, creo que su labor es puentear al spc700 como procesador de audio, posiblemente (y digo posiblemente) porque los samples llevan compresiones mas fuertes de las que el spc700 puede soportar, por no hablar de que entonces podría ser un formato incompatible.

Antes de que el sdd1 fuese emulado, el sfa2 se ejecutaba sin problemas con el sonido, pero los gráficos estaban corrompidos. Ese co procesador (sdd1), solo descomprime gráficos, los vuelca en una memoria en el cartucho, y los manda al vuelo ya descomprimidos a la vram.
VempireX está baneado del subforo por "flames"
@Señor Ventura
Yo también leí que ayudaba a la descompresión de audio, debido a que el comentarista no se calla ni de bajo el agua.
Tendría sentido, ya que es el único juego de todo el catalogo de super famicom, con Sa-1, que se ralentiza.
VempireX escribió:@Señor Ventura
Yo también leí que ayudaba a la descompresión de audio, debido a que el comentarista no se calla ni de bajo el agua.
Tendría sentido, ya que es el único juego de todo el catalogo de super famicom, con Sa-1, que se ralentiza.

Sa-1????
riffraff escribió:Si entendieras la explicación que acabas de dar, entenderías por qué es imposible el invento que propones.


¿La has entendido tu?.

Estoy diciendo que el hdma cuenta con registros propios para actualizar esa tabla en cualquier momento mediante IRQs, y me dices esto.

riffraff escribió:Pero repito, aunque fuera posible, las secciones de la serpiente se superponen, por lo que la PPU tendría que "rebobinar" (volver hacia atrás) para pintar todas las secciones con el mismo fondo. Una burrada, un rebuzno.


Existen las prioridades. Se dibuja de arriba a abajo, es básico.

Lo de rebuzno ya lo has dicho varias veces, y hasta aquí. Queda reportado.

riffraff escribió:El gif que has puesto por poner algo no superpone dos o más secciones de un mismo plano en la misma horizontal con HDMA, ni "comparte concepto" porque no se puede.


Ya he notado que no lo ves.
Un saludo a la consolegada!

Ésto es lo que pienso yo.

https://cdn1.suno.ai/cc5fdde2-0fd5-410b ... 585376.mp4

Una canción hecha desde el corazón.
Otra vez...

Señor Ventura escribió:
riffraff escribió:Pero repito, aunque fuera posible, las secciones de la serpiente se superponen, por lo que la PPU tendría que "rebobinar" (volver hacia atrás) para pintar todas las secciones con el mismo fondo. Una burrada, un rebuzno.


Existen las prioridades. Se dibuja de arriba a abajo, es básico.

Tú lo has dicho.

De arriba a abajo, cambiando el estado de la PPU una sola vez por scanline, no varias veces por scanline ni mucho menos haciendo retroceder a la PPU, que es lo que haría falta para mostrar todas las piezas de la serpiente con un solo fondo, ya que se superponen.

Señor Ventura escribió:Lo de rebuzno ya lo has dicho varias veces, y hasta aquí. Queda reportado.

Reporta lo que creas conveniente, pero aunque te fastidie oírlo, lo siento mucho, pero tu invento es una burrada.

Señor Ventura escribió:
riffraff escribió:El gif que has puesto por poner algo no superpone dos o más secciones de un mismo plano en la misma horizontal con HDMA, ni "comparte concepto" porque no se puede.


Ya he notado que no lo ves.

¿Eres capaz de señalar en ese gif las scanlines en las que se superponen dos o más secciones de un mismo plano en la misma horizontal con HDMA?
¿Eres capaz de aportar ejemplos de juegos de SNES que sí lo hayan hecho?
¿Eres capaz de aportar una demo que sí lo haga?

No, ¿verdad?
Pues reporta todo lo que quieras, pero por favor, deja el tema y para de inventar.
PepAlacant escribió:Un saludo a la consolegada!

Ésto es lo que pienso yo.

https://cdn1.suno.ai/cc5fdde2-0fd5-410b ... 585376.mp4

Una canción hecha desde el corazón.



@riffraff no existen ejemplos con interrupciones masivas, que sería lo que necesita algo así. No existe por un motivo, y ese motivo tiene solución.

Sobre el resto de lo que dices, da la sensación de que no es posible que entiendas.
Señor Ventura escribió:@riffraff no existen ejemplos con interrupciones masivas, que sería lo que necesita algo así. No existe por un motivo, y ese motivo tiene solución.

Sobre el resto de lo que dices, da la sensación de que no es posible que entiendas.

Ni mil millones de interrupciones permitirían hacer retroceder a la PPU para renderizar las piezas que se superponen con el mismo fondo.

Además, igual la PPU cachea los registros de posición del fondo al inicio de la scanline, por lo que igual no se podría hacer incluso si las piezas no se solaparan.

Sobre eso y el resto de lo que digo, da la sensación de que ni quieres ni puedes entender.

EDIT

Llevaba razón, no se puede incluso aunque las piezas de la serpiente no se solaparan.

Por ejemplo, BG1HOFS (el registro que controla la posición horizontal del fondo 1) no se puede escribir en v-draw (mientras la PPU pinta la pantalla).

En esta tabla:
https://wiki.superfamicom.org/registers

Dicen que BG1HOFS (como el resto de registros de posición de fondos) sólo se puede escribir en f-blank, v-blank y h-blank, no "any time" como INIDISP por ejemplo.

Aunque le pongas a la pobre SNES un reactor nuclear generando "interrupciones masivas" [+risas], no se puede.
VempireX está baneado del subforo por "flames"
mcfly escribió:
VempireX escribió:@Señor Ventura
Yo también leí que ayudaba a la descompresión de audio, debido a que el comentarista no se calla ni de bajo el agua.
Tendría sentido, ya que es el único juego de todo el catalogo de super famicom, con Sa-1, que se ralentiza.

Sa-1????

Chips de apoyo
@riffraff Así que no serías capaz de ingeniártelas...
VempireX escribió:
mcfly escribió:
VempireX escribió:@Señor Ventura
Yo también leí que ayudaba a la descompresión de audio, debido a que el comentarista no se calla ni de bajo el agua.
Tendría sentido, ya que es el único juego de todo el catalogo de super famicom, con Sa-1, que se ralentiza.

Sa-1????

Chips de apoyo

Sf alpha 2=sdd-1
Señor Ventura escribió:@riffraff Así que no serías capaz de ingeniártelas...

Ni yo, ni tú ni nadie [+risas]

Si algo no se ha hecho antes en una consola tan "estrujada" como la SNES, suele ser por un buen motivo.
VempireX está baneado del subforo por "flames"
mcfly escribió:
VempireX escribió:
mcfly escribió:Sa-1????

Chips de apoyo

Sf alpha 2=sdd-1

Lo se...pero le estoy contestando a Ventura, sobre su comentario de el último Parodius...
PepAlacant escribió:Un saludo a la consolegada!

Ésto es lo que pienso yo.

https://cdn1.suno.ai/cc5fdde2-0fd5-410b ... 585376.mp4

Una canción hecha desde el corazón.


Como se nota que es IA...
riffraff escribió:Una burrada, un rebuzno.

Esto sobra. Cuidado con entrar así al trapo.

PepAlacant escribió:Un saludo a la consolegada!

Ésto es lo que pienso yo.

https://cdn1.suno.ai/cc5fdde2-0fd5-410b ... 585376.mp4

Una canción hecha desde el corazón.

Esto también. PepAlacant, llevas ya varios avisos. No habrá otro.
Alejo I escribió:
riffraff escribió:Una burrada, un rebuzno.

Esto sobra. Cuidado con entrar así al trapo.

¿Qué sinónimo hubiera estado bien usar para decir que es una burrada como un templo sin ofender a nadie?
¿Estupidez? ¿Disparate? ¿Barbaridad?

Supongo que también sobra decir que lo último que pretendía era ofender, pero una cosa es intentar evitar ofender y otra no poder llamar a las cosas por su nombre, no vaya a ser que alguien se ofenda.
VempireX está baneado del subforo por "flames"
Alejo I escribió:
riffraff escribió:Una burrada, un rebuzno.

Esto sobra. Cuidado con entrar así al trapo.

PepAlacant escribió:Un saludo a la consolegada!

Ésto es lo que pienso yo.

https://cdn1.suno.ai/cc5fdde2-0fd5-410b ... 585376.mp4

Una canción hecha desde el corazón.

Esto también. PepAlacant, llevas ya varios avisos. No habrá otro.

Como se notan los favoritismos Alejo, saca pecho, que es una cosa que ya se sabe desde hace tiempo.
riffraff escribió:Ni yo, ni tú ni nadie [+risas]

Si algo no se ha hecho antes en una consola tan "estrujada" como la SNES, suele ser por un buen motivo.


Cuando te están diciendo que aseguras que funciona como no se está explicando, después de cinco veces es para plantearse que igual hay algo... pero entiendo que negando rotundamente con firmeza se aparenta conocimiento, que es lo único que te interesa, y no el problema como ejercicio.

No se dibuja por fragmentos solo porque el gráfico original sean sprites, que si lo son (fragmentos).

Algo así no se ha hecho antes en snes porque se necesita un hardware de apoyo que nunca se le ha dedicado para esa tarea, eso no significa que no se pueda, solo que no se ha hecho.

Tampoco se han hecho rpg's con fondos de 400 colores, y eso no significa que no se pueda, solo que no se ha hecho.

P.D: la snes no estuvo para nada "estrujada". Hay multitud de características y modos gráficos que no se usaron habitualmente, o que directamente no se usaron.
VempireX escribió:
Alejo I escribió:
riffraff escribió:Una burrada, un rebuzno.

Esto sobra. Cuidado con entrar así al trapo.

PepAlacant escribió:Un saludo a la consolegada!

Ésto es lo que pienso yo.

https://cdn1.suno.ai/cc5fdde2-0fd5-410b ... 585376.mp4

Una canción hecha desde el corazón.

Esto también. PepAlacant, llevas ya varios avisos. No habrá otro.

Como se notan los favoritismos Alejo, saca pecho, que es una cosa que ya se sabe desde hace tiempo.

Las quejas las pones en Feedback.
Señor Ventura escribió:Cuando te están diciendo que aseguras que funciona como no se está explicando, después de cinco veces es para plantearse que igual hay algo... pero entiendo que negando rotundamente con firmeza se aparenta conocimiento, que es lo único que te interesa, y no el problema como ejercicio.

Si te explico que algo no se puede de veinte formas, como si fueras un crío de siete años, con tablas, capturas y demás, y aun así crees que estoy "aparentando" conocimiento en vez de decirme en qué me equivoco, poco más puedo hacer.

Si tú te centraras de una vez en "el problema como ejercicio", con echar un ojo a esta tabla debería haberte sido suficiente para entender que lo que propones es imposible.

Por cierto, ¿que me hayas dicho varias veces que no sé de lo que hablo y que "aparento conocimiento" sin tener una sola prueba es motivo para reportar?
¿ @Alejo I, a él también le vas a llamar la atención en público?

Señor Ventura escribió:Algo así no se ha hecho antes en snes porque se necesita un hardware de apoyo que nunca se le ha dedicado para esa tarea, eso no significa que no se pueda, solo que no se ha hecho.

Una vez más, te he dado varios motivos de por qué no se puede aunque le enchufaras un MareNostrum a la pobre SNES [+risas]

Para que lo entiendas de una vez (aunque lo dudo), no es por falta de CPU, sino por limitaciones de la PPU, la cuál no se puede mejorar con hardware de apoyo.

Pero bueno, no sé por qué lo sigo intentando.
No hay peor ciego que el que no quiere ver.
riffraff escribió:¿ @Alejo I, a él también le vas a llamar la atención en público?

Si consideras que sus mensajes infringen las normas puedes utilizar la función de reporte y tomaremos las medidas oportunas.
No, yo no debería reportar nada porque soy un adulto y no debería ir corriendo al botón de reportar en cuanto algo me moleste, igual que tampoco deberías haberme llamado la atención en público por decir que algo es una burrada (con motivos).
riffraff escribió:No, yo no debería reportar nada porque soy un adulto y no debería ir corriendo al botón de reportar en cuanto algo me moleste, igual que tampoco deberías haberme llamado la atención en público por decir que algo es una burrada (con motivos).

No es decir que algo sea una burrada, sino decir que alguien está rebuznando. Que puede parecer una diferencia de matiz, pero es totalmente innecesario.

Sea como fuere (y sin ir necesariamente por ti), nuestra paciencia en este hilo está llegando a su límite.
VempireX está baneado del subforo por "flames"
Alejo I escribió:
VempireX escribió:
Alejo I escribió:Esto sobra. Cuidado con entrar así al trapo.


Esto también. PepAlacant, llevas ya varios avisos. No habrá otro.

Como se notan los favoritismos Alejo, saca pecho, que es una cosa que ya se sabe desde hace tiempo.

Las quejas las pones en Feedback.

Buen chiste, no hacéis caso de mis reportes, vais a hacer caso de los feedback, hazme un favor, y no insultes mi inteligencia, como para intentar hacerme perder el tiempo.
Alejo I escribió:Sea como fuere (y sin ir necesariamente por ti), nuestra paciencia en este hilo está llegando a su límite.


Estaba hablando de la serpiente del xenocrisis desde un punto de vista técnico, ¿estoy participando mal?.

Pregunto para saber si debo desistir.
VempireX escribió:
Alejo I escribió:
VempireX escribió:Como se notan los favoritismos Alejo, saca pecho, que es una cosa que ya se sabe desde hace tiempo.

Las quejas las pones en Feedback.

Buen chiste, no hacéis caso de mis reportes, vais a hacer caso de los feedback, hazme un favor, y no insultes mi inteligencia, como para intentar hacerme perder el tiempo.

Llevas más de una docena de infracciones en un año sin contar las que hemos pasado por alto, vas perdonando vidas por ahí y cuando no estás siendo un dolor de cabeza para los mods no haces otra cosa que despotricar. Es evidente que no estás cómodo en este foro, así que vamos a hacernos un favor todos.

El hilo puede continuar.
649 respuestas
19, 10, 11, 12, 13