[Homebrew NES] Shadow of the Beast (demo técnica)

Archivado
1, 2, 3
Imagen


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

Título: Shadow of the Beast
Compañía original: Psygnosis
Port: RetroNES Software
Consola: NES (8 bits)
Mapper: MMC3
Librería: NESlib (Shiru)
Multiscroll engine: Doug Fraker
Música: MovieMovies1, arreglada para que funcione en MMC3
ROM: Shadow of the Beast (alpha 0.34) [HB].nes

https://twitter.com/RetroNES_Soft/statu ... 1169505281

Recomiendo encarecidamente utilizar el emulador VirtuaNES para jugar en el PC, o un flascard como puede ser el Everdrive para jugar en una NES real.

Os presento una pequeña demo técnica para la Nintendo NES de 8bits basado en el videojuego Shadow of the Beast de Psygnosis.

Como muchos sabreis, la NES aunque fuese la consola más popular de finales de los años 80, se quedó sin su versión de Shadow of the Beast ante la inminente salida de su heredera de 16bits, SNES, que si obtuvo su correspondiente versión.

De esta forma, muchos nos hemos preguntado muchas veces como sería esta versión para NES y hasta que punto se podría sacar partido de los 8bits de Nintendo.

Para poner solución a esto, me he puesto a lo largo de esta última semana a trabajar en un port y no os puedo enseñar más que una demo técnica que yo mismo he realizado. Tampoco pretendo realizar el juego entero; simplemente acabar con la curiosidad de muchos.

Hay que tener en cuenta que por ahora simplemente se mueve el player de izquierda a derecha en el famoso campo que daba comienzo al principio del juego.

Existen dos versiones: la simple y más básica, basada en una placa NROM (32kb PRG + 8kb CHR), y la todoterreno, basada en una placa MMC3 que me da más capacidad para almacenar programa, gráficos, e interrupción de lineas para conseguir efectos de planos.

Por ahora solo os enseñaré dos vídeos:
NROM: https://www.youtube.com/watch?v=882dv1PwCJw

MMC3: https://www.youtube.com/watch?v=W_TrfDLk6S0

Y os pongo los gifs demostrativos con los que empezó todo:
- 9 de abril de 2018: surge la idea y muestro un primer pantallazo.
Imagen

- 10 de abril de 2018: primer ensayo de scroll, paleta de colores, background, etc...
Imagen

- 11 de abril de 2018: presentación del player y cambios en colores.
Imagen

- 15 de abril de 2018: el player se mueve
Imagen

- 16 de abril de 2018: primeros ensayos con el MMC3. Silencio absoluto.

- 20 de abril de 2018: presentación de la demo técnica funcionando bajo un MMC3
Imagen

- 28 de abril de 2018: añadimos la valla silueteada, abajo.
Imagen

- 29 de abril de 2018: primer boceto del bosque y la casa HOME. Cambios en el degradado del cielo.
Imagen

- 10 de mayo de 2018: primeras pruebas de scroll con errores.
https://www.youtube.com/watch?v=FFKp4oZ21F8

- 13 de mayo de 2018: trabajando en el engine del scroll y bosque terminado
Imagen

- 17 de mayo de 2018: Empiezo a trabajar en la cueva
Imagen

- 17 de junio de 2018: pantalla de título y preparación de la rom demo.
Imagen

- 12 de julio de 2018: publicación de la rom
Se ha desarrollado con soporte de la librería NESlib de Shiru. El scroll multidireccional es una modificación del engine original de Doug Fraker, que además ha sido adaptado para que funciones con el mapper MMC3 (para conseguir efectos de plano). La música la encontré de casualidad en un foro dedicado a famitraker, y fue desarrollada por MovieMovies1 para el mapper MMC5. Evidentemente, la he adaptado para que funcione en el MMC3.

Funciona perfectamente en una NES real mediante flashcard y otros métodos.

Si se quiere utilizar en PC u smartphone, se recomienda el emulador VirtuaNES.

Un saludo a @kusfo79 @emerald golvellius @robotnik16 @puch666
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
Diskover escribió:- 20 de abril de 2018: presentación de la demo técnica funcionando bajo un MMC3
Imagen


Menuda pasada tío, mi enhorabuena y gracias por demostrarnos lo que puede dar de sí una NES.

Imagen

Ojalá te vengas arriba y te animes a hacer la conversión entera con algo de ayuda XD
Que interesante esto amigo @diskover muy buen trabajo! :)
Qué et voy a decir... he seguido la evolución desde el principio. Te ha quedado de brutal, la inclusión del scroll en las nubes ha sido la guinda. Te lo va a decir todo el mundo, pero es cierto que es una pena que no tengas intención de hacer el juego entero porque serái una pasada, aun así, chapó por lo que ya has hecho y encima tan rápido.

Felicidades pro tu criatura!!!
Gracias compis retros.

Mi siguiente objetivo va a ser mejorar la animación del player. Puedo añadir más frames gracias a que ahora el espacio de gráficos no me preocupa mucho, y después de todo es solo una demo técnica.

¡Ah, y el zeppelin que salía en el original de Amiga!
@Diskover ExceLsioR!!! [oki] ,como eso se empice a ver te van a rogar el juego.
emerald golvellius escribió:@Diskover ExceLsioR!!! [oki] ,como eso se empice a ver te van a rogar el juego.


Sí; eso creo que va a pasar.
Llevo la vida registrado y soy de comentar muy poco, pero esto se lo merece, enhorabuena por el desarrollo.
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
gynion escribió:
emerald golvellius escribió:@Diskover ExceLsioR!!! [oki] ,como eso se empice a ver te van a rogar el juego.


Sí; eso creo que va a pasar.


Yo ya se la he tirado en el primer post xD
Sexy MotherFucker escribió:
gynion escribió:
emerald golvellius escribió:@Diskover ExceLsioR!!! [oki] ,como eso se empice a ver te van a rogar el juego.


Sí; eso creo que va a pasar.


Yo ya se la he tirado en el primer post xD


No lo había visto con el gif. Pues creo que no le quedará otra que venirse arriba. Eso no lo puede dejar así. :o

PD. Es que da muy buena impresión, cada vez que le echo un ojo.
Muy buenas las dos versiones. La MMC3 es todo un lujo.
Da gusto tener foreros que se lo curran tanto y lo comparten con el foro. Gracias!
Me quito el sombrero, que pasada!!
No sé que pasa pero el MMC3 no veo el video, me sale una exclamación...pero viendo el NROM ya he tenido suficiente....de mayor quiero ser como tú, ¡excelente trabajo! [beer]
Esto promete. :)
@Sexy MotherFucker @SweetPotato @robotnik16 @emerald golvellius @gynion @Phobiac @puch666 @mayhem @isacin @Hasami Age

Disculpadme, la versión del vídeo MMC3 estaba puesto en privado. Ahora ya se puede ver:

https://www.youtube.com/watch?v=W_TrfDLk6S0
@Diskover

Parece que se ve mejor en el video; el personaje tiene unos contornos ligeramente más oscuros, mejor contrastado con el fondo.
@Diskover

En dos palabras espec-tacular!! :-D [boing] [boing] [boing] ME encanta como has usado la paleta!
tiene muy buena pinta !!! te animo a que lo termines.
gynion escribió:@Diskover

Parece que se ve mejor en el video; el personaje tiene unos contornos ligeramente más oscuros, mejor contrastado con el fondo.


Esta grabado desde el televisor LED.

En cuanto pueda subo una prueba en televisor de tubo, que es como debería ser.
Diskover escribió:
gynion escribió:@Diskover

Parece que se ve mejor en el video; el personaje tiene unos contornos ligeramente más oscuros, mejor contrastado con el fondo.


Esta grabado desde el televisor LED.

En cuanto pueda subo una prueba en televisor de tubo, que es como debería ser.

Es fantastico de verdad,me he suscrito para ver si cambias un solo pixel,de verdad que se ve muy bonito,lo que no entiendo muy bien es como trabajas tan rapido,lo tienes por la mano,fantastico de verdad.
Trabajo tan rápido gracias a las herramientas que tengo y la experiencia ganada en estos dos años. De todas formas, siempre salen obstáculos nuevos, y aprender a dominar algo (no del todo) el MMC3 me ha llevado una semana simpática en la cual nada me salia bien.

Para todo el tema gráfico utilizo NES Screen Tool, de Shiru. Una herramienta muy potente para y solo para NES.
Para todo el tema de montaje de pantallas utilizo el Tiled.
Para las funciones principales que me permiten funcionar con la NES utilizo la librería NESlib.dll que también es de Shiru.
Para compilar utilizo CC65, que me permite programar en lenguaje C y el lo transforma a lenguaje máquina para que lo entienda la NES.

En estos dos años he estudiado mucho el foro de NESdev, y usuarios como na_th_an (de Mojon Twin) o doug, me han sido de mucha ayuda para entender cosas y encaminarme.

Todo lo demás es tiempo y trabajo constante.


Cambiando de tema, para que os hagáis una idea de porque esto no va a pasar de ser una demo técnica, por muchas virguerias que haga, ya solo el player y la luna (que son sprites) me consumen 61 tiles. La NES solo puede mostrar en pantalla 64 tiles.

Así que haceros una idea que por lo pronto, el zeppelin que querían poner como en el Amiga (moviéndose y tal) ya va a ser como que no. Y ya no digamos lo de poner enemigos... tampoco. Y no, no existe en NES ningun chip especial ni mapper que permita saltarse tal restricción.

Una pena.

La única alternativa sería hacer la luna más pequeña o directamente quitarle tiles de detalles. O quitarla directamente. También puedo hacer al player más pequeño... ¿pero al final que tendríamos? Algo más parecido a la versión SMS, y es lo que no quiero ver.

Lo que si voy ha hacer es mejorar el movimiento del player, añadirle más frames.

Me estoy basando en el player de la versión Mega Drive porque es del único del que he encontrado sprites que poder copiar.
Muy chulo @Diskover
@Diskover

Aunque no puedas hacer nada más a la altura, por las limitaciones técnicas que comentas, te puede servir para volver a intentarlo con un juego original. Igual un Shooter 2D plataformero funcionaria bien.
@Diskover El programador tiene que adaptarse lo que tiene, hay veces que hay que hacer sacrificios para que funcione perfectamente un juego, tendras que depurar las linias para que no ocupe mas ram de lo necesario y buscar formulas para que funcione un juego completo en la NES y que sean estables en el momento de jugar.

No haces un juego para una consola actual sino para una consola retro que tiene sus limitaciones de los 8 bytes y es tener mucho merito.

Por ejemplo las 10 capas del juego que haces , esta ocupando demasiado espacio para una NES dando el resultado que estas al limite y tendras que usar tu ingenio para sacrificar algunos fondos.

Investiga de como eran las graficas de los juegos de la NES que te pueden dar algunas respuestas para que no ocupen tanto.
Excelente demo.
Genialidad Diskover. [tadoramo] [tadoramo]
muy buen trabajo
Hasami Age escribió:@Diskover El programador tiene que adaptarse lo que tiene, hay veces que hay que hacer sacrificios para que funcione perfectamente un juego, tendras que depurar las linias para que no ocupe mas ram de lo necesario y buscar formulas para que funcione un juego completo en la NES y que sean estables en el momento de jugar.

No haces un juego para una consola actual sino para una consola retro que tiene sus limitaciones de los 8 bytes y es tener mucho merito.

Por ejemplo las 10 capas del juego que haces , esta ocupando demasiado espacio para una NES dando el resultado que estas al limite y tendras que usar tu ingenio para sacrificar algunos fondos.

Investiga de como eran las graficas de los juegos de la NES que te pueden dar algunas respuestas para que no ocupen tanto.


10 capas? Te refieres a 10 planos de scroll? Eso no ocupa nada, el problema viene de que sólo puedes tener 64 sprites de 8x8 a la vez, y ya con el jugador, la luna y alguna cosilla más ya estas en el límite o casi, de forma que no se puede mostrar enemigos u otros elementos sin tirar de parpadeos o partes que desaparecen de cuando en cuando.

Por cierto @Diskover, qué problema le ves al de Master System? El juego en sí creo que está muy bien, poco más se puede hacer.
@Diskover Enhorabuena!!!! Una chulada, si señor [oki] [oki] [oki] [oki]
Hasami Age escribió:@Diskover El programador tiene que adaptarse lo que tiene, hay veces que hay que hacer sacrificios para que funcione perfectamente un juego, tendras que depurar las linias para que no ocupe mas ram de lo necesario y buscar formulas para que funcione un juego completo en la NES y que sean estables en el momento de jugar.

No haces un juego para una consola actual sino para una consola retro que tiene sus limitaciones de los 8 bytes y es tener mucho merito.

Por ejemplo las 10 capas del juego que haces , esta ocupando demasiado espacio para una NES dando el resultado que estas al limite y tendras que usar tu ingenio para sacrificar algunos fondos.

Investiga de como eran las graficas de los juegos de la NES que te pueden dar algunas respuestas para que no ocupen tanto.


No hay planos. Son interrupciones por línea. Gracias al MMC3 no cuestan NADA. Son apenas 20 líneas de código. No, tampoco consumen RAM.

Llevo años programando en NES

@Gammenon No le veo mayor problema. Simplemente quiero que está demo técnica luzca y se acerque un poco más a la de las versiones 16bits. Rollo Aladdin chino de NES
Tremendo trabajo y una pregunta, si haces el juego solo para poder ser ejecutado con emulador podrías saltarte las restricciones del Hardware de la nes?
@Diskover La solución al problema de la luna es evidente, ¡desvía la atención!.

Sin saber cuanta memoria libre te queda para dibujar en el plano, te diría que te tomases la licencia de introducir nuevos elementos.
-Tienes mucho margen libre en el suelo para introducir el muro de piedra de las versiones 16 bits.
-Aumenta el tamaño de las briznas de hierba antes de cada interrupción de cada línea para que se haga notar mas la separación de cada trozo de suelo. Tienes margen en el dibujo.
-Las tres secciones del suelo se mueven a una velocidad muy parecida, sería bueno diferenciarlo un poco mas para que sea coherente con el movimiento de las nubes.
-Si las características del MMC3 te lo permiten, a lo mejor podrías animar las nubes en la zona donde iría la luna, para enseñar algunas partes sin consumir tantos tiles como lo hace actualmente a base de sprites.


¿Cuales son las limitaciones con las que tienes que lidiar?, ¿con que límite el mmc3 puede leer tiles de la rom?.
Señor Ventura escribió:@Diskover La solución al problema de la luna es evidente, ¡desvía la atención!.

Sin saber cuanta memoria libre te queda para dibujar en el plano, te diría que te tomases la licencia de introducir nuevos elementos.
-Tienes mucho margen libre en el suelo para introducir el muro de piedra de las versiones 16 bits.


Lo tengo encuenta. Creeme que la lucha con la paleta de colores tiene mucho que ver su atraso.

Señor Ventura escribió:-Aumenta el tamaño de las briznas de hierba antes de cada interrupción de cada línea para que se haga notar mas la separación de cada trozo de suelo. Tienes margen en el dibujo.


Eso está más que follao

Señor Ventura escribió:-Las tres secciones del suelo se mueven a una velocidad muy parecida, sería bueno diferenciarlo un poco mas para que sea coherente con el movimiento de las nubes.


Tengo una lucha importante con el control de las velocidades . Está atestiguado en Twitter

Señor Ventura escribió:-Si las características del MMC3 te lo permiten, a lo mejor podrías animar las nubes en la zona donde iría la luna, para enseñar algunas partes sin consumir tantos tiles como lo hace actualmente a base de sprites.


No es tan sencillo.

El MMC3 me permite interrupciones de linea (IRQ) y saltos de bancos CHR (cambio conjunto de tiles al vuelo)

La solución más factible es hacerla desaparecer o reducir su numero de tiles

Señor Ventura escribió:¿Cuales son las limitaciones con las que tienes que lidiar?, ¿con que límite el mmc3 puede leer tiles de la rom?.


El MMC3 me permite cambar conjunto de tiles al vuelo mediante cambios de bancos de tiles (CHR), y también permite hacer interrupciones de lineas (IRQ) para efectos de planos.

La NES permite mostrar 64 tiles en pantalla, 8 en la misma línea de escaneo. Si pongo más, no se muestran. Muchos programadores de la época solventaban de alguna forma esta limitación haciendo el típico parpadeo de sprites para enseñarnos todo lo que querían en pantalla.
Imagen

Impresionante.

[beer] [plas] [plas] [plas] [plas]
¡Me quito el sombrero Sr. Diskover! [Ooooo]

Cada vez que veo cosas como esta, me dan ganas de hacerme el harakiri por no haberme puesto a aprender a programar desde joven (ahora lo veo muy dificil [+risas] )

En mi opinión, y siempre que quieras seguir añadiendo más cosas (enga, animate y hazlo jugable y tal XD ), reduciría la luna hasta hacer que fuese un detalle sin más (ahora destaca un montón, pero te has ventilado media vram [carcajad] [carcajad] [carcajad] ). Esto te permitiría un zepellin pequeñin y sin parpadeos por el cielo. También te dejaría libre la posibilidad de hacer enemigos... (¿ves por dónde quiero ir? engaaaaaaa... animate a hacer algo jugable XD XD XD )
Una simple palabra '' alucinante'' [ok]
Akomander escribió:¡Me quito el sombrero Sr. Diskover! [Ooooo]

Cada vez que veo cosas como esta, me dan ganas de hacerme el harakiri por no haberme puesto a aprender a programar desde joven (ahora lo veo muy dificil [+risas] )

En mi opinión, y siempre que quieras seguir añadiendo más cosas (enga, animate y hazlo jugable y tal XD ), reduciría la luna hasta hacer que fuese un detalle sin más (ahora destaca un montón, pero te has ventilado media vram [carcajad] [carcajad] [carcajad] ). Esto te permitiría un zepellin pequeñin y sin parpadeos por el cielo. También te dejaría libre la posibilidad de hacer enemigos... (¿ves por dónde quiero ir? engaaaaaaa... animate a hacer algo jugable XD XD XD )


Tengo una solución que había pasado por alto: usar el modo tiles 8x16

Puedo hacer los sprites en ese modo y de esta forma reducir a prácticamente a la mitad los 61 que actualmente gasto.

En NES no se suele usar ese modo, pero hubo juegos exitosos que lo hicieron en su día, como por ejemplo el TMNT:

Imagen

https://www.youtube.com/watch?v=2Xxe0TXGg-8


Lo malo es que a la hora de hacer los sprites, es un poco más complejo con la herramienta que tengo, pero poder, se puede hacer.
@Diskover Yo me plantearía animar los tiles del plano que pasan por delante del área donde debería estar la luna.

Por eso preguntaba sobre limitaciones a la hora de actualizar gráficos, porque no se si el mmc3 puede cambiar tiles del plano al vuelo sin agotar ancho de banda, y sería una solución que liberaría recursos a saco.

Eso si, la paleta de colores a lo mejor obligaría a la luna a tener colores raros, pero a lo mejor sería planteable con un diseño de colores basado en grises y marrones.

¿Como lo ves?. Es decir, es mucho curro, pero, ¿técnicamente es posible actualizar tantos tiles por frame?.
Diskover escribió:
Akomander escribió:¡Me quito el sombrero Sr. Diskover! [Ooooo]

Cada vez que veo cosas como esta, me dan ganas de hacerme el harakiri por no haberme puesto a aprender a programar desde joven (ahora lo veo muy dificil [+risas] )

En mi opinión, y siempre que quieras seguir añadiendo más cosas (enga, animate y hazlo jugable y tal XD ), reduciría la luna hasta hacer que fuese un detalle sin más (ahora destaca un montón, pero te has ventilado media vram [carcajad] [carcajad] [carcajad] ). Esto te permitiría un zepellin pequeñin y sin parpadeos por el cielo. También te dejaría libre la posibilidad de hacer enemigos... (¿ves por dónde quiero ir? engaaaaaaa... animate a hacer algo jugable XD XD XD )


Tengo una solución que había pasado por alto: usar el modo tiles 8x16

Puedo hacer los sprites en ese modo y de esta forma reducir a prácticamente a la mitad los 61 que actualmente gasto.

En NES no se suele usar ese modo, pero hubo juegos exitosos que lo hicieron en su día, como por ejemplo el TMNT:

Imagen

https://www.youtube.com/watch?v=2Xxe0TXGg-8


Lo malo es que a la hora de hacer los sprites, es un poco más complejo con la herramienta que tengo, pero poder, se puede hacer.


El Contra creo que es otro juego que usa sprites de 8x16. O en Máster System tienes títulos como Gemitas XD
Killer Instinct NES tech demo 8bit
este proyecto puede estar en desarrollo próximamente, según Z80 artist

https://www.youtube.com/watch?v=Cm3H5mO3LSM
http://forums.nesdev.com/viewtopic.php?f=2&t=12830
Señor Ventura escribió:@Diskover Yo me plantearía animar los tiles del plano que pasan por delante del área donde debería estar la luna.

Por eso preguntaba sobre limitaciones a la hora de actualizar gráficos, porque no se si el mmc3 puede cambiar tiles del plano al vuelo sin agotar ancho de banda, y sería una solución que liberaría recursos a saco.

Eso si, la paleta de colores a lo mejor obligaría a la luna a tener colores raros, pero a lo mejor sería planteable con un diseño de colores basado en grises y marrones.

¿Como lo ves?. Es decir, es mucho curro, pero, ¿técnicamente es posible actualizar tantos tiles por frame?.


Si, el MMC3 permite tener distintos bancos CHR (hasta 256Kb, que es una salvajada) y previamente puedes configurarlo para hacer divisiones entre estos bancos y poder cambiarlos al vuelo sin mayor problema ni consumo alguno.

Entiendo lo que me pides, pero es realmente complejo y difícil de realizar dado que la luna es más grande que cualquiera de las divisiones IRQ que hay establecidas (cada 16 pixeles) y no quedaría bien.

Créeme que la opción de usar el modo 8x16 sería más lógico y rentable.

Para que veas lo que se puede hacer gracias al cambio al vuelo entre bancos CHR en un MMC3
Imagen

Como podemos ver en el videojuego The Three-eyed One [Natsume] (1992) se configuró el CHR en 4 divisiones distintas. Las dos primeras son para el background, y las dos últimas para los sprites.

En la segunda división podemos ver como cambia a lo largo de 8 bancos distintos para poder hacer el efecto de doble fondo que se ve en la imagen, dando sensación de animación.

Este efecto puede quedar bien, por ejemplo, cuando Beast está dentro de una cueva, para darle profundidad.
La verdad es que el uso del 8x16 podría funcionar bastante bien en este caso. La bestia y la luna son alargadas y como dices tu, ahorrarías un montón de tiles [sonrisa]

La cosa es que sigue existiendo en este modo la misma limitación de representarlos horizontalmente ¿no?
Akomander escribió:La verdad es que el uso del 8x16 podría funcionar bastante bien en este caso. La bestia y la luna son alargadas y como dices tu, ahorrarías un montón de tiles [sonrisa]

La cosa es que sigue existiendo en este modo la misma limitación de representarlos horizontalmente ¿no?


Sí, los mismos 8 sprites por scanline
Impresionante demo. Gran trabajo.
Akomander escribió:La verdad es que el uso del 8x16 podría funcionar bastante bien en este caso. La bestia y la luna son alargadas y como dices tu, ahorrarías un montón de tiles [sonrisa]

La cosa es que sigue existiendo en este modo la misma limitación de representarlos horizontalmente ¿no?


Si, ahí poca solución hay más que hacer un arreglo mediante parpadeos, que era lo que se hacía antes para solventar hasta cierto punto esa limitación.

ACTUALIZACIÓN:

@kusfo79 @emerald golvellius @robotnik16 @puch666 @Gammenon @Señor Ventura

Os comunico que ya he pasado los tiles a modo 8x16

Ha costado un poco y por el camino se ha consumido un poco más de espacio en el CHR, pero hemos reducido los 61 tiles que había en los momentos más altos en pantalla a tan solo 29 tiles, con lo cual, es factible meter enemigos, etc...

Además, he añadido unos cuantos frames que faltaban a la animación de Beast
¡Qué bueno! A ver para cuando sale un gif nuevo demostrativo [angelito]
@Diskover

Bueno, 35 tiles para enemigos está muy, muy bien. Te vas a topar antes con el límite por scanline que con agotar la tabla de sprites.

¿Que hay del muro/verja del suelo?.
@Diskover ¡Excelente noticia! La verdad es que se ha ahorrado en tiles más de lo que pensaba [carcajad]
El GIF nuevo le tendré listo cuando añada más movimientos a Beast (agacharse, saltar...) y la inclusión de algún enemigo. Quizá el enemigo ojo sea la primera opción por su facilidad, e incluso los montículos de piedra.

Tengo que estudiar el cambio de bancos CHR mediante MMC3 para aprovecharme del espacio extra que tengo desperdiciado por ahí.

Señor Ventura escribió:@Diskover

Bueno, 35 tiles para enemigos está muy, muy bien. Te vas a topar antes con el límite por scanline que con agotar la tabla de sprites.

¿Que hay del muro/verja del suelo?.


El muro verja del suelo está planeado. Hay espacio en el CHR dedicado al background.No lo he incluido todavía porque con la paleta actual no se que combinación de colores podría usar para que quede bien.

Quizá al final opte por una simple silueta del muro.

Cuando tenga algo medianamente chulo, colgaré la ROM. También os debo comentar que esta demo funciona en una NES real sin problema (ya lo habéis visto en los vídeos), pero no en todos los emuladores. Por alguna razón, en VirtuaNES va bien, pero en FCEUltra casca.
Diskover escribió:El muro verja del suelo está planeado. Hay espacio en el CHR dedicado al background.No lo he incluido todavía porque con la paleta actual no se que combinación de colores podría usar para que quede bien.

Quizá al final opte por una simple silueta del muro.

Cuando tenga algo medianamente chulo, colgaré la ROM. También os debo comentar que esta demo funciona en una NES real sin problema (ya lo habéis visto en los vídeos), pero no en todos los emuladores. Por alguna razón, en VirtuaNES va bien, pero en FCEUltra casca.


¿Que tal un muro simulando estar cubierto de musgo, con blancos/grises y verdes?, ¿tienes alguna paleta que permita acercarte a eso?.

¿Podrías poner en un momentillo como tienes configuradas las paletas?, a lo mejor a alguien se le ocurre algo que pueda inspirarte.
138 respuestas
Archivado
1, 2, 3
Volver a Consolas clásicas