[Duda Snes] Beta de Street Fighter Alpha 2 con chip SA-1

Efectivamente, Devil Akuma (yo lo llamaba así, por lo menos) era desbloqueable.

Cuando compré el Action Replay resucité la SNES, le di una caña a todos los juegos brutal. Ya no sólo con el listado de códigos que te incluía en un librito al comprarlo, si no con las funcionalidades de buscar nuevos códigos. Pues anda que no me pasé horas descubriendo locuras

Aquí tienes una web con todos los del Street Fighter Alpha 2 de SNES, entre ellos el de escoger personaje y ahí puedes ponerle el número de Shin Akuma:

http://bsfree.org/?s=4&d=5&g=5143

Encontré un montón de cosas, pero ningún personaje oculto más. Lo curioso es que Devil Akuma fuera realmente totalmente controlable pero no hubiese ningún truco para acceder a él. Quiero decir, que no es como el primer SF2 en que los jefes están pero no puedes controlarlos mediante ningún código, esa posibilidad no estaba implementada.

En cuanto a la versión Alpha o Beta del Street Fighter Alpha 2 (qué lío!), yo he llegado a oir que de inicio empezaron programando el Street Fighter Alpha, pero que el desarrollo se demoró de tal manera que, y ya teniendo los personajes hechos y pudiendo usarlos para hacer el 2, decidieron aventurarse a hacer el 2. De hecho si te fijas, salió bastante a la par que las versiones PSX y Saturn.

El tamaño de personajes y su número de frames no puede ser ayudado por ningún tipo de chip adicional.

Ni siquiera el MSU1 aumenta las capacidades de la snes para reproducir vídeo (es decir, que los vídeos, sin el audio, que vemos en todos los ejemplos de es chip, son reproducidos por la propia snes a 256 colores por frame).

En esto no hay mas cera que la que arde... 5,72KB por frame, o mas memoria si reduces la resolución (a 256x192, por ejemplo, el ancho de banda se sitúa en los 11KB por frame... en megadrive podría irse a los 14KB fácilmente).

La cuestión es hasta que punto el killer instinct ocupa el ancho de banda de la snes, teniendo en cuenta que los escenarios ya están precargados en la VRAM, y tan solo se transfieren los tiles de los personajes y magias, y los efectos de sonido y músicas.

Yo no creo que el SA-1 fuera una opción para el SFA2, ya que la verdadera necesidad de ese juego era meter más gráficos para tener más frames de animación de cada personaje o personajes más grandes y hacer más fluidos los movimientos. Aunque el SA-1 acelera las descompresiones, siempre es mejor un chip dedicado a ello como el S-DD1, por lo que opino que éste sería la opción desde el principio.
Lo de meter dos chips en la placa sí que lo veo absolutamente innecesario y extraordinariamente caro: lo primero es que cada uno hubiera necesitado tener su propio chip de ROM, ya que si no colisionarían los dos al acceder a ella.
Luego SA-1 necesita su RAM propia, así que es un tercer chip más a añadir, y además creo que el consumo del cartucho excedería el máximo de la SNES al conectar el segundo mando, lo cual hace inviable técnicamente meter dos chips.
Y económicamente también es inviable, porque recordemos que el objetivo del S-DD1 era ahorrarse un chip de ROM metiendo una descompresión al vuelo. Si al final te sale más caro el collar que el perro, no merece la pena meter el chip.

De todos modos la snes ya está muy al límite con el street fighter alpha 2 (hablo de frames de animación, y tamaño de personajes).

Si a ese tamaño puedes añadir 1 o 2 frames mas en cada animación, ya puedes darte con un canto en los dientes.

Eso si, lo que si que si que se quedó muy por debajo del nivel de la máquina, es el aspecto sonoro, pero claro, ¿que haces?, ¿le dedicas mas ancho de banda a la música?, porque si es así, ya puedes olvidarte de tener animaciones mejores en el juego casi con total seguridad.

Estoy incluso por pensar que los efectos de sonido están todos metidos en la RAM del SPC700 antes de empezar el combate, porque es que es una jodía barbaridad lo demandante de memoria que tiene que ser cargar las animaciones de un zangief vs sodom:
https://youtu.be/mYQNw8XXy8o?t=46


Una lástima que no se plantearan meter una resolución de 256x192.

Hay muchas cosas que, con perspectiva, hechas de otra forma creo que hubiesen salido mejor pero que probablemente tuvieran alguna razón para hacer así... espero!

El tema de las sombras del suelo, por ejemplo: putas sombras que parpadean a un framerate tan bajo que son insufribles. A ver, está claro que así sólo pintan una sombra por frame en lugar de las dos, pero tanto hubiese afectado ponerlas transparentes, que la SNES lo puede hacer, y dejarlas fijas? Sería pintar a cada frame una sombra más, cierto es, pero... uf, es que ese parpadeo era muy insufrible.

Las músicas, sí, menuda mierda de samples, todas suenan como si fueran del escenario de china. Yo, directamente, hubiese suprimido toda la intro: ¿hacía falta? Que sí, que mola, pero... no sé, y un cartucho de 48 megas no era posible? Recuerdo que se vendía por 10000 pesetas en ECI.

Nunca entendí qué apaño raro y cutre hicieron en el escenario de Guy para que en lugar de poner JEFFRY en el fondo ponga JEFFFRY

Y obviamente, lo de la pausa después del Fight... en serio, hay que quitar la voz de fight y la imagen para que quepa el resto durante el combate? No podían poner "Round One", que aquí hiciera la descompresión, y que con el Fight! se empezar a luchar?

Creo recordar haber leído por ahí que la "paradinha" que hace el juego antes de cada combate es para meter los samples de sonido en la memoria, no sé si directamente del SPC o en RAM de la SNES, pero estaba relacionado con el driver de sonido.

Por muchos megas que tenga el cartucho en el chip de sonido de la SNES sólo entran 64Kb de instrumentos, voces y "partituras", así que a hacer malabarismos entre la calidad y cantidad de todos estos elementos. Supongo que se podría hacer streaming desde el cartucho pero eso en un juego comercial parece ser que no hubiese sido viable por el precio de la ROM, y tampoco se si podría reproducir efectos de sonido aparte del sonido del streaming.

Gammenon escribió:Por muchos megas que tenga el cartucho en el chip de sonido de la SNES sólo entran 64Kb de instrumentos, voces y "partituras", así que a hacer malabarismos entre la calidad y cantidad de todos estos elementos. Supongo que se podría hacer streaming desde el cartucho pero eso en un juego comercial parece ser que no hubiese sido viable por el precio de la ROM, y tampoco se si podría reproducir efectos de sonido aparte del sonido del streaming.

Con 2KB del ancho de banda te monto una canción a 32Khz en su perfecto stereo sin ocupar mas de 32KB de la RAM del SPc700.

El problema es ese, que necesitas reservar 2KB del ancho de banda, por frame.

Pero hay juegos, por ejemplo un super pang, donde podría hacerse sin ningún problema, porque las animaciones de todo el resto de sprites no demandan 3,72KB por frame ni hartos de vino.

Señor Ventura escribió:

Gammenon escribió:Por muchos megas que tenga el cartucho en el chip de sonido de la SNES sólo entran 64Kb de instrumentos, voces y "partituras", así que a hacer malabarismos entre la calidad y cantidad de todos estos elementos. Supongo que se podría hacer streaming desde el cartucho pero eso en un juego comercial parece ser que no hubiese sido viable por el precio de la ROM, y tampoco se si podría reproducir efectos de sonido aparte del sonido del streaming.

Con 2KB del ancho de banda te monto una canción a 32Khz en su perfecto stereo sin ocupar mas de 32KB de la RAM del SPc700.

El problema es ese, que necesitas reservar 2KB del ancho de banda, por frame.

Pero hay juegos, por ejemplo un super pang, donde podría hacerse sin ningún problema, porque las animaciones de todo el resto de sprites no demandan 3,72KB por frame ni hartos de vino.

En un Pang quizás funcione (obviando lo que ocuparían en la ROM las músicas del streaming) pero en un SF ya el ancho de banda es totalmente insuficiente para recurrir a esta técnica. En todo caso, entonces sería posible hacer streaming y reproducir efectos de sonido en la SPC700? No hay problemas del tipo de que no se puede reproducir nada mientras se está actualizando la RAM del chip?

Pero a ver, en el Street Fighter 2 Turbo cabían las voces, la música y sus instrumentos, y los round x: fight. Por qué en este caso no?

Porque por instrumentos no será, que en esta versión hay CUATRO en todo el juego y gracias.

Supongo que no es tanto por los samples que por el driver en sí.

Imagino que meter el sonido en medio de toooooda esa descompresión gráfica sin que te interrumpa otros procesos será cuanto menos laborioso.

NiceKen escribió:Pero a ver, en el Street Fighter 2 Turbo cabían las voces, la música y sus instrumentos, y los round x: fight. Por qué en este caso no?

Porque por instrumentos no será, que en esta versión hay CUATRO en todo el juego y gracias.

Quizás son los diferentes efectos de sonido + voces los que ocupaban tanto? No se si los de Alpha 2 tienen más voces por personaje que los de SF2Turbo o SSF2

Gammenon escribió:En un Pang quizás funcione (obviando lo que ocuparían en la ROM las músicas del streaming) pero en un SF ya el ancho de banda es totalmente insuficiente para recurrir a esta técnica. En todo caso, entonces sería posible hacer streaming y reproducir efectos de sonido en la SPC700? No hay problemas del tipo de que no se puede reproducir nada mientras se está actualizando la RAM del chip?

Ahí está, eso es lo que comentaba, que el apartado sonoro es tan pobre por una razón (bueno, dos)... por un lado no restarle ancho de banda a los gráficos, y por otro el tamaño de la rom, claro.

La clave está en reproducir 15KB mientras cargas los siguientes 15KB, y así sucesivamente.

josete2k escribió:Supongo que no es tanto por los samples que por el driver en sí.

Imagino que meter el sonido en medio de toooooda esa descompresión gráfica sin que te interrumpa otros procesos será cuanto menos laborioso.

No, el SDD1 descomprime al vuelo, y los datos llegan al bus tal y como lo harían las tiles descomprimidas de una rom normal y corriente.

Es una cuestión de ancho de banda. Para actualizar los tiles de los personajes de un tamaño como el de zangief vs zangief hace falta un ancho de banda determinado, y eso solo en un momento específico en que coincidan dos frames totalmente diferentes (cuando son iguales, se utilizan los mismos tiles, no hace falta transferirlos dos veces).

La cuestión es que se parte de la peor situación posible como estándar, porque obviamente un ryu vs ryu no requieren el mismo ancho de banda. Por lo tanto, por culpa de unos breves momentos en la duración total de todo el juego, el ancho de banda dedicado para músicas y sonidos es mermado por defecto.

Gammenon escribió:Quizás son los diferentes efectos de sonido + voces los que ocupaban tanto? No se si los de Alpha 2 tienen más voces por personaje que los de SF2Turbo o SSF2

Es una cuestión de lo que los gráficos le dejan al apartado sonoro en el ancho de banda.

Lo irónico es que el 95% del juego está desaprovechando ancho de banda por culpa de que en determinados momentos de un zangief vs zangief el juego alcanza el pico en el requerimiento de ancho de banda para gráficos.

Cuántas mas cosas veo del street fighter alpha 2, mas veo alcanzable la versión playstation (a base de notar un desequilibrio en la calidad de animación de los personajes pequeños con respecto a los personajes grandes, o en su defecto evitando que dos zangiefs puedan coincidir, ni siquiera en el modo a 2 players).

La versión de Game Boy Advance de SFA3 era una auténtica maravilla, a mi juicio. Pero la hicieron otras personas, más tarde y en un cartucho más grande.

Habéis visto videos como éste comparando los SFA2, no?

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

Hola, muchísimas gracias a todos por la información estaba equivocado sobre las funciones de estos chips.. antes de abrir hilos como este debería invertir tiempo en empaparme de un montón de conceptos que desconozco, así entendería mejor las respuestas..

@NiceKen, te agradezco el enlace con los códigos de Action Replay a ver si reparo mi Snes (o me compro otra) y le doy caña.. Zsnes soporta los códigos, pero jugar en la consola con una tele de tubo se disfruta infinitamente más. Si, Street Fighter Alpha 2 de Game Boy Advance es tremendo. Llevo dos semanas enganchado al canal Vs Decide..

Señor Ventura escribió:Es una cuestión de lo que los gráficos le dejan al apartado sonoro en el ancho de banda.

Por este motivo que comentas creí hace años que el Street Fighter 2 CE de Megadrive tenía un sonido tan (para mi) pésimo, recuerdo haberlo hablado con algún amigo sobre 1995, "los gráficos y los modos de juego sacrificaron el sonido, mientras que Sreets of Rage -1- es al contrario, los gráficos son modestos pero suena como un vinilo", años despues salió a la luz el tema de los drivers de audio poco elaborados..

Señor Ventura escribió:Lo irónico es que el 95% del juego está desaprovechando ancho de banda por culpa de que en determinados momentos de un zangief vs zangief el juego alcanza el pico en el requerimiento de ancho de banda para gráficos. Cuántas mas cosas veo del street fighter alpha 2, mas veo alcanzable la versión playstation (a base de notar un desequilibrio en la calidad de animación de los personajes pequeños con respecto a los personajes grandes, o en su defecto evitando que dos zangiefs puedan coincidir, ni siquiera en el modo a 2 players).

En mi ignorancia pienso que es completamente cierto... por un "momento" de carga gráfica puntual se debe sacrificar todo un apartado entero, primero por lógica, segundo por pura precaución.

En Sunset Riders creo que podemos observar un ejemplo básico de esto, en las fases a caballo tuvieron que omitir la capa de los cactus, supongo que al funcionar en scroll... dos jugadores, más enemigos, más el tren, más el scroll del propio escenario, más los disparos (jugando con Cormano), seguramente hubieran provocado caidas puntuales de frames o buen flickering en los momentos de mayor embrollo, y buscaron que el juego en todo momento permaneciera a 40 Frames -no recuerdo a qué velocidad funciona en Pal-, un poco victoria pírrica, pero el juego se mueve de lujo con unos gráficos (la mayor parte del tiempo) clavados al arcade..

https://www.youtube.com/watch?v=6JLPBp6Qxvw

https://www.youtube.com/watch?v=tz2WgkJe3Hs
(3,25)

De pequeño, pensaba que Konami utilizó el DSP-1 o DSP-2 en exclusiva para procesar el scroll de horizonte en esta segunda fase, de esta forma se alivia trabajo al procesador..



Regresando a Street Fighter Alpha 2 de Super, en el escenario de Sagat quitaron dos capas de scroll respecto al arcade, como has dicho tal vez que no quisieron pillarse los dedos si coincidian dos Sagats o Sagat con Zangief o con Katana, porque el monumento de la Diosa es una carga gráfica considerable... si bien el escenario de Rolent se me antoja más complejo. Creo que el escenario de Rose es uno de los más recortados...

Sobre descomprimir los datos, en el análisis de la revista Super Juegos afirmaron que el parón al inicio del combate se producía por la carga (descompresión) del audio. pero hay un detalle curioso que descubrió un amigo mio, y es que si durante la carga del "Fight" ejecutamos un movimiento (combinación de mágia, avanzar o un golpe simple), este se ejecuta a destiempo tras la carga, lo que puede dar a entender que una parte de la consola está desocupada... a mi juicio esto ocurre porque es sólo el S-DD1 el único que trabaja en ese momento, mientras que el procesador de la Super aguarda para entrar en acción tras el Fight, lo deseable sería que dicha descompresión fuera realizada de manera conjunta, (para minimizar el tiempo de espera) y no sólo por el S-DD1, pero me figuro que sería tecnicamente imposible, o tal vez Capcom no tenía una librería extensa sobre el funcionamiento del Chip




Saludos

[Jun] escribió:Por este motivo que comentas creí hace años que el Street Fighter 2 CE de Megadrive tenía un sonido tan (para mi) pésimo, recuerdo haberlo hablado con algún amigo sobre 1995, "los gráficos y los modos de juego sacrificaron el sonido, mientras que Sreets of Rage -1- es al contrario, los gráficos son modestos pero suena como un vinilo", años despues salió a la luz el tema de los drivers de audio poco elaborados..

En realidad es una cuestión de drivers. Las músicas del streets of rage 2 de megadrive suenan a través del sintetizador, como siempre, solo que a veces compones bien, y a veces compones mal, pero el esfuerzo del hardware es el mismo. Con todo, creo que hicieron un bien trabajo.

El sonido sin embargo utiliza el canal pcm de la megadrive para mostrar las voces digitalizadas, y ahí la poca calidad del driver provoca que sean reproducidas con toda esa suciedad, además de estar limitado a que cada voz nueva interrumpe a la anterior, porque por defecto por aquel entonces los drivers de la mega solo estaban soportando un canal.

[Jun] escribió:En Sunset Riders creo que podemos observar un ejemplo básico de esto, en las fases a caballo tuvieron que omitir la capa de los cactus, supongo que al funcionar en scroll... dos jugadores, más enemigos, más el tren, más el scroll del propio escenario, más los disparos (jugando con Cormano), seguramente hubieran provocado caidas puntuales de frames o buen flickering en los momentos de mayor embrollo, y buscaron que el juego en todo momento permaneciera a 40 Frames -no recuerdo a qué velocidad funciona en Pal-, un poco victoria pírrica, pero el juego se mueve de lujo con unos gráficos (la mayor parte del tiempo) clavados al arcade..

La fase a caballo del sunset riders de snes usa 2 capas de scroll. La primera con todo el escenario dividiendo el scroll en varios fragmentos con distintas prioridades para simular la profundidad, y la segunda para representar la carreta.

Todo eso no le supone ningún esfuerzo ni a la cpu, ni al sistema de vídeo, puesto que tanto la snes como la megadrive admiten manejar de forma separada cada scanline de cada plano, y esto es debido a que al mostrarse, cada línea tiene un valor registrado, y solo es necesario alterarlo para provocar el tipo de comportamiento ya comentado, puesto que revisarse se revisa a cada frame, tanto si se altera, como si no.

Lo curioso es que el juego en esa fase de los caballos utiliza incluso solo 2 colores por tile en la mayoría de ellos, y hasta 3 tonos en los mas complejos, y la snes podría haber empleado ahí hasta CUATRO capas de scroll, lo cual obliga a dibujar tiles de solo 4 colores (3 mas el transparente), pero no hubiera degradado nada el dibujo tal cual está, y hubiese permitido meter los cactus del arcade, e incluso un plano extra con mas detalles, como por ejemplo la explosión de la carreta (que en snes lo hicieron con sprites, y debo decir que lo hicieron muy cutre, pues incluso siendo con sprites, da para mucho mas).

[Jun] escribió:Regresando a Street Fighter Alpha 2 de Super, en el escenario de Sagat quitaron dos capas de scroll respecto al arcade, como has dicho tal vez que no quisieron pillarse los dedos si coincidian dos Sagats o Sagat con Zangief o con Katana, porque el monumento de la Diosa es una carga gráfica considerable... si bien el escenario de Rolent se me antoja más complejo. Creo que el escenario de Rose es uno de los más recortados...

El escenario de sagat está recortado frente al arcade porque para conseguir el mismo degradado de colores que la versión CPS2, ya te obliga a usar los modos gráficos con menos planos simultáneos (que son los que mas colores por tile admiten). El juego está usando un modo gráfico con tres planos, y utiliza uno de ellos para el "HUD" (incluídas las palabras "fight", "round 1,2,3", etc), mientras que los otros dos se usan para el escenario.
Habrían habido maneras de dejar libre ese tercer plano para usarlo también para los escenarios, pero supongo que no quisieron complicarse mas la vida. Aún así, los planos principales admiten mucha mas profundidad de color que la vista en el juego, este port tiene mucho margen de mejora en muchos apartados.

[Jun] escribió:Sobre descomprimir los datos, en el análisis de la revista Super Juegos afirmaron que el parón al inicio del combate se producía por la carga (descompresión) del audio. pero hay un detalle curioso que descubrió un amigo mio, y es que si durante la carga del "Fight" ejecutamos un movimiento (combinación de mágia, avanzar o un golpe simple), este se ejecuta a destiempo tras la carga, lo que puede dar a entender que una parte de la consola está desocupada... a mi juicio esto ocurre porque es sólo el S-DD1 el único que trabaja en ese momento, mientras que el procesador de la Super aguarda para entrar en acción tras el Fight, lo deseable sería que dicha descompresión fuera realizada de manera conjunta, (para minimizar el tiempo de espera) y no sólo por el S-DD1, pero me figuro que sería tecnicamente imposible, o tal vez Capcom no tenía una librería extensa sobre el funcionamiento del Chip

Es que cabe la posibilidad de que el parón sea provocado adrede con toda la intención para que de tiempo a cargar samples, y no una cuestión de interrupción en el que la cpu se queda congelada por conflictos con el uso del bus.

Posiblemente solo esté cargando samples para tenerlos almacenados en la ram del spc700, y ahorrar ancho de banda durante el combate evitando cargarlos 10 o 15 veces durante el mismo.

@Señor_Ventura, muchas gracias por tomarte el tiempo de responderme de esa manera, hay conceptos que no puedo entender bien por pura ignorancia pero me queda todo mucho más claro.

Señor Ventura escribió:(que en snes lo hicieron con sprites, y debo decir que lo hicieron muy cutre, pues incluso siendo con sprites, da para mucho mas).

Si, siempre me chocó bastante, por la pixelación pensaba que para hacer las explosiones utilizaron un plano en modo 7, de esa forma evitaban utilizar un gráfico compuesto de varias animaciones, ahorrando así memoria.

Señor Ventura escribió:Lo curioso es que el juego en esa fase de los caballos utiliza incluso solo 2 colores por tile en la mayoría de ellos, y hasta 3 tonos en los mas complejos, y la snes podría haber empleado ahí hasta CUATRO capas de scroll, lo cual obliga a dibujar tiles de solo 4 colores (3 mas el transparente), pero no hubiera degradado nada el dibujo tal cual está, y hubiese permitido meter los cactus del arcade, e incluso un plano extra con mas detalles

Justo esta mañana, al comparar en video las dos versiones pensé en esa carencia de color, en verdad a nivel gráfico la fase que más cojea es la segunda, y tal vez tambien la de los indios. Aunque, siendo un poco cínico, viendo la conversión que Konami hizo en Megadrive, los "Supernintenderos" no tenemos ningún derecho a quejarnos.

Señor Ventura escribió:El escenario de sagat está recortado frente al arcade porque para conseguir el mismo degradado de colores que la versión CPS2, ya te obliga a usar los modos gráficos con menos planos simultáneos (que son los que mas colores por tile admiten). El juego está usando un modo gráfico con tres planos, y utiliza uno de ellos para el "HUD" (incluídas las palabras "fight", "round 1,2,3", etc), mientras que los otros dos se usan para el escenario.

Habrían habido maneras de dejar libre ese tercer plano para usarlo también para los escenarios, pero supongo que no quisieron complicarse mas la vida. Aún así, los planos principales admiten mucha mas profundidad de color que la vista en el juego, este port tiene mucho margen de mejora en muchos apartados.

Comprendo. Imagino que el escenario de Rose tambien ocurre lo mismo (o en el escenario de Billy Kane en FFE), Pero en este apartado, siempre me pregunté el motivo de simplificar 'tanto' los marcadores, ¿porqué omitieron las caras de los personajes y la fuente en verde de los números?, las razones que encontré fueron que tal vez utilizaron la cuarta capa gráfica casi en exclusiva para dibujar el marcador, (que me parece imposible porque esa capa admite muy pocos colores), o bien porque la resolución empleada era demasiado baja como para que el aspecto de las figuras se visualizara bien. (esto se vé quizás tambien en el plantel de selección de personaje, en el tuvieron que quitar efecto de profundidad).

Aunque sea entrar en un tema distinto, siempre me ha resultado muy curioso la simplificación de los marcadores al pasar/portar un juego de una plataforma superior a otra inferior, (Megadrive >> Máster System, Neo Geo >> Snes/Megadrive), los marcadores deberían ser fáciles en extremo de gestionar y el especio que ocupan es mínimo. Por esta la misma regla de tres y salvando las distancias, podríamos preguntarnos porqué motivo, teniendo 16 Megas, Worms y Lost Wikings 2 no se hicieron en Snes más similares a las versiones de 32 Bits, cuando pienso que DKC demostró que era del todo posible...

Siento ser tan profano en la materia y no poder debatir en condiciones, pero gracias a vosotros estoy siendo un poco menos inculto...



Saludos

Señor Ventura escribió:Todo eso no le supone ningún esfuerzo ni a la cpu, ni al sistema de vídeo, puesto que tanto la snes como la megadrive admiten manejar de forma separada cada scanline de cada plano, y esto es debido a que al mostrarse, cada línea tiene un valor registrado, y solo es necesario alterarlo para provocar el tipo de comportamiento ya comentado, puesto que revisarse se revisa a cada frame, tanto si se altera, como si no.

No, Señor Ventura, esto ya lo comentamos en el pasado: la SNES y la Megadrive no manejan scanlines, manejan tiles, por lo que el desplazamiento para el scroll se hace en tiles; y esto sí carga algo la CPU: ten en cuenta que según las pulsaciones del mando (y por tanto la dirección en la que se mueva el personaje y la velocidad a la que lo haga), hay que actualizar más tiles o menos para hacer el scroll. Y hay que calcular qué tiles son, cuánto se desplazan y controlar si son tiles que ya están en VRAM o hay que transferirlas. Aquí hay un dilema, ya que en algunas ocasiones es más costoso comprobar si las tiles están ya en VRAM que transferirlas cada frame; pero claro, si las transfieres cada frame, pierdes ancho de banda con la VRAM.
Sobre todo esto pasa en escenarios que son muy variados, como un Final Fight, en los que merece la pena comprobar si están en VRAM para enviarlas y dejar ancho de banda libre para mover a los personajes.
En otros escenarios más repetitivos, como en el Sunset Riders, merece la pena enviarlas cada X frames, ya que al ser repetitivos, muchas partes se reutilizan.

Luego, volviendo al tema de los scanlines, la SNES tiene además el modo HDMA, que sí es independiente de la CPU, y que permite modificar el offset de cada línea por separado, pero esto no vale para hacer scroll, ya que al ser independiente de la CPU, ésta no controlaría cuánto habría que desplazar el fondo según las pulsaciones de los mandos,

Señor Ventura escribió:Es que cabe la posibilidad de que el parón sea provocado adrede con toda la intención para que de tiempo a cargar samples, y no una cuestión de interrupción en el que la cpu se queda congelada por conflictos con el uso del bus.

Posiblemente solo esté cargando samples para tenerlos almacenados en la ram del spc700, y ahorrar ancho de banda durante el combate evitando cargarlos 10 o 15 veces durante el mismo.

Es que no puede haber conflicto de bus por una razón: el S-DD1 descomprime haciendo un DMA, por lo que si lo hace a VRAM tiene que ser en un VBlank, por lo que la pantalla no podría estar encendida todo el rato. Por tanto, descartamos que el S-DD1 esté haciendo cualquier descompresión gráfica durante el parón.
Si el S-DD1 está descomprimiendo audio (cosa que dudo, porque el algoritmo aritmético que lleva no se comporta demasiado bien con el BRR del SPC), entonces ha de hacer un DMA a RAM para de ahí enviar al SPC, que es donde se produciría el parón. Por tanto la CPU no se queda "congelada", sino que va a todo trapo para enviar el audio.

magno escribió:No, Señor Ventura, esto ya lo comentamos en el pasado: la SNES y la Megadrive no manejan scanlines, manejan tiles, por lo que el desplazamiento para el scroll se hace en tiles;

Pensaba que la megadrive si podía, aunque ahora que recuerdo, creo que cuando se habló del tema se habló de algún tipo de pega que no recuerdo.

Despista un montón encontrarse ejemplos como el suelo del street fighter 2, en el que la corrección de perspectiva tiene un detalle enorme (scanline por scanline).

magno escribió:y esto sí carga algo la CPU: ten en cuenta que según las pulsaciones del mando (y por tanto la dirección en la que se mueva el personaje y la velocidad a la que lo haga), hay que actualizar más tiles o menos para hacer el scroll. Y hay que calcular qué tiles son, cuánto se desplazan y controlar si son tiles que ya están en VRAM o hay que transferirlas. Aquí hay un dilema, ya que en algunas ocasiones es más costoso comprobar si las tiles están ya en VRAM que transferirlas cada frame; pero claro, si las transfieres cada frame, pierdes ancho de banda con la VRAM. Sobre todo esto pasa en escenarios que son muy variados, como un Final Fight, en los que merece la pena comprobar si están en VRAM para enviarlas y dejar ancho de banda libre para mover a los personajes.
En otros escenarios más repetitivos, como en el Sunset Riders, merece la pena enviarlas cada X frames, ya que al ser repetitivos, muchas partes se reutilizan.

En realidad contaba con que el programador contara con que ya tuviese todos los tiles necesarios instalados en la VRAM.

Y visto así... no consideraba el impacto de lo que la perspectiva obliga a otras secciones del scroll a moverse mas rápido de lo que lo haría si todo el mapeado fuese un solo bloque (moviendose mas despacio).

Sin embargo, también puede darse el caso contrario. Un plano principal que se mueve a toda pastilla, que gracias a dividirlo en varias secciones, las mas superiores se muevan mas despacio, y permitiendo así que las secciones del plano mas "ceracanas"(mas rápidas), puedan moverse incluso mas rápido (ya que las superiores, mas lentas, necesitan menos recursos actualizando tiles).

magno escribió:Luego, volviendo al tema de los scanlines, la SNES tiene además el modo HDMA, que sí es independiente de la CPU, y que permite modificar el offset de cada línea por separado, pero esto no vale para hacer scroll, ya que al ser independiente de la CPU, ésta no controlaría cuánto habría que desplazar el fondo según las pulsaciones de los mandos,

Esta es la cuestión. En snes puedes controlar cada scanline, pero tenía totalmente ignorado que no se pudiera hacer scroll con ellas. Chasco.

Igualmente, cada grupo de 8 scanlines tampoco está tan mal, ya te permite un nivel de detalle para la perspectiva importante... sin embargo, ¿que hay de lo mencionado con el suelo del street fighter 2?, ahí hay scroll, y creo que se puede apreciar que cada scanline va a su bola (salvo que vea mal, claro xD)

magno escribió:Es que no puede haber conflicto de bus por una razón: el S-DD1 descomprime haciendo un DMA, por lo que si lo hace a VRAM tiene que ser en un VBlank, por lo que la pantalla no podría estar encendida todo el rato. Por tanto, descartamos que el S-DD1 esté haciendo cualquier descompresión gráfica durante el parón.

Además coincide, porque se estarían transfiriendo samples de audio, y esos no están comprimidos en ROM (es lo que siempre he pensado, vamos).

magno escribió:Si el S-DD1 está descomprimiendo audio (cosa que dudo, porque el algoritmo aritmético que lleva no se comporta demasiado bien con el BRR del SPC), entonces ha de hacer un DMA a RAM para de ahí enviar al SPC, que es donde se produciría el parón. Por tanto la CPU no se queda "congelada", sino que va a todo trapo para enviar el audio.

Por lo que, podría ser que finalmente los samples si estén comprimidos. No veo otra forma de que todo el programa se congele si no hay conflictos con la cpu.

Va petaíta esa rom. La de incidencias que habría ahorrado haber puesto una memoria de 64 megas (dos de 32, quiero decir).

P.D: ¿Por qué tengo la idea preestablecida de que no puedes poner roms de mas de 32 megas? (es decir, 2 roms para 64, o 4 roms para 128).

Señor Ventura escribió:Igualmente, cada grupo de 8 scanlines tampoco está tan mal, ya te permite un nivel de detalle para la perspectiva importante... sin embargo, ¿que hay de lo mencionado con el suelo del street fighter 2?, ahí hay scroll, y creo que se puede apreciar que cada scanline va a su bola (salvo que vea mal, claro xD)

Buena pregunta... Habrá que ver cómo está hecho, pero yo apuesto a que por HDMA y esto es fácil de comprobar si se carga la ROM en SNES9x y se desactiva el HDMA pulsando la tecla '0' en el teclado.
Por HDMA se podría hacer ya que no es un scroll realmente, si no una corrección de perspectiva en donde sabes cuánto tienes que desplazar cada scanline según la posición del personaje en el escenario. Es decir, si por ejemplo en el escenario de Dhalsim cuando el luchador está frente a los elefantes las 64 líneas de pantalla inferiores las tienes que desplazar 1 píxel la última, 2 píxeles la penúltima, 3 píxeles la antepenúltima y así sucesicamente, esto mismo se repetirá cada ves que el luchador pase por ahí, por lo que basta con programar un HDMA cuando las coordenadas del personaje estén en ese punto del escenario.
Quizá está hecho como se ha comentado otras veces: se desplaza cada línea de una tile las veces necesarias para dar ese efecto de perspectiva, y como no se hace en todo el escenario, es un proceso costoso pero realizable.

Señor Ventura escribió:Por lo que, podría ser que finalmente los samples si estén comprimidos. No veo otra forma de que todo el programa se congele si no hay conflictos con la cpu..

Los samples pueden estar comprimidos, sí, pero no creo que con el S-DD1. Y si no lo están con el S-DD1, estarán con otro algoritmo que tendrán que implementar por software, con lo cual es costoso también.

Señor Ventura escribió:P.D: ¿Por qué tengo la idea preestablecida de que no puedes poner roms de mas de 32 megas? (es decir, 2 roms para 64, o 4 roms para 128).

Sí, puedes, de hecho las placas que enseñé hace unos meses que diseñé para meter el StarOcean te permiten 3 ROMS de 32 megas, y el límite máximo de la SNES está en 126 Megabits. El problema es que meter 1 chip más te obliga por narices a tener un decodificador de direcciones para acceder a ambos correctamente, por lo que hay que diseñar la placa para meter 3 chips.

magno escribió:Buena pregunta... Habrá que ver cómo está hecho, pero yo apuesto a que por HDMA y esto es fácil de comprobar si se carga la ROM en SNES9x y se desactiva el HDMA pulsando la tecla '0' en el teclado.
Por HDMA se podría hacer ya que no es un scroll realmente, si no una corrección de perspectiva en donde sabes cuánto tienes que desplazar cada scanline según la posición del personaje en el escenario. Es decir, si por ejemplo en el escenario de Dhalsim cuando el luchador está frente a los elefantes las 64 líneas de pantalla inferiores las tienes que desplazar 1 píxel la última, 2 píxeles la penúltima, 3 píxeles la antepenúltima y así sucesicamente, esto mismo se repetirá cada ves que el luchador pase por ahí, por lo que basta con programar un HDMA cuando las coordenadas del personaje estén en ese punto del escenario.
Quizá está hecho como se ha comentado otras veces: se desplaza cada línea de una tile las veces necesarias para dar ese efecto de perspectiva, y como no se hace en todo el escenario, es un proceso costoso pero realizable.

Pues no veas, menuda liada hay con el tema del HDMA. Resulta que si lo desactivas todo el escenario se queda estático.

Todo hace scroll por HDMA, el suelo con perspectiva, los planos del escenario... todo. Lo único que si hace scroll, son los elementos dibujados a base de sprites (los extintores de la fase de zangief, por ejemplo).

magno escribió:Los samples pueden estar comprimidos, sí, pero no creo que con el S-DD1. Y si no lo están con el S-DD1, estarán con otro algoritmo que tendrán que implementar por software, con lo cual es costoso también.

Entonces, ¿nos quedamos como mas factible con la teoría de pasar los samples comprimidos a la RAM del sistema, y que la CPU descomprime para pasarlos a la RAM del SPC700?.

magno escribió:Sí, puedes, de hecho las placas que enseñé hace unos meses que diseñé para meter el StarOcean te permiten 3 ROMS de 32 megas, y el límite máximo de la SNES está en 126 Megabits. El problema es que meter 1 chip más te obliga por narices a tener un decodificador de direcciones para acceder a ambos correctamente, por lo que hay que diseñar la placa para meter 3 chips.

Me refería por ejemplo a no poder meter una ROM de 64 megas, o una ROM de 128 megas, sino que tengo entendido que debe ser en memorias de 32 en 32.

A ver, que estoy desde el movil y es complicado contestar como dios mandó.
Lo de las ROMs de más de 32 megas se debe al tamaño del DIE, las memorias suelen ocupar mucho tamaño de silicio y hacer ROMs mas grandes era caro. Antiguamente el tamaño máximo era de 32 megas y hasta que no se abarató el coste con las flash NAND y NOR no se popularizaron tamaños mayores.

Y lo del HDMA que comentas es muy interesante. Es increíble la cantiidad de sitios donde se usa para efectos sencillos. Por ejemplo, los menús de FF6 y Star Ocean usan HDMA para colocar los textos a diferentes alturas, saltándose así la limitación de poner el texto alineado a la rejilla 8x8.

Tengo en mente desde hace tiempo destripar juegos de SNES y sacar su codigo para ver cómo se hacen ciertos efectos, pero yo solo no doy abasto ya...

magno escribió:Y lo del HDMA que comentas es muy interesante. Es increíble la cantiidad de sitios donde se usa para efectos sencillos. Por ejemplo, los menús de FF6 y Star Ocean usan HDMA para colocar los textos a diferentes alturas, saltándose así la limitación de poner el texto alineado a la rejilla 8x8.

Se podría decir entonces que si es posible hacer scroll manipulando individualmente cada scanline de cada plano. Y si a esto le sumamos que en snes a cada pixel de un tile de cada plano le puedes cambiar su prioridad, quien tenga los sabtos bemoles de organizarlo todo podría conseguir unos resultados asombrosos. Por ejemplo, que en un desarrollo de juego horizontal parezca que hay 7 u 8 planos de scroll diferentes, y no la típica solución de mover un plano por bloques... pero tiene que ser bestial tener claro en la cabeza como llevarlo a cabo.

Incluso debería ser posible alterar cada scanline de un plano mientras realizas los cálculos de perspectiva en modo 7... ahora que lo pensaba, de hecho hay ejemplos en juegos comerciales (dos juegos de coches que ahora no recuerdo sus nombre).

magno escribió:Tengo en mente desde hace tiempo destripar juegos de SNES y sacar su codigo para ver cómo se hacen ciertos efectos, pero yo solo no doy abasto ya...

Yo es que voy a tope con la hinjeniería, pero tengo el librito del 65816 a mano, y algún día lo tendré que terminar.