Curiosidades de la NES/Famicom [Cuidado 56k y Tarifas Datos]

@Diskover
Muy interesante!!

@Diskover la virgen... si no fuese por la espada giratoria, jacquio me habria puteado de lo lindo... de hecho lo hizo hasta que descubrí las bondades de ese ataque, que siempre descartaba porque no puedes evitar usarlo si atacas en el aire, agotando el ki en dos paradas.

Eso hace que el enemigo final sea un cachondeo, pero ojo, a cambio convierte en un infierno el tramo final hasta que llegas al final boss xD

Evitar atacar, medir saltos al milimetro en plataformas ridículamente pequeñas que encima se encuentran ocupadas por un enemigo que encima no puedes matar, acumulación de enemigos que esquivar...

Recuerdo que si o si había que usar ese movimiento en un punto porque si no era imposible, y puedo decirlo bien, que aprendí a pasarme esa última pantalla con la gorra, pero que con esa tremenda habilidad llegado a ese punto no me servía de nada.

Que grande el ninja gaiden, y que fino era el ninja gaiden 2, ahora ya sabemos por qué



edit:
@kusfo79 @Diskover Una forma de dar invencibilidad a un personaje mediante un item, por ejemplo, sería quitarle su caja de colisión, pero, ¿que pasa si cae por un vacío?, ¿puede hacerse algo directamente para que detecte que se ha caído?, o ya habría que ir a sustituir una caja de impacto por otra que solo reaccione ante el vacío cuando un objeto se cae por un hueco.

@Señor Ventura
Dependerá de como esté hecho el juego. Puede ser que la manera de morir al caer al vacío no tenga que ver con cajas de colisión (lo más probable) sino con salir por la parte inferior de la pantalla. Pero si lo quisieramos hacer con cajas de colisión, otra cosa que puedes hacer es dejar la caja, y cuando hay una colisión, comprobar contra que ha sido, y si tienes invencibilidad.

@Diskover
Muy bueno, no se me había ocurrido lo de calcular las colisiones a 30Hz o colisiones punto-cuadrado, raya-cuadrado (aunque estas últimas no se si ganan mucho, ya que creo que se calculan igual que las cuadrado-cuadrado).

kusfo79 escribió:@Señor Ventura
Dependerá de como esté hecho el juego. Puede ser que la manera de morir al caer al vacío no tenga que ver con cajas de colisión (lo más probable) sino con salir por la parte inferior de la pantalla. Pero si lo quisieramos hacer con cajas de colisión, otra cosa que puedes hacer es dejar la caja, y cuando hay una colisión, comprobar contra que ha sido, y si tienes invencibilidad.

¿Como lo harías?, ¿compruebas las coordenadas de la tabla de atributos?.

SI te refieres a lo de la salida de la pantalla, compruebas si la entidad player, su y es mayor que el margen inferior del scroll, por ejemplo (así a bote pronto). En juegos que si que hay mucho scroll vertical tambien, puedes tener una logica para que en ciertos sitios si que caer haga que el juego scrollee hacia abajo, y en otros no, y provoquen la muerte.

Muy buen post, parece una chorrada pero se antoja crucial a la hora de diseñar la jugabilidad y optimizar recursos, algunas fórmulas son muy ingeniosas. Es algo que se intuye pero explicado así refleja muy bien su lógica y deja claro que no se pueden comparar alegramente los juegos, aún siendo del mismo género o a priori parecidos.

Señor Ventura escribió: @kusfo79 @Diskover Una forma de dar invencibilidad a un personaje mediante un item, por ejemplo, sería quitarle su caja de colisión, pero, ¿que pasa si cae por un vacío?, ¿puede hacerse algo directamente para que detecte que se ha caído?, o ya habría que ir a sustituir una caja de impacto por otra que solo reaccione ante el vacío cuando un objeto se cae por un hueco.

Hay muchos juegos que determinan que si un sprite X se va más allá de las coordenadas del límite de la pantalla, automáticamente muere.

Diskover escribió:

Señor Ventura escribió: @kusfo79 @Diskover Una forma de dar invencibilidad a un personaje mediante un item, por ejemplo, sería quitarle su caja de colisión, pero, ¿que pasa si cae por un vacío?, ¿puede hacerse algo directamente para que detecte que se ha caído?, o ya habría que ir a sustituir una caja de impacto por otra que solo reaccione ante el vacío cuando un objeto se cae por un hueco.

Hay muchos juegos que determinan que si un sprite X se va más allá de las coordenadas del límite de la pantalla, automáticamente muere.

Luego, comparas la coordenada del sprite con la de la pantalla, y en el sprite la tienes en su atributo, ¿como rescatas ese dato?.

@Señor Ventura ¿Que quieres decir? Normalmente se tiene en una sección de la memoria los atributos del metasprite (pocas veces se usa un sprite por si solo) dónde se incluye la posición X e Y. Si la posición Y está por debajo de un valor predeterminado (el borde inferior de la pantalla) el personaje muere.

MasterDan escribió:@Señor Ventura ¿Que quieres decir? Normalmente se tiene en una sección de la memoria los atributos del metasprite (pocas veces se usa un sprite por si solo) dónde se incluye la posición X e Y. Si la posición Y está por debajo de un valor predeterminado (el borde inferior de la pantalla) el personaje muere.

Exacto. Esa sección dela memoria es la tabla oam, en ella se almacenan las coordemadas de todos los sprites contemplados en ella, así que es fácil determinar cuando superas el límite de pantalla por el que eliminas procesos, o matas al personaje.

La cuestión es que no se como recuperas ese dato de vuelta para hacer la comparación, y así obtener un resultado.

@Señor Ventura

Ese dato lo has de tener en RAM, y encargarte de ir actualizando la OAM cada frame con los valores de las nuevas posiciones.

kusfo79 escribió:Ese dato lo has de tener en RAM, y encargarte de ir actualizando la OAM cada frame con los valores de las nuevas posiciones.

@Señor Ventura
Básicamente. En la tabla OAM están los atributos de los sprites, en cada vblank se han de actualizar con lo que tienes almacenado en la memoria. No hace falta leer la OAM en ningún momento.

Señor Ventura escribió:

Diskover escribió:

Señor Ventura escribió: @kusfo79 @Diskover Una forma de dar invencibilidad a un personaje mediante un item, por ejemplo, sería quitarle su caja de colisión, pero, ¿que pasa si cae por un vacío?, ¿puede hacerse algo directamente para que detecte que se ha caído?, o ya habría que ir a sustituir una caja de impacto por otra que solo reaccione ante el vacío cuando un objeto se cae por un hueco.

Hay muchos juegos que determinan que si un sprite X se va más allá de las coordenadas del límite de la pantalla, automáticamente muere.

Luego, comparas la coordenada del sprite con la de la pantalla, y en el sprite la tienes en su atributo, ¿como rescatas ese dato?.

No es tan complejo.

El sprite del player (por ejemplo) se mueve en coordenadas X e Y (variable que has diseñado para su cometido previamente) y esto en todo momento lo sabe la maquina porque así se lo has explicado.

Para un precipicio en la NES, a grosso modo, le dices que cuando supere la coordenada X del 224 pixel, que tu player automaticamente muera. Eh ya.

Una duda...
Ya que el mando de super Nintendo tiene los mismos patrones y concesiones que el de Nes...
¿Podrían habilitar todos los botones en un juego (hack o nuevo)de Nes?
Ejemplo...
El primer mando de megadrive tiene 4 botones y después sacaron el de 8 y empezaron a sacar juegos que soportaban todos los botones con funciones independientes.

@Diskover desde la absoluta ignorancia técnica, esto podría estar en una "NES" un poco rebajado ?.

@Creation Muy rebajado diría yo. Se le tendrían que quitar todos los planos de scroll, reducir el número de colores de los personajes, puede que la interfaz se tuviera que cambiar y reducir el número de tiles diferentes para los escenarios.

Las oficinas de NOA en 1990 y un poco de la divertida cadena de montaje de NES

Creation escribió:@Diskover desde la absoluta ignorancia técnica, esto podría estar en una "NES" un poco rebajado ?.

Rebajado si.

Por ejemplo, tendríamos que quitar los distintos planos de scroll, y en algún punto igual rebajar colores.

Puede que me anime a hacer una demostración para probar como se veria, como aquella vez con el Shadow of the Beast

Nuevo video de Displaced Gamers dónde se explica como funcionan los drops y la aleatoriedad en el primer Legend of Zelda:

Para mi el mejor juego de nes

Y aparecemos con novedades curiosas que pueden tambalear el mundo de la scene de NES.

El usuario de Twitter, FrankenGFX, famoso por sus trabajos gráficos para varios juegos homebrew de NES, a dado a conocer que está trabajando desde abril de 2020 en un nuevo juego de NES como animador.

La peculiaridad está en que este nuevo juego, desarrollado por entre diez personas aglutinados en un equipo que se hace llamar Something Nerdy Studios LLC, es que está desarrollándose bajo un nuevo mapper llamado MXM-0.

Este MXM-0 pretende romper las barreras conocidas hasta ahora por otros mappers, y quiere dar otra vuelta de rosca para sacar aun más partido a este limitado hardware. Entre las características que por ahora se han filtrado sobre este mapper, esta:

- Un contador de scanlines (IRQ) mucho más robusto que lo visto en los mappers MMC3/MMC5 y FME7. Esta herramienta es la que permite hacer scroll con la pantalla partida en varios trozos y moviéndose a distinta velocidad.

- Acceso total e inmediato a todos los tiles de la memoria del juego sin necesidad de hacer mapeos de 256 en 256. Ahora si tienes por ejemplo 8 megas de gráficos, puedes tener a tu disposición 32.756 tiles de golpe y porrazo. Esto en teoría ya lo podía hacer el MMC5 en su día, pero nunca se usó.

- El espacio de la memoria deja de ser un problema. Se da a entender que sobrepasan y por mucho los límites vistos hasta ahora de juegos de NES de 1MB.

- Atributos de color para los background (fondos de pantalla) de 8x1. Acordaros que el límite estaba en 16x16, y que el MMC5 como mucho podía llegar a hacer 8x8.

El twitt de FrankenGFX ha dejado esta bonita animación en la que esta trabajando.



Podemos ver un sprite formado por distintos tiles que a priori parece superar el limite de colores de 3+1 que puede dar la NES para este tipo de formas. No obstante, podíamos estar ante un juego visual al solapar dos sprites distintos uno encima de otro y con distintas paletas, para dar sensación de más colores como ya se hacía en su día con algunos juegos de NES (Megaman, SMB2, Duck Tales, etc...).

No obstante si que podemos apreciar una suavidad inusual en los frames de la animación, posiblemente dado al sacar partido de la no limitación de uso de tiles al vuelo, así como del espacio requerido.

@Diskover por fín la nes va a demostrar que es el unico hardware capaz de merecer ser comparado con una neo geo en cuanto a funcionamiento

No entiendo muy bien que aporta como algo nuevo y mejor la interrupción de scanlines si va a hacer lo mismo que el mmc5, ¿o es que puede hacer algo mas?.

Lo que si me parece un salto es que pueda mostrar 3 colores cada 8 pixels, línea a línea... a lo mejor esa es la mejora de la interrupción de scanlines, que no solo puedes desplazar el plano en un scanline, sino cambiar su atributo de color. Que importante es esto.

Y juegos de 64 megas, con animaciones imposibles de fondos y de sprites para otros sistemas, ¡pero no para la nes!.

Viva la ninten geo entertainment system

Señor Ventura escribió:@Diskover por fín la nes va a demostrar que es el unico hardware capaz de merecer ser comparado con una neo geo en cuanto a funcionamiento

No entiendo muy bien que aporta como algo nuevo y mejor la interrupción de scanlines si va a hacer lo mismo que el mmc5, ¿o es que puede hacer algo mas?.

Lo que si me parece un salto es que pueda mostrar 3 colores cada 8 pixels, línea a línea... a lo mejor esa es la mejora de la interrupción de scanlines, que no solo puedes desplazar el plano en un scanline, sino cambiar su atributo de color. Que importante es esto.

Y juegos de 64 megas, con animaciones imposibles de fondos y de sprites para otros sistemas, ¡pero no para la nes!.

Viva la ninten geo entertainment system

Ja, ja, ja, ja... Pues como no han soltado aun toda la información, podríamos divagar durante horas, la verdad.

Para mi esto es como un MMC5 pero al cuadrado, ya solo por lo de atributos de color en fondos de 8x1... por esto ya es un buen salto para hacer cosas visuales mucho más bonitas, degradados, etc...

Lo de no tener límites en la memoria CHR, lo mismo te pueden meter animaciones bastante trabajadas. Ya con el MMC5 se han hecho cosas hackeando juegos, como este parche de The Legend of Zelda llamado Zelda - The Legend of Link, que le metía unas imágenes animadas de la leche y otras cosas.



Lo de un mejor contador de scanlines... pues igual te permite hacer partición de pantalla del tamaño pixel, o partición de pantalla en vertical, que algo ya conseguía hacer MMC5, pero limitado.

Lo de los tiles a 8x1 de color es interesante y se asemeja a los gráficos de MSX. Lo que estaría bien es que se pudiera tener más colores para los sprites (3 + transparencia limita mucho) o en su defecto más paletas posibles.

El tema del contador de scanlines seguramente será más eficiente o proporcionará más información, dudo que sirva para partir la pantalla verticalmente ya que no daría tiempo para el código para ejecutarse en el intervalo de un píxel al del lado (para estos efectos la NES usaba tiles animados y las máquinas de 16 bits capas de fondos).

MasterDan escribió:Lo de los tiles a 8x1 de color es interesante y se asemeja a los gráficos de MSX. Lo que estaría bien es que se pudiera tener más colores para los sprites (3 + transparencia limita mucho) o en su defecto más paletas posibles.

El tema del contador de scanlines seguramente será más eficiente o proporcionará más información, dudo que sirva para partir la pantalla verticalmente ya que no daría tiempo para el código para ejecutarse en el intervalo de un píxel al del lado (para estos efectos la NES usaba tiles animados y las máquinas de 16 bits capas de fondos).

Lo dicho, sobre todo el tema de la paleta tan limitada.

Nos podríamos hacer una idea de lo que sería poder disponer de una paleta más grande observando lo que se hacía con GBC

EDITO:

Sobre el poder usar tiles al vuelo sin limitarnos a 256 por pantalla, se demuestra en este demo presumiblemente programado por Dominic Muller, integrante de Something Nerdy Studios



Como podemos ver, varias figuras forman el background. Ya solo el cubo nos hubiese ocupado los 256 tiles del CHR.

Hola a todos. La verdad es que ha sido una semana bastante excitante.

Hoy vamos a seguir hablando del nuevo mapper MXM-0 que ha desarrollado Something Nerdy Studios LLC para nuestra NES.

Tal y como comentamos hace unos días, el MXM-0 es capaz de (por ahora) hacer todo esto:

- Un contador de scanlines (IRQ) mucho más robusto que lo visto en los mappers MMC3/MMC5 y FME7. Esta herramienta es la que permite hacer scroll con la pantalla partida en varios trozos y moviéndose a distinta velocidad.

- Acceso total e inmediato a todos los tiles de la memoria del juego sin necesidad de hacer mapeos de 256 en 256. Ahora si tienes por ejemplo 8 megas de gráficos, puedes tener a tu disposición 32.756 tiles de golpe y porrazo. Esto en teoría ya lo podía hacer el MMC5 en su día, pero nunca se usó.

- El espacio de la memoria deja de ser un problema. Se da a entender que sobrepasan y por mucho los límites vistos hasta ahora de juegos de NES de 1MB.

- Atributos de color para los background (fondos de pantalla) de 8x1. Acordaros que el límite estaba en 16x16, y que el MMC5 como mucho podía llegar a hacer 8x8.

A continuación, vamos a seguir añadiendo nuevas cosas:

- El primer juego que llevará este mapper, se llamará The Inversion Project, un videojuego de Acción-RPG, con toques de ciencia ficción, donde deberemos controlar a distintos personajes en un planeta alienígena, y que pretende durar como mínimo 15 horas. Aquí tenéis un enlace a la web para que podeís ver una galería de imágenes sobre el juego: https://somethingnerdy.com/gallery/





- ¡El equipo de desarrollo promete que este videojuego sera una ROM del tamaño similar al de un CD! Si, lo habéis oído bien. Con esto se resuelve la duda del otro día cuando decían que sobrepasarían por mucho el tamaño normal de una ROM de NES. Técnicamente es como si la NES derrepente tuviera un dispositivo CD-ROM para leer juegos, tal como hacía Turbografx o Sega Mega CD.

- Este mapper será capaz de reproducir FMV. Aun no se ha hablado del tipo de compresión que usará, pero si que han mostrado una demo donde podemos ver una escena del videojuego Chrono Trigger de SNES, que utilizaba distintos efectos en Modo-7, llevado ahora a video FMV y reproducido por una NES.











Con esto despejamos las dudas que había cuando se hablaba del acceso total a todos los tiles disponibles en el CHR. Os podeís hacer una buena idea de lo que permite esta ventaja.

- Sobre el cacareado uso del atributo de color de 8x1 pixel, bueno... han enseñado algo:



Y también en video para que veamos como se ve en una pantalla CRT:



- También aseguran que el uso del atributo de color 8x1, no dará ningún problema a la hora de hacer scroll, incluso si este es multidireccional, lo que hace sospechar que este mapper también tendrá una extensión de RAM como en su día ya aplicaban otros mapper. ¿De cuanta RAM hablamos? Ni idea.

- Los más avispados habréis observado de que este ultimo video se esta ejecutando en un flashcard N8 Pro. Puede que se pretenda compatibilidad de algún modo (limitado, aclaran) con este flashcard, pero aclaran que su placa para el videojuego The Inversion Project, dependerá de otra distinta basada en INL, y no en Verilog como la de Krikzz. Vamos, que este mapper no es un FPGA.



- Por ultimo, falta saber el tema del sonido. Seguramente añadan algún tipo de canal o canales extras que mejoren el PCM propio de la NES.

Puede que este post os interese: @MasterDan @Señor Ventura, @kusfo79, @aranya, @SuperPadLand

Madre mia @Diskover ¿Pero qué maravilla es esta?. A mí más que interesarme me ilusiona una barbaridad. Yo siempre soñé con FMV en 8 bits y con lector de CDs para la NES o MS con el fin de hacer juegos sin límite de espacio.

Este mapper nuevo es la leche. A mí me interesa mucho que no pierda la esencia NES, y creo que van por muy buen camino.
Ostras, yo este juego, si va prometiendo así, creo que me lo compraré.

La scene de la NES es seguramente hoy, el arma más fuerte que tenemos los que defendemos a capa y espada esta consola como la mejor de la historia. Es que hasta en la scene, esta consola NO tiene rival.

Gracias por avisarme!.

@Diskover Gracias!
Por lo que dicen hay tema de bankswitching, por lo que creo que va a ser es que el chip permite realizar un cambio de banco de memoria de gráficos durante el hblank, para poder mostrar una linea diferente (o con cambio de atributos para realizar lo del 8x1). Esto choca un poco con el tema de tener acceso a todos los tiles gráficos a la vez, por lo que creo que seguramente permita tener tamaños de banco de un tile.
Esto significaría que se tendrá un límite de 256 tiles por línea (límite absurdo ya que sólo caben 32 tiles por línea, por lo que sobran).

La verdad es que es impresionante, aunque el tema de mostrar fmv me da igual. La NES no tiene paleta adecuada para eso y se ve peor que el MegaCD (La caída de Lavos por su banda está muy bien, supongo que por los pocos colores que usa en comparación).

Los escenarios del juego que están sacando son preciosos, pero los sprites personalmente no me gustan.

Lo que me da rabia es que mi Everdrive N8 no es el PRO, y no estoy por comprarme uno nuevo cuando este me va perfectamente. Espero que saquen una versión LITE del chip como comentan, para la gente que no actualiza el hardware cuando a Krikzz decide sacar un nuevo modelo (Ya me ha pasado con este y con el SD2SNES ).

@Diskover gracias! Yo ya les he preguntado como comprarlo, me han dicho que en unos meses abren crowfunding ahora mis dudas van en si podré jugarlo bien en una PAL50hz o si va siendo hora que me plantee pillar una NES NTSC Se coronarían si sacasen el primer juego con selector de hz en una 8bits jajaja.

También lo van a sacar para PC por cierto, para quien quiera acceder al juego legalmente sin tener que comprarse una consola de hace 30 años y un cartucho de 100€

SuperPadLand escribió:@Diskover gracias! Yo ya les he preguntado como comprarlo, me han dicho que en unos meses abren crowfunding ahora mis dudas van en si podré jugarlo bien en una PAL50hz o si va siendo hora que me plantee pillar una NES NTSC Se coronarían si sacasen el primer juego con selector de hz en una 8bits jajaja.

Olvidate de una NES NTSC, píllate una Famicom AV (y un adaptador para cartuchos de 72 pins) o una AVS de RetroUSB. Los canales extra de sonido y compatibilidad con el FDS se agradecen.

aranya escribió:La scene de la NES es seguramente hoy, el arma más fuerte que tenemos los que defendemos a capa y espada esta consola como la mejor de la historia. Es que hasta en la scene, esta consola NO tiene rival.

Sabia que te gustaría.

Desde luego, junto con la de ZX Spectrum y otros microordenadores, la scene homebrew de NES es la más nutrida muy por delante de otras.

MasterDan escribió:@Diskover Por lo que dicen hay tema de bankswitching, por lo que creo que va a ser es que el chip permite realizar un cambio de banco de memoria de gráficos durante el hblank, para poder mostrar una linea diferente (o con cambio de atributos para realizar lo del 8x1). Esto choca un poco con el tema de tener acceso a todos los tiles gráficos a la vez, por lo que creo que seguramente permita tener tamaños de banco de un tile.
Esto significaría que se tendrá un límite de 256 tiles por línea (límite absurdo ya que sólo caben 32 tiles por línea, por lo que sobran).

La verdad es que es impresionante, aunque el tema de mostrar fmv me da igual. La NES no tiene paleta adecuada para eso y se ve peor que el MegaCD (La caída de Lavos por su banda está muy bien, supongo que por los pocos colores que usa en comparación).

Los escenarios del juego que están sacando son preciosos, pero los sprites personalmente no me gustan.

El tema del FMV la verdad es que da un poco igual, aunque en ciertas situaciones donde no haya muchos colores, o sea un entorno controlado, puede que nos sorprenda.

Yo lo veo más bien como si estuviésemos viendo una Game Boy Color en formato sobremesa y a lo bestia. Lo del tamaño de las ROM con cantidades absurdas va a dar muchísimo juego ya no solo para ver animaciones suaves y gráficos más trabajados, si no también para jugar con efectos seudo-parallax como ya veíamos hacer en PC-Engine/Turbografx.

SuperPadLand escribió:@Diskover gracias! Yo ya les he preguntado como comprarlo, me han dicho que en unos meses abren crowfunding ahora mis dudas van en si podré jugarlo bien en una PAL50hz o si va siendo hora que me plantee pillar una NES NTSC Se coronarían si sacasen el primer juego con selector de hz en una 8bits jajaja.

También lo van a sacar para PC por cierto, para quien quiera acceder al juego legalmente sin tener que comprarse una consola de hace 30 años y un cartucho de 100€

Actualmente el homebrew que se saca a la venta viene integrado un chip de protección de región reprogramable mediante el botón reset para que los juegos valgan tanto en formato PAL como en NTSC.

Otra cosa es que arreglen las velocidades para los distintos sistemas, que si bien se puede hacer fácilmente mediante programación (la libreria básica de Shiru para escribir en C, por ejemplo, tiene un detector de región útil para estas cosas), no siempre lo hacen y acabamos viendo juegos con extraños comportamientos en PAL como ocurre con Trophy.

@Diskover este nuevo mapper MXM-0 podría mover con soltura el Mario Bros que comentamos o sigue siendo limitado en algún aspecto ?

MasterDan escribió:

SuperPadLand escribió:@Diskover gracias! Yo ya les he preguntado como comprarlo, me han dicho que en unos meses abren crowfunding ahora mis dudas van en si podré jugarlo bien en una PAL50hz o si va siendo hora que me plantee pillar una NES NTSC Se coronarían si sacasen el primer juego con selector de hz en una 8bits jajaja.

Olvidate de una NES NTSC, píllate una Famicom AV (y un adaptador para cartuchos de 72 pins) o una AVS de RetroUSB. Los canales extra de sonido y compatibilidad con el FDS se agradecen.

Pues mira estuve el mes pasado mirando que consola incorporar (al final fue una Xbox clásica) y dudaba entre Xbox, Saturn, GameCube y una NES/FAMICON, pero las NES occidentales no me gustan por el carro de los juegos, me dio mucho la lata arreglar el PAL para que pillase bien los juegos a la primera y aun así ahora tengo que hacer bastante fuerza hacia abajo para que quede enganchado, es decir ahora los pilla a la primera, pero el juego no se sujeta a la primera.

Descartadas esas miré las Famicom, estéticamente me molan con ese rojiblanco, pero me tira para atrás los mandos integrados porque si se rompen yo no sé arreglar estas cosas y no puedo cambiar el mando por otro que compre. Entonces vi que hay los modelos 101 este corrige todo lo anterior, pero el modelo americano sólo soporta RF así que necesitaría uno japo para usar RCA o encontrar un modelo con mod RGB. E interesado estoy, pero es muy difícil encontrar exactamente eso a la venta: 101+mod.

La AVS es FPGA o un clon bien hecho estilo NASA? También pensé en buscarme una clon de la época que sea NTSC, pero sólo encuentro PAL.

Creation escribió:@Diskover este nuevo mapper MXM-0 podría mover con soltura el Mario Bros que comentamos o sigue siendo limitado en algún aspecto ?

Moverlo lo puede mover una NES sin problema.

El mayor "pero" sigue siendo el scroll-parallax que tiene. Hay demasiados planos, y la NES solo puede mover un fondo (background), y luego poner sprites por delante o por detrás del fondo. Aquí, además, hay que entender que el fondo tiene un color "más al fondo" que se comparte de entre las cuatro paletas que configuremos. De esta forma, cuando dibujamos un fondo, disponemos de cuatro paletas de 3+1 color. Ese 1 color es uno a elegir que se comparte entre todas ellas y que tiene la prioridad más baja. De esta forma, cuando ponemos un sprite, este puede poner prioridad alta para que le veamos por encima del fondo dibujado, o prioridad baja, para verle por detras del fondo, PERO NUNCA POR DETRÁS DE ESE COLOR "MÁS AL FONDO".

Para que me entiendas:



Una vez entendido como funciona esto, podrás ver donde radica el problema para que podamos ver "tal cual" lo que expones en ese tweet en una NES real.

Se pueden hacer trucos gráficos que asemejen lo que vemos ahí. Por ejemplo, gracias a los contadores de interrupción de pantalla (IRQ) que hacen algunos mappers como el MMC3 de Nintendo, o este MXM-0 nuevo, podemos trocear la pantalla horizontalmente en distintas partes de distintos tamaños para que se muevan a distinta velocidad y que den la sensación de "más planos".

El problema de este truco es que a la vista igual le engañas durante un tiempo, pero acabaras observando que no hay luego ningún objeto que pase por encima de los planos "más alejados" y ya todo se iría al traste. Se puede en este caso usar sprites que simulen ser parte del fondo y situarlos en una coordenada que de sensación de profundidad cuando se hace scroll.

Esto en NES es inviable hasta cierto punto porque solo podemos poner 8 sprites en linea en pantalla, y no estamos para derrochar. En cambio, PC-Engine/Turbografx tenía el mismo problema que la NES a la hora de hacer fondos de pantalla, pero como disponia de infinidad de sprites para mostrar en linea en pantalla, se podian permitir hacer estos derroches y sacar juegos que simulaban tener distintos planos de scroll parallax.

Tambien existe otro truco que es reservar un espacio de los 256 tiles disponibles en el CHR de la NES, para moverlos en la memoria de video de la PPU, y que una vez puestos en el backgrund, simulen doble plano. Se vio en juegos como Sword Master.



Las montañas se mueven a distinta velocidad que los arboles, porque se estan moviendo dentro de la memoria de video de la PPU y simulan tener más planos.

En este video se explica bien como funciona el background y los scrolls en la NES.




Con el MXM-0 ahora podemos hacer muchas virguerias de estas gracias a que tenemos casi un espacio "infinito" para derrochar tiles y moverlos en la memoria de video a gusto, pero nunca conseguiríamos hacer algo exactamente igual a lo que muestras, si no más bien algo parecido y muy cercano.

¿Como? Pues veamos... podríamos primero hacer el HUB, pero ninguna nube podría pasar por debajo a no ser que las dibujáramos como sprites, y nunca superando 8 tiles en linea con lo cual nos quedaría unas nubes pequeñas.

Luego podríamos trocear el cielo en 4 o 5 planos moviéndose a distinta velocidad que nos daría un resultado muy parecido.

Los arbustos con ojos... complicado. Hay bloques de piedra que forman parte del plano de fondo y tuberías... habría o que colocarlos en un punto del fondo que nunca coincidiese con los entornos de plataformas, o eliminarlos.

Con las flores podríamos hacer el truco de moverlas en la memoria de vídeo para dar sensación de profundidad.

Los arboles habría que eliminarlos. A no ser que los quieras construir con sprites, con lo cual tendríamos el problema de la limitación por línea.

Y luego ya queda el suelo, que es normal y corriente.

SuperPadLand escribió:Pues mira estuve el mes pasado mirando que consola incorporar (al final fue una Xbox clásica) y dudaba entre Xbox, Saturn, GameCube y una NES/FAMICON, pero las NES occidentales no me gustan por el carro de los juegos, me dio mucho la lata arreglar el PAL para que pillase bien los juegos a la primera y aun así ahora tengo que hacer bastante fuerza hacia abajo para que quede enganchado, es decir ahora los pilla a la primera, pero el juego no se sujeta a la primera.

Descartadas esas miré las Famicom, estéticamente me molan con ese rojiblanco, pero me tira para atrás los mandos integrados porque si se rompen yo no sé arreglar estas cosas y no puedo cambiar el mando por otro que compre. Entonces vi que hay los modelos 101 este corrige todo lo anterior, pero el modelo americano sólo soporta RF así que necesitaría uno japo para usar RCA o encontrar un modelo con mod RGB. E interesado estoy, pero es muy difícil encontrar exactamente eso a la venta: 101+mod.

La AVS es FPGA o un clon bien hecho estilo NASA? También pensé en buscarme una clon de la época que sea NTSC, pero sólo encuentro PAL.

Existen NES top loader con el multiout de Nintendo y compatibilidad RCA, pero son muy pocas y muy caras, la Famicom AV es mucho más asequible y tiene los canales extra de audio.

En cuanto a la AVS es una FPGA con compatibilidad tanto con famicom como con NES (Americana y europeas). Es mucho más barata que las NES de Analogue (lo que tiene estar hecha de plástico en vez de metal), tiene conector para cuatro mandos también, pero por contra sólo tiene salida HDMI y resolución de 720p en vez de 1080.
También tenía un scoreboard online para publicar tus puntuaciones más altas, pero habiendo desaparecido el foro de Nintendoage que era dónde se subían no se si esa opción aun funciona.

@MasterDan pues la cosa está entre una Famicom y una AVS pues. La analogue muy cara como bien dices y además siempre que entro en su web todo está agotado así que ya no pierdo el tiempo en mirar.

@Diskover se agradece la explicación
simular a través de -trucos- los limitados efectos scroll-parallax, debido al sistema.
( parece bastante mejor el 2º método empleado en el Sword Master )

espero que este MXM-0 también explore este efecto tan limitado y poco usado en el sistema de la Nintendo 8-Bits.

De hecho, puedes animar el plano de nes simulando ser 8 o 9 planos reales.

Maldita sea, puedes hacer lo que quieras con esa máquina, que hardware tan inigualable xD

Creation escribió:@Diskover se agradece la explicación
simular a través de -trucos- los limitados efectos scroll-parallax, debido al sistema.
( parece bastante mejor el 2º método empleado en el Sword Master )

espero que este MXM-0 también explore este efecto tan limitado y poco usado en el sistema de la Nintendo 8-Bits.

Como ya te he dicho, PC-Engine/Turbografx, que para mi es la evolución lógica de lo que tenía que haber sido una NES 2, hace uso de todos estos trucos ampliamente. Te puedes hacer una idea de lo que se puede llegar a hacer si no fuera por las otras limitaciones técnicas.

Señor Ventura escribió:De hecho, puedes animar el plano de nes simulando ser 8 o 9 planos reales.

Maldita sea, puedes hacer lo que quieras con esa máquina, que hardware tan inigualable xD

Poder toquetear la memoria de video a gusto es lo que tiene, como si cascas una animación por FMV completa en el fondo. Cosas que ya se veían en Mega CD o Playstation.

@Diskover

Muchas grácias Diskover!! muy, muy, muy interesante!

La verdad es que el aspecto es genial! a ver que sale con el juego este!

@jekuthiel Buenas, bienvenido y gracias por ofrecernos respuestas. Yo tengo curiosidad en cómo se va a poder acceder a esa gran cantidad de tiles. Por norma general la NES sólo puede acceder a 256 tiles y 256 sprites y por ello otros juegos usan bank switching para poder cambiar un conjunto de sprites/tiles/código por otro distinto.

¿Cómo lo hace el chip que estáis creando? Mi teoría es que puede hacer bank switching por sprite/tile individual durante el hblank para poder mostrar esas imágenes tan complejas para la máquina.

Otra duda que me asalta es que por lo que se ve habéis podido reducir la tabla de atributos de tiles de unos 16x16 a 8x1. ¿Se podría hacer algo similar con los sprites?

Saludos y gracias

Mis disculpas de antemano. A pesar de que estudié español en la universidad durante 2 años, ha pasado mucho tiempo desde que lo utilicé. Pude hablar español en España (Madrid, Segovia, Toledo y algunas otras ciudades) en 2017 cuando mi esposa y yo visitamos Europa, pero usar jerga técnica en español no es algo que haya aprendido a hacer. Entonces, mi mensaje inicial en este foro fue traducido del inglés al español por alguien que probablemente contrate por sus habilidades de traductor. Google Translate me está traduciendo el mensaje que estoy escribiendo en este momento. Tiempos maravillosos en los que estamos viviendo, ¿no?

MasterDan escribió:@jekuthiel Buenas, bienvenido y gracias por ofrecernos respuestas. Yo tengo curiosidad en cómo se va a poder acceder a esa gran cantidad de tiles. Por norma general la NES sólo puede acceder a 256 tiles y 256 sprites y por ello otros juegos usan bank switching para poder cambiar un conjunto de sprites/tiles/código por otro distinto.

¿Cómo lo hace el chip que estáis creando? Mi teoría es que puede hacer bank switching por sprite/tile individual durante el hblank para poder mostrar esas imágenes tan complejas para la máquina.

Bueno, esa es una buena suposición. Pero no del todo correcto. De hecho, lo que hacemos es usar 2 bytes en lugar de 1 byte para almacenar la información del índice del mosaico. Por lo tanto, cuando la PPU está obteniendo datos para mosaicos uno por uno en el medio de una línea de exploración, MXM-0 puede observar para qué mosaico está adquiriendo información y cambiar automáticamente los bancos al correcto unos nanosegundos antes de que el PPU lo necesite la información. Requiere una sincronización muy precisa, pero la hemos perfeccionado. No es necesario hacerlo en hblank. Se cambiará al banco correcto, cada ficha, en todo el marco. Esto es lo que permite que haya "entropía completa"; Es decir, 960 mosaicos únicos para cada fotograma renderizado.

Es muy importante que se debata sobre TILES. La forma en que el PPU obtiene datos para los sprites es completamente diferente, porque el OAM se almacena en la RAM interna del PPU, a la que no tenemos acceso excepto a través del bus de datos muy lento entre la CPU y el PPU. Así que este truco no se puede realizar con sprites. Sin embargo, eso es básicamente irrelevante, ya que solo hay 64 sprites posibles para un fotograma renderizado específico en primer lugar. Con un buen diseño u organización de datos, no hay necesidad de hacer nada sofisticado en el mapeador de sprites.

MasterDan escribió:Otra duda que me asalta es que por lo que se ve habéis podido reducir la tabla de atributos de tiles de unos 16x16 a 8x1. ¿Se podría hacer algo similar con los sprites?

Saludos y gracias

Como acabo de decir en mi párrafo anterior, esta reducción de la granularidad del color no se puede realizar para los sprites. Sin embargo, hay un truco bajo la manga que PUEDE hacerse con los sprites. De hecho, es mi mayor contribución al proyecto. He encontrado una manera de expandir la cantidad de colores disponibles para sprites de 54 a 400. Sí, lo leíste correctamente. Sin embargo, depende mucho de que el televisor sea NTSC de 60Hz. PAL a 50Hz es demasiado lento para que el truco funcione, desafortunadamente. Es posible que haya notado que Ava, la encantadora dama que FrankenGraphics ha animado para mí con el equipo SCABA (Self-Contained Aboveground Breathing Aparatus en inglés, que podría traducirse como aparato de respiración autónomo sobre el suelo en español), que tiene la máscara para su cara, tiene más de 3 colores. Bueno, eso no es nada inusual para la NES en los casos extremos. Antes de Something Nerdy Studios, Battletoads tenía el récord de la mayor cantidad de colores en un personaje de juego de NES, con 6 colores. Ava tiene 9 colores. Esto no se debe a que tenga 3 capas, sino a que estamos cambiando paletas en cada vblank de una manera altamente coordinada e inteligente. La sensación de nuevos colores es innegable y confiable, porque la parte de la pantalla en la que aparece Ava es tan pequeña que el ojo humano no puede detectar la luz estroboscópica. Muchas personas han intentado y fracasado antes que nosotros para lograr esta hazaña, y estoy muy orgulloso de mí mismo por haber descubierto el secreto. Es un proceso complicado que me encantaría explicar en algún momento en el futuro.

El número máximo teórico de colores que se pueden poner en un sprite de una sola capa de esta manera es 9. Para un sprite de doble capa, como Ava, ese número es 36. Sí, son posibles 36 colores para un personaje de NES. Pero no se vería bien a ese nivel porque a medida que aumenta la cantidad de colores, el contraste alcanzable disminuye. Entonces, lo que realmente estamos haciendo es lograr 4 colores en una de las capas de sprites y 5 en la otra para un total de 9. Es una coincidencia que el número 9 aparezca dos veces en esta discusión; por favor no se confunda.

El personaje principal del juego, Jekuthiel alias Jeku, tiene 7 colores. Incluso 7 sería imposible bajo las restricciones normales de NES, usando solo 2 capas de sprites. Pero la diferencia entre 7 y 6 es tan sutil que la mayoría de las personas se percatan de la diferencia. Sin embargo, la gente definitivamente puede notar la diferencia con Ava.

Se desconoce cuántos colores de sprites se pueden lograr en un marco durante el juego normal, pero sospecho que el número está entre 40 y 50 sin hacer que el contraste sea demasiado bajo y, por lo tanto, el juego parezca basura.

Estoy seguro de que alguien preguntará, así que déjeme decir ahora que NO, no será posible deshabilitar este comportamiento de intercambio de paleta de colores en vblank en la configuración del juego, por una razón técnica muy específica que puedo explicar si hay interés en que me explique. Sé que será algo controvertido, pero es lo que es.

-jekuthiel

@jekuthiel That’s incredible to read such a big improvements O_O

A 400 color plaette, and dozens of colors per sprite sounds much 16 bit-ish, right?.

My question is about of using this method with an LCD tv, Does this matters?.



Beautiful to see something not so much far away from this...

Señor Ventura escribió:@jekuthiel That’s incredible to read such a big improvements O_O

A 400 color plaette, and dozens of colors per sprite sounds much 16 bit-ish, right?.

My question is about of using this method with an LCD tv, Does this matters?.



Beautiful to see something not so much far away from this...

Thank you for the encouragement. We're trying very hard to make something special, and pave the way for other NES game developers to surpass our own efforts in the future. This is something I am very passionate about. You can read a bit of my personal history with the NES at my company's Blog section at: https://somethingnerdy.com/ under the title "Something Nerdy This Way Comes". I will be writing many more blog entries in the future. I'm just getting started. In particular, I will be explaining my philosophy on memory mapper design, and what I consider cheating and non-cheating.

The term "16-bit-ish" is exactly what I'm striving for. I've joked that it's 12-bit-ish, since it's in between.

In regards to your question about LCD TVs -- very astute question. YES, it matters a LOT. LCD TVs typically have garbage upscalers for the yellow composite input line. Most of them will fail to interpret the 240p signal correctly and instead treat it like non-double-strike 480i, which results in flickering effects being rendered horribly in various ways. I really should record some video of this on some of our test monitors so people can see what I'm talking about.

Sometimes, you can get lucky with an LCD TV and its "game mode" or "low latency mode" will work well enough that NES games can be rendered correctly on them. We have a Vizio LCD TV here at the office that is one such example. But it's rare.

If you don't have a CRT, you should use an upscaler like the Retrotink or Framemeister in order to get a more proper input signal to the television.

We have 15 different CRTs in the office, on which we have conducted extensive testing. We have also purchased very, very expensive spectrophotometers in order to measure with scientific precision what the colors are that are actually being displayed to the screen. You might be interested to know that in fact, there is such a thing as a CORRECT master palette for the NES. No one in history has ever captured it, but we have begun to do so. It is one of the many fruits of our labor on this project that arose as a natural consequence of the kind of research that we had to do in order to unlock the deeper secrets of the NES's hardware.

No emulator to date renders the sky color on Super Mario Bros. ($22) correctly. The reason for this is that the luminance on a modern LCD TV or computer monitor is typically 250 nits or higher. The luminance on an old CRT was 100 nits by standards/reference. In order to achieve the correct colors for an emulator running on a computer displaying to a typical LCD monitor, the luminance that is captured must be difference than the luminance that is displayed, because of quirks with the NTSC color space. I will be explaining this phenomenon in some detail in the near future on the company blog.

The overall system I have created for the color enhancement technique is called UCS, which is short for Ultimate Color System. Here is a few examples of what UCS can produce if some risk is taken and it is used for background colors instead of sprites:

https://cdn.discordapp.com/attachments/ ... nknown.png

https://cdn.discordapp.com/attachments/ ... nknown.png

https://cdn.discordapp.com/attachments/ ... nknown.png

How much interest does everyone here have in this kind of technique? Do you feel like it's worth it to put graphics like this on the NES? This is my first time telling anyone about this in public. It's probably a mistake to do so at this time, but the cat had to be let out of the bag at some point. I decided to do it here on this forum because there was so much enthusiasm displayed for my project here. =)

Thanks,

-jekuthiel

--

Spanish Translation from Google Translate:

Gracias por el aliento. Estamos haciendo un gran esfuerzo para hacer algo especial y allanar el camino para que otros desarrolladores de juegos de NES superen nuestros propios esfuerzos en el futuro. Esto es algo que me apasiona mucho. Puedes leer un poco de mi historia personal con la NES en la sección del Blog de mi empresa en: https://somethingnerdy.com/ bajo el título "Something Nerdy This Way Comes". Escribiré muchas más entradas de blog en el futuro. Recién estoy comenzando. En particular, explicaré mi filosofía sobre el diseño de mapas de memoria y lo que considero hacer trampa y no hacer trampa.

El término "16 bits" es exactamente lo que estoy buscando. Bromeé diciendo que es de 12 bits, ya que está en el medio.

Con respecto a su pregunta sobre televisores LCD, pregunta muy astuta. SÍ, importa MUCHO. Los televisores LCD suelen tener escaladores de basura para la línea de entrada compuesta amarilla. La mayoría de ellos no interpretarán correctamente la señal de 240p y, en cambio, la tratarán como 480i sin doble impacto, lo que da como resultado efectos de parpadeo que se representan horriblemente de varias maneras. Realmente debería grabar un video de esto en algunos de nuestros monitores de prueba para que la gente pueda ver de lo que estoy hablando.

A veces, puede tener suerte con un televisor LCD y su "modo de juego" o "modo de baja latencia" funcionará lo suficientemente bien como para que los juegos de NES se puedan reproducir correctamente en ellos. Tenemos un televisor LCD Vizio aquí en la oficina que es un ejemplo. Pero es raro.

Si no tiene un CRT, debe usar un escalador como Retrotink o Framemeister para obtener una señal de entrada más adecuada para el televisor.

Tenemos 15 CRT diferentes en la oficina, en los que hemos realizado pruebas exhaustivas. También hemos comprado espectrofotómetros muy, muy caros para medir con precisión científica cuáles son los colores que realmente se muestran en la pantalla. Quizás le interese saber que, de hecho, existe una paleta maestra CORRECTA para NES. Nadie en la historia lo ha capturado nunca, pero hemos comenzado a hacerlo. Es uno de los muchos frutos de nuestro trabajo en este proyecto que surgió como una consecuencia natural del tipo de investigación que tuvimos que hacer para descubrir los secretos más profundos del hardware de NES.

Ningún emulador hasta la fecha muestra correctamente el color del cielo en Super Mario Bros. ($ 22). La razón de esto es que la luminancia en un televisor LCD moderno o un monitor de computadora es típicamente de 250 nits o más. La luminancia en un CRT antiguo era de 100 nits según los estándares / referencia. Para lograr los colores correctos para un emulador que se ejecuta en una computadora que se muestra en un monitor LCD típico, la luminancia que se captura debe ser diferente de la luminancia que se muestra, debido a peculiaridades con el espacio de color NTSC. Explicaré este fenómeno con cierto detalle en un futuro próximo en el blog de la empresa.

El sistema general que he creado para la técnica de mejora del color se llama UCS, que es la abreviatura de Ultimate Color System. Aquí hay algunos ejemplos de lo que UCS puede producir si se toma algún riesgo y se usa para colores de fondo en lugar de sprites:

https://cdn.discordapp.com/attachments/ ... nknown.png

https://cdn.discordapp.com/attachments/ ... nknown.png

https://cdn.discordapp.com/attachments/ ... nknown.png

¿Cuánto interés tienen todos los aquí presentes en este tipo de técnica? ¿Sientes que vale la pena poner gráficos como este en la NES? Esta es la primera vez que le cuento a alguien sobre esto en público. Probablemente sea un error hacerlo en este momento, pero en algún momento hubo que sacar al gato de la bolsa. Decidí hacerlo aquí en este foro porque había mucho entusiasmo mostrado por mi proyecto aquí. =)

Gracias,

-jekuthiel

jekuthiel escribió:Hola a todos/as. Soy Jared Hoag, el fundador y director general de Something Nerdy Studios. No pude evitar notar vuestro interés por mi proyecto de un juego de NES y nuestros esfuerzos para hacer un mapper de memoria. Ciertamente no esperaba esto del mundo hispanohablante, ¿pero por qué no? El objetivo general del desarrollo tecnológico de este proyecto es mejorar la NES a un punto cercano a la TurboGrafx-16, sin hacer trampa usando co-procesamiento en el cartucho. Parece que por lo menos uno de vosotros se ha percatado de este hecho, lo cual me hace muy feliz. ¿Hay algo más que quisierais saber aquí en este foro?

Bienvenido al hilo sobre Curiosidades de la NES/Famicom del foro ElOtroLado, jekuthiel. Soy Diskover, y me encargo de mostrar a la gente todas las cualidades de esta consola de 8bits, así como acercar el homebrew de la NES al mundo hispano hablante, aquí y en mi web personal, RetroNES.

No es para menos estar tan entusiasmado, sobre todo con todas las cualidades que promete tu equipo de desarrollo gracias al nuevo mapper MXM-0, y el videojuego que estáis desarrollando.

Si, ya me di cuenta por donde ibais cuando se filtraron todas las cualidades de MXM-0... directamente me acordé de la PC-Engine sin duda.

Me ha llamado mucho la atención lo que explicas sobre la aplicación de colores en los sprites sobrepasando los límites de la NES y me surgen preguntas.

Hablas sobre que esto será así en NTSC 60Hz, pero no en PAL 50Hz ¿como se verá entonces en los televisores PAL 50Hz? ¿con errores?

Por otro lado ¿Realmente habéis desarrollado el mapper desde cero, u os habéis basado en el MCC5 de Nintendo?

Sobre el videojuego que estáis desarrollando ¿cuanto os falta de tiempo de desarrollo? ¿tenéis pensado hacer algún tipo de crowfunding?

No dudes en seguir publicando contenido en este mismo hilo. Es muy interesante.

puerto modem original / prototipo =
https://www.sbmania.net/forums/threads/nes-expansion-port-mystery-solved.53366/

Bueno, como todos sabéis ya a estas alturas del hilo, la NES solo puede mostrar 8 sprites de 8x8 pixeles en línea. Esto es un auténtico quebradero de cabeza para algunos juegos que pueden acabar convirtiendose en un festival de parpadeos de sprites, sobre todo en juegos como los shooter.

Sin embargo, las investigaciones y la obtención de nueva documentación en pleno 2021, nos permite arañar un poco más dentro de la PPU de la NES/Famicom y sacar partido.

De esta forma, un japones que se hace llamar @Nao_u en Youtube, nos muestra una demo técnica del videojuego Salamander que él mismo ha programado (todos sabéis que este juego sin embargo tiene una versión oficial en esta consola), en donde podemos observar como puede utilizar el disparo de rayo, dibujando una linea entera a lo largo de la pantalla sin ningún tipo de parpadeo de por medio.



¿Como es posible esto? ¿Como lo ha hecho? Pues ingeniosamente; usando el efecto raster por un lado, y la interrupción de pantalla (IRQ) que le proporciona el mapper MMC3.

El efecto raster, se usa para los juegos de conducción para dibujar la carretera y sus curvas.
La interrupción IRQ del MMC3, permite en un momento dado dibujar en alguna porción de la pantalla lo que tengamos cargado en otra nametable distinta a la que actualmente se ejecuta

De esta forma, en esta demo, en la Nametable A vemos el escenario donde nos estamos moviendo, etc... Sin embargo, en la Nametable B, tenemos una porción de la pantalla dibujada con una gran franja verde. Esa franja verde es la que se usará como laser.



Cuando pulsamos el botón B de disparo, se comprueba donde esta el disparador del rallo para iniciar el tiro (esto gracias al efecto raster), y luego ya se dibuja el disparo entero gracias al IRQ, al cual le hemos programado para que haga una interrupción de 1 pixel de alto y muestre la Nametable B. El resto son meras colisiones con los sprites, los cuales, cuando toquen esa interrupción, impactan y explotan.

Sorprendentemente, es un efecto barato y no come casi recursos.

Para terminar, el efecto de doble fondo, es una simple actualización de tiles en la VRAM que se ejecuta también gracias a la facilidad de cambios de porciones de bancos gráficos que proporciona el MMC3 de gratis.

Podéis descargaros la demo aquí: https://www.youtube.com/redirect?event= ... sLaser.nes

@Diskover ¿en el juego original no hay laser?.