Batalla campal Snes Vs Megadrive, patio de colegio On

Aquí vídeo a 256 colores. No se si mejorable, aunque no es lo mismo imagen estática (un plano mismamente), que codificar vídeo.

https://youtu.be/azyBxPtPdPY?t=341

Sobre la fluidez que se hablaba antes, discutiendo que Megadrive tenga más facilidad para mover el parallax con más fluidez, y que a SNES le cuesta un poco más hacer lo mismo...

El ejemplo que se puso de SNES, donde efectivamente el parallax sí se mueve igual de fluido que el Musha, en realidad no es lo mismo; la carga gráfica o información que se está procesando es menor, y así supongo que para SNES será mucho más fácil:



-



Básicamente, es mover un fondo de NES contra uno con una profundidad de color bastante mayor, de 16bits. Si queremos comprobar el mantra (repetido hasta la saciedad) de que "Si SNES baja en colores hasta el nivel de Megadrive la iguala en rendimiento", basándonos en este ejemplo de Battletoads evidentemente no se cumple tal idea, porque SNES tiene que bajar los colores del fondo muy por debajo de Megadrive para igualar la fluidez del parallax del Musha.

A no ser que haya otros juegos, los ejemplos puestos solo van encaminados a constatar que a Megadrive le cuesta menos mover el parallax, en cualquier dirección. Juegos que tienen una carga gráfica similar se mueven más bruscamente en SNES, y SNES solo iguala el rendimiento de Megadrive al bajar el número de colores a nivel NES, no a nivel Megadrive. Esto, insisto, hablando del parallax y en base a ejemplos que no he elegido yo, sino los pro-SNES.

Otro ejemplo de parallax vertical, pero hila muy fino, no me atrevería a decir que desplaza verticalmente columnas de mas de 8 pixels.
https://youtu.be/ds3mj064lIs?t=1013

@gynion lo siento pero yo en las roquitas esas del musha veo practicamente las mismas tonalidades de las roquitas verdes del super aleste por ejemplo ,y si adelantas un poco el video verás que van a toda pastilla ,contando la ingente cantidad de sprites que pone ese juego en la pantalla.
lo siento pero no lo veo así .


tu los ves igual en terminos de color?

y como digo follao vivo y con muchisima tralla
aleste
no veo ningún problema moviendo el parallax

otro fondito interesante
aleste
este juego es un continuo desfile de las bondades de snes ,se nota que la emplearon muy bien

titorino escribió:@gynion lo siento pero yo en las roquitas esas del musha veo practicamente las mismas tonalidades de las roquitas verdes del super aleste por ejemplo ,y si adelantas un poco el video verás que van a toda pastilla ,contando la ingente cantidad de sprites que pone ese juego en la pantalla.
lo siento pero no lo veo así .

Bueno, lo mismo podía haber cogido de ejemplo el Super Aleste... ¿En qué imagen dirías tú que hay más información gráfica?

titorino escribió:@gynion lo siento pero yo en las roquitas esas del musha veo practicamente las mismas tonalidades de las roquitas verdes del super aleste por ejemplo ,y si adelantas un poco el video verás que van a toda pastilla ,contando la ingente cantidad de sprites que pone ese juego en la pantalla.
lo siento pero no lo veo así .

Que cada uno sea mas feliz pensando lo que le mejor le convenga pensar, pero el parallax vertical del musha se mueve exactamente igual que el parallax vertical del super aleste: a trompicones.

Mientras se sigan negando estas evidencias no se puede esperar avanzar mucho mas en este debate.

gynion escribió:

titorino escribió:@gynion lo siento pero yo en las roquitas esas del musha veo practicamente las mismas tonalidades de las roquitas verdes del super aleste por ejemplo ,y si adelantas un poco el video verás que van a toda pastilla ,contando la ingente cantidad de sprites que pone ese juego en la pantalla.
lo siento pero no lo veo así .

Bueno, lo mismo podía haber cogido de ejemplo el Super Aleste... ¿En qué imagen dirías tú que hay más información gráfica?

te lo he dicho de primeras ,compara lo que pone uno y otro,que un fondo sea una pared y la otra rocas no deja de ser cuestiones de diseño .
el super aleste va mas rápido y pone muchas mas cosas en pantalla según lo que veo
aparte que me has puesto la primera capa ,las rocas de fondo estan con muchos menos colores.
o ahora el musha tambien tiene mas colores que el super aleste

titorino escribió:te lo he dicho de primeras ,compara lo que pone uno y otro,que un fondo sea una pared y la otra rocas no deja de ser cuestiones de diseño .
el super aleste va mas rápido y pone muchas mas cosas en pantalla según lo que veo
aparte que me has puesto la primera capa ,las rocas de fondo estan con muchos menos colores

Dile que los espacios en negro al line buffer se la suda a menos que interrumpas la imagen, cosa que no es el caso, ni de serlo implicaría nada tampoco en cuanto a rendimiento per se.

Al vdp de la megadrive y a los ppu's de la snes les cuesta exactamente el mismo esfuerzo mover un plano de un solo tile (un plano con un dibujo de 8x8 pixels y el resto en negro, o transparente), que un plano de 2000 tiles, repetidos, o no.

Y lo de la profundidad de color vs rendimiento... que tampoco. Nada que ver.

@titorino

Creo haber dicho desde el principio que estoy hablando solo del parallax. No sé a qué te refieres.

Estoy esperando ejemplos mejores, porque esos, por más palabras con las que sean acompañados...

gynion escribió:@titorino

Creo haber dicho desde el principio que estoy hablando solo del parallax. No sé a qué te refieres.

me refiero al paralax tambien ,que no veo donde ves el problema de verdad.
¿que te parece mejor el del musha ? no te lo voy a discutir ,yo sin enbargo veo el del super aleste en general ,todo ,más espectacular y un ejemplo de hasta donde se podía llegar en snes empleandola bien ,con scrolles muy rápidos ,buenos efectos y sobre todo hasta donde podía llegar en terminos de sprites y acción .
lo demás son sensaciones de cada uno .

A mi del super aleste me disgusta el desarrollo de las fases a partir de la primera, porque si fuese progresivo sería una barbaridad.

Y luego que para mi gusto se equivocaron no haciendo que las explosiones gordas tengan la máxima prioridad. Se silencian explosiones a mitad de su reproducción para que suenen disparos, cuando naturalmente durante el transcurso de una explosión no deberías oir nada mas.

titorino escribió:

gynion escribió:@titorino

Creo haber dicho desde el principio que estoy hablando solo del parallax. No sé a qué te refieres.

me refiero al paralax tambien ,que no veo donde ves el problema de verdad.

Pues que es más brusco, nada más, y que Megadrive tiene más facilidad para moverlo.

No se donde ves el problema en un punto o dos menos de fluidez.

¿Aún seguís?.

P.D.: Yo insisto en que veo el parallax moverse con la misma fluidez en ambos.

Me alegra ver que lo de coger capturas estáticas bonitas para decir "lo mio es mejor" ignorando la fluidez, efectos en movimiento, etc aunque el juego vaya a pedales sucede en todos lados.

Señor Ventura escribió:

Mira, tenía pensado preparar algo parecido, pero te has adelantado.

En esta se aprecia mejor.

Anda, si resulta que el Musha también se acelera a tope, y encima con más detalle gráfico y resolución.

Y como la cantidad de información gráfica no importa para el rendimiento, y como puede ser cosa de diseño artístico...

Resulta que Super Aleste, un juego con unos fondos que flipas, con transparencias, morphings, etc... en el único fondo con parallax en vez de mantener el nivel decidieron bajarlo, pese al contraste a peor que supone eso con el resto de juego, y pese a que a SNES le sale gratis hacer un fondo parallax no al nivel de Musha, sino al nivel de resto del Super Aleste.

Y resulta que en Battletoads tenemos a unos sapos, aero-deslizadores y plano delantero con detalle y gráficos nivel SNES, pero... oh, que curioso, el plano de fondo parallax es tan detallado como el del Battletoads de NES.

Vaya decisiones de diseño más raras, y vaya mal aprovechamiento de esos recursos teóricos infinitos.

Es verdad el mito de que el chip de sonido sony de la snes habia que pagar licencia para usarlo y por eso hay juegos con mal sonido que no lo usan?

Es verdad que las mega Drive japonesas tienen mucho mejor sonido por el yamaha? Hay más diferencias respecto a la pal/usa?
Era posible subirle los MHz a la snes?
Cuál eran los mejores juegos de carreras?
(Aparte de los fzero, creo q el punto débil de la snes eran los de coches)

Gracias!

Es importante recordar que cuando se dio el lanzamiento de Musha Aleste, el SNES no estaba en el mercado,
y a pesar de que Super Aleste ser una showcase de cómo hacer un shooter vertical para la consola, mi percepción personal es que Musha es mucho mejor recordado como referencia en el género, sea por su jugabilidad, suavidad, muy buenos arte y gráficos para 1990 o su memorable banda sonora

Abajo un momento que el juego simula 3 planes para dar mayor sensación de profundidad

Hola, Donald Maui Mallard, Ball-Z y Realm creo que son buenos exponentes en Snes de lo que estais debatiendo, (perdón si ya habeis dicho alguno, estoy siguiendo el hilo menos de lo que me gustaría), mostrando haces de luz, reflejos, capas, transparencias, efectos raster.. y en global un apartado técnico 'majestuoso' (si se permite la expresión), para una consola de 16 Bit, aunque los DKC en ese terreno acaben siendo el mejor exponente.

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

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

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

los dos primeros títulos en particular los encuentro mejor acabados que en Megadrive pero ese no es el tema, sino las virtudes que muestran y que fueron juegos injustamente olvidados (o semi olvidados), cuando en Snes tienen un nivel técnico y jugable elevadísimo..

Ziu, intento responder lo poco que conozco..

Ziu escribió:Es verdad el mito de que el chip de sonido sony de la Snes habia que pagar licencia para usarlo y por eso hay juegos con mal sonido que no lo usan?

Tengo entendido que es cierto, de hecho TheElf lo comentó en Hobby Consolas (sección Game Master), y tambien lo he leido en internet hace tiempo, sin embargo lo segundo, que por este motivo hay juegos con mal sonido, no lo tengo claro.. diría más bien que componer música para el chip era dificil porque la escasez de memoria en los cartuchos (megas) obligaba a comprimir en exceso, y se veian obligados a sacrificar la tasa de Herzios, o utilizar la capacidad de modulación en lugar de emplear samples o digitalizaciones de voz, que hubieran otorgado una mayor calidad (frecuentes simulaciones de coros en los RPG, la risa de Shredder en T.M.N.T in Time..),

https://skirmishfrogs.com/2016/08/22/th ... soundchip/

Ziu escribió:Es verdad que las Mega Drive Japonesas tienen mucho mejor sonido por el yamaha? Hay más diferencias respecto a la pal/usa?

Tampoco lo sé, el modelo de Megadrive 2 (la pequeñita), tiene peor sonido que la Megadrive 1 original,

https://www.youtube.com/watch?v=-AHKRf-2WBc

aquí se explica. Este tema se ha tocado muchas veces pero siempre lo olvido...

https://sh2central.wordpress.com/2017/1 ... -lo-creas/

a ver que pueden comentarte sobre la Megadrive Japonesa,

Ziu escribió:Cuál eran los mejores juegos de carreras?

En Megadrive me gustan mucho Street Racer, Top Gear 2, Virtua Racing, OutRun, Super Hang-On, Heavenly Symphony (Mega-CD) y Action 52 Daytona por su mérito técnico.

Para Snes, Battle Cars, Lamborghini American challenge, Mario Cart, GT Racing, Power Drive, Stunt Race, Rock and Roll Racing, Street Racer, Super Chase H.Q (porque me recuerda a Konami GT), Super Off-Road The Baja, Exhaust Heat, y la fase de conducción de Batman Returns

Ziu escribió:Aparte de los fzero, creo q el punto débil de la snes eran los de coches)

no creo que sea así con franqueza, aunque si reconozco que a la Super le pasó un poco como a Dreamcast años despues, que viendo el nivel general del sistema ya en su madurez, te esperabas que sus juegos de coches tuvieran un apartado gráfico más elevado, (Neo Geo adoleció del mismo detalle), pero es normal en las tres máquinas de 16 Bit, porque no son sistemas del todo pensados para ese tipo de representación gráfica, al no poseer scaling por hardware... Snes gracias al MD7 podía desenvolverse mejor cuando los programadores echaban el resto, pero Megadrive poco más pudo hacer... por ejemplo Street Racing es muy meritorio y no queda a tanta distancia de la versión de Super.



Saludos

Que conste que yo contesto como mucho a los que me citan y dialogan conmigo directamente, sin miedos. A los que me vienen diciéndole a otros tonterías del tipo "dile esto y dile lo otro" , ni caso, aunque me estén buscando como almas en pena. Que me citen y me digan lo que quieren, como la gente normal. Encima se molestan si no les haces caso, con esos modos. Flipo

@balónybalín

Estoy de acuerdo con el Maui Mallard; es bastante peor la versión de Megadrive, y muy bien hecho en SNES. Sólo me fijé en la primera fase, de todas formas, pero me imagino que en el resto de juego no cambiará la cosa. Sí que me parece que lo comenté y comentamos, ya que lo dices, pero sería hace tiempo ya.

EPSYLON EAGLE escribió:Es importante recordar que cuando se dio el lanzamiento de Musha Aleste, el SNES no estaba en el mercado,
y a pesar de que Super Aleste ser una showcase de cómo hacer un shooter vertical para la consola, mi percepción personal es que Musha es mucho mejor recordado como referencia en el género, sea por su jugabilidad, suavidad, muy buenos arte y gráficos para 1990 o su memorable banda sonora

Abajo un momento que el juego simula 3 planes para dar mayor sensación de profundidad

nadie está diciendo que musha aleste sea peor ,para algunos será mejor ,otros preferimos la versión snes .
lo que si te digo es que super aleste aprovecha muy bien las virtudes de snes que megadrive carece como transparencias en las capas ,modo 7 ,acercamientos ect ,además de la suavidad y fluidez con la que se mueve el juego poniendo la snes al limite,es más pone muchimos sprites y sabe disimular bastante bien el flickering .
no creo que esto se ponga en duda .
son igual de recordados porque son dos juegazos si te gustan este tipo de juegos ya eso depende de cada uno,no hay una opción única .

@EPSYLON EAGLE @gynion @Señor Ventura @Papitxulo

Sobre el Parallax vertical, como dije antes, si lo hace el chip (En Mega seguro, en Super parece que tambien), le da igual al chip que haya mas o menos información en el plano. Lo moverá igual si es un plano negro que si es un plano lleno de cosas.

No olvides que la versión de Super Nes de Mahui Mallard salió casi un año después de la versión Mega Drive, los desarrolladores tuvieron bastante tiempo para reparar eventuales fallas y reforzar los puntos fuertes de la plataforma, a pesar de considerar las versiones relativamente equilibradas en el sonido.

Sobre Ballz 3D, vale recordar que la versión Super Nes lleva chip acelerador lo que garantiza gráficos muy superiores a la versión Mega Drive, aún así desempeña sustancialmente inferior en términos de control y fluidez, también me molan mas las voces y musica en 16 bits de SEGA.

Este vídeo es muy representativo.
https://www.youtube.com/watch?v=6fNkcJv9aSY

kusfo79 escribió:@EPSYLON EAGLE @gynion @Señor Ventura @Papitxulo

Sobre el Parallax vertical, como dije antes, si lo hace el chip (En Mega seguro, en Super parece que tambien), le da igual al chip que haya mas o menos información en el plano. Lo moverá igual si es un plano negro que si es un plano lleno de cosas.

Ok. ¿la vram no influye ahí en nada, quieres decir?

Bueno, el caso es que diferentes son, y menos detalles y peor aspecto sí que tiene esa fase, aunque el resto del Super Aleste sea superior.

gynion escribió:

kusfo79 escribió:@EPSYLON EAGLE @gynion @Señor Ventura @Papitxulo

Sobre el Parallax vertical, como dije antes, si lo hace el chip (En Mega seguro, en Super parece que tambien), le da igual al chip que haya mas o menos información en el plano. Lo moverá igual si es un plano negro que si es un plano lleno de cosas.

Ok. ¿la vram no influye ahí en nada, quieres decir?

Bueno, el caso es que diferentes son, y menos detalles y peor aspecto sí que tiene esa fase, aunque el resto del Super Aleste sea superior.

Influiria si estuviera recargando tiles, pero por el aspecto de esos parallax, no se está recargando nada en ningún momento, así que el coste es 0.

PD: De hecho, la mayor parte de juegos de la época recargan muy pocas cosas de forma dinámica (la mayor parte de los tiles de un escenario ya están cargados). Por eso, al final lo del ancho de banda etc no importa en la mayor parte de los juegos el 90% del tiempo.

@titorino

De acuerdo. Cambiando un poco, una de las cosas que me hace falta en Super Aleste, es la ausencia de una trama más detallada, haria mucho más identidad al juego, uno de los puntos fuertes de Musha es su historia, contada de manera de diálogos simples, pero que te crea un vínculo muy chulo con el juego.

kusfo79 escribió:

gynion escribió:

kusfo79 escribió:@EPSYLON EAGLE @gynion @Señor Ventura @Papitxulo

Sobre el Parallax vertical, como dije antes, si lo hace el chip (En Mega seguro, en Super parece que tambien), le da igual al chip que haya mas o menos información en el plano. Lo moverá igual si es un plano negro que si es un plano lleno de cosas.

Ok. ¿la vram no influye ahí en nada, quieres decir?

Bueno, el caso es que diferentes son, y menos detalles y peor aspecto sí que tiene esa fase, aunque el resto del Super Aleste sea superior.

Influiria si estuviera recargando tiles, pero por el aspecto de esos parallax, no se está recargando nada en ningún momento, así que el coste es 0.

PD: De hecho, la mayor parte de juegos de la época recargan muy pocas cosas de forma dinámica (la mayor parte de los tiles de un escenario ya están cargados). Por eso, al final lo del ancho de banda etc no importa en la mayor parte de los juegos el 90% del tiempo.

Entendido. ¿Y el framerate de los fondos o del juego en general puede verse afectado por algún motivo relacionado?

gynion escribió:Entendido. ¿Y el framerate de los fondos o del juego en general puede verse afectado por algún motivo relacionado?

Si no van a 60 fps es por que conscientemente han rebajado los fps o está mal programado.

Entrando un poco más en harina, si que es cierto que igual en algún momento estas haciendo algo que consume mucho, y eso provoca que no se actualice el valor del scroll (aunque el coste de eso es casi gratis). No obstante, esto en la época, y especialmente con la música (que se nota mucho) se solucionaba con una interrupcion HBlank. ¿Como? hacias que saltara la interrupcion en una cierta linea, y ahí siempre updateabas la música y el scroll. De esta manera, aunque la máquina fuera ahogada en un cierto momento, la música no se enlentecia ni el scroll lagueaba.

EPSYLON EAGLE escribió:No olvides que la versión de Super Nes de Mahui Mallard salió casi un año después de la versión Mega Drive, los desarrolladores tuvieron bastante tiempo para reparar eventuales fallas y reforzar los puntos fuertes de la plataforma, a pesar de considerar las versiones relativamente equilibradas en el sonido.

Sobre Ballz 3D, vale recordar que la versión Super Nes lleva chip acelerador lo que garantiza gráficos muy superiores a la versión Mega Drive, aún así desempeña sustancialmente inferior en términos de control y fluidez, también me molan mas las voces y musica en 16 bits de SEGA.

Este vídeo es muy representativo.
https://www.youtube.com/watch?v=6fNkcJv9aSY

no solo eso ,se aprovecho el colorido de snes y el sonido.
no importa que saliese antes o despúes ,esa mejora estaba disponible ,hablo del donald.
el ball z aun pareciendome un aborto ambas versiones la de snes esta gráficamente mucho mejor .

kusfo79 escribió:Si no van a 60 fps es por que conscientemente han rebajado los fps o está mal programado.

Entrando un poco más en harina, si que es cierto que igual en algún momento estas haciendo algo que consume mucho, y eso provoca que no se actualice el valor del scroll (aunque el coste de eso es casi gratis). No obstante, esto en la época, y especialmente con la música (que se nota mucho) se solucionaba con una interrupcion HBlank. ¿Como? hacias que saltara la interrupcion en una cierta linea, y ahí siempre updateabas la música y el scroll. De esta manera, aunque la máquina fuera ahogada en un cierto momento, la música no se enlentecia ni el scroll lagueaba.

Pues las diferencias que se suelen notar irán por ahí, por cómo se programaron. Por eso había ralentizaciones en algunos juegos, que en algunos casos se pudieron solucionar después con fixes. Ahí influirá pues la mayor dificultad para programar que debe tener SNES; porque en Megadrive tengo entendido que hasta programando en C se pueden obtener buenísimos resultados.

Gynion escribió:Estoy de acuerdo con el Maui Mallard; es bastante peor la versión de Megadrive, y muy bien hecho en SNES. Sólo me fijé en la primera fase, de todas formas, pero me imagino que en el resto de juego no cambiará la cosa. Sí que me parece que lo comenté y comentamos, ya que lo dices, pero sería hace tiempo ya.

Si, como bien dices creo que ya se comentó aquí y en otros dos foros de videojuegos , pero deseaba refrescarlo, porque me parece muy destacable en Snes y un tanto 'tapado', sus movimientos son muy fluidos, algo que como decís y por desgracia, no siempre se vé en Snes, y su acabado gráfico es impecable con multitud de perlas que merecen mención.

Realm, a pesar de aparecer en el fin del ciclo vital de la consola (a España llegó en el verano de 1996), y tener sólo 16 Mb, mostró detalles de gran factura..

EPSYLON EAGLE escribió:No olvides que la versión de Super Nes de Mahui Mallard salió casi un año después de la versión Mega Drive, los desarrolladores tuvieron bastante tiempo para reparar eventuales fallas y reforzar los puntos fuertes de la plataforma, a pesar de considerar las versiones relativamente equilibradas en el sonido.

Desconocía que se llevaran tanto tiempo, para mi era unos cinco o seis meses (no recuerdo bien las fechas de los análisis de las revistas, que eran mi guia principal, porque jugar, comprar o alquilar cartuchos, en mi caso funcionaba como reza el refrán: una vez al año no hace daño

Tambien ocurrió algo similar con Sunset Riders, en favor de Snes, además de tener el doble de megas, (4 vs 8), sin embargo, y disculpa si se interpreta como cinismo, en anteriores debates, inclusive en este mismo, no recuerdo a nadie haber puntualizado que, por hacer una equivalencia, Castlevania de Megadrive fué dos años posterior al de Snes... y como este ejemplo si hago memoria puedo citar algunos más en favor de Snes... (Mr.Nutz, S.W.I.V, Clayfighters), no pretendo hacer una cortina de humo ni echar balones fuera, ha sido un error mio, sólo que me parece un detalle curioso que por norma se haga hincapié en las ocasiones en las que Megadrive quedó en desventaja, pero a la inversa rara vez ocurra.. :/

EPSYLON EAGLE escribió:Sobre Ballz 3D, vale recordar que la versión Super Nes lleva chip acelerador lo que garantiza gráficos muy superiores a la versión Mega Drive, aún así desempeña sustancialmente inferior en términos de control y fluidez, también me molan mas las voces y musica en 16 bits de SEGA.

Este vídeo es muy representativo.
https://www.youtube.com/watch?v=6fNkcJv9aSY

No tenía idea de que Ball-Z en Snes utiliza chip, te agradezco la info y lamento mi error... de alguna forma esto revaloriza a mis ojos (y a los de todos) la versión de Megadrive, a pelo y manteniendo un enorme nivel (para mi en la época estaban codo a codo con la ver de 3-DO -algo mejorable- aunque visto ahora, de nuevo debo desdecirme...)

Quizá me lapideis, pero pienso -dentro de toda mi insondable ignorancia- con la debida programación, Snes podría haber bordado Ball-Z sin necesidad de chips... sí, soy un fanboy de Snes porque me cautivó todo de ella nada más ver su aspecto y sus juegos, el detalle es que al mismo tiempo soy Seguero hasta la médula..



Saludos

kusfo79 escribió:Influiria si estuviera recargando tiles, pero por el aspecto de esos parallax, no se está recargando nada en ningún momento, así que el coste es 0.

PD: De hecho, la mayor parte de juegos de la época recargan muy pocas cosas de forma dinámica (la mayor parte de los tiles de un escenario ya están cargados). Por eso, al final lo del ancho de banda etc no importa en la mayor parte de los juegos el 90% del tiempo.

Cierto al 100%. Lo que se actualiza en un scroll es el tilemap y no las tiles en sí. Y el tilemap depende de la resolución.

kusfo79 escribió:Si no van a 60 fps es por que conscientemente han rebajado los fps o está mal programado.

Entrando un poco más en harina, si que es cierto que igual en algún momento estas haciendo algo que consume mucho, y eso provoca que no se actualice el valor del scroll (aunque el coste de eso es casi gratis). No obstante, esto en la época, y especialmente con la música (que se nota mucho) se solucionaba con una interrupcion HBlank. ¿Como? hacias que saltara la interrupcion en una cierta linea, y ahí siempre updateabas la música y el scroll. De esta manera, aunque la máquina fuera ahogada en un cierto momento, la música no se enlentecia ni el scroll lagueaba.

No tiene por qué estar mal programado, simplemente es que consideran prioritario meter más elementos en pantalla y por tanto, el micro se tira más tiempo entre dos frames consecutivos calculando colisiones y procesando la IA. Si eso se alarga en el tiempo, es posible que en el siguiente frame no pueda actualizar el scroll.
Anunque parece que actualizar el scroll es casi gratis (que lo es porque consiste en escribir un par de registros de la PPU en SNES), el problema está en que cada 8 píxeles que te muevas tienes que actualizar también 1 línea de tiles en pantalla (no las tiles en sí, sino el tilemap), y eso ya lleva más tiempo para calcular qué tilemap tienes que cambiar según la posición de la cámara en el mapa completo de la fase, lo que ya implica un acceso a RAM o ROM, depende de dónde esté almacenado (normalmente en RAM, que es más lenta que la ROM).

Y lo de esperar al HBlank es complicado, porque pierdes más tiempo esperándolo (haciendo polling) que luego lo que sacas de ventaja en aprovechar el HBLank; de hecho por eso no hay una interrupción específica en SNES para el HBlank, sino que para sacarle provecho a ese tiempo en cada scanline, se usa el HDMA.
Y con el HDMA puedes actualizar el sonido del SPC700, aunque ya comenté alguna vez que el protocolo de comunicación no está pensado para usarlo: el HDMA sólo escribe en un registro y luego no lee de él. El protocolo con el SPC700 requiere que la CPU sepa si el SPC700 ha leído el dato y para eso ha de hacer polling al registro donde acaba de leer para comprobar si el dato ha cambiado.
Y lo de usar el HDMA para el scroll sí se suele hacer, aunque siempre hay que tener en cuenta lo que te comentaba antes, que si el scroll ha superado la frontera de una tile, hay que transferir el tilemap, y eso no lo puede hacer el HDMA porque en cada HBlank sólo hay tiempo para escribir 4 bytes.

@balónybalín sobre el chip de ball z ,los chips eran herramientas que se le daban a los desarrolladores ,más opciones.
no creo que snes no pudiese hacer lo mismo sin chips viendo cosas como esta
4 players
eso si si te dan un chip que te ahorra trabajo ,pues yo tambien me lo pensaria

magno escribió:No tiene por qué estar mal programado, simplemente es que consideran prioritario meter más elementos en pantalla y por tanto, el micro se tira más tiempo entre dos frames consecutivos calculando colisiones y procesando la IA. Si eso se alarga en el tiempo, es posible que en el siguiente frame no pueda actualizar el scroll.

No quiero entrar para que sigáis vosotros; pero solo sobre este punto... entonces en ese caso, una CPU más rápida lo hará mejor, ¿no?

gynion escribió:

magno escribió:No tiene por qué estar mal programado, simplemente es que consideran prioritario meter más elementos en pantalla y por tanto, el micro se tira más tiempo entre dos frames consecutivos calculando colisiones y procesando la IA. Si eso se alarga en el tiempo, es posible que en el siguiente frame no pueda actualizar el scroll.

No quiero entrar para que sigáis vosotros; pero solo sobre este punto... entonces en ese caso, una CPU más rápida lo hará mejor, ¿no?

Yo creo que aquí tiene cabida todo el mundo, hombre

Una CPU más rápida gestionaría más elementos en pantalla hasta llegar al límite de la PPU. Es decir, que en el caso de la SNES, la PPU hubiera permitido más elementos por pantalla en el Super Aleste, pero quizá la CPU no llegara a poder moverlos todos con suficiente fluidez.

kusfo79 escribió:

gynion escribió:Entendido. ¿Y el framerate de los fondos o del juego en general puede verse afectado por algún motivo relacionado?

Si no van a 60 fps es por que conscientemente han rebajado los fps o está mal programado.

Entrando un poco más en harina, si que es cierto que igual en algún momento estas haciendo algo que consume mucho, y eso provoca que no se actualice el valor del scroll (aunque el coste de eso es casi gratis). No obstante, esto en la época, y especialmente con la música (que se nota mucho) se solucionaba con una interrupcion HBlank. ¿Como? hacias que saltara la interrupcion en una cierta linea, y ahí siempre updateabas la música y el scroll. De esta manera, aunque la máquina fuera ahogada en un cierto momento, la música no se enlentecia ni el scroll lagueaba.

Es justo lo que me dijeron que hiciera en mi juego de Master System, ya que en algunos momentos los cálculos podían hacer que la música no se actualizase a la frecuencia adecuada

magno escribió:

gynion escribió:

magno escribió:No tiene por qué estar mal programado, simplemente es que consideran prioritario meter más elementos en pantalla y por tanto, el micro se tira más tiempo entre dos frames consecutivos calculando colisiones y procesando la IA. Si eso se alarga en el tiempo, es posible que en el siguiente frame no pueda actualizar el scroll.

No quiero entrar para que sigáis vosotros; pero solo sobre este punto... entonces en ese caso, una CPU más rápida lo hará mejor, ¿no?

Yo creo que aquí tiene cabida todo el mundo, hombre

Una CPU más rápida gestionaría más elementos en pantalla hasta llegar al límite de la PPU. Es decir, que en el caso de la SNES, la PPU hubiera permitido más elementos por pantalla en el Super Aleste, pero quizá la CPU no llegara a poder moverlos todos con suficiente fluidez.

Hombre, uno por no fastidiar algo más interesante; nah más.

Me encaja lo que comentas con lo que veo. Una cosa es que se pueda mostrar algo, pero también hay que ver con que resultado se hace; si se puede aplicar IA propia a todos los elementos, o si por contra funcionan simplemente reproduciendo patrones fijos e inalterables, como una reproducción de un video.

En un shoot'em up me imagino que poco problema habrá en ese sentido, porque los enemigos perfectamente pueden seguir patrones preestablecidos para rellenar espacios libres; pueden haber túneles, o cavidades estrechas situadas de forma estratégica, que te obliguen a pasar por ciertos puntos peligrosos; vamos, que a los enemigos no les tienen por qué meter IA para que te busquen, te apunten directamente, se protejan, ni interactúen de ninguna forma con lo que haces.

Pero si nos metemos en juegos donde los enemigos tienen sí o sí que tener una cierta IA, para evitar tus golpes, perseguirte, atacarte de forma precisa y demás, entonces supongo que sí que podrá haber penalizaciones según la CPU.

magno escribió:Y lo de esperar al HBlank es complicado, porque pierdes más tiempo esperándolo (haciendo polling) que luego lo que sacas de ventaja en aprovechar el HBLank; de hecho por eso no hay una interrupción específica en SNES para el HBlank, sino que para sacarle provecho a ese tiempo en cada scanline, se usa el HDMA.
Y con el HDMA puedes actualizar el sonido del SPC700, aunque ya comenté alguna vez que el protocolo de comunicación no está pensado para usarlo: el HDMA sólo escribe en un registro y luego no lee de él. El protocolo con el SPC700 requiere que la CPU sepa si el SPC700 ha leído el dato y para eso ha de hacer polling al registro donde acaba de leer para comprobar si el dato ha cambiado.
Y lo de usar el HDMA para el scroll sí se suele hacer, aunque siempre hay que tener en cuenta lo que te comentaba antes, que si el scroll ha superado la frontera de una tile, hay que transferir el tilemap, y eso no lo puede hacer el HDMA porque en cada HBlank sólo hay tiempo para escribir 4 bytes.

Buenas magno!
El caso es que en la master y en la mega, puedes definir cada cuantas lineas quieres que salte la interrupción, con lo que, al igual que ha hecho @Gammenon , pones por ejemplo un valor de 200, y saltará justamente una vez por frame. Lo que esto solo lo puedes hacer si no andas haciendo nada con las interrupciones horizontales.

Yo creo que el problema de la snes no es el scroll, sino lo de meter mas cantidad de sprites en pantalla con sus puntos de colisión, ia's y demás. Hace poco Ventura subió un giff del Super Turrican 2 en el que se percibía algo curioso, y es que en el jefe final los sprites que conforman al jefe eran "transparentes", quiero decir, que no tenían colisión, los únicos elementos que le podían hacer daño al jugador era la garra y el cuerpo del jefe, el resto no interfiere en lo jugable. Además de ese detalle, cuando el jefe golpea el techo, los escombros que caen escapan por la pantalla, sin golpear contra el suelo, lo que ello conllevaría sus respectivas colisiones y demás... A todo eso, sumarle que tampoco hay demasiadas balas en pantalla. Ventura lo subió como ejemplo de las bondades de la consola (aunque creo que iba tirado por el tema del scroll) pero yo creo que es un buen ejemplo de cómo enmascarar las limitaciones del sistema.

Edito: a esto me refiero https://youtu.be/5EvIIdLWLYY?t=2945

Ese creo que el problema de la consola, por eso que el Rendering Ranger me parezca un juego del montón jugablemente hablando, o no me parezcan tan destacables los shooters/run n guns de snes (mirando el enlace del Real que habéis comentado se puede ver lo cuidado de los gráficos en color, efectos y demás, pero en cuanto a la acción... mehhh).

@balónybalín El Maui Mallard se ve mejor en snes, algo que no debería pillar por sorpresa a nadie, pero sí es cierto que se rehicieron algunas cosas y se pierden movimientos (además creo que era lo de correr). También se pierde precisamente el scroll vertical similar al del Mickey Mania en la fase del arbol... ¿casualidad?

kusfo79 escribió:Buenas magno!
El caso es que en la master y en la mega, puedes definir cada cuantas lineas quieres que salte la interrupción, con lo que, al igual que ha hecho @Gammenon , pones por ejemplo un valor de 200, y saltará justamente una vez por frame. Lo que esto solo lo puedes hacer si no andas haciendo nada con las interrupciones horizontales.

Sí, imaginaba que se podría hacer en Megadrive al menos porque así lo habías comentado tú; sólo quería matizar el caso de SNES: aunque también se puede poner una interrupción como dices en Mega, ésta no va sincronizada al HBlank, por lo que no te permite escribir en el registro de scroll por ejemplo, que ha de hacerse cuando la PPU está inactiva (en los blankings vertical y horizontal).

kusfo79 escribió:Influiria si estuviera recargando tiles, pero por el aspecto de esos parallax, no se está recargando nada en ningún momento, así que el coste es 0.

PD: De hecho, la mayor parte de juegos de la época recargan muy pocas cosas de forma dinámica (la mayor parte de los tiles de un escenario ya están cargados). Por eso, al final lo del ancho de banda etc no importa en la mayor parte de los juegos el 90% del tiempo.

Dilo de otra forma porque así te están entendiendo que se trata de lo que hay en la pantalla, y no lo que hay en vram, o debe transferirse a vram.

Es decir, influye en el parallax, al igual que influye en cualquier scroll, los tiles que tienen que transferirse para poder mostrarse, que esto tiene un límite.

Pero el dibujado da igual.

robotnik16 escribió:Yo creo que el problema de la snes no es el scroll, sino lo de meter mas cantidad de sprites en pantalla con sus puntos de colisión, ia's y demás. Hace poco Ventura subió un giff del Super Turrican 2 en el que se percibía algo curioso, y es que en el jefe final los sprites que conforman al jefe eran "transparentes", quiero decir, que no tenían colisión, los únicos elementos que le podían hacer daño al jugador era la garra y el cuerpo del jefe, el resto no interfiere en lo jugable. Además de ese detalle, cuando el jefe golpea el techo, los escombros que caen escapan por la pantalla, sin golpear contra el suelo, lo que ello conllevaría sus respectivas colisiones y demás... A todo eso, sumarle que tampoco hay demasiadas balas en pantalla. Ventura lo subió como ejemplo de las bondades de la consola (aunque creo que iba tirado por el tema del scroll) pero yo creo que es un buen ejemplo de cómo enmascarar las limitaciones del sistema.

Edito: a esto me refiero https://youtu.be/5EvIIdLWLYY?t=2945

Ese creo que el problema de la consola, por eso que el Rendering Ranger me parezca un juego del montón jugablemente hablando, o no me parezcan tan destacables los shooters/run n guns de snes (mirando el enlace del Real que habéis comentado se puede ver lo cuidado de los gráficos en color, efectos y demás, pero en cuanto a la acción... mehhh).

@balónybalín El Maui Mallard se ve mejor en snes, algo que no debería pillar por sorpresa a nadie, pero sí es cierto que se rehicieron algunas cosas y se pierden movimientos (además creo que era lo de correr). También se pierde precisamente el scroll vertical similar al del Mickey Mania en la fase del arbol... ¿casualidad?

Lo del Turrican 2 puede ser también en parte por un tema de jugabilidad. Imagina por un momento que todas las partes de ese jefe pudiesen dañarte, o pudieras tropezar con ellas. Dado el área tan limitada en la que se puede mover nuestro personaje, no tendría casi posibilidad de desplazarse.

Señor Ventura escribió:Es decir, influye en el parallax, al igual que influye en cualquier scroll, los tiles que tienen que transferirse para poder mostrarse, que esto tiene un límite.

Se refiere que en el 90% de los juegos, esas tiles ya están en VRAM, por lo que no se transfieren dinámicamente sino al principio de la fase. Por tanto, aunque sea muy compleja la calidad y cantidad artística de las tiles, éstas están almacenadas en VRAM desde el principio de la fase y no influye en el rendimiento.
Por eso te he insistido tantas veces que el ancho de banda a VRAM no es tan determinante en el rendimiento.

balónybalín escribió:No tenía idea de que Ball-Z en Snes utiliza chip, te agradezco la info y lamento mi error... de alguna forma esto revaloriza a mis ojos (y a los de todos) la versión de Megadrive, a pelo y manteniendo un enorme nivel (para mi en la época estaban codo a codo con la ver de 3-DO -algo mejorable- aunque visto ahora, de nuevo debo desdecirme...)

El ball z no lleva chip de apoyo. Para muchos todo lleva chip de apoyo, pero vamos, que no es así.

magno escribió:

Señor Ventura escribió:Es decir, influye en el parallax, al igual que influye en cualquier scroll, los tiles que tienen que transferirse para poder mostrarse, que esto tiene un límite.

Se refiere que en el 90% de los juegos, esas tiles ya están en VRAM, por lo que no se transfieren dinámicamente sino al principio de la fase. Por tanto, aunque sea muy compleja la calidad y cantidad artística de las tiles, éstas están almacenadas en VRAM desde el principio de la fase y no influye en el rendimiento.
Por eso te he insistido tantas veces que el ancho de banda a VRAM no es tan determinante en el rendimiento.

Es justo lo que he dicho, que a menos que no esté disponible en vram, obligas al sistema a una espera, y la única manera de que no pueda estar disponible en memoria es que el dma esté saturado.

magno escribió:Sí, imaginaba que se podría hacer en Megadrive al menos porque así lo habías comentado tú; sólo quería matizar el caso de SNES: aunque también se puede poner una interrupción como dices en Mega, ésta no va sincronizada al HBlank, por lo que no te permite escribir en el registro de scroll por ejemplo, que ha de hacerse cuando la PPU está inactiva (en los blankings vertical y horizontal).

Ah vale, es que como comenté no soy nada experto en SNES, jeje.
Dicho esto, que documentacion usas tu para SNES? me gustaría conocer mejor como va, pero encuentra la información bastante dispersa por los sitios. Hay algo que recopile bastante?

magno escribió:

Señor Ventura escribió:Es decir, influye en el parallax, al igual que influye en cualquier scroll, los tiles que tienen que transferirse para poder mostrarse, que esto tiene un límite.

Se refiere que en el 90% de los juegos, esas tiles ya están en VRAM, por lo que no se transfieren dinámicamente sino al principio de la fase. Por tanto, aunque sea muy compleja la calidad y cantidad artística de las tiles, éstas están almacenadas en VRAM desde el principio de la fase y no influye en el rendimiento.
Por eso te he insistido tantas veces que el ancho de banda a VRAM no es tan determinante en el rendimiento.

Exacto, solo tienes que actualizar el tilemap (nametable) y no los tiles, ya que normalmente están ya cargados al inicio de la fase. Y, de hecho, en el caso del parallax vertical este de los alestes, ni escribir al tilemap hace falta, ya que es un fondo sin fin.

Señor Ventura escribió:Es justo lo que he dicho, que a menos que no esté disponible en vram, obligas al sistema a una espera, y la única manera de que no pueda estar disponible en memoria es que el dma esté saturado.

No he entendido nada de esta frase xDD

Papitxulo escribió:

robotnik16 escribió:Yo creo que el problema de la snes no es el scroll, sino lo de meter mas cantidad de sprites en pantalla con sus puntos de colisión, ia's y demás. Hace poco Ventura subió un giff del Super Turrican 2 en el que se percibía algo curioso, y es que en el jefe final los sprites que conforman al jefe eran "transparentes", quiero decir, que no tenían colisión, los únicos elementos que le podían hacer daño al jugador era la garra y el cuerpo del jefe, el resto no interfiere en lo jugable. Además de ese detalle, cuando el jefe golpea el techo, los escombros que caen escapan por la pantalla, sin golpear contra el suelo, lo que ello conllevaría sus respectivas colisiones y demás... A todo eso, sumarle que tampoco hay demasiadas balas en pantalla. Ventura lo subió como ejemplo de las bondades de la consola (aunque creo que iba tirado por el tema del scroll) pero yo creo que es un buen ejemplo de cómo enmascarar las limitaciones del sistema.

Edito: a esto me refiero https://youtu.be/5EvIIdLWLYY?t=2945

Ese creo que el problema de la consola, por eso que el Rendering Ranger me parezca un juego del montón jugablemente hablando, o no me parezcan tan destacables los shooters/run n guns de snes (mirando el enlace del Real que habéis comentado se puede ver lo cuidado de los gráficos en color, efectos y demás, pero en cuanto a la acción... mehhh).

@balónybalín El Maui Mallard se ve mejor en snes, algo que no debería pillar por sorpresa a nadie, pero sí es cierto que se rehicieron algunas cosas y se pierden movimientos (además creo que era lo de correr). También se pierde precisamente el scroll vertical similar al del Mickey Mania en la fase del arbol... ¿casualidad?

Lo del Turrican 2 puede ser también en parte por un tema de jugabilidad. Imagina por un momento que todas las partes de ese jefe pudiesen dañarte, o pudieras tropezar con ellas. Dado el área tan limitada en la que se puede mover nuestro personaje, no tendría casi posibilidad de desplazarse.

Jefe final... hay muchas maneras de diseñar la rutina (esa es otra) y que siga siendo top técnicamente. Siendo la súper y viendo que en Contra 3 ya se las ve y desea para mover cosas más pequeñas, me cuesta creer que sea por eso. Trend es un monstruo diseñando cosas con 'truco'.

kusfo79 escribió:No he entendido nada de esta frase xDD

Desplazo verticalmente un plano en "equis secciones", y en lugar de establecer un bucle con tiles almacenadas en vram, necesito transferir desde la rom un streaming de tiles porque he diseñado el escenario como un elemento que varía constantemente, así que dependo de que el ancho de banda sea suficiente, si no, las tiles no llegarán a tiempo y habrían ralentizaciones.