[Homebrew] Vigilante para NES (port de SMS)

Solo la idea ya me parece maravillosa,pero ver como te esta quedando...
genial,Kudos!

ojala un dia alguien tenga a bien llevar un titulo imprescindible que muy injustamente no salio en Famicom,tambien es un Irem con una impecable version en SMS,no hace falta que diga el titulo,ya se sabe...

muy buen trabajo,en serio.
emerald golvellius escribió:Solo la idea ya me parece maravillosa,pero ver como te esta quedando...
genial,Kudos!

ojala un dia alguien tenga a bien llevar un titulo imprescindible que muy injustamente no salio en Famicom,tambien es un Irem con una impecable version en SMS,no hace falta que diga el titulo,ya se sabe...

muy buen trabajo,en serio.

R-Type, aunque existe una versión china con los sprites cambiados
Diskover escribió:
emerald golvellius escribió:Solo la idea ya me parece maravillosa,pero ver como te esta quedando...
genial,Kudos!

ojala un dia alguien tenga a bien llevar un titulo imprescindible que muy injustamente no salio en Famicom,tambien es un Irem con una impecable version en SMS,no hace falta que diga el titulo,ya se sabe...

muy buen trabajo,en serio.

R-Type, aunque existe una versión china con los sprites cambiados

Es muy feilla,se necesita un poco mas de amor ahi,a mi esa version no me gusto mucho.
emerald golvellius escribió:
Diskover escribió:R-Type, aunque existe una versión china con los sprites cambiados

Es muy feilla,se necesita un poco mas de amor ahi,a mi esa version no me gusto mucho.

Exacto.

No la tengo muy catada, pero igual hackeandola se podría cambiar los gráficos y la jugabilidad y la cosa mejora, jajaja

Creo que en España fue Gluk la que saco la versión chiná esta y le llamo ¿El bombardero?
@Diskover
Está genial Diskover!! Me encanta lo bien que se mueve!

@Yaripon
Si quieres hacer algo para master, tienes mi tutorial para ir empezando.
Bueno, he estado estos días optimizando los tiles del CHR dedicado al background del nivel 1. Todavía tenía (y tengo) hueco para añadir cosas sin liarme a leches con las restricciones de color, así que se me ocurrió hacer la furgoneta donde la novia del protagonista está secuestrada, ya que dibujé en su día el final del nivel 1 más acorde al arcade original.

Así que me he puesto manos a la obra y he aquí el resultado:

Imagen


Ahora quiero hacer la animación de la furgoneta huyendo cuando el player derrota al boss del nivel y se acerca a ella. Por ahora he aprovechado ese espacio que me quedaba (aun queda unos pocos tiles más, como os he dicho) para dibujar el vehículo en cuestión basándome en sprites del nivel 2 de la versión de SMS y parte de mi propia mano.

Como he visto que ha quedado pequeña, he decidido desplazarla un poco al fondo de la calle para que quede mejor en la perspectiva.

La idea es la dicha: que el player cuando se acerque, la furgoneta arranque y huya. La furgoneta actualmente es parte del background. Aquí voy a intentar hacer el truco de justo cuando se dispara el susodicho evento, sustituir parte de los tiles de la furgoneta por sprites, de tal forma que estos sprites se superpongan por encima del background y se puedan desplazar hacia la derecha suavemente, mientras por debajo el background ha sido sustituido por tiles del suelo de la calle.

Veamos si me sale bien.
Diskover escribió:Bueno, he estado estos días optimizando los tiles del CHR dedicado al background del nivel 1. Todavía tenía (y tengo) hueco para añadir cosas sin liarme a leches con las restricciones de color, así que se me ocurrió hacer la furgoneta donde la novia del protagonista está secuestrada, ya que dibujé en su día el final del nivel 1 más acorde al arcade original.

Así que me he puesto manos a la obra y he aquí el resultado:

Imagen


Ahora quiero hacer la animación de la furgoneta huyendo cuando el player derrota al boss del nivel y se acerca a ella. Por ahora he aprovechado ese espacio que me quedaba (aun queda unos pocos tiles más, como os he dicho) para dibujar el vehículo en cuestión basándome en sprites del nivel 2 de la versión de SMS y parte de mi propia mano.

Como he visto que ha quedado pequeña, he decidido desplazarla un poco al fondo de la calle para que quede mejor en la perspectiva.

La idea es la dicha: que el player cuando se acerque, la furgoneta arranque y huya. La furgoneta actualmente es parte del background. Aquí voy a intentar hacer el truco de justo cuando se dispara el susodicho evento, sustituir parte de los tiles de la furgoneta por sprites, de tal forma que estos sprites se superpongan por encima del background y se puedan desplazar hacia la derecha suavemente, mientras por debajo el background ha sido sustituido por tiles del suelo de la calle.

Veamos si me sale bien.


Que rápido ha quedado tapado este hilo, pensaba que lo habían borrado y todo. Oye te ha quedado muy bien la furgo y menudo arte para dibujar los fondos por cierto. [tadoramo]
Pues hoy os voy a enseñar más cosillas: optimización de tiles y sprites. Un antes y un ahora en el caso del PLAYER.

Imagen


También estoy con el tema de colisiones. Ya funciona, pero por ahora voy a ver si recreo todos los sprites del player, porque igual tengo que pasar del mapper UNROM al mapper MMC3 para conseguir más optimización.
Mola como está quedando!
@Diskover usa el MMC5 directamente mejor que sobre que qué falte. [looco]
SuperPadLand escribió:@Diskover usa el MMC5 directamente mejor que sobre que qué falte. [looco]

Mucho me pides. Ni tengo el conocimiento para usarlo, ni las herramientas para poder aprovecharme de sus mejoras en los colores de los graficos
@Diskover Muy chulo, ¡que no decaiga!.


Una pequeña crítica sobre la perspectiva de los tiles de la carretera al final de la fase. Da la sensación de que el asfalto está en vertical, y choca con como está dibujada la acera.

He cambiado parte de esa zona con otro patrón (en plan rápido), porque explicado solo con palabras igual no se entiende.

Imagen
Ejemplo de como van quedando los movimientos del protagonista.

Por ahora estoy usando el mapper UNROM, pero no descarto pasar todo a MMC3 para tener mejor administración de espacio y poder añadir todos los sprites necesarios. Ya solo los movimientos del protagonista se están comiendo la mitad del CHR destinado a sprites.




Señor Ventura escribió:Una pequeña crítica sobre la perspectiva de los tiles de la carretera al final de la fase. Da la sensación de que el asfalto está en vertical, y choca con como está dibujada la acera.

He cambiado parte de esa zona con otro patrón (en plan rápido), porque explicado solo con palabras igual no se entiende.

Imagen


Se estudiará la viabilidad de hacer algo mejor. Tengo en este caso espacio de sobra.
Por fin he podido crear la intro del port de Vigilante para NES. Lo suyo me ha costado

Actualización de 4 de julio de 2025

Sigo retomando el proyecto y he podido añadir cosas nuevas:

- Iniciado el proyecto utilizando el mapper MMC3, y abandonando definitivamente el UNROM.
- Añadidos tres tipos distintos de enemigos, y boss del primer nivel.
- Animaciones y movimiento de los tres tipos de enemigos distintos.
- Colisiones de los tres tipos de enemigos distintos con el player y viceversa.
- Marcador prácticamente funcional y casi completo. Suma puntos, resta vida, y cuenta atrás funcional.



Debido a la diversidad de enemigos distintos que aparece en los niveles, decidí abandonar el mapper UNROM, y pasarme al MMC3, que definitivamente me da muchísima más libertad de creación y es relativamente sencillo de utilizar.

Mediante el scroll, puedo saber en qué pantalla del nivel estoy, qué enemigos aparecen en esa pantalla, y controlar que CHR hay que cargar para el dibujado del sprite que lo necesite. No está optimizado, se puede hacer mejor, pero por ahora funciona y como demo me vale.

Además, el player también necesita de distintos bancos CHR para dibujar sus movimientos y no quedarnos sin espacio. Esto también lo hago según que botón pulse: si voy de izquierda o derecha o estoy parado, se carga su primer CHR, o si hago puñetazo, se carga su segundo CHR, y lo mismo si estoy agachado cargando con ello su tercer CHR y así sucesibamente.

El MMC3, entre varias de sus configuraciones, me permite cambiar bancos de 64 tiles conjuntos a la vez cuando quiera. Para ello, controla los 256 tiles de sprites, en 4 mini-bancos distintos. Está todo controlado.

Esto es un ejemplo actual de como han quedado los CHRs.

Imagen Imagen Imagen Imagen Imagen


Y unas imágenes nuevas plasmando a los enemigos.

Imagen Imagen


El boss es estático, aún no se mueve ni tiene colisiones, pero quería probar que tal quedaba. Tendré que redibujarle para evitar el excesivo uso de tiles que tiene, y de este modo evitar parpadeos innecesarios.

Imagen
Definitivamente, hay que reorganizar esto

Imagen
Diskover escribió:El boss es estático, aún no se mueve ni tiene colisiones, pero quería probar que tal quedaba. Tendré que redibujarle para evitar el excesivo uso de tiles que tiene, y de este modo evitar parpadeos innecesarios.


Al final te has decidido a hacer el juego final, tienes nuestras bendiciones XD... es considerablemente ambicioso, ¿eh?.

Si algún día se te ocurreriera implementar el mmc5 para mejorar el color, ¿que tendrías que liar?, ¿solo los atributos?.

La versión master system no parpadea en absoluto incluso con un masilla adicional aparte del personaje del jugador, y el jefe de final de fase, ¿que cambia?.
Tengo que verificar la versión SMS con más detalle para evitar el tema parpadeos.

Por otro lado, el mapper MMC5 permite atributos de color 8x8 pero solo en pantallas estáticas, ojo
Bueno, nos conformaremos xD

Falta mucho por avanzar en el mundo de la nes. Si técnicamente con un mapper puedes elegir el color de cada pixel de cada tile, es algo que debería poderse aprovechar para la escena... ¿ese nuevo mapper del former dawn permite ese atributo de color también para sprites?, o solo planos.

De momento tiene muy buena pinta tu port, que no decaiga. A ver ese sonido, ¿te ves puesto en el tema?.
Señor Ventura escribió:Bueno, nos conformaremos xD

Falta mucho por avanzar en el mundo de la nes. Si técnicamente con un mapper puedes elegir el color de cada pixel de cada tile, es algo que debería poderse aprovechar para la escena... ¿ese nuevo mapper del former dawn permite ese atributo de color también para sprites?, o solo planos.

De momento tiene muy buena pinta tu port, que no decaiga. A ver ese sonido, ¿te ves puesto en el tema?.

Según tengo entendido, el atributo de color 1x8 que usan en Former Dawn es gracias a una investigación interna de la PPU de la NES y no tienen nada que ver con el mapper.

Estos tíos cogieron la PPU, la decaparon, la fotografiaron, y descubrieron nuevas características
Diskover escribió:
Señor Ventura escribió:Bueno, nos conformaremos xD

Falta mucho por avanzar en el mundo de la nes. Si técnicamente con un mapper puedes elegir el color de cada pixel de cada tile, es algo que debería poderse aprovechar para la escena... ¿ese nuevo mapper del former dawn permite ese atributo de color también para sprites?, o solo planos.

De momento tiene muy buena pinta tu port, que no decaiga. A ver ese sonido, ¿te ves puesto en el tema?.

Según tengo entendido, el atributo de color 1x8 que usan en Former Dawn es gracias a una investigación interna de la PPU de la NES y no tienen nada que ver con el mapper.

Estos tíos cogieron la PPU, la decaparon, la fotografiaron, y descubrieron nuevas características


Entonces lo del color 1x1, ¿es porque la ppu lo permite, pero podría no haberlo hecho y entonces no hubiera habido mapper que hubiese valido?.

Vamos, que es una virtud del propio hardware de la nes, no solo "mapper ilegítimo" (nótense las comillas).
Señor Ventura escribió:
Diskover escribió:
Señor Ventura escribió:Bueno, nos conformaremos xD

Falta mucho por avanzar en el mundo de la nes. Si técnicamente con un mapper puedes elegir el color de cada pixel de cada tile, es algo que debería poderse aprovechar para la escena... ¿ese nuevo mapper del former dawn permite ese atributo de color también para sprites?, o solo planos.

De momento tiene muy buena pinta tu port, que no decaiga. A ver ese sonido, ¿te ves puesto en el tema?.

Según tengo entendido, el atributo de color 1x8 que usan en Former Dawn es gracias a una investigación interna de la PPU de la NES y no tienen nada que ver con el mapper.

Estos tíos cogieron la PPU, la decaparon, la fotografiaron, y descubrieron nuevas características


Entonces lo del color 1x1, ¿es porque la ppu lo permite, pero podría no haberlo hecho y entonces no hubiera habido mapper que hubiese valido?.

Vamos, que es una virtud del propio hardware de la nes, no solo "mapper ilegítimo" (nótense las comillas).

Atributo de color 1x8, y sí, - espero no equivocarme - pero según leí en las últimas conversaciones en Discord del equipo de investigación y desarrollo de Something Nerdy Studios, es una característica propia de la PPU de la NES
72 respuestas
1, 2