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

Señor Ventura escribió:@Diskover un mapper que permita 30 bloques de 256 tiles cada 8 scanlines (uno para establecer la longitud del escenario, junto con los otros 29 bloques para establecer una actualización de estado de las tiles para una animación), empleando una ch-ram para postprocesarlos para un efecto de escalado (zoom in, zoom out), y ser usada como ch-rom...

Todo a 60fps, animación de escenario a 2 tics (aunque si quisieras, también a 60fps).


¿Si?.

Claro. De hecho, MMC5 podía hacerlo, o el nuevo MXM-1 ya lo hace. Aunque lo del zoom creo que sería más complejo, pero creo que se conseguiría solventar.

Como siempre, el problema sería el tamaño de la memoria y los costes, si quieres luego lanzar el videojuego en un mercado real en pleno 1990 - 1994

Diskover escribió:Como he puesto antes, son 128 tiles reservados para el efecto, y utiliza en total 27 bancos de 256 tiles

27 bancos...

¿Ese zoom está funcionando a 30fps?.[/quote]

Por lo menos. Probándolo en la NES diría que da los 60fps perfectamente.

Te puedo decir que el contador IRQ no deja de funcionar en todo momento, y que el cambio de banco se realiza cada 2 fps... pero insisto, el IRQ continuando con su aplicación, por lo que da la sensación de 60fps finales.

Diskover escribió:Claro. De hecho, MMC5 podía hacerlo, o el nuevo MXM-1 ya lo hace. Aunque lo del zoom creo que sería más complejo, pero creo que se conseguiría solventar.

Básicamente porque en ch-ram sigues teniendo tus 32 tiles, pero cuanto mas lejano sea el zoom, mas tiles de la ch-rom van a conformarlos. Por lo tanto, si reservas 128 tiles para cada columna, y el escenario es demasiado grande, vas a tener que prever una cierta repetición de tiles para no quedarte sin información gráfica al alejar el plano.

1 -Postprocesar todos los tiles implicados en la ch-ram.

2 -En zoom out la información de mas de un tile debe conformar la información del tile resultante. Esta conversión requiere de mucha potencia de cálculo, pero el propio mapper podría servirla estando hecho para esto.

3 -Si el escenario ocupa 128 tiles de ancho, reservas 128 tiles por bloque cada 8 scanlines, y contemplas un zoom out de 3 tiles en el espacio de 1, necesitas que el patrón del dibujo esté conformado por unos 42 tiles en bucle, o por mas tiles para una mayor complejidad del dibujo, pero con espacios, tiles repetidos, etc

4 -Los personajes deben tener un tamaño máximo de 32 píxeles de ancho, y aconsejablemente de no mas de 100 píxeles de alto.

5 -50 colores para planos, y mas de 6 para sprites.

6 -Ese canal pcm echando fuego.

De parte del señor @doblete, que lo publicó en el hilo de Novedades de la scene retro.

Demo de la intro de Another World para la NES:



Descarga en la descripción del video.

La cosa es como se ha hecho, porque vídeo, vídeo... no se yo.

Señor Ventura escribió:La cosa es como se ha hecho, porque vídeo, vídeo... no se yo.

Cambio de CHR al vuelo en escenas con movimiento. Se ve perfectamente con el emulador Mesen.

No lo he mirado, pero me imagino que han usado MMC3.

Edito: está usando el MMC5

@Diskover puede que decepcione, pero es que es mucha resolución como para pretender algo en tiempo real.

La cosa es que ya que se usa un mapper, que este pueda realizar esas tareas junto a su propia ram (como el élite), para no meter una rom de 64 megabits... que aunque hoy en día no supone ningún problema, no sabe igual 8 megabits en tiempo real que 64 megabits de actualización de tiles, aunque en la práctica no notes nada.

O, ¿que tal precalcular todo?, ¿hay cpu para gestionarlo?, ¿hasta dónde se va el uso de una rom?.


Empiezo a querer verlo en una nes.

Sabía que había habido versiones coreanas de la Famicom. La que no había visto nunca es la India.
La Samurai puede parecer una consola bootleg pero inicialmente sí que tenía licencia/permiso de Nintendo. https://bootleggames.fandom.com/wiki/Sa ... ic_TV_Game

Esto es una nes. Con sus 64 sprites en pantalla, y sus 8 sprites por línea.

https://x.com/morphcat/status/193866141 ... BkRPg&s=19


Te quedas...

Señor Ventura escribió:Esto es una nes. Con sus 64 sprites en pantalla, y sus 8 sprites por línea.

https://x.com/morphcat/status/193866141 ... BkRPg&s=19


Te quedas...

Madre mía que espectáculo y que control tiene el programador del hardware de la consola.

Haces ese efecto en Snes o Megadrive y te quedas loco igual xD

Se vienen cositas:

Diskover escribió:Se vienen cositas:

No he entendido nada, nuevo mapper?

SuperPadLand escribió:

Diskover escribió:Se vienen cositas:

No he entendido nada, nuevo mapper?

Eso parece, con capacidad para mover polígonos básicos al estilo Super FX

Pero en esa placa hay una micro pi, no sera quien esta haciendo los calculos??

Esto tiene 16 años...

https://www.youtube.com/watch?v=Fgnd3Ws ... x4&index=5

Un usuario del canal NESdev de Discord, @CardboardBox, está desarrollando un interesante concepto de parallax "real" para nuestra NES.

Por supuesto, tiene truco, pero no deja de ser meritorio. Otra curiosidad más para nuestra 8 bits favorita:

La última demo técnica para NES, sin ningún tipo de mapper.

Diskover escribió:La última demo técnica para NES, sin ningún tipo de mapper.

Estoy impresionado. Que ni ve lón!

Sobre el tema de aplicar un "chip Super FX" a la Famicom/NES... bueno, hubiese sido algo así.

Utilizando un Rasperry Pi Pico que previamente procese los polígonos y luego se lo escupa mascadito y ordenado a los CHR 256 tiles en BG (seguramente sean más tiles, dado que VRAM de NES puede procesar aún más tiles que esos si les mapeas, tal como hace el MMC5 o el MXM-1), para que lo represente con las restricciones de la Famicom/NES.



Interesante para pantallas estáticas, ojo, y poco más futuro le vería. Algún boss que no se mueva de pantalla y que haga alarde de movimientos tridimensionales, o algún escenario que simule algo.

Las estrellas son sprites, pertenecientes al otro CHR 256 tiles en SP, que aun queda espacio para poner enemigos, colisiones, etc...

@Diskover porque dices que no podría hacer mucho más? El Doom de NES es jugable y viene a ser algo similar a esto no? Un SFX en la época podría ser eso.

Edit: Y sabes si puedo comprar la ROM de Form Dawn ahora para apoyar al proyecto o ya desde el kickstarter no recogen más? Es que compré el de krikzz asíque ahora sí puedo comprarme juegos dopados

Pero ya hubo algo así durante su etapa comercial.

https://www.youtube.com/shorts/0N4v_qtvwOQ

SuperPadLand escribió:@Diskover porque dices que no podría hacer mucho más? El Doom de NES es jugable y viene a ser algo similar a esto no? Un SFX en la época podría ser eso.

Creo recordar que, hace años, cuando se presentó con un Rasperry Pi el Doom de NES, este era muy tramposo porque prácticamente ejecutaba todo el Rasperry Pi y luego usaba la NES como paso de video para mostrar la imagen y poco más. A lo mucho, usaba los controles de la NES para manejarnos por el entorno y ya.

¿Notas la diferencia?



En cambio, este Rasperry Pi Pico para Famicom/NES lo que hace es atenerse a las limitaciones de la NES, procesando todo el entorno gráfico 3D, cortándolo en cachitos en forma de tiles de 8x8 destinados al background, y enviándoselo a la VRAM para que la PPU lo muestre en pantalla.

Quizá estoy metiendo la pata afirmando que no se podría usar para mucho más, pero es cierto que saltándote la restricción de 256 tiles por background como hacen muchos mapeadores, perfectamente podrías mostrar a pantalla completa eso y mucho más, simulando un Star Fox o un Virtua Racing.

Nos sobrarían 256 tiles de sprites para todo lo demás.

SuperPadLand escribió:Y sabes si puedo comprar la ROM de Form Dawn ahora para apoyar al proyecto o ya desde el kickstarter no recogen más? Es que compré el de krikzz asíque ahora sí puedo comprarme juegos dopados

Que yo sepa, no.

Señor Ventura escribió:Pero ya hubo algo así durante su etapa comercial.

https://www.youtube.com/shorts/0N4v_qtvwOQ

Sí, el concepto es el mismo, pero con diferencias:

- Elite usa la CPU para procesar los vectores, luego los corta en cachitos de tiles de 8x8 y se lo pasa a la VRAM de la PPU para que lo muestre en pantalla. Esto ya deja a la CPU sin muchos diclos.
- Elite se salta la restricción de los 256 tiles de background y utiliza direcciones de memoria de los 256 tiles de sprites para mostrar parte del background ("se roba" 128 tiles en principio solo para los vectores, pero veo que aún usa muchos más para otros detalles, dejando pocos tiles para dibujar las estrellas y ya).
- Debido al uso intenso de la CPU, Elite a lo mucho tira a 12 o 15 frames por segundo. No le da para mucho más.
- Elite solo funciona en PAL debido a que el tiempo de procesamiento que tiene la CPU es mucho más largo que en NTSC cuando llega al VBLANK.

Con este Rasperry Pi Pico, liberas a la CPU de hacer todo ese trabajo, puedes hacer graficos 3D más detallados y no limitarte solo a vectores, ganas más frames, y puede reproducirse tanto en PAL como en NTSC.

Es como un "Super FX" pero para NES.

@Diskover pero el SFX en SNES no hace algo similar a Doom NES? Genera todo el chip que lo vuelva a su propio framebuffer y de ahí lo pasa ya generado a la VRAM de la máquina. O lo que es lo mismo, se podría haber metido un SFX a NES en los 90 y tener un Starfox/Doom en NES como los de SNES, pero adaptados a las limitaciones de la PPU de NES?

SuperPadLand escribió:@Diskover pero el SFX en SNES no hace algo similar a Doom NES? Genera todo el chip que lo vuelva a su propio framebuffer y de ahí lo pasa ya generado a la VRAM de la máquina. O lo que es lo mismo, se podría haber metido un SFX a NES en los 90 y tener un Starfox/Doom en NES como los de SNES, pero adaptados a las limitaciones de la PPU de NES?

Lo que tu estas diciendo es exactamente lo que hace este nuevo Rasperry Pi Pico, pero no funciona así el Doom de NES.

El Doom de NES ni siquiera pasa por la VRAM de la PPU. Ni siquiera usa la CPU más que para procesar los controles del mando.

Procesa todo en el Rasperry Pi (programa y gráficos) y lo lanza directamente a la salida del video, aunque en el video dice que funciona de forma similar al Super FX de SNES, eso no es cierto.

Al menos así tengo entendido que se explicó en su día.

Diskover escribió:

SuperPadLand escribió:@Diskover pero el SFX en SNES no hace algo similar a Doom NES? Genera todo el chip que lo vuelva a su propio framebuffer y de ahí lo pasa ya generado a la VRAM de la máquina. O lo que es lo mismo, se podría haber metido un SFX a NES en los 90 y tener un Starfox/Doom en NES como los de SNES, pero adaptados a las limitaciones de la PPU de NES?

Lo que tu estas diciendo es exactamente lo que hace este nuevo Rasperry Pi Pico, pero no funciona así el Doom de NES.

El Doom de NES ni siquiera pasa por la VRAM de la PPU. Ni siquiera usa la CPU más que para procesar los controles del mando.

Procesa todo en el Rasperry Pi (programa y gráficos) y lo lanza directamente a la salida del video, aunque en el video dice que funciona de forma similar al Super FX de SNES, eso no es cierto.

Al menos así tengo entendido que se explicó en su día.

Ah vale vale, creía que era lo mismo. Pero a efectos de usar un SFX de NES podría usarse para crear juegos 3D para algo más que generar algún boss o elemento 3D del escenario no?

SuperPadLand escribió:Ah vale vale, creía que era lo mismo. Pero a efectos de usar un SFX de NES podría usarse para crear juegos 3D para algo más que generar algún boss o elemento 3D del escenario no?

Si.

Quizá me precipité al asegurar lo contrario primeramente. Pero si tienen acceso a los registros de memoria de cualquier de los tiles del CHR, sean para BG o SPR, da de sobra para dibujar un Star Fox en pantalla.

Diskover escribió:Lo que tu estas diciendo es exactamente lo que hace este nuevo Rasperry Pi Pico, pero no funciona así el Doom de NES.

El Doom de NES ni siquiera pasa por la VRAM de la PPU. Ni siquiera usa la CPU más que para procesar los controles del mando.

Procesa todo en el Rasperry Pi (programa y gráficos) y lo lanza directamente a la salida del video, aunque en el video dice que funciona de forma similar al Super FX de SNES, eso no es cierto.

Al menos así tengo entendido que se explicó en su día.

El caso es que aún así, ninguna otra consola permite un througout de todo el pipeline gráfico, por mucho que tu quieras en lass 16 bits le mandas al line buffer lo que pueda dar el dma, y por ahí si podemos hablar de una característica de la nes usada por ese doom, y no una ausefncia de ellas.

SuperPadLand escribió:Ah vale vale, creía que era lo mismo. Pero a efectos de usar un SFX de NES podría usarse para crear juegos 3D para algo más que generar algún boss o elemento 3D del escenario no?

De hecho, a 60fps, al contrario que cualquier 16 bits.

Y es que si hablamos de juegos mediante procesador de apoyo, ya no hay un "ya, pero es que la nes...", porque van todas a tope a por el mismo objetivo, y ahí la nes asesina.

Señor Ventura escribió:De hecho, a 60fps, al contrario que cualquier 16 bits.

Ojo con esta afirmación.

En su época, seguramente era complicado por un tema de costes, pero hoy en día seguro que te pueden cascar un Super FX3 asequible que generé polígonos a 60fps e incluso texturizados sin problema para SNES y Mega Drive.

Diskover escribió:

Señor Ventura escribió:De hecho, a 60fps, al contrario que cualquier 16 bits.

Ojo con esta afirmación.

En su época, seguramente era complicado por un tema de costes, pero hoy en día seguro que te pueden cascar un Super FX3 asequible que generé polígonos a 60fps e incluso texturizados sin problema para SNES y Mega Drive.

Bueno, ojo... en una ventanita lo que quieras.

Pero ventanita. Sencillamente no les da el ancho de banda.

Señor Ventura escribió:

Diskover escribió:

Señor Ventura escribió:De hecho, a 60fps, al contrario que cualquier 16 bits.

Ojo con esta afirmación.

En su época, seguramente era complicado por un tema de costes, pero hoy en día seguro que te pueden cascar un Super FX3 asequible que generé polígonos a 60fps e incluso texturizados sin problema para SNES y Mega Drive.

Bueno, ojo... en una ventanita lo que quieras.

Pero ventanita. Sencillamente no les da el ancho de banda.

Ahí ya no discuto que no tengo ni idea.