[Homebrew] Magical Chase para NES (port de PC-Engine/Turbografx)

Responder
Parece que he desempolvado la parte de mi cerebro para tocar código y me he propuesto juguetear con el mapper MMC3 de la NES, y para la ocasión (a parte de otras cosas que ya hice hace tiempo) me he querido ayudar del videojuego Magical Chase (Quest 1991, PC-Engine/Turbografx) para mostrar cuanto de viable tendría un port para NES de este programa.

Imagen


Imagen Imagen
Imagen Imagen


Como siempre, utilizaré el compilador CC65, que me permite escribir en Lenguaje C, y como librería con las funciones más básicas, tiraré de NESlib (de Shiru). Además, añadiré otra librería más para funciones más complejas y que me ayude a desarrollar el programa en el mapper MMC3, con sus IRQs, cambios de banco al vuelo, etc. Esta librería es la última versión de NESdoug (de Dougeff).

Llevo un par de semanas con el asunto, y lo cierto es que dominar esta librería y su implementación del IRQ no me ha sido sencillo para la cierta "complejidad" que requieren algunos mapeados del juego. Actualmente, me estoy centrando en el primer nivel de la versión americana (cambian los gráficos respecto al japonés), y aunque parece muy sencillo de copiar, ya no lo es tanto si quieres hacer el pequeño parallax que tiene en el eje Y. Seguramente se pueda hacer muy similar, pero por ahora yo solo he conseguido hacer esto.



Como podéis ver, hay varias líneas de división para simular profundidad:

Imagen


Y realmente aquí lo que hay es una combinación de las dos nametables A y B, configurados con un mirroring en VERTICAL, y luego calculando los IRQ para los cortes, salto de cámara, y escaneos.

Imagen


Opte por esta forma de trabajar el nivel, por el empeño de realizar ese pequeño parallax vertical sobre el eje Y que no ha quedado como quería, aunque menos es nada.

Otros detalles a tener en cuenta, son los soportes del puente. En este caso he elegido realizarlo con sprites para que se fusionen convenientemente con el fondo y creen la ilusión de que estamos ante dos capas. Esto más adelante va a dar algún problema, dado que la NES solo puede mostrar 64 sprites/tiles en pantalla, y los dos soportes del puente ya consumen 12 tiles cada uno.

Además, hay que tener en cuenta el detalle de que parte de estos soportes se esconden tras el HUB inferior cuando la cámara está en su punto más bajo. Para ocultarlos, puse 8 tiles vacíos, con alta prioridad, en uno de los costados de la pantalla para que cuando el puente pase por su línea de escaneo, estos no se puedan dibujar debido a que la NES solo puede poner 8 tiles/sprites en la misma línea.

Imagen


Todo esto queda muy bonito si no tenemos en cuenta que todavía nos falta añadir enemigos, proyectiles, etc... Lo que provocaría un autentico festival de parpadeos muy al estilo de Parodius! (Konami 1992).

¿Soluciones? Ahora os cuento.
Duro con ello :cool:
Elazul está baneado por "clon de usuario baneado"
Me parece una idea genial. Magical Chase es uno de mis juegos favoritos de PC Engine, es una preciosidad y su jugabilidad es una maravilla.

Ahora bien, podrías usar el decorado japonés de la primera fase? Es mucho más bonito que lo que hicieron en la versión americana, que es mucho menos original.
Para el HUD lo que puedes hacer es desactivar los sprites en esa scanline y luego activarlos ya para el siguiente frame, así no gastas esos sprites.
Lo siguiente sería intentar hacerlo con sprites de 8x16 porque si no te vas a quedar enseguida sin (solo un disparo o una estrella ya parece que usaría 4 de 8x8).
Desperdiciarás un poco de espacio en VRAM en algunos casos pero teniendo los slots de 1KB del MMC3 en los sprites no creo que haya mucho problema.

PS: Si no tienes el código fuente no es un port xD
wave escribió:Para el HUD lo que puedes hacer es desactivar los sprites en esa scanline y luego activarlos ya para el siguiente frame, así no gastas esos sprites.
Lo siguiente sería intentar hacerlo con sprites de 8x16 porque si no te vas a quedar enseguida sin (solo un disparo o una estrella ya parece que usaría 4 de 8x8).
Desperdiciarás un poco de espacio en VRAM en algunos casos pero teniendo los slots de 1KB del MMC3 en los sprites no creo que haya mucho problema.

PS: Si no tienes el código fuente no es un port xD

Desactivar sprites queda muy feo. En algún los soportes pasarían por encima del HUB antes de borrarlos, o se borrarían antes rompiendo la ilusión de profundidad.
Mis diesels por esto.
Diskover escribió:Desactivar sprites queda muy feo. En algún los soportes pasarían por encima del HUB antes de borrarlos, o se borrarían antes rompiendo la ilusión de profundidad.

Por otro lado, si uso sprites de 8x16, en vez de 64 en pantalla, nos quedaríamos en 32. Seguimos teniendo el mismo problema.

De todas formas, he dado con una solución para ganar espacio en la tabla de sprites...

No debo haber entendido que querías hacer porque desactivar sprites en la scanline del hud es exactamente el mismo efecto que parecías describir hacer.
Desactivar sprites es un flag de la cpu sencillo que usan muchos juegos de nes para lo mismo.
Y lo otro no, no tienes 32, tienes 64 sprites igual, con sprites de 8x16 puedes llenar el doble de pantalla, lo único que en horizontal sigues teniendo el límite de 8 por scanline.
wave escribió:
Diskover escribió:Desactivar sprites queda muy feo. En algún los soportes pasarían por encima del HUB antes de borrarlos, o se borrarían antes rompiendo la ilusión de profundidad.

Por otro lado, si uso sprites de 8x16, en vez de 64 en pantalla, nos quedaríamos en 32. Seguimos teniendo el mismo problema.

De todas formas, he dado con una solución para ganar espacio en la tabla de sprites...

No debo haber entendido que querías hacer porque desactivar sprites en la scanline del hud es exactamente el mismo efecto que parecías describir hacer.
Desactivar sprites es un flag de la cpu sencillo que usan muchos juegos de nes para lo mismo.
Y lo otro no, no tienes 32, tienes 64 sprites igual, con sprites de 8x16 puedes llenar el doble de pantalla, lo único que en horizontal sigues teniendo el límite de 8 por scanline.


Discúlpame, me he liado con lo de las limitaciones. Efectivamente, seguimos teniendo 64 sprites para mostrar. Borraré la anterior frase para que no haya desinformación.

La desactivación de sprites conlleva que cuando haga el efecto de que la camara suba y baje por el eje Y, y desactive esos sprites del puente, a lo largo del recorrido de esos 8 pixeles que ocupa de alto un tile, desaparecera´n bruscamente en algún momento y quedará feo.

La solución que he aplicado es esta:
- Simplificar los soportes del puente.
- Superponer unos tiles del mismo color que el HUB para que cuando los soportes del puente pasen por debajo del HUB, los tiles de este color tengan preferencia y se oculte los que están por debajo. Ahorramos mucho espacio.

Imagen

Imagen



No obstante, probaré a configurar los sprites en 8x16 pixeles para comprobar la ganancia de espacio
El efecto de scroll parallax de la versión de pc engine seguramente se podría duplicar sin muchos problemas con el MMC3, ya que la máquina original tampoco tiene capas y seguro que hay truco, pero debería descubrirse.

El tema del hub y las columnas lo que puedes hacer es que los tiles del hub tengan el bit de prioridad para que se muestren delante de los sprites mientras que los del fondo que hay delante de las columnas se muestren por detrás. De esta forma si con los "cambios de cámara" las columnas tienen que baja y quedarse detrás del hub lo harán automáticamente sin desactivar nada.
Diskover escribió:La desactivación de sprites conlleva que cuando haga el efecto de que la camara suba y baje por el eje Y, y desactive esos sprites del puente, a lo largo del recorrido de esos 8 pixeles que ocupa de alto un tile, desaparecera´n bruscamente en algún momento y quedará feo.

No queda feo, da el efecto de desaparecer "por debajo" pero es que diría que es exactamente lo mismo que taparlo con otros 8 sprites.
No es que el sprite no se muestre entero, es que dejará de pintarse a medio tile en la scanline del HUD.

Unas imágenes de Super Mario Bros. 3 y Tortugas 2 por si no queda claro:
Imagen
Imagen
Imagen
Imagen
wave escribió:
Diskover escribió:La desactivación de sprites conlleva que cuando haga el efecto de que la camara suba y baje por el eje Y, y desactive esos sprites del puente, a lo largo del recorrido de esos 8 pixeles que ocupa de alto un tile, desaparecera´n bruscamente en algún momento y quedará feo.

No queda feo, da el efecto de desaparecer "por debajo" pero es que diría que es exactamente lo mismo que taparlo con otros 8 sprites.
No es que el sprite no se muestre entero, es que dejará de pintarse a medio tile en la scanline del HUD.

Unas imágenes de Super Mario Bros. 3 y Tortugas 2 por si no queda claro:
Imagen
Imagen
Imagen
Imagen

Vale, no recordaba esa capacidad del IRQ del MMC3.

Lo investigaré como hacer
Diskover escribió:Vale, no recordaba esa capacidad del IRQ del MMC3.

Lo investigaré como hacer

No es de la IRQ en sí, es un flag de la PPU que puedes modificar cuando quieras, eso sí, en IRQ es más útil.
https://www.nesdev.org/wiki/PPU_registers#Mask_($2001)_%3E_write
También puede usarse para el efecto de gris o resaltar colores para otros efectos como simular agua.
wave escribió:
Diskover escribió:Vale, no recordaba esa capacidad del IRQ del MMC3.

Lo investigaré como hacer

No es de la IRQ en sí, es un flag de la PPU que puedes modificar cuando quieras, eso sí, en IRQ es más útil.
https://www.nesdev.org/wiki/PPU_registers#Mask_($2001)_%3E_write
También puede usarse para el efecto de gris o resaltar colores para otros efectos como simular agua.

Ok, muchas gracias por la ayuda. Una nueva cosa aprendida.

Lo he aplicado y parece que funciona. Ahora trasladaré los sprites a formato 8x16
Diskover escribió:Ok, muchas gracias por la ayuda. Una nueva cosa aprendida.

Lo he aplicado y parece que funciona. Ahora trasladaré los sprites a formato 8x16

Genial, de nada :)
Os pongo una nueva actualización, mostrando algún enemigo y disparos.



Debido a problemas con la librería NESdoug, que es la que me permite tener control sobre el MMC3 y crear la ilusión de parallax, el proyecto le tengo "atrancado".

Esta librería actualmente tiene problemas con el estándar 8x16, ideal para mostrar tantos sprites en pantalla en este programa, y estoy esperando a un arreglo o actualización.

Por otro lado, llevo al menos dos semanas peleándome con un scroll que me permita dibujar el escenario poco a poco, utilizando si o si el Mirroring Horizontal, pero me está costando lo suyo pese a algún tímido avance.

Existe la solución de pasar todo a Mirroring Vertical, para el cual tengo un motor de scroll perfectamente utilizable, pero se perdería el efecto parallax en el eje Y, y ya no tendría tanta gracia.
A ver si hay suerte y solucionan el tema de librerías y puedes avanzar, tiene muy buena pinta. Ánimo!

Saludos.
Más avances.

He conseguido arreglar parcialmente el problema que tenía con el motor MMC3 de nesdoug a la hora de tratar tiles de 8x16.

Imagen


El problema ahora es que en una NES real, el parallax en movimiento, hace rebotar la imagen arriba y abajo y mucho me temo que deberé volver a configurar las líneas IRQ que hacen esa magia visual.

Parece que ahora "chuta" y he aprovechado para hacer una pantalla de título para la ocasión, mezclando background con sprites, y, por supuesto, intentando recrear lo más posible la pantalla original de PC-Engine. Creo que ha quedado resultona.

Os dejo un video con el avance:

Y ahora, me he atrevido con otro nivel distinto que usa un efecto para simular doble fondo. Realmente el efecto que estoy haciendo es parecido a lo que hace PC-Engine: mover los tiles del background dentro de la memoria de video para que parezca que hay un fondo más atrás.

En el caso de la NES, aunque también se podría hacer exactamente igual, es muy laborioso, y requeriría un mapper con WRAM, así que he optado a tirar por lo fácil con el mapper MMC3 y simplemente hago un cambio de bancos de gráficos al vuelo.

Imagen
Imagen
Que chulo te esta quedando.
Gran trabajo. Te ha quedado muy chulo.

Mah o meno, creo que he pillao el truco. Supongo que también es necesario que todo sea cuadriculado, por algunas esquinas que veo.
No hay limitaciones. Cuanto mas complejo sea el dibujo, mas te obliga a hacer animaciones para cada detalle.

Haciéndolo cuadriculado simplificas el número de cosas a animar porque todo encaja "matemáticamente", pero si te lo curras, puedes animar dibujos con mucha complejidad.

Es la premisa de siempre, cuanto mas trabaje el programador, menos trabaja el hardware.
Acabo de hacer un pequeño arreglo.

En el videojuego original de PC-Engine, los tiles del fondo realmente se mueven hacia la derecha, para dar sensación de que se mueven más lento por estar más lejos. Ahora lo he hecho similar, y la verdad es que queda mejor.

Imagen
Esta quedandote super chulo. No sé hasta donde llegarás con el proyecto pero me encanta ver juegos tan resultones en la NES. :)
@Diskover

Claro. No lo dije por no ser tiquismiquis, pero en el de antes me daba una sensación visual rara, y no sabía por qué. Con el parallax en sentido inverso queda mucho mejor, sí.
Impresionante se queda corto. Sigue así.
Diskover escribió:Acabo de hacer un pequeño arreglo.

En el videojuego original de PC-Engine, los tiles del fondo realmente se mueven hacia la derecha, para dar sensación de que se mueven las lento por estar más lejos. Ahora lo he hecho similar, y la verdad es que queda mejor.

Imagen


No me había dado ni cuenta, estoy espesito xD
El mapeado del nivel 4 por fin está completo.

¡Además, he podido añadir colisiones con el escenario!

@Diskover

Fetén.

Esto ya es una cosa del juego original, pero las sombras creo que no tendrían que desplazarse a la vez que el fondo delantero, sino junto con el fondo trasero, ya que es en el fondo trasero en donde están proyectadas.
gynion escribió:@Diskover

Fetén.

Esto ya es una cosa del juego original, pero las sombras creo que no tendrían que desplazarse a la vez que el fondo delantero, sino junto con el fondo trasero, ya que es en el fondo trasero en donde están proyectadas.

No te estoy entendiendo.

Las sombras se desplazan igual que el fondo trasero, al mismo tiempo y siguiendo el mismo dibujo. Son los mismos tiles animados pero con un tono de color distinto.

Imagen
@Diskover

Ya, tú te refieres a los tiles, pero el efecto visual que hace en acción la sombra (viendo el mosaico en conjunto) es que se desplaza junto a la capa delantera, no junto al fondo de ladrillos.

Pero ya te digo que es un detalle que viene del juego original. Debe ser ya algo más complicado de lograr.
gynion escribió:@Diskover

Ya, tú te refieres a los tiles, pero el efecto visual que hace en acción la sombra (viendo el mosaico en conjunto) es que se desplaza junto a la capa delantera, no junto al fondo de ladrillos.

Pero ya te digo que es un detalle que viene del juego original. Debe ser ya algo más complicado de lograr.

Mmmm, pues no sé, pero el efecto es correcto y no veo que se mueva junto a la capa delantera, por eso no estoy entendiendo

No hay otra forma de hacerlo.

Existe otro juego en NES que hace exactamente lo mismo.


Imagen
@Diskover

A ver, yo la veo moverse junto a la capa delantera si en vez de una sombra me imagino que es pintura negra sobre la capa de ladrillos, y es cuando no veo lógico ese movimiento.

De todas formas, el Magical Chase es una cuestión más bien de preferencias, o con la intención de añadir una idea al comportamiento de las sombras. Y además es un detalle sobre el juego original, porque tú ya lo has clavado. Simplemente, consideraron que la fuente de luz estaba en una posición diferente a la que me he imaginado yo o me gustaría a mí, y poco más.

Las sombras del juego del monje están ligeramente peor, para mi gusto.
Probando la pantalla de Tienda bonus. Una primera versión.

Imagen
Yo no conozco el juego original, pero en las imágenes parece que lo que te está quedando es una chulada. Si eres capaz de hacer eso yo creo que deberías plantearte hacer algun juego comercial que sea 100% tuyo después de esto (entiendo que partiendo de un juego existente, no podrás cobrar por el por mucho trabajo que tenga). Algo que puedas vender.
Yo nunca había hecho mucho caso a los nuevos desarrollos para consolas antiguas, pero desde que jugué el Good boy Galaxy de Gba y el Witch n Wiz de Nes me cambió bastante la perspectiva.
te felicito, me gusta el trabajo, soy muy ignorante en esto, te pregunto, como haces los gráficos? un programa te ayuda o vos construís los scrolls y sprites desde 0?
nes tiene 8 tiles por linea y pc engine 12?
cristus escribió:te felicito, me gusta el trabajo, soy muy ignorante en esto, te pregunto, como haces los gráficos? un programa te ayuda o vos construís los scrolls y sprites desde 0?
nes tiene 8 tiles por linea y pc engine 12?


Programo en C y compilo en CC65. La librería NESlib te da lo básico para empezar.

Para el scroll me ayudó de la liberia NESdoug, y un motor ya hecho para este fin que en algunos programas he tenido que modificar para ajustar a mis preferencias. Actualmente este motor solo me sirve en alguna pantalla. Para otras voy a tener que hacer uno yo mismo.

Para el tema gráfico, dibujo al pixel utilizando el programa NEXXT, que es una versión mejorada del NESst, ambos destinada para crear tiles y sprites para NES, así como backgrounds, metasprites, metatiles, y paletas de color.

Luego esto genera archivos CHR que lee la PPU de la NES, y también hace el código de estas obras gráficas tanto en asm como en C, dependiendo de tu preferencia a la hora de programar en NES.

Si, NES solo puede poner 8 tiles de 8x8 píxeles en línea u 8x16p

PC-Engine sin embargo puede poner hasta 16 sprites en una misma línea, y estos pueden a su vez ser de distintos tamaños (8x8p, 16x16p, etc...) con que imagínate la complejidad de este port
Diskover escribió:
cristus escribió:te felicito, me gusta el trabajo, soy muy ignorante en esto, te pregunto, como haces los gráficos? un programa te ayuda o vos construís los scrolls y sprites desde 0?
nes tiene 8 tiles por linea y pc engine 12?


Programo en C y compilo en CC65. La librería NESlib te da lo básico para empezar.

Para el scroll me ayudó de la liberia NESdoug, y un motor ya hecho para este fin que en algunos programas he tenido que modificar para ajustar a mis preferencias. Actualmente este motor solo me sirve en alguna pantalla. Para otras voy a tener que hacer uno yo mismo.

Para el tema gráfico, dibujo al pixel utilizando el programa NEXXT, que es una versión mejorada del NESst, ambos destinada para crear tiles y sprites para NES, así como backgrounds, metasprites, metatiles, y paletas de color.

Luego esto genera archivos CHR que lee la PPU de la NES, y también hace el código de estas obras gráficas tanto en asm como en C, dependiendo de tu preferencia a la hora de programar en NES.

Si, NES solo puede poner 8 tiles de 8x8 píxeles en línea u 8x16p

PC-Engine sin embargo puede poner hasta 16 sprites en una misma línea, y estos pueden a su vez ser de distintos tamaños (8x8p, 16x16p, etc...) con que imagínate la complejidad de este port

si me imagino, además ese juego parece usar bastante bien a pc engine, programaron para simular mas scrolls tambien
cristus escribió:
Diskover escribió:
cristus escribió:te felicito, me gusta el trabajo, soy muy ignorante en esto, te pregunto, como haces los gráficos? un programa te ayuda o vos construís los scrolls y sprites desde 0?
nes tiene 8 tiles por linea y pc engine 12?


Programo en C y compilo en CC65. La librería NESlib te da lo básico para empezar.

Para el scroll me ayudó de la liberia NESdoug, y un motor ya hecho para este fin que en algunos programas he tenido que modificar para ajustar a mis preferencias. Actualmente este motor solo me sirve en alguna pantalla. Para otras voy a tener que hacer uno yo mismo.

Para el tema gráfico, dibujo al pixel utilizando el programa NEXXT, que es una versión mejorada del NESst, ambos destinada para crear tiles y sprites para NES, así como backgrounds, metasprites, metatiles, y paletas de color.

Luego esto genera archivos CHR que lee la PPU de la NES, y también hace el código de estas obras gráficas tanto en asm como en C, dependiendo de tu preferencia a la hora de programar en NES.

Si, NES solo puede poner 8 tiles de 8x8 píxeles en línea u 8x16p

PC-Engine sin embargo puede poner hasta 16 sprites en una misma línea, y estos pueden a su vez ser de distintos tamaños (8x8p, 16x16p, etc...) con que imagínate la complejidad de este port

si me imagino, además ese juego parece usar bastante bien a pc engine, programaron para simular mas scrolls tambien

Utiliza buenos trucos que se ven también en muchos otros juegos de la consola, si; y la simulación de parallax scroll está conseguido.

Muchos de esos trucos se utilizan igualmente en NES, y si no fuese por la limitación de sprites en línea y color, nos acercaríamos sin pestañear
porque elegiste nes para trabajar en este port? es menos compleja que por ejemplo megadrive?
cristus escribió:porque elegiste nes para trabajar en este port? es menos compleja que por ejemplo megadrive?

Es mi consola de cabecera y además es donde estoy acostumbrado a hacer mis proyectos. Se donde están los limites

Tengo un hilo con todos ellos
me pase por tu hilo, veo que Tenes varios demos, el mmc es un chip que le da varias funciones al nes cierto?
cristus escribió:me pase por tu hilo, veo que Tenes varios demos, el mmc es un chip que le da varias funciones al nes cierto?

Los MMC son mapeadores de memoria que originalmente aparecieron para solucionar el problema de espacio de memoria limitada que tenía la NES para el tamaño de los videojuegos.

De esta forma, el primero de ellos, el mapeador CNROM, permitía cambiar hasta entre ocho bancos de memoria CHR (donde se almacenan los gráficos) saltándose el límite de uno solo y de esta forma poder tener juegos con mejor apariencia visual.

Pronto llegaron otros muchos mapeadores que aparte de ampliar la memoria CHR, también ampliaban el PRG (donde se almacena la lógica del los programas) y así se podía tener juegos mucho más largos y con un mejor diseño.

Además, aparecieron otros que añadían más canales de sonido, más RAM, o interruptores de línea (IRQ) para poder hacer efectos de parallax como es el caso del MMC3 y otros, incluso de terceras compañías

En Japón fue muy normal que compañías como Namco, Konami, o Sunsoft, tuviesen sus propios mapeadores; algunos parecidos entre sí, pero fuero de allí, Nintendo solo permitía los mapeadores que ellos mismos diseñaban, así que muchos juegos de estas compañías o se adaptaban a estos o directamente nunca salían de Japon
@Diskover sabia que super mario 3 tambien usa, creo que el mmc3? seguro para tener una rom mas grande, y tambien le permitía mejorar el scroll. master system mejora colores respecto a esta, pero creo que esta limitada para mover el scroll, ya pc engine tiene 1 solo pero creo que tiene como un buffer(una parte del scroll ya esta hecha pero no se muestra) para tener mas suavidad? tambien incorpora desplazamiento diagonal.
cristus escribió:@Diskover sabia que super mario 3 tambien usa, creo que el mmc3? seguro para tener una rom mas grande, y tambien le permitía mejorar el scroll. master system mejora colores respecto a esta, pero creo que esta limitada para mover el scroll, ya pc engine tiene 1 solo pero creo que tiene como un buffer(una parte del scroll ya esta hecha pero no se muestra) para tener mas suavidad? tambien incorpora desplazamiento diagonal.

Vayamos por orden:

Super Mario Bros. 3 fue el primer videojuego de NES en usar el mapper MMC3. Digamos que fue como una carta de presentación de este mapeador hacia el resto de desarrolladores en octubre de 1988.

Este videojuego hace uso intensivo de cambio de bancos CHR para las animaciones de fondos de pantalla, y tambien se ayuda del extra de 2Kb de RAM para el guardado de datos durante el juego, pero sin embargo, el IRQ a penas lo usa más que para mostrar el marcador inferior de datos (vidas, puntos, items...) mientras se mueve toda la pantalla.

Efectivamente, se ayuda también del MMC3 para tener un juego con una capacidad más grande, pero esto ya se podía hacer años atrás con otros mapeadores inferiores.

No, de ninguna manera el MMC3 ayuda en algo al scroll. Para el scroll, en todas sus configuraciones, se vale la NES por sí misma (también para las diagonales).

Master System no está limitada para mover scroll hasta donde yo sé. Puede hacer lo mismo que la NES.

PC-Engine lo mismo. Su forma de hacer scroll es similar a estas dos consolas pero con más holgura debido a la mayor capacidad de memoria de su sistema de vídeo.
@Diskover gracias por la explicación, como no tengo una base para poder entender ciertos aspectos técnicos esta idea me había quedado de ver creadores algunos de contenido en YouTube....
Diskover escribió:Master System no está limitada para mover scroll hasta donde yo sé. Puede hacer lo mismo que la NES.

Ya por precisar, la Master tiene un par de inconvenientes con el scroll respecto a la NES.
  • El primero, y más importante, que no puedes cambiar el valor y del scroll en medio del frame, ya que se cachea al inicio. Así que nada de marcadores gigantes, o trozos del escenario moviéndose en vertical mientras el resto permanece quieto.
  • El segundo, no tan importante, el tilemap solo tiene 32 columnas de ancho, y para hacer scroll y que no se vea el "seam", escondes la primera (la 0), dejando solo 31 columnas visibles. En la nes, depende como configures las nametables, puede tener 64 tiles de ancho, y puedes hacer algún efecto más complicado actualizando fondos en la parte no visible del nametable.
kusfo79 escribió:[*]El primero, y más importante, que no puedes cambiar el valor y del scroll en medio del frame, ya que se cachea al inicio. Así que nada de marcadores gigantes, o trozos del escenario moviéndose en vertical mientras el resto permanece quieto.


En la NES se solventa usando primitivamente lo del sprite zero que hace que se divida la pantalla en dos mitades. Puedes dejar una mitad quieta y la otra moverla en X o Y a tu antojo.

kusfo79 escribió:[*]El segundo, no tan importante, el tilemap solo tiene 32 columnas de ancho, y para hacer scroll y que no se vea el "seam", escondes la primera (la 0), dejando solo 31 columnas visibles. En la nes, depende como configures las nametables, puede tener 64 tiles de ancho, y puedes hacer algún efecto más complicado actualizando fondos en la parte no visible del nametable. [/list]


En NES lo de los 64 metatiles de ancho, que estan divididos en Nametables y se pueden configurar a antojo. Es lo que se usa para hacer construcción de scroll y que no se vea el truco, aunque en muchos juegos se ve por como está programado un motor de scroll si se usa una configuración de Nametables en concreto.

Es lo que me esta pasando con el scroll del primer nivel de Magical Chase: el motor que tengo dibuja en configuración mirroring vertical, pero yo estoy creando la pantalla gracias al mirroring horizontal, y es un desastre si aplico este motor de scroll, viéndose todas las costuras.
@Diskover
¿La Nes también tiene la opción de ocultar la primera columna para que no se ve el seam? La mega también lo tiene, pero casi no se usa, y me sonaba que alguna otra lo tiene.

Yo vi, en una demo, usar los 64 tiles de ancho para animar un fondo sin scroll. Las dos mitades contenían lo mismo, pero empezaba a cambiar cosas en la mitad no visible, y cuando tenía el fondo actualizado, scrolleaba una pantalla entera. Creo que solo conseguía 2-3 fps en el fondo, pero impresionaba bastante.
kusfo79 escribió:@Diskover
¿La Nes también tiene la opción de ocultar la primera columna para que no se ve el seam? La mega también lo tiene, pero casi no se usa, y me sonaba que alguna otra lo tiene.

Yo vi, en una demo, usar los 64 tiles de ancho para animar un fondo sin scroll. Las dos mitades contenían lo mismo, pero empezaba a cambiar cosas en la mitad no visible, y cuando tenía el fondo actualizado, scrolleaba una pantalla entera. Creo que solo conseguía 2-3 fps en el fondo, pero impresionaba bastante.

Si, tiene la opción de ocultar los 8 primeros pixeles de la izquierda de la pantalla, la columna entera. Se usa en muchos juegos para que no se vea la actualización de metatiles en motores de scroll concretos.

Muchos juegos de NES lo usan, sobre todo los que tiran de scroll multidireccional, como por ejemplo Kirby's Adventure o el propio Super Mario Bros. 3

La propia librería básica NESlib, para programar en C, ya trae esa función incluida. Basta con activarla y te borra la columna entera, dejando ver solo el color primario del background.

¿Que demo dices que era esa que usaba los 64 metatiles?

PD: digo metatiles, porque los tiles solo pueden medir 8x8 pixeles, y lo que actualiza la NES son metatiles de 16x16
A ver si la encuentro, la tenia bajada por que mire esto en el emulador, pero si la dejé en downloads igual ya no està. Però o la saqué de aquí, o twitter, o Pouet, o similar. Salían unas bolas haciendo formas geomètricas moviéndose sobre un fondo que estaba semianimado.
49 respuestas
Responder
Volver a Consolas clásicas