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

Responder
1…8, 9, 10, 11, 12
@Diskover menuda barbaridad, inviable lo mires por donde lo mires, y más aún si encima no se le hubiera sacado provecho hasta varios años después.
aranya escribió:@Diskover menuda barbaridad, inviable lo mires por donde lo mires, y más aún si encima no se le hubiera sacado provecho hasta varios años después.

Quizá a esa segunda PPU se le podía haber limitado ciertas capacidades, como por ejemplo el uso de sprites, y que se dedicara en exclusiva solo a backgrounds.

De todas maneras, esto produciría realizar otro estudio y otro chip distinto, incrementando si o si costes pese a que en un primer momento pudiese verse como una versión barata.
Diskover escribió:
aranya escribió:@Diskover menuda barbaridad, inviable lo mires por donde lo mires, y más aún si encima no se le hubiera sacado provecho hasta varios años después.

Quizá a esa segunda PPU se le podía haber limitado ciertas capacidades, como por ejemplo el uso de sprites, y que se dedicara en exclusiva solo a backgrounds.

De todas maneras, esto produciría realizar otro estudio y otro chip distinto, incrementando si o si costes pese a que en un primer momento pudiese verse como una versión barata.

Casi que mejor meter más sprites que otro fondo y nos quitamos los parpadeos [carcajad]
cirote3 escribió:Casi que mejor meter más sprites que otro fondo y nos quitamos los parpadeos [carcajad]

Nos quitamos de parpadeos y entonces los desarrolladores se quejarían de que programar con dos PPU en paralelo, es arduo dificil, dejando sin usar la segunda cada dos por tres.

A esto sumale que el hecho de dedicarla solo a sprites, y suponiendo que fuesen otros 64 más (o sea, 128 en total) se iba a ver limitado a ciertos momentos y efectos que no requiriesen de proceso de colisiones, que si la CPU ya en muchos escenarios se ahogaba, imaginate.
Diskover escribió:
cirote3 escribió:Casi que mejor meter más sprites que otro fondo y nos quitamos los parpadeos [carcajad]

Nos quitamos de parpadeos y entonces los desarrolladores se quejarían de que programar con dos PPU en paralelo, es arduo dificil, dejando sin usar la segunda cada dos por tres.

A esto sumale que el hecho de dedicarla solo a sprites, y suponiendo que fuesen otros 64 más (o sea, 128 en total) se iba a ver limitado a ciertos momentos y efectos que no requiriesen de proceso de colisiones, que si la CPU ya en muchos escenarios se ahogaba, imaginate.

Que yo sepa los desarrolladores de la Supergrafx no tuvieron ningún problema en usar dos VDCs para mostrar dos capas de sprites. Si te sobran sprites, siempre puedes usarlos para hacer o mejorar efectos de parallax, como si fueran pequeños trozos de otro fondo. Supongo que es cuestión de gustos, pero yo prefiero mil veces quitar los parpadeos de sprites que meter otro fondo.
.
cirote3 escribió:
Diskover escribió:
cirote3 escribió:Casi que mejor meter más sprites que otro fondo y nos quitamos los parpadeos [carcajad]

Nos quitamos de parpadeos y entonces los desarrolladores se quejarían de que programar con dos PPU en paralelo, es arduo dificil, dejando sin usar la segunda cada dos por tres.

A esto sumale que el hecho de dedicarla solo a sprites, y suponiendo que fuesen otros 64 más (o sea, 128 en total) se iba a ver limitado a ciertos momentos y efectos que no requiriesen de proceso de colisiones, que si la CPU ya en muchos escenarios se ahogaba, imaginate.

Que yo sepa los desarrolladores de la Supergrafx no tuvieron ningún problema en usar dos VDCs para mostrar dos capas de sprites. Si te sobran sprites, siempre puedes usarlos para hacer o mejorar efectos de parallax, como si fueran pequeños trozos de otro fondo. Supongo que es cuestión de gustos, pero yo prefiero mil veces quitar los parpadeos de sprites que meter otro fondo.


Los desarrolladores de SuperGrafx, en 1989 tenían unas herramientas que estaban a años luz de las herramientas de la Famicom de 1983, que eran nulas.

A los desarrolladores de Famicom, les costo dolor, lagrimas y ayuda de Dios (en inversión de I+D) para poder desarrollar cualquier cosa en Famicom/NES, y no fue hasta 1989 cuando ya podemos decir que la tenían bastante dominada la gran mayoría.

Ponles una PPU en paralelo con cero herramientas de desarrollo, y seguramente te mandasen a la mierda o se dedicarían a sacar juegos centrados solo a la PPU principal para evitar rollos.

Pero el tema no es este. El tema es que en cuanto a costes y precio final de salida de la consola, se iría de madre todo.
Diskover escribió:
cirote3 escribió:
Diskover escribió:Nos quitamos de parpadeos y entonces los desarrolladores se quejarían de que programar con dos PPU en paralelo, es arduo dificil, dejando sin usar la segunda cada dos por tres.

A esto sumale que el hecho de dedicarla solo a sprites, y suponiendo que fuesen otros 64 más (o sea, 128 en total) se iba a ver limitado a ciertos momentos y efectos que no requiriesen de proceso de colisiones, que si la CPU ya en muchos escenarios se ahogaba, imaginate.

Que yo sepa los desarrolladores de la Supergrafx no tuvieron ningún problema en usar dos VDCs para mostrar dos capas de sprites. Si te sobran sprites, siempre puedes usarlos para hacer o mejorar efectos de parallax, como si fueran pequeños trozos de otro fondo. Supongo que es cuestión de gustos, pero yo prefiero mil veces quitar los parpadeos de sprites que meter otro fondo.


Los desarrolladores de SuperGrafx, en 1989 tenían unas herramientas que estaban a años luz de las herramientas de la Famicom de 1983, que eran nulas.

A los desarrolladores de Famicom, les costo dolor, lagrimas y ayuda de Dios (en inversión de I+D) para poder desarrollar cualquier cosa en Famicom/NES, y no fue hasta 1989 cuando ya podemos decir que la tenían bastante dominada la gran mayoría.

Ponles una PPU en paralelo con cero herramientas de desarrollo, y seguramente te mandasen a la mierda o se dedicarían a sacar juegos centrados solo a la PPU principal para evitar rollos.

Pero si fuera así también las pasarían muy putas por tener que usar una segunda PPU para mostrar otro fondo, y seguramente te mandasen aún más a la mierda porque mostrar otro fondo es menos útil que mostrar más sprites, ¿no? XD

Otro tema a tener en cuenta es que si quieres un juego con pantallas con doble fondo, el tamaño de la ROM va a aumentar bastante, mientras que quitar los parpadeos de sprites no tiene por qué aumentar mucho el tamaño de la ROM. En el 83 una consola con dos fondos no tendría mucho sentido, creo.
cirote3 escribió:Pero si fuera así también las pasarían muy putas por tener que usar una segunda PPU para mostrar otro fondo, y seguramente te mandasen aún más a la mierda porque mostrar otro fondo es menos útil que mostrar más sprites, ¿no? XD

Otro tema a tener en cuenta es que si quieres un juego con pantallas con doble fondo, el tamaño de la ROM va a aumentar bastante, mientras que quitar los parpadeos de sprites no tiene por qué aumentar mucho el tamaño de la ROM. En el 83 una consola con dos fondos no tendría mucho sentido, creo.

Esa es otra: el tamaño de las ROMs

Si ya de por sí eran caras, añadir más, encarecía el producto.

De todas formas, con la ROM base se puede seguir usando esa segunda PPU, pero los gráficos seguramente iban a ser muy repetitivos.
Diskover escribió:
cirote3 escribió:Pero si fuera así también las pasarían muy putas por tener que usar una segunda PPU para mostrar otro fondo, y seguramente te mandasen aún más a la mierda porque mostrar otro fondo es menos útil que mostrar más sprites, ¿no? XD

Otro tema a tener en cuenta es que si quieres un juego con pantallas con doble fondo, el tamaño de la ROM va a aumentar bastante, mientras que quitar los parpadeos de sprites no tiene por qué aumentar mucho el tamaño de la ROM. En el 83 una consola con dos fondos no tendría mucho sentido, creo.

Esa es otra: el tamaño de las ROMs

Si ya de por sí eran caras, añadir más, encarecía el producto.

De todas formas, con la ROM base se puede seguir usando esa segunda PPU, pero los gráficos seguramente iban a ser muy repetitivos.

Algo me dice que ese fue uno de los motivos por los que NEC prefirió soportar en la PC Engine más sprites por scanline en vez de meter otro fondo.
@cirote3 yo también creo que en esos años el tema "generaciones de consolas" no existía o no lo tomaban en cuenta como ahora en el sentido de que tenias que diseñar maquina no sólo mejor que lo anterior sino también con vistas a aguantar el pulso durante 5 años y no pensaron más que en hacer una máquina mejor que NES sin pensar que al poco competirían con MD y SNES.
SuperPadLand escribió:@cirote3 yo también creo que en esos años el tema "generaciones de consolas" no existía o no lo tomaban en cuenta como ahora en el sentido de que tenias que diseñar maquina no sólo mejor que lo anterior sino también con vistas a aguantar el pulso durante 5 años y no pensaron más que en hacer una máquina mejor que NES sin pensar que al poco competirían con MD y SNES.

Sega no era gran competencia en Japón y Nintendo sacó la SNES 3 años después de que saliera la PC Engine, así que no empezaron a competir precisamente "al poco" XD

De hecho la verdadera competencia de la SNES iba a ser la SuperGrafx, la cual sacaron un año antes que la SNES.
Vamos a ver que se está cociendo últimamente en la scene homebrew de NES.

Good Tune, lanzó Gold Guardian Gun Girl 2 hace un par de semanas, y luce espectacular.










Este mismo grupo de desarrollo, sigue experimentando cosas en la NES, y nos va poniendo sobre aviso:





Pequeños trucos que se pueden hacer en NES y que en su época nadie exploto.



Explicación:

En el caso del laser, está dibujando una pantalla totalmente azul en el nametable donde no apunta la cámara (recordad que la NES tiene cuatro nametables, aunque se usan dos en vertical u horizontal según convenga, y el resto espejado a no ser que se use el modo window, o el 4 mirror).

Luego, mediante un IRQ bien calculado y preciso, muestra esta pantalla en el nametable donde está apuntando la camara del juego, y lo acorta justo un pixel para que parezca un laser.

Por otro lado, el boss se está dibujando en el propio background, utilizando, además, bancos de memoria del CHR para la animación superior e inferior de su movimiento cada ocho pixeles. Un truco visual raramente usado pero que da el pego. Para moverle horizontalmente, bastaría con usar el IRQ, pero claro, en esa escena el IRQ ya se está usando para el efecto laser, así que o una cosa o la otra.

Por cierto, este mismo tío acaba de hacer esto otro:




Otra explicación sobre el mismo "efecto monocromo" en NES que utilizó el año pasado para Gradius:

Como si de un Super FX se tratase, aquí tenemos pruebas con polígonos para NES, gracias al FC PICO.





Más info sobre FC PICO: https://impactsoft.booth.pm/items/7736698
Hace unos días se presentó este proyecto tanto para MSX como para MSX2.

Inspirado en Mirror's Edge, ahora tenemos aquí un intento para realizar la versión de NES.

Se está usando el mapper 5 (Nintendo, 1989), y debido a las limitaciones tan peculiares de esta 8 bits, la consa se está complicando.

Siguen mejorando la versión Space Harrier para NES, ahora sacandole 30fps estables.

Andamos estos días muy extrañados con las publicaciones de este usuario japones en Twitter: https://x.com/yunomifactory

Hace días publico un video donde mostraba un programa que estaba desarrollando en Famicom, juego tipo shotem'up. Llamaba mucho la atención el salto del límite de 64 tiles por frame sin parpadeos.



Las respuestas a todas las preguntas son muy escuetas, pero hasta ahora, asegura que está usando en el background tiles de 8x8 (similar a lo que se podía usar en MMC5), y que usa comando para WRAM donde puede dibujar lineas tipo vector, o cambiar el BG detrás de los sprites a los valores de la paleta 3 usando las coordenadas enviadas por DMA de sprites (esto, según el, es lo que reduce el parpadeo).

Dicho esto, entiendo que está usando un mapper propio. Como digo, sus respuestas son muy escuetas y plantean dudas.





Pero más sorprendente es este otro vídeo:




Aquí ya directamente está tirando la casa por la ventana.

Pasados unos días, ha soltado prenda: esta usando Raspberry 2350B

Lo usa como almacenamiento PRG y CHR, usando la CHR en modo RAM, y, por tanto, dibujando en ella al vuelo lo que le de la gana dentro de los límites de la Famicom/NES. Por eso decía que hacia algo similar al MMC5



Un poco más de contexto, pues al parecer no esta muy alejado de lo que está haciendo Something Studio con su Former Dawn.

Digamos que esta persona ha creado un cartucho con tres mappers diferentes y un el exRAM como MMC5 .

"Este juego de disparos funciona con un cartucho de diseño original. Utiliza una RP2350B para cada respuesta del bus de CPU y del bus de PPU, evitando el uso de NOR FLASH de 5V y SRAM paralelo de 5V que se están volviendo difíciles de conseguir, para constituir un cartucho de Famicom. Este cartucho cuenta con tres modos: mapeador 0, mapeador 30 y gráficos extendidos. En el modo de gráficos extendidos, al igual que con el MMC5, se deshabilita el CIRAM del lado del cuerpo de la Famicom, y la RP2350B para la respuesta del bus de PPU responde a todo, incluyendo la región de la tabla de nombres. De esta manera, se logran las siguientes características.

・Cada baldosa de 8×8 puede seleccionar independientemente una de cuatro paletas de fondo
・Es posible especificar patrones diferentes para todas las 960 baldosas máximas de la pantalla
・Tabla de nombres virtual (4 pantallas)

Además, en el modo de gráficos extendidos, es posible enviar comandos a la RP2350B del lado de la PPU escribiendo valores en direcciones específicas de la WRAM del 6502. Con estos comandos, se puede leer datos de la memoria flash de 16 MB o ejecutar varios tipos de comandos de dibujo de imágenes. En este juego de disparos, se utiliza una pantalla de superposición de 1 bpp para dibujar varios efectos (por ejemplo, partículas).

Al escribir un 1 en la pantalla de superposición, el BG en esa posición se mostrará con la paleta 3. Al usar esta función para dibujar la forma de la bala en superposición sobre la "sombra" del sprite de bala enemiga, se previene que la bala desaparezca completamente cuando ocurre un desbordamiento en el número de sprites mostrados. Aunque esta visualización alternativa del sprite se muestra en un solo color usando la paleta del BG, por lo que no se puede reproducir el color original del sprite, si se usa hábilmente, puede reducir el parpadeo de las balas."

En desarrollo.

Es la propia NES con un mappeador similar al MMC5 y muuuuucha cantidad de ROM.



Este mappeador similar al MMC5, al tener acceso total a todo el CHR, puede reproducir graficos ya renderizados, masticados, como si de un vídeo se tratase.



El concepto no es algo nuevo. Pudimos ver algo así en Game Boy Color con el videojuego Toy Story Racer



De hecho, si quisieran, podría portarse tal cual.
568 respuestas
Responder
1…8, 9, 10, 11, 12
Volver a Consolas clásicas