Super nes sufre bastante al mostrar varios elementos

Archivado
1, 2, 3, 4, 5
Siempre me ha surgido la duda de si Super Nes podría mover esta fase tal cual:

https://youtu.be/bxq3OaMpPis?t=1904

Creo que el Rocket Knight es una de las cosas más burras que se pueden ver en Mega Drive.
gynion escribió:Se lo aclaré a tito, y creo que cualquier persona puede entender que ya está, que no tengo intención de afirmar nada, que soy jugador/espectador y hablo sólo de lo que veo; no puedo teorizar sobre tecnicismos, y tú lo sabes además. Pero, aunque lo hubiera afirmado, en la práctica se cumple, y eso es lo que importa; la afirmación sería correcta, al menos en la práctica.


No se trata de intenciones, se trata de que consideras mas complejo un scroll vertical libre, que automático, y no necesitas demostraciones que corroboren eso para creerlo así. Sin embargo, la afirmación que niega esa creencia, a pesar de venir acompañado con una serie de explicaciones, si necesita de pruebas y demostraciones para ser tenida en cuenta.

No es mas que eso... y lo que no puede ser, es que se hagan afirmaciones sin apoyarlo en nada mientras que se pone en duda la opinión de quien se molesta en dar explicaciones sobre como funciona tal cuestión.

Si algo se pone en duda por no venir acompañado de demos que demuestren las cosas, entonces deberíamos callarnos todos, no solo yo.


gynion escribió:Si otro hubiera sido sabes perfectamente que hubiera hecho más sangre de esta situación, pero a mí no me gustan las hostilidades, ni los zascas, ni dejar mal a nadie, y por eso edité, porque fue un arrebato de rabia y porque creía que con recordarte eso (no lo voy a calificar ni de error, para que veas) de los 6 o 7 planos bastaría para que pienses que lo mejor es que todos corramos un tupido velo.


Como ya he dicho, que sean 6 o 7 planos de scroll, o 4 con varios de ellos maniupulando sus scanlines para dividirlos en varias secciones, no hace que la explicación sobre el funcionamiento del scroll vertical quede desautorizada. Son dos cosas diferentes, y sinceramente, sería un riesgo meter caña aludiendo a que si me equivoco en una cosa, entonces me equivoco en todo, porque es ponerse en evidencia.

Claro que me equivoco, constantemente, pero no siempre hablo por hablar. De vez en cuando hablo con datos contrastados en la mano.
A ver, no hace falta entrar en peleas; es verdad que @Señor Ventura hace algunas afirmaciones que no se corresponden con la realidad, ya lo comenté en otro hilo al respecto de las multiplicaciones, pero no creo que sea ni malintencionado ni por soberbia ni para tomárselo a mal: a mi juicio lo hace porque se plantea constantemente cómo se harían ciertas cosas y le da vueltas hasta encontrar una explicación, y eso está genial, así se termina aprendiendo mucho si se sabe buscar la respuesta correcta. Así aprendí yo casi todo que sé de la SNES, haciéndome preguntas mucho más absurdas y dando respuestas muy descabelladas hasta que iba dando con la respuesta correcta en la muchísima documentación que hay por esparcida por internet.


Señor Ventura escribió:Sobre lo demás, efectivamente, la snes maneja hasta 4 planos por hardware, lo cual no quiere decir que no pueda añadirse alguno por software, como hace la megadrive. Eres libre de pensar que no lo estaba teniendo en cuenta para responder con toda esa inquina... pero no por ello hay que dejar de decir que esta cuestión no tiene nada que ver con el tema del scroll vertical. Usas eso para anular cualquier respuesta que se te pueda dar, y eso es huir hacia adelante (como se equivoca con una cosa, entonces se equivoca con todo). Porque tu lo vales, vamos.


La SNES tiene hasta 4BGs, que como dices son menos dependiendo del modo, como regla general, a más BGs, menos colores puedes usar en cada uno de ellos.
Pero pensando que hay 4 en el Axelay, solo podrías hacer 4 planos de scroll. Lo de hacerlo por software no sé exactamente a qué te refieres... A lo mejor te refieres a que se puede coger un plano de scroll y actualizar las tiles para que parezca que hay un scroll diferente al que tiene la capa, pero esto no es un plano extra de scroll, sigue siendo uno solo.
Como ejemplo: podrías hacer que BG4 se moviera hacia la derecha y a la vez actualizar las tiles en vertical, pareciendo que hay dos scrolls diferentes, pero realmente sería un único scroll en dirección arriba-derecha. Además, esto no se puede hacer trivialmente, ya que cuando actualizas las tiles solo lo puedes hacer con resolución 8x8 (tamaño mínimo de una tile, hasta 32x32) pero esto provocaría un efecto raro en pantalla porque en los bordes inferior y superior verías que cambian 8 píxeles de golpe, y por eso el scroll no se implementa de esa manera sino con registros hardware que permiten desplazarte pixel a pixel.



paco_man escribió:Siempre me ha surgido la duda de si Super Nes podría mover esta fase tal cual:

https://youtu.be/bxq3OaMpPis?t=1904

Creo que el Rocket Knight es una de las cosas más burras que se pueden ver en Mega Drive.


Hay tres planos de scroll y no demasiados sprites en pantalla, yo creo que sí podría, al menos técnicamente. Solo habría que ver a qué velocidad lo haría. Yo creo que sí, pero es mi opinión tan solo.
Yo lo haría así:
* Montaría un modo con 3 BGs
* Cada BG tendría un tamaño de 2x1 pantallas, es decir, que el tilemap lo formaría la parte visible en pantalla más otra parte no visible de igual tamaño que está contigua horizontalmente
* Metería en VRAM todas las tiles y tilemaps de los dos planos más profundos y no las actualizaría nunca, ya que son los más repetitivos y de hecho en ese video parece que los elementos se reptien con menos de 2 pantallas de ancho de frecuencia. Estos dos planos no los actualizaría nunca, simplemente haría scroll continuamente escribiendo en los 2 registros pertinentes
* Metería en VRAM todas las tiles del plano más cercano, pero no todo el tilemap, sino el correspondiente a dos pantallas de ancho. Para que no parezca tan repetitivo, iría actualizando el tilemap para que los tejados y demás aparezcan en diferente orden y frecuencia, y lo conjugaría con el correspondiente registro de scroll
* Crearía los sprites suficientes en OAM para mover hasta 6 misiles diferentes (unos 6 sprites 16x16 por cada misil), lo que hace 36 sprites, más los del protagonista. Y simplemente habría que tener la precaución de que no coincidieran más de 32 sprites en la misma línea de pantalla (cosa que no ocurre en ese video) para que no salte el bug de la SNES.
* En cada VBlank solo actualizaría las tiles necesarias de los sprites, la tabla OAM con la posición de los mismos, y el tilemap del BG1, el más cercano a la pantalla.
He pasado de leer el flame de peleas, así que perdon si repito algo ya dicho:

La Super tiene 4 planos en el modo más comun. Lo que pasa es que puedes usar trucos para simular mas planos, sea por animación de tiles, o moviendo sprites por delante, etc.

Por ejemplo, caso típico, la NES y la Master tienen un solo plano de scroll, pero simulan varios usando trucos.
Ejemplos:

Micromachines Minuto 1:52

Return of the Joker Minuto 1:25

Esto mismo se usó en bastantes juegos de Mega y Super. Por ejemplo Toy Story, Batman & Robin....
Estamos hablando de Rendering Ranger, programado por Manfred Trenz, que si consiguió hacer lo que hizo con Turrican 2 en un Commodore 64, seguramente se sacó cualquier truco de la manga para hacer que 4 planos de parallax parezcan 7 a la vista.

Me hubiera gustado ver un juego programado por él mismo en Mega Drive.

Por cierto, no lo sé porque nunca he jugado en una Snes, solo en emulador (y como para buscar un cartucho del juego y pagarlo...), ¿sabéis si Rendering Ranger se ralentiza en la SNES?
Hay videos jugando con hardware real luego si eso lo busco y lo vemos.
Pero vamos este juego pone de manifiesto que con un codigo buen optimizado se puede lograr una velocidad bastante buena.
Por otra parte no veo bien que os peleis por eso.
A Señor ventura no lo veo que haga las cosas con malas intenciones y a gynion tampoco ,vamos a tomarnos el hilo para resolver dudas y trucos en ambas máquinas.
Señor Ventura escribió:
Naitguolf escribió:¿Entonces eso indica que tener un scroll que se mueva libremente no tiene consumo de potencia? Vaya, entonces es algo que no se solía hacer por manías tontas de los diseñadores. ¡Claro que requiere más potencia tener un scroll libre, y más memoria! Y cuantos más planos, lo pones aún peor.


Dependes del ancho de banda del bus de datos, no de un soporte lógico extra de la cpu mas allá de el de establecer el orden de los tiles para conformar los planos... lo que ocurre, es que esto te lo encuentras tanto si la cámara es automática, como si es fija.


La única manera de que un scroll que puedas mover libremente en dirección vertical no pueda hacerse en snes, es superando el ancho de banda de los datos, que en megadrive es superior. NO es una cuestión de potencia gráfica, ni de cpu.


Y ese ordenamiento de tiles como si viene del ancho de banda más lento del mundo, eso supondrá más trabajo todavía para la CPU perdiendo tiempo en esperar datos, o tener que estar contínuamente pidiendo datos si es baja la memoria. DA lo mismo, el computo de exceso de límites en el scroll se tiene que calcular, bien lo haga el procesador gráfico, o la CPU. Aparte de todo lo que implica después del refresco de máscaras que se tenga que hacer de los demás elementos de pantalla. No es lo mismo tener pequeñas porciones de pantalla que son la capa de scroll horizontales como el Shadow Of the Beast, a las enormes capas enormes en el Thunder Force IV.
Naitguolf escribió:Y ese ordenamiento de tiles como si viene del ancho de banda más lento del mundo, eso supondrá más trabajo todavía para la CPU perdiendo tiempo en esperar datos, o tener que estar contínuamente pidiendo datos si es baja la memoria. DA lo mismo, el computo de exceso de límites en el scroll se tiene que calcular, bien lo haga el procesador gráfico, o la CPU. Aparte de todo lo que implica después del refresco de máscaras que se tenga que hacer de los demás elementos de pantalla.


La cuestión es que esa escena no va a ser mas demandante por moverse el scroll de forma libre, que de forma automática.

Lo que lo determina es el ancho de banda que requieren los tiles de los planos, no el explorar un plano a voluntad. Si puedes mostrar un plano "sobre raíles", puedes explorarlo libremente.
jebiman escribió:Estamos hablando de Rendering Ranger, programado por Manfred Trenz, que si consiguió hacer lo que hizo con Turrican 2 en un Commodore 64, seguramente se sacó cualquier truco de la manga para hacer que 4 planos de parallax parezcan 7 a la vista.

Me hubiera gustado ver un juego programado por él mismo en Mega Drive.

Por cierto, no lo sé porque nunca he jugado en una Snes, solo en emulador (y como para buscar un cartucho del juego y pagarlo...), ¿sabéis si Rendering Ranger se ralentiza en la SNES?



Respondiendo la pregunta es difícil tener ese juego de rendering ranger R2 original cuesta mucho aproximadamente 1000$ la única forma de jugarlo es en un Flash card así lo jugué y no vi que se relentizara alguna vez
Señor Ventura escribió:
Naitguolf escribió:Y ese ordenamiento de tiles como si viene del ancho de banda más lento del mundo, eso supondrá más trabajo todavía para la CPU perdiendo tiempo en esperar datos, o tener que estar contínuamente pidiendo datos si es baja la memoria. DA lo mismo, el computo de exceso de límites en el scroll se tiene que calcular, bien lo haga el procesador gráfico, o la CPU. Aparte de todo lo que implica después del refresco de máscaras que se tenga que hacer de los demás elementos de pantalla.


La cuestión es que esa escena no va a ser mas demandante por moverse el scroll de forma libre, que de forma automática.
.


Por supuesto que sí. Porque por sobrerailes estás controlando lo que se muestra, no tienes que tener en cuenta el movimiento del jugador. Y no es hablar sobrerailes, sino scroll solo hacia la derecha automático o tener scroll que además suba y baje a voluntad del jugador. Son cálculos adicionales que se deben hacer, son capas adicionales que se tienen que tener en cuanta máscaras, etc, que un simple scroll automático pelado a la derecha. Porque además mueves el resto de elementos y tienes que hacer cálculos de referencia respecto a la pantalla, etc.
Otra cosa es el tipo de disparo (hablo del TFIV), por ejemplo, si llevas el "hunter" el disparo calcula los enemigos más cercanos y va hacia ellos, hasta el momento en que mueren, que cambia la trayectoria y vuelve a buscar al siguiente enemigo que esté más cerca. Este detalle puede parecer una chorrada pero es una carga más que requiere un cálculo extra en tiempo real, de hecho, las veces que el juego se resiente suele ser con este disparo.

Al Axelay no le veo inalcanzable, más allá del color o los efectos de serie de la super como las transparencias.
Naitguolf escribió:
Señor Ventura escribió:
Naitguolf escribió:Y ese ordenamiento de tiles como si viene del ancho de banda más lento del mundo, eso supondrá más trabajo todavía para la CPU perdiendo tiempo en esperar datos, o tener que estar contínuamente pidiendo datos si es baja la memoria. DA lo mismo, el computo de exceso de límites en el scroll se tiene que calcular, bien lo haga el procesador gráfico, o la CPU. Aparte de todo lo que implica después del refresco de máscaras que se tenga que hacer de los demás elementos de pantalla.


La cuestión es que esa escena no va a ser mas demandante por moverse el scroll de forma libre, que de forma automática.
.


Por supuesto que sí. Porque por sobrerailes estás controlando lo que se muestra, no tienes que tener en cuenta el movimiento del jugador. Y no es hablar sobrerailes, sino scroll solo hacia la derecha automático o tener scroll que además suba y baje a voluntad del jugador. Son cálculos adicionales que se deben hacer, son capas adicionales que se tienen que tener en cuanta máscaras, etc, que un simple scroll automático pelado a la derecha. Porque además mueves el resto de elementos y tienes que hacer cálculos de referencia respecto a la pantalla, etc.


Supongo que pasará algo parecido a los Resident Evil Chronicles de Wii (los de pistola/wiimote), que mostraban unos gráficos tremendos para ser de Wii, pero on rails, todo era automático, sin libertad de movimientos, similar Virtua Cop o House of The Dead.

Luego, te ibas a otros survival con libertad de movimientos, y la calidad visual pegaba un bajón considerable.
Naitguolf escribió:Por supuesto que sí. Porque por sobrerailes estás controlando lo que se muestra, no tienes que tener en cuenta el movimiento del jugador. Y no es hablar sobrerailes, sino scroll solo hacia la derecha automático o tener scroll que además suba y baje a voluntad del jugador. Son cálculos adicionales que se deben hacer, son capas adicionales que se tienen que tener en cuanta máscaras, etc, que un simple scroll automático pelado a la derecha. Porque además mueves el resto de elementos y tienes que hacer cálculos de referencia respecto a la pantalla, etc.


Hacer que el scroll suba y baje a voluntad del jugador supone cargar nuevos tiles mientras dejan de cargarse otros, es exactamente el mismo esfuerzo para el frame buffer dibujar una escena frame a frame, y lo único que necesitas es tener los datos cargados en la VRAM a tiempo.

Estais insistiendo en que hay que calcular mas, pero el tiempo de proceso lógico es exactamente igual (siempre que la nueva zona no requiera de un mayor número de tiles, en cuyo caso no es que se tarde mas en "construir" el plano, es que requiere mas ancho de banda).

Hacer un scroll automático te permite tener un control de lo que se carga en pantalla hasta el punto de aprovechar al milímetro la VRAM, pero es eso, una cuestión de ancho de banda y memoria, no de cpu para ordenar los tiles que conforman el plano, esa es una tarea para la que están de sobra preparadas, y mas aún snes.

Es el ppu1 quien se encarga de gestionar todo lo referente a los planos sin dependencia de la cpu (salvo para las pertinentes llamadas a la ROM para transferir datos), y el solito además ordena los datos para el frame buffer. Si hay un hardware que mueve con la gorra los planos de scroll, ese es la super nintendo.
Señor Ventura escribió:En esta escena se cuentan 6 planos de scroll:
Imagen


Yo ahí solo he visto 3 planos



Señor Ventura escribió:En esta otra 7 planos:
Imagen


Y aquí vuelve a haber 3 planos, pero te engañan con el segundo plano donde esta dividido en varias partes a distinta velocidad. Muy común en juegos de la ultima hornada de la NES que luego aplicaban en SNES.
Señor Ventura escribió:Si hay un hardware que mueve con la gorra los planos de scroll, ese es la super nintendo.


Ah bueno, así que en eso se resume. Que la snes es mejor que otro sistema. Qué pérdida de tiempo. Y sí, requiere más cálculo mover un scroll libre. Y por scroll, hablamos de pantallas enteras, no trozos de mapas como muy bien apunta @Diskover. NO es lo mismo lo que cuesta mover el Shadow Of the Beast, que los mapas del ThuderForce IV (ni a la velocidad que lo hace ni la cantidad de elementos móviles) Haga el cálculo quien lo haga, bien tengas un chip dedicado o tengas que hacerlo por software. Y como todo, sacarle provecho a un hardware requiere tiempo, más cuando tienes un sistema tan delicado en velocidad como la snes, que como prueba, los primeros juegos eran muy lentos como bien indica el OP. A mí me decepcionó muchísimo el Ghouls and Ghosts en ese sentido.
Diskover escribió:Yo ahí solo he visto 3 planos
Diskover escribió:Y aquí vuelve a haber 3 planos, pero te engañan con el segundo plano donde esta dividido en varias partes a distinta velocidad. Muy común en juegos de la ultima hornada de la NES que luego aplicaban en SNES.


Al menos en el segundo tendrían que ser 4 planos, en todo caso. En el primero podrían ser 3.


Naitguolf escribió:
Señor Ventura escribió:Si hay un hardware que mueve con la gorra los planos de scroll, ese es la super nintendo.


Ah bueno, así que en eso se resume. Que la snes es mejor que otro sistema. Qué pérdida de tiempo.


Lo he explicado con detalles, así que resulta sesgado coger ese comentario para aplicarme esta respuesta, ¿eh?.

No, no se resume en eso, se resume en que la snes mueve hasta 4 planos por hardware, siendo el ppu1 quien se encarga de moverlos sin ninguna dependencia de la cpu. El 65c816 no tiene que hacer nada, excepto dar la orden para que el DMA transfiera los tiles de la ROM a la VRAM, y proveer las instrucciones de como se tienen que ordenar, cosa que hace el sistema gráfico, no la cpu.

El sistema de vídeo se encarga de conformar los planos con los tiles de la VRAM, de moverlo como corresponda, de construir los scanlines del frame buffer, y de lanzarlo a la TV.

Eso es lo que significa mover planos por hardware, y es por eso que la snes es una máquina especializada en esa tarea sin que la cpu tenga que hacer nada.

Lo de que "un sistema sea mejor que otro" lo has dicho tu, no yo.

Naitguolf escribió:Y sí, requiere más cálculo mover un scroll libre. Y por scroll, hablamos de pantallas enteras, no trozos de mapas como muy bien apunta @Diskover. NO es lo mismo lo que cuesta mover el Shadow Of the Beast, que los mapas del ThuderForce IV (ni a la velocidad que lo hace ni la cantidad de elementos móviles) Haga el cálculo quien lo haga, bien tengas un chip dedicado o tengas que hacerlo por software.


Si tienes que mover un scroll en horizontal y vertical simultaneamente, tienes que ordenar el doble de tiles. Si te refieres a eso, está claro que es así.

Otra cosa es que sea una tarea tan demandante como se dice. La velocidad del scroll depende en su mayoría del ancho de banda.
Señor Ventura escribió:Al menos en el segundo tendrían que ser 4 planos, en todo caso. En el primero podrían ser 3.


Eso es muy fácil de ver: basta ponerte el emulador que quieras y quitar las capas BG con las teclas "1", "2", "3" o "4".



Señor Ventura escribió:No, no se resume en eso, se resume en que la snes mueve hasta 4 planos por hardware, siendo el ppu1 quien se encarga de moverlos sin ninguna dependencia de la cpu. El 65c816 no tiene que hacer nada, excepto dar la orden para que el DMA transfiera los tiles de la ROM a la VRAM, y proveer las instrucciones de como se tienen que ordenar, cosa que hace el sistema gráfico, no la cpu.

El sistema de vídeo se encarga de conformar los planos con los tiles de la VRAM, de moverlo como corresponda, de construir los scanlines del frame buffer, y de lanzarlo a la TV.

Eso es lo que significa mover planos por hardware, y es por eso que la snes es una máquina especializada en esa tarea sin que la cpu tenga que hacer nada.


Eso es así tal cual lo cuentas, aunque creo que la Megadrive tenía algo parecido. Supongo, de hecho, que todas las consolas antiguas funcionaban parecido en ese sentido, con una pantalla basada en caracteres (tiles) y no en píxeles.


Señor Ventura escribió:Si tienes que mover un scroll en horizontal y vertical simultaneamente, tienes que ordenar el doble de tiles. Si te refieres a eso, está claro que es así.

Otra cosa es que sea una tarea tan demandante como se dice. La velocidad del scroll depende en su mayoría del ancho de banda.


Lo cierto es que la SNES tiene un modo DMA que permite hacer los scrolls diagonales muy fácilmente: se configura un DMA para que envíe el tilemap de la primera línea de pantalla (que son todo direcciones correlativas) y otro DMA con un incremento igual al ancho en tiles de la pantalla para enviar el tilemap de la primera columna de pantalla (que son todo direcciones de VRAM no correlativas, ya que las tiles están unas debajo de las otras separadas en memoria el ancho del tilemap).
Luego controlas el scroll con los dos registros correspondientes y tienes un bonito y sencillo scroll vertical hacia la izquierda.
magno escribió:
Señor Ventura escribió:No, no se resume en eso, se resume en que la snes mueve hasta 4 planos por hardware, siendo el ppu1 quien se encarga de moverlos sin ninguna dependencia de la cpu. El 65c816 no tiene que hacer nada, excepto dar la orden para que el DMA transfiera los tiles de la ROM a la VRAM, y proveer las instrucciones de como se tienen que ordenar, cosa que hace el sistema gráfico, no la cpu.

El sistema de vídeo se encarga de conformar los planos con los tiles de la VRAM, de moverlo como corresponda, de construir los scanlines del frame buffer, y de lanzarlo a la TV.

Eso es lo que significa mover planos por hardware, y es por eso que la snes es una máquina especializada en esa tarea sin que la cpu tenga que hacer nada.


Eso es así tal cual lo cuentas, aunque creo que la Megadrive tenía algo parecido. Supongo, de hecho, que todas las consolas antiguas funcionaban parecido en ese sentido, con una pantalla basada en caracteres (tiles) y no en píxeles.


Todas las consolas de NES hacia arriba hacen el scroll por hardware, Master, Mega. Nes, Pc Engine....

Y realmente, con un buen diseño, no hace falta ni recargar muchos tiles tan solo. En Antarex, en la demo que se ha visto por las ferias, no recargamos nada del tilemap, solo unos cuantos tiles para animar los destructores del fondo.

En master por ejemplo, hay un par de juegos que no usan los planos de scroll por hardware ni los sprites, como Altered Beast y Golden Axe, y entonces el scroll resulta brutalmente brusco (lo tiene que hacer la CPU).
kusfo79 escribió:Todas las consolas de NES hacia arriba hacen el scroll por hardware, Master, Mega. Nes, Pc Engine....

Y realmente, con un buen diseño, no hace falta ni recargar muchos tiles tan solo. En Antarex, en la demo que se ha visto por las ferias, no recargamos nada del tilemap, solo unos cuantos tiles para animar los destructores del fondo.

En master por ejemplo, hay un par de juegos que no usan los planos de scroll por hardware ni los sprites, como Altered Beast y Golden Axe, y entonces el scroll resulta brutalmente brusco (lo tiene que hacer la CPU).


Sí, suponía que todas funcionarían más o menos parecido. Y como bien dices, un buen hardware es fundamental, pero un diseño óptimo puede conseguir cosas increíbles.
Un ejemplo de hacer las cosas bien en snes,es el pop n twinbee.Un juego de konami,con graficazos,musicón y multitud de enemigos y efectos en pantalla,en los cuales,no cae el framerate en ningún momento.
https://youtu.be/8wZ6JMS3sik
Si el pop and twinbee es una gozada.
Otro tapadillo y que me parece brutal es el Adams family el del niño de plataformas ,tiene una velocidad brutal ,buen sonido.,muchos scrolles y fases muy chulas como la del baño con las burbujas ,muy bien hechas.
Y otras como la de la bola .
titorino escribió:Si el pop and twinbee es una gozada.
Otro tapadillo y que me parece brutal es el Adams family el del niño de plataformas ,tiene una velocidad brutal ,buen sonido.,muchos scrolles y fases muy chulas como la del baño con las burbujas ,muy bien hechas.
Y otras como la de la bola .


Prefiero el Addams Family normal, el otro no me lo he podido pasar, aunque es cierto que visualmente es mejor.

Pero es que el normal lo he completado un monton de veces y siempre encuentro pasadizos secretos nuevos, es un juego casi infinito en ese sentido.

Y si, el Pop and Twin Bee es una gozada, recuerdo que en el escenario del mar se llenaba la pantalla de peces y en el de China caian dos lluvias de pandas bastante generosas en enemigos.

Lástima que la segunda parte (Rainbow Bell Adventures o algo asi) fuese un juego raruno, entiendo que quisieran variar, pero si llegan a hacer otro Twin Bee como el anterior, me habria gustado mas.
Señor Ventura escribió:
Diskover escribió:Yo ahí solo he visto 3 planos
Diskover escribió:Y aquí vuelve a haber 3 planos, pero te engañan con el segundo plano donde esta dividido en varias partes a distinta velocidad. Muy común en juegos de la ultima hornada de la NES que luego aplicaban en SNES.


Al menos en el segundo tendrían que ser 4 planos, en todo caso. En el primero podrían ser 3.


No, no, son solo 3 planos.

Primer plano, la verja, lo que se pone por encima de los sprites.

Segundo plano, el escenario en si, a su vez está dividido en varios trozos que se mueven a distinta velocidad para dar sensación de profundiad.

Tercer plano, el detalle del fondo del todo, una luz roja que se apaga y se enciende lentamente y no parece moverse con el resto del escenario.

Imagen

Como te comentaba antes, lo del segundo plano es un truquete que ya se hacia en la era de los 8 bits para que pareciese que había más planos, pero realmente es solo uno dividido en trozos que se mueven a distinta velocidad. La NES solo puede mover un solo plano y en Battletoad hace ese truco (y otros juegos).

Imagen
Diskover escribió:
Señor Ventura escribió:
Diskover escribió:Yo ahí solo he visto 3 planos
Diskover escribió:Y aquí vuelve a haber 3 planos, pero te engañan con el segundo plano donde esta dividido en varias partes a distinta velocidad. Muy común en juegos de la ultima hornada de la NES que luego aplicaban en SNES.


Al menos en el segundo tendrían que ser 4 planos, en todo caso. En el primero podrían ser 3.


No, no, son solo 3 planos.

Primer plano, la verja, lo que se pone por encima de los sprites.

Segundo plano, el escenario en si, a su vez está dividido en varios trozos que se mueven a distinta velocidad para dar sensación de profundiad.

Tercer plano, el detalle del fondo del todo, una luz roja que se apaga y se enciende lentamente y no parece moverse con el resto del escenario.

Imagen

Como te comentaba antes, lo del segundo plano es un truquete que ya se hacia en la era de los 8 bits para que pareciese que había más planos, pero realmente es solo uno dividido en trozos que se mueven a distinta velocidad. La NES solo puede mover un solo plano y en Battletoad hace ese truco (y otros juegos).

Imagen


El truco del Battletoads es mover bloques de píxeles a diferentes velocidades. El caso más extremo de esta técnica es el suelo con perspectiva de SF2 y similares.
Aprovecho para preguntar por ese efecto y comparar ambos efectos de street fighter 2 en mega y super .
¿que consola lo mueve mejor?
Siempre escuche que en super iba mas fino ¿es cierto eso?
No le veo sentido andar discutiendo limitaciones de hardware de una consola, especialmente en el tema de planos de scroll, cuando esta todo en manos del programador

Claro que el hardware ayuda, pero es solo una parte del total


Por ejemplo, acabo de hacer esta pequeña demo, me base en un codigo q habia echo antes, y modifique un poco (por eso los bloques pegan saltos, en el codigo original habia programado una rutina para escalones... paso de arreglarlo)

www.akihabara-online.com/Megadrive/ejemplos/scroll.zip


En esta demo hay solo UN (1) plano de scroll, NINGUN (0) sprite, asi q no hay trucos con sprite, y solo UNA (1) paleta de 15 colores

Imagen
theelf escribió:No le veo sentido andar discutiendo limitaciones de hardware de una consola, especialmente en el tema de planos de scroll, cuando esta todo en manos del programador

Claro que el hardware ayuda, pero es solo una parte del total


Por ejemplo, acabo de hacer esta pequeña demo, me base en un codigo q habia echo antes, y modifique un poco (por eso los bloques pegan saltos, en el codigo original habia programado una rutina para escalones... paso de arreglarlo)

www.akihabara-online.com/Megadrive/ejemplos/scroll.zip


En esta demo hay solo UN (1) plano de scroll, NINGUN (0) sprite, asi q no hay trucos con sprite, y solo UNA (1) paleta de 15 colores

Imagen

Si se movieran las "montañas" esas verdes o las pirámides (o ambas) tendrías un pseudo Jim Power... XD

Se agradecen estas cosas! [oki]
titorino escribió:Aprovecho para preguntar por ese efecto y comparar ambos efectos de street fighter 2 en mega y super .
¿que consola lo mueve mejor?
Siempre escuche que en super iba mas fino ¿es cierto eso?


Acabo de echar una partida a ambos (tengo los cartuchos originales) y no he notado diferencia en ese efecto (puede que sea en algún nivel concreto y se me haya escapado, pero no creo). Las únicas diferencias técnicas destacables que encuentro son en el color y el sonido, ambas a favor de la Super Nintendo.
robotnik16 escribió:Si se movieran las "montañas" esas verdes o las pirámides (o ambas) tendrías un pseudo Jim Power... XD

Se agradecen estas cosas! [oki]



Me pones en un aprieto tio jeje

El truco para trabajar con un solo plano, es que si un objeto tapa a otro, tiene que carecer de transparencoa, o sea ser cuadrado o rectangular

Pero me gustaria algun dia ponerme y hacer un efecto de varios planos de scroll simulados en un mimo plano, y poder usar transparencia

Eso se podria hacer leyendo la vram dinamicamente, y volviendo a escribirla con los cambios, pero claro, se escapa de, tanto mi tiempo libre, como del tiempo que dedicaria a un ejemplo para un foro
Muchas thirds optimizaban como el culo en esa época(bueno y siempre XD ) sobre todo capcom pero había otros que si se ponían las pilas.

Los juegos third party no son referente de nada porque cada uno trabaja de forma diferente y obviamente unos son mejores que otros en el tema de optimizar los juegos.
theelf escribió:
robotnik16 escribió:Si se movieran las "montañas" esas verdes o las pirámides (o ambas) tendrías un pseudo Jim Power... XD

Se agradecen estas cosas! [oki]



Me pones en un aprieto tio jeje

El truco para trabajar con un solo plano, es que si un objeto tapa a otro, tiene que carecer de transparencoa, o sea ser cuadrado o rectangular

Pero me gustaria algun dia ponerme y hacer un efecto de varios planos de scroll simulados en un mimo plano, y poder usar transparencia

Eso se podria hacer leyendo la vram dinamicamente, y volviendo a escribirla con los cambios, pero claro, se escapa de, tanto mi tiempo libre, como del tiempo que dedicaria a un ejemplo para un foro


Por lo que dices, con las pirámides del último plano sí que podrías hacerlo, creo, aprovechando que el cielo no tiene otros detalles como nubes o cosas así al lado de las pirámides; solo tiene colores uniformes, y se podrían hacer bloques cuadrados o rectangulares pillando las pirámides dentro.

Luego, para que se notará el efecto, tendrías que poner sí o sí nubes o algo por encima de las pirámides, en la zona con scroll diferente, porque sino no se notaría ningún cambio.

No se si me me he explicado bien. [+risas]
@gynion

Pero en ese caso no se diferenciaria de lo q hay ahora, simplemente que en vez de los bloques flotantes, serian los arbustos ensima de las piramides

El tema es que si quiero mezclar arbusto, piramide y bloques, ya es mas complejo, porque me encuentro con puntos donde se mezclan demasiadas cosas sin transparencia

Podria hacer los arbustos mas altos, y que la punta (la unica que requiere transparencia), termine arriba de las ontañas, y poner los bloques debajo de estos

Pero ya me tengo q meter demasiado con photoshop, para un ejemplo q no es trascendental jejee
@theelf

Mira, más fácil; pillas toda la zona de las pirámides, la separas del resto del cielo (al estilo Battletoads de Nes), le das distinto scroll (velocidad) a cada sección y en la sección por encima de la zona de las pirámides pones detalles (como nubes, por ejemplo).

Si es como pienso, parecería que hay otro plano más en esa demo; vamos, estoy casi seguro.
gynion escribió:No, mira, más fácil; pillas toda la zona de las pirámides, la separas del resto del cielo (al estilo Battletoads de Nes), le das distinto scroll a cada sección y en la sección por encima de la zona de las pirámides pones detalles (como nubes, por ejemplo).

Si es como pienso, parecería que hay otro plano más en esa demo; vamos, estoy casi seguro.


Pero lo q mola es superponer planos XD lo de las nuves lo habia pensado, pero imagine se veria poco espectacular

tecnicamente se piuede hacer scroll por lineas, asi que hay 224 planos de scroll "falsos" posibles dentro de un mismo plano

Lo que queria era superponer esos planos, que es lo que tecnicamente no es posible, y es lo q hacen los ladrillos
theelf escribió:
gynion escribió:No, mira, más fácil; pillas toda la zona de las pirámides, la separas del resto del cielo (al estilo Battletoads de Nes), le das distinto scroll a cada sección y en la sección por encima de la zona de las pirámides pones detalles (como nubes, por ejemplo).

Si es como pienso, parecería que hay otro plano más en esa demo; vamos, estoy casi seguro.


Pero lo q mola es superponer planos XD lo de las nuves lo habia pensado, pero imagine se veria poco espectacular

tecnicamente se piuede hacer scroll por lineas, asi que hay 224 planos de scroll falsos posibles dentro de un mismo plano

Lo que queria era superponer esos planos, que es lo que tecnicamente no es posible, y es lo q hacen los ladrillos


Ah vale; sí, eso parece más chungo, y ya habría que saber más del tema. [+risas]

Mi idea era para buscar una alternativa a las transparencias y dar el pego de otro plano, al no poder utilizarlas como dices.

De todas formas, es así como lo pienso, y daría la apariencia de que existe otro plano ¿no?
@gynion
Si no te entiendo mal, de la manera q dices, podrias hacer 224 planos independientes
magno escribió:La SNES tiene hasta 4BGs, que como dices son menos dependiendo del modo, como regla general, a más BGs, menos colores puedes usar en cada uno de ellos.
Pero pensando que hay 4 en el Axelay, solo podrías hacer 4 planos de scroll. Lo de hacerlo por software no sé exactamente a qué te refieres... A lo mejor te refieres a que se puede coger un plano de scroll y actualizar las tiles para que parezca que hay un scroll diferente al que tiene la capa, pero esto no es un plano extra de scroll, sigue siendo uno solo.


Disculpa que haya tardado un poco en contestar, quería estar seguro de que decir.

Pues era algo así, obligar a la cpu a dibujar capas de tiles en adición a los planos dibujados por el sistema gráfico (que en el fondo soin también capas de tiles, por decirlo de alguna manera). Pensaba en la forma en que megadrive sale del paso debido a la limitación de 1 plano para la ventana + 1 plano de scroll parallax, y si se puede hacer por software, entonces esa posibilidad no excluye a ningún procesador.

Fué querer verlo así, aunque también tiene su justificación porque en los dos gifs que puse se aprecian algunas cosas raras que no cuadran con desplazar los scanlines de un plano a velocidades diferentes para simular el efecto de varias capas.

Por ejemplo, en el primer gif, aunque no se aprecia bien, en la parte inferior hay una capa que tiene una zona dibujada que invade los scanlines de la zona de otro plano... si divides un plano en dos alterando los scanlines, eso sería imposible de hacer porque va tapando el dibujo del otro plano, y también dejándolo ver... y volviéndolo a tapar...
Se que me explico mal, pero se que eso que veo no puede corresponder a un mismo plano.

Por desgracia, parece ser que el rendering ranger no se lleva bien con los debuggers :(

magno escribió:Como ejemplo: podrías hacer que BG4 se moviera hacia la derecha y a la vez actualizar las tiles en vertical, pareciendo que hay dos scrolls diferentes, pero realmente sería un único scroll en dirección arriba-derecha. Además, esto no se puede hacer trivialmente, ya que cuando actualizas las tiles solo lo puedes hacer con resolución 8x8 (tamaño mínimo de una tile, hasta 32x32) pero esto provocaría un efecto raro en pantalla porque en los bordes inferior y superior verías que cambian 8 píxeles de golpe, y por eso el scroll no se implementa de esa manera sino con registros hardware que permiten desplazarte pixel a pixel.


Entendido... entonces, si quieres añadir "un conjunto de tiles" para obtener un plano por software, no sale a cuenta porque este se desplazaría de 8 pixels en 8 pixels, y no hay otra forma de hacerlo por las buenas.

Obligaría a idear una rutina que encargue a la cpu la tarea de desplazar los tiles de pixel a pixel, pero intuyo que sería bastante costoso, mas que nada porque el código debería empezar por ahí cada vez que comienza un frame, y eso podría ser conflictivo en los momentos en que un programa demande rutinas con total prioridad, pudiendo causar ralentizaciones, etc... ¿no?.

magno escribió:Lo cierto es que la SNES tiene un modo DMA que permite hacer los scrolls diagonales muy fácilmente: se configura un DMA para que envíe el tilemap de la primera línea de pantalla (que son todo direcciones correlativas) y otro DMA con un incremento igual al ancho en tiles de la pantalla para enviar el tilemap de la primera columna de pantalla (que son todo direcciones de VRAM no correlativas, ya que las tiles están unas debajo de las otras separadas en memoria el ancho del tilemap).
Luego controlas el scroll con los dos registros correspondientes y tienes un bonito y sencillo scroll vertical hacia la izquierda.


Que gozada leerte... es que todavía no me puedo creer que estés aquí mismo respondiendo a mis dudas, y ofreciendo información de primera mano [+risas]

Muchas gracias!! [risita]
theelf escribió:@gynion
Si no te entiendo mal, de la manera q dices, podrias hacer 224 planos independientes


Sí, creo que me has entendido bien.
Simplemente que en el ejemplo que te dije se reduciría a 2. Puede que con màs se notara demasiado el truquillo. [carcajad]
gynion escribió:Sí, creo que me has entendido bien.
Simplemente que en el ejemplo que te dije se reduciría a 2. Puede que con màs se notara demasiado el truquillo. [carcajad]


O quedar todavía mas chulo.

El mar de la fase de las montañas del thunder force IV es un plano dividido en muchos trozos (alterando la velocidad de los scanlines), y le da un impacto a la escena inmejorable... pero lo mejor de todo, es que no te cuesta cpu, estos recursos son "gratis".
@gynion

Si queres ver un ejemplo simple de scroll por lineas, este es una tonteria, pero muestra que cada linea esta haciendo un scroll diferente, 224 en total

Basicamente aplicas scroll a cada linea, por ejemplo la parte del codigo q hace el efecto

for y=0 to 223
reload sine,contador+y AND 63
read x

scroll2 right,y>>5+x-4,y
next



http://www.akihabara-online.com/Megadrive/ejemplos/scrollw.zip


El problema es que para que los planos de scroll den la impresion de ser "planos", tienen q mostrar un grado de transparencia, q se vea lo de debajo, si no, quedan sosos
Papitxulo escribió:
titorino escribió:Aprovecho para preguntar por ese efecto y comparar ambos efectos de street fighter 2 en mega y super .
¿que consola lo mueve mejor?
Siempre escuche que en super iba mas fino ¿es cierto eso?


Acabo de echar una partida a ambos (tengo los cartuchos originales) y no he notado diferencia en ese efecto (puede que sea en algún nivel concreto y se me haya escapado, pero no creo). Las únicas diferencias técnicas destacables que encuentro son en el color y el sonido, ambas a favor de la Super Nintendo.

Gracias no tengo el de mega para comprobarlo.
@theelf

En megadrive podría dibujarse una capa de tiles a base de cpu, y poder desplazarse nativamente pixel a pixel sin tener que liarse uno a escribir código para forzarlo ( a cambio de tiempo de proceso)... o algo así tenía entendido, ¿puede ser?.
Señor Ventura escribió:@theelf

En megadrive podría dibujarse una capa de tiles a base de cpu, y poder desplazarse nativamente pixel a pixel sin tener que liarse uno a escribir código para forzarlo ( a cambio de tiempo de proceso)... o algo así tenía entendido, ¿puede ser?.


No entiendo muy bien que queres preguntar, pero los metodos de scroll q soporta el VDP son


HSCROLL_OVERALL
VSCROLL_OVERALL

HSCROLL_CELL
VSCROLL_2CELL

HSCROLL_LINE



Los primeros dos como bien se entiende, hace un scroll tanto vertical como horizontal de todo el plano

Los siguientes, son scroll por tile horizontal (8x8), y scroll por dos tiles vertical (16x8)

El ultimo es el scroll por linea, solo horizontal, y permite las 224 lineas de NTSC


Todos esos metodos son por VDP, solo es necesario llamarlos y pasarles los parametros, pero codigo tenes q escribir, ya que hay que acceder a esos registros por ensamblador


Y olvidate de eso del tiempo de proceso, que te lo he leido mucho, y no es algo de relevancia en la mayoria de los temas, solo cuando estas programando, y normalmente es por limitaciones de software, o sea, te quedas bloqueado y tiras de un metodo ineficiente
theelf escribió:Y olvidate de eso del tiempo de proceso, que te lo he leido mucho, y no es algo de relevancia en la mayoria de los temas, solo cuando estas programando, y normalmente es por limitaciones de software, o sea, te quedas bloqueado y tiras de un metodo ineficiente


Es que en snes es ineficiente si se entiende que para desplazar los tiles (de una capa dibujada por la cpu) pixel a pixel habría que escribir una rutina que indique como hacerlo (mientras que en megadrive acudes a la instrucción con los valores, y fuera). En snes sería gastar tiempo de proceso.

theelf escribió:Todos esos metodos son por VDP, solo es necesario llamarlos y pasarles los parametros, pero codigo tenes q escribir, ya que hay que acceder a esos registros por ensamblador


Vamos, que eso de que solo admite 2 planos por hardware, es una verdad a medias, en el fondo la cpu recibe bastante ayuda del VDP a partir del tercer plano, que sería dibujado a base de cpu... ¿no?.
theelf escribió:@gynion

Si queres ver un ejemplo simple de scroll por lineas, este es una tonteria, pero muestra que cada linea esta haciendo un scroll diferente, 224 en total

Basicamente aplicas scroll a cada linea, por ejemplo la parte del codigo q hace el efecto

for y=0 to 223
reload sine,contador+y AND 63
read x

scroll2 right,y>>5+x-4,y
next



http://www.akihabara-online.com/Megadrive/ejemplos/scrollw.zip


El problema es que para que los planos de scroll den la impresion de ser "planos", tienen q mostrar un grado de transparencia, q se vea lo de debajo, si no, quedan sosos


Anda, pues ahora comprendo como hacían esos efectos de ondulaciones.

Gracias por esa jugosa info. No creo que me ponga a programar para Mega, con todo lo que habrá que saber de ensamblador para sacarle jugo, pero nunca se sabe. [+risas]
@gynion

De nada, si un dia te pones, y queres codigo completos, sin problema

Deje de postearlos, porque creo que mas que copiar/pegar, lo ideal es que la gente se ponga a programar, y si pones el codigo, da pie al copiado/pegado, lo que no quita que ver codigo completo sea cojonudo a veces


@Señor Ventura

No entiendo bien tu pregunta, a ver, si tenes una capacidad de vdp X la usas, si no, usas otra que haga un efecto similar, si no tenes ninguna, buscas otro efecto...

Lo de los planos, me suena que no entendes el concepto por tu pregunta, no le veo logica. Para megadrive, esto lo explica bien

http://segaretro.org/Plane
La cpu de snes no está pensada para cálculo, si no para atender a interrupciones de forma rápida. De hecho, creo recordar, que su uso intencional fue para aplicaciones de telefonía y satélites en los 70.
En cambio la de MD si está pensada para cálculo intensivo, de 1980. De ahí que los juegos que realizan operaciones intensas, detección de muchas colisiones y respuesta de la IA, se muevan con algo más de soltura.

Señor Ventura escribió:
theelf escribió:Y olvidate de eso del tiempo de proceso, que te lo he leido mucho, y no es algo de relevancia en la mayoria de los temas, solo cuando estas programando, y normalmente es por limitaciones de software, o sea, te quedas bloqueado y tiras de un metodo ineficiente


Es que en snes es ineficiente si se entiende que para desplazar los tiles (de una capa dibujada por la cpu) pixel a pixel habría que escribir una rutina que indique como hacerlo (mientras que en megadrive acudes a la instrucción con los valores, y fuera). En snes sería gastar tiempo de proceso.


Si es scroll horizontal puedes activar interrupciones (NMI creo que lo llaman) y modificar los registros sin necesidad de tráfico de datos, la cpu de snes es muy efectiva para tal cosa. En cambio la de MD, si activas la misma interrupción, en todas las líneas, está ya de por si consume más del 50% de la cpu.

Son máquinas diferentes.
Bueno, por eso la MD tiene tabla de scroll

En todo caso, las interrupciones en la MD no toman tanto CPU, unos 64 ciclos por interrupcion, diria que en caso de hacer las 224, andara por el 8-10% de uso de CPU, claro que eso solo es la interrupcion

Te lo digo basado en los datos que da el pdf del 68k, la verdad que en el dia a dia, no es algo q me preocupe comprobar. No tiene mucho sentido a menos que estes programando algo teorico
gynion escribió:Claro que toda maquina podía tenerlas, pero lo que importa no es que haya ralentizaciones en una consola, sino lo que las causa y cuanto aguanta una consola sin sufrirlas.

En el caso de Metal Slug 2, creo que era un fallo tonto de software, y en las siguientes ediciones no pasaba; en el caso de ThunderForce IV, seguramente SNES ni podría correr ese juego.


Algunos mencionaban que las relantizaciones estaban a favor como en shooters de naves cono Gradius 3 tanto en su version original Arcade como en una recopilacion para PS2 pasaba esto, explicacion "era emulacion pura y dura, por eso pasa este pequeno pero perdonable "slowdown" que a veces es favorable en tramos dificiles del juego, segun la revista Super Juegos.
Gammenon escribió:

El truco del Battletoads es mover bloques de píxeles a diferentes velocidades. El caso más extremo de esta técnica es el suelo con perspectiva de SF2 y similares.


Ya, eso es lo que he dicho.

Es el,ejemplo más primitivo de scroll paralax.

Luego, si se mezcla con diferentes background de profundidad se consiguen cosas como los gif de ejemplo de SNES
225 respuestas
Archivado
1, 2, 3, 4, 5
Volver a Consolas clásicas