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

Archivado
1…6, 7, 8, 9, 10
Señor Ventura escribió:@Diskover ¿en el juego original no hay laser?.


Sí, pero está formado con fragmentos, no es una linea continua.
Diskover escribió: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.

Imagen


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


Mmm... normalmente la interrupción se dispara al llegar al final de la scanline y aquí el laser lo dibuja a partir de cualquier punto de la pantalla. Supongo que tendrá un precálculo de en que momento se ha de hacer el cambio de fondo a partir de la interrupción de hblank de la linea anterior, de forma similar a como se hace con la colisión del sprite 0 en otros juegos pero mucho más eficiente.
MasterDan escribió:Mmm... normalmente la interrupción se dispara al llegar al final de la scanline y aquí el laser lo dibuja a partir de cualquier punto de la pantalla. Supongo que tendrá un precálculo de en que momento se ha de hacer el cambio de fondo a partir de la interrupción de hblank de la linea anterior, de forma similar a como se hace con la colisión del sprite 0 en otros juegos pero mucho más eficiente.


Como he explicado en el propio post, gracias a la ejecución del "raster", la interrupción cuando se ejecuta, puede nacer donde queramos si el raster está movido en el eje X.
Diskover escribió:
MasterDan escribió:Mmm... normalmente la interrupción se dispara al llegar al final de la scanline y aquí el laser lo dibuja a partir de cualquier punto de la pantalla. Supongo que tendrá un precálculo de en que momento se ha de hacer el cambio de fondo a partir de la interrupción de hblank de la linea anterior, de forma similar a como se hace con la colisión del sprite 0 en otros juegos pero mucho más eficiente.


Como he explicado en el propio post, gracias a la ejecución del "raster", la interrupción cuando se ejecuta, puede nacer donde queramos si el raster está movido en el eje X.


¿Hacia arriba no?.
Señor Ventura escribió:
Diskover escribió:
MasterDan escribió:Mmm... normalmente la interrupción se dispara al llegar al final de la scanline y aquí el laser lo dibuja a partir de cualquier punto de la pantalla. Supongo que tendrá un precálculo de en que momento se ha de hacer el cambio de fondo a partir de la interrupción de hblank de la linea anterior, de forma similar a como se hace con la colisión del sprite 0 en otros juegos pero mucho más eficiente.


Como he explicado en el propio post, gracias a la ejecución del "raster", la interrupción cuando se ejecuta, puede nacer donde queramos si el raster está movido en el eje X.


¿Hacia arriba no?.


En NES parece ser que era muy, muy complicado hacer interrupciones de línea, e incluso rasters effect en vertical.

Cuando apareció el MMC5, por fin se pudo realizar el IRQ vertical, pero creo que un solo juego le ha dado uso. Olvídate incluso de ver algún efectillo chulo con ello por ahora, pues en la scene todavía no se han metido mucho con este mapper.

Y ahora que ha aparecido el mapper MXM-0, creo que la comunidad tirará por ahí, pues da muchísimo más que el MMC5.
Interesante proyecto que se está realizando por aquí:

@Diskover

Muy buena pinta.
Para Nes? Lo digo porque hay proyectos nes Style pero son para pc
Diskover escribió:Interesante proyecto que se está realizando por aquí:



Tiene mucho homenaje al Shatterhand
danibus escribió:@Diskover

Muy buena pinta.
Para Nes? Lo digo porque hay proyectos nes Style pero son para pc


Todo lo que salga en este hilo es para NES si o si
La verdad es que se está sacando bastante jugo a NES últimamente sin entrar en el uso de chips de apoyo nuevos y rasps insertadas en cartuchos. Cuesta creer que algunos juegos que salen se muevan así tal cual en el sistema y muchas veces es simplemente por un gran trabajo en el diseño gráfico y buen uso de la paleta de colores ¿Qué cosas lllegaríamos a ver en NES y MS en sus buenos años si ya existiera un mercado grande con consumidores adultos comprando juegos todos los meses?

Y para quien se lo haya perdido, @Diskover ha retomado su homebrew de portear Vigilante a NES. El hilo es este: hilo_homebrew-vigilante-para-nes-port-de-sms_2174926
@SuperPadLand La gracia del doom de la NES es que alcanza los 60fps a pantalla completa, cosa imposible de conseguir ni por las 16 bits. El buffer de megadrive y snes limita cualquier streaming a 30fps, y con un tamaño de pantalla no demasiado grande.
Echadle un ojo a esto, ya no serían necesarias pistolas de 400€ para jugar cuatro juegos en un LCD: http://neslcdmod.com/
Os dejo un video del programador homebrew CutterCross, quien está desarrollando un programa de dibujo "tipo paint" para la NES.

Es muy curioso el dominio que tiene sobre la máquina, a la cual le saca tanto partido que consigue poner hasta 104 colores en pantalla usando distintos trucos.



Así como hacer efectos raster sin ningún tipo de chip de apoyo.

¿Una IA jugando al Tetris de la NES hasta hacerlo mierda?

Si, aquí es:

Diskover escribió:¿Una IA jugando al Tetris de la NES hasta hacerlo mierda?

Si, aquí es:



A ver quién es el guapo que coloca las "L"´s a esa velocidad :Ð .

Impresiona verlo...yo en los primeros niveles sigo el mismo patrón de dejar una columna vacía pero claro...llega un momento que la velocidad de dedos y del juego no se coordinan...es que ha sacado 10 veces más puntuación [boing]
Curioso es que el juego se crashee mucho después de superar los límites originales para un humano.
Interesante artículo del usuario de Twitter @upsilandre, que nos narra como la NES fue "descubriendo" el scroll en varias direcciones, y abre debate sobre si Nintendo diseñó la consola con esa perspectiva o si fue todo un cumulo de investigaciones y desarrollo entre varias compañías.

SPOILER: diseño claro desde el principio pero soltado a cuenta gotas.

Link: LE PARADOXE ORIGINEL DE LA FAMICOM
¿Como es esto posible?:

Imagen
Señor Ventura escribió:¿Como es esto posible?:

Imagen

Actualizaciones del background al vuelo, en posiblemente bloques de metatiles de 32x32 para ahorrar espacio.

Con la picha si tienes un código bien depurado.

Los objetos como player, enemigos, etc... Son sprites
Señor Ventura escribió:¿Como es esto posible?:

Imagen


¿Cómo se llama?
SuperPadLand escribió:
Señor Ventura escribió:¿Como es esto posible?:

Imagen


¿Cómo se llama?


Es el After Burner.
@Papitxulo no me avergüenza admitir que nunca fui capaz de pasar la primera fase en ninguna de sus versiones. [carcajad]
Diskover escribió:Actualizaciones del background al vuelo, en posiblemente bloques de metatiles de 32x32 para ahorrar espacio.

Con la picha si tienes un código bien depurado.

Los objetos como player, enemigos, etc... Son sprites


Esa es la gracia, que no es solo actualización de las tiles del fondo como si fuera un vídeo, sino que deben indicar su prioridad, y en que punto pueden empezar a representar una colusión (incluir su caja de colisiones, y tal).

Este hardware es infinito...
Señor Ventura escribió:
Diskover escribió:Actualizaciones del background al vuelo, en posiblemente bloques de metatiles de 32x32 para ahorrar espacio.

Con la picha si tienes un código bien depurado.

Los objetos como player, enemigos, etc... Son sprites


Esa es la gracia, que no es solo actualización de las tiles del fondo como si fuera un vídeo, sino que deben indicar su prioridad, y en que punto pueden empezar a representar una colusión (incluir su caja de colisiones, y tal).

Este hardware es infinito...

Un truco: las torres de paredes laterales no tienen colisiones. Simplemente el avión no debe salirse de X coordenadas. Si se sale, explota.
@Diskover era más mágico pensar que estaba procesando colisiones a granel [jaja]
SuperPadLand escribió:@Diskover era más mágico pensar que estaba procesando colisiones a granel [jaja]

Solo los sprites y solo cuando está en la línea Z más cercana (o Y más baja si queréis verlo de otra forma).
Desde el móvil no puedo enlazarlo, pero sabéis el vídeo de kirkzz de su prototipo RGB donde pone dos CRT con dos NES una compuesto y otra RGB. El juego es Panic Restaurant, total que sale una valla, en RCA es un amasijo de píxeles borroso y en RGB se ve que realmente dibujaron una alambrada formada por pequeños rombos.

Lo demás sólo noto cambios en los colores y en las letras, pero nada exagerado. El caso ¿Qué creéis que es mejor? El efecto reja rgb o rca? Conocéis más casos donde se vea tan diferente?
Diskover escribió:Solo los sprites y solo cuando está en la línea Z más cercana (o Y más baja si queréis verlo de otra forma).


Solo se está burlando de mi, no es que le interese tanto xD

El caso es que para dibujar los tiles del escenario se hace puramente de forma manual, ¿no?. No hay tablas de atributos que te permitan alterar tiles entre varios planos dado que solo tiene uno, así que básicamente es una animación, ya que por otro lado la nes tiene posibilidades casi ilimitadas en ese sentido.

Imagino que la forma en que se construye la fase implica precachear un buffer con los tiles cada uno en su sitio, y ya si, construir la imagen... lo cual tampoco es moco de pavo para la cpu porque no es una imagen fija como un vídeo, sino que es mas "procedural".

Vamos, que si que tira de cpu, ¿no?.
Señor Ventura escribió:
Diskover escribió:Solo los sprites y solo cuando está en la línea Z más cercana (o Y más baja si queréis verlo de otra forma).


Solo se está burlando de mi, no es que le interese tanto xD


No, no estoy burlándome de ti. Si tienes algún problema el botón de reporte está en todos los post.

El aporte que has hecho me parece interesante de hecho.
No encuentro ninguna forma de que darle una propiedad a cada tile pudiera ofrecer mas ventajas que una o varias líneas verticales para detectar colisiones.

Dos línas a cada lado para detectar solo las colisiones manejadas por el avión del jugador.
Dos líneas cercanas para detectar colisiones para misies, proyectiles, vehículos y aviones enemigos.
Dos, cuatro, ocho, o las líneas que sean mas hacia el fondo para que todo objeto controlado por la IA pued dar la sensación de colisionar al fondo del escenario.


Siempre será mas barato de recursos hacerlo así que controlando cada tile, cuando de hecho los propios sprites ya tienen sus propiedades y sus cajas de colisiones, hacerlo por partido doble (avión y pared de piedra, por ejemplo, es una redundancia, inaceptable. Un error grosero, incluso.
Señor Ventura escribió:
Diskover escribió:Solo los sprites y solo cuando está en la línea Z más cercana (o Y más baja si queréis verlo de otra forma).


Solo se está burlando de mi, no es que le interese tanto xD

El caso es que para dibujar los tiles del escenario se hace puramente de forma manual, ¿no?. No hay tablas de atributos que te permitan alterar tiles entre varios planos dado que solo tiene uno, así que básicamente es una animación, ya que por otro lado la nes tiene posibilidades casi ilimitadas en ese sentido.

Imagino que la forma en que se construye la fase implica precachear un buffer con los tiles cada uno en su sitio, y ya si, construir la imagen... lo cual tampoco es moco de pavo para la cpu porque no es una imagen fija como un vídeo, sino que es mas "procedural".

Vamos, que si que tira de cpu, ¿no?.

Me pongo en su situación y yo lo que haría sería tener varias tablas de backgrounds formado por metatiles de 32x32 que dibujasen plano a plano las secuencias de animación que va a tener X nivel.

Fíjate que a fin de cuentas es muy repetitivo, y con unos 12 muestreos distintos, se puede tener un nivel con distintas combinaciones.

Pero vamos, es como yo creo que se haría.

De lo que tira es de la PPU, no de la CPU. Cambia el background cuando la linea de escaneo llega al VBlank; unos pocos milisegundos. Se usar ese momento para procesar toda la lógica del juego y los cambios de backgrounds (que en un juego con scroll, se suele hacer fuera de pantalla para que surja "la magia"). En este caso, el cambio de background se hace delante de tus narices, y como mucho se suele cambiar 32 metatiles de 16x16 pixeles para que no salte todo por los aires.
@Diskover acabo de leer que Elite sólo fue posible en PAL porque la consola funciona a 50fps y en NTSC al ser 60 la máquina no llegaba ¿Esto está mal no?
SuperPadLand escribió:@Diskover acabo de leer que Elite sólo fue posible en PAL porque la consola funciona a 50fps y en NTSC al ser 60 la máquina no llegaba ¿Esto está mal no?


Por lo que tengo entendido, el sistema PAL de la NES permite dibujar hasta 240 líneas de escaneo en vez de 224 líneas, aunque luego la mayoría de los videojuegos de NES dibujen 224 líneas.

Si vas a programar exclusivamente en PAL, puedes aprovechar esas líneas extras para activar el VBLANK (donde se procesa toda la lógica del juego y se actualiza la memoria de vídeo) durante más tiempo; y eso es lo que hace Elite: en PAL tiene más tiempo para dibujar en los 256 tiles de vídeo el trazado de líneas vectoriales (realmente no consigue dibujar en los 256 tiles la vez, solo en unas 190 tiles), cosa que en NTSC no le daría tiempo, quedándose bastante corto (quizá en 130 tiles).

En ese hilo de AtariAge hablan sobre ello: https://atariage.com/forums/topic/23534 ... -ntsc-nes/
@Diskover interesante, pero en una hipotética versión NTSC podría funcionar bajando la res a 208 y hasta 224 una franja negra para el VBlank?
SuperPadLand escribió:@Diskover interesante, pero en una hipotética versión NTSC podría funcionar bajando la res a 208 y hasta 224 una franja negra para el VBlank?

Si, creo que esa sería una buena solución
@Diskover guay era mi principal duda, por otra parte si se usa el juego en una NTSC qué pasa? Se cuelga? [tomaaa]
SuperPadLand escribió:@Diskover guay era mi principal duda, por otra parte si se usa el juego en una NTSC qué pasa? Se cuelga? [tomaaa]

No, pero verás fallos gráficos graves al faltar esa cantidad de tiles que no les da tiempo a dibujar al vuelo con gráficos vectoriales.

Verás naves formadas parcialmente
@Diskover curioso, pues esa franja negra en NTSC y listo que más franjas negras nos hemos comido aquí [qmparto]
@Creation se sabe si este nuevo mapper cuando terminen de comercializar su juego será introducido en el everdrive de kirkzz? Porque es un factor importante a valorar si pillarme el chino de 80€ o el vip de 200. Por este juego y otros futuros que usen ese mapper me cunde el desembolso (suponiendo que vendan dichos juegos en digital claro).
@SuperPadLand en teoría krikzz implementaría este nuevo mapper actualizando su versión de OS del EDN8Pro una vez el juego sea liberado y su Rom este disponible
( esto no se a confirmado por krikzz ni se sabe si será llevado a cabo )
@diskover algo que no encuentro de NES es su "configurabilidad" de resoluciones y colores en pantalla, ya sabes lo típico de otros sistema retro que podían soportar resoluciones más altas usando menos colores o por ejemplo en SNES que según el modo gráfico usado el número de colores, planos, etc. va cambiando.

El caso es que mirando Castelian al usar el efecto gráfico de la torre se nota que los colores son muchos menos ¿6?


Algo que aumenta en las fases laterales, salvo que esté engañado:



@Creation los creadores del juego confirmaron que será compatible con el flashcard de kirkzz y que podrá comprarse digitalmente, sólo con ese flashcard porque tiene una FPGA suficiente para ese mapper. Supongo que ya lo han hablado con Kirkzz o que venderán el juego digitalmente preparado para que la FPGA se transforme en el mape nuevo.
SuperPadLand escribió:@diskover algo que no encuentro de NES es su "configurabilidad" de resoluciones y colores en pantalla, ya sabes lo típico de otros sistema retro que podían soportar resoluciones más altas usando menos colores o por ejemplo en SNES que según el modo gráfico usado el número de colores, planos, etc. va cambiando.

El caso es que mirando Castelian al usar el efecto gráfico de la torre se nota que los colores son muchos menos ¿6?


Algo que aumenta en las fases laterales, salvo que esté engañado:


Dado que los colores de background van en una máscara aparte (atributos de color), quedaría muy feo aplicar colores a trompicones cada vez que un bloque gira en el efecto de torre, dado que estos atributos van en celdas de 16x16 píxeles, así que lo mejor es que sea siempre el mismo color y no haya que moverlo.

Haciendo scroll estos problemas pueden solventarse haciendo los cambios de color fuera de cámara, y aun así son cientos los juegos de NES a los que se les descubre el truco en el lateral derecho de pantalla cuando hay cambios en los atributos de color del background (SMB. 3, por ejemplo), con que imagínate si hay que hacerlo con la cámara mirando.

Siempre tenéis que imaginar los gráficos background de la NES como si fuesen en blanco y negro y luego se le aplicase una capa de color por debajo (color compartido) y otra capa por encima (atributos de tres colores)
@Diskover entonces no hay restricciones de colores-res-rendimiento como en otros sistemas retro?
SuperPadLand escribió:@Diskover entonces no hay restricciones de colores-res-rendimiento como en otros sistemas retro?


No. La cantidad de colores no importa en el rendimiento; es algo ya fijado, igual que la resolución. Además, todos estos aspectos de vídeo están controlados por la GPU, liberando tareas a la CPU central.
@Diskover por un casual sabes si en MS es lo mismo? Usa el modo 192p prácticamente siempre pese a soportar 240 (o era 224) y leí que se debía a que los primeros modelos el chip gráfico sólo soportaba 192 y por ofrecer compatibilidad los desarrolladores subían la res, pero me extraña que en Brasil y Europa del 90 en adelante no se usase en alguno de sus exclusivos porque creo que esa incompatibilidad es sólo en los primeros sistemas japoneses y USA.
SuperPadLand escribió:@Diskover por un casual sabes si en MS es lo mismo? Usa el modo 192p prácticamente siempre pese a soportar 240 (o era 224) y leí que se debía a que los primeros modelos el chip gráfico sólo soportaba 192 y por ofrecer compatibilidad los desarrolladores subían la res, pero me extraña que en Brasil y Europa del 90 en adelante no se usase en alguno de sus exclusivos porque creo que esa incompatibilidad es sólo en los primeros sistemas japoneses y USA.

Creo que si, que es el mismo caso.

Si la actualización de resolución no se usó en los 90 en los territorios donde todavía tenía mercado SMS, creo que se debe más a un desconocimiento de este modo de vídeo que a otra cosa.

He leído que en NTSC podía llegar a dar 224p y en PAL los 240p, pero que siempre se restringió todo a 192p.

¿Quizá alguna norma de SEGA sobre el sistema?
Diskover escribió:
SuperPadLand escribió:@Diskover por un casual sabes si en MS es lo mismo? Usa el modo 192p prácticamente siempre pese a soportar 240 (o era 224) y leí que se debía a que los primeros modelos el chip gráfico sólo soportaba 192 y por ofrecer compatibilidad los desarrolladores subían la res, pero me extraña que en Brasil y Europa del 90 en adelante no se usase en alguno de sus exclusivos porque creo que esa incompatibilidad es sólo en los primeros sistemas japoneses y USA.

Creo que si, que es el mismo caso.

Si la actualización de resolución no se usó en los 90 en los territorios donde todavía tenía mercado SMS, creo que se debe más a un desconocimiento de este modo de vídeo que a otra cosa.

He leído que en NTSC podía llegar a dar 224p y en PAL los 240p, pero que siempre se restringió todo a 192p.

¿Quizá alguna norma de SEGA sobre el sistema?


Buenas a los dos!
Diskover tiene razón en que NTSC podía usar 224 (y PAL 240p) a costa de un poco menos de tiempo de VBLANK.
Varios juegos de Codemasters si que usan la resolución alta (240 creo).
@kusfo79 y en PAL no tuvimos nada a 240p? Lo digo porque hay varios exclusivos [+risas]
@SuperPadLand
Los de Codemasters, exactamente estos segun smspower:
    · Cosmic Spacehead
    · MicroMachines
    · Fantastic Dizzy
    · The Excellent DIzzy collection
Fuente: https://www.smspower.org/Tags/Extra-Height
480 respuestas
Archivado
1…6, 7, 8, 9, 10
Volver a Consolas clásicas