[HO] Former Dawn (NES). Avances y actualizaciones.

SuperPadLand escribió:Pero por ejemplo ,SMS podría usar un mapeador para interrumpir el escaneo como en este juego para generar las siluetas con el color del fondo? Me refiero a este tipo de cosas que parece que solo NES puede y no entiendo el porqué.

Pues a priori, en el canal de Discord aseguran que ni SMS, ni Mega Drive, ni siquiera la SNES pueden hacer esto.

Yo creo que realmente sí podrían hacerlo, pero todavía no se ha averiguado como.

Diskover escribió:

SuperPadLand escribió:Pero por ejemplo ,SMS podría usar un mapeador para interrumpir el escaneo como en este juego para generar las siluetas con el color del fondo? Me refiero a este tipo de cosas que parece que solo NES puede y no entiendo el porqué.

Pues a priori, en el canal de Discord aseguran que ni SMS, ni Mega Drive, ni siquiera la SNES pueden hacer esto.

Yo creo que realmente sí podrían hacerlo, pero todavía no se ha averiguado como.

Los chips gráficos de la SNES y la MD trabajan con datos situados en VRAM, no en el cartucho, así que es difícil (por no decir imposible, supongo) que el cartucho pueda alterar o interrumpir el renderizado del chip gráfico.

Por eso los SuperFX, el SVP y el MegaCD no eran capaces de mostrar nada por ellos mismos, y los tiles a mostrar debían ser copiados a la VRAM del sistema anfitrión.

cirote3 escribió:Creo que el problema viene por utilizar el mismo palabro "mapper" para hablar de los mappers de la NES que los de otros sistemas. Mientras que en el resto de sistemas los mappers sólo se suelen utilizar para poder direccionar más memoria, en la NES se utilizan para muchas más cosas que poco tienen que ver con ello, como añadir canales de sonido extra por ejemplo. Si se utilizaran palabros diferentes para los dos casos, la gente lo entendería mejor y no habría tanto drama

Yo me refiero a mapper, mapper.

Proporcionar bancos grandes de gráficos, y ya. La nes no tiene límites actualizando tiles, y solo con eso ya tienes algo que solo una nes te puede dar (todos los tiles de plano y sprites actualizados a cada frame, 60fps).

Por otro lado, ya entrando en lo que no es un mapper, ¿cuantos hardwares admiten que cada pixel pueda tener el color que quieras de toda la paleta? (former dawn proporciona 1x8, pero me suena que ya afirmaron que es posible 1x1).

Sería posible aplicar un pseudo direct color en la nes, cosa que ni con procesadores extra cualquier hardware podría admitir, o al menos sin consecuencias (como tener que anular los sprites en algún caso).

cirote3 escribió:

Diskover escribió:

SuperPadLand escribió:Pero por ejemplo ,SMS podría usar un mapeador para interrumpir el escaneo como en este juego para generar las siluetas con el color del fondo? Me refiero a este tipo de cosas que parece que solo NES puede y no entiendo el porqué.

Pues a priori, en el canal de Discord aseguran que ni SMS, ni Mega Drive, ni siquiera la SNES pueden hacer esto.

Yo creo que realmente sí podrían hacerlo, pero todavía no se ha averiguado como.

Los chips gráficos de la SNES y la MD trabajan con datos situados en VRAM, no en el cartucho, así que es difícil (por no decir imposible, supongo) que el cartucho pueda alterar o interrumpir el renderizado del chip gráfico.

Por eso los SuperFX, el SVP y el MegaCD no eran capaces de mostrar nada por ellos mismos, y los tiles a mostrar debían ser copiados a la VRAM del sistema anfitrión.

Y otros sistemas 'menores' tampoco podrían?: las Ataris, GB, PCE, MSX, la AmstradGX4000, Etc? Es que es raro esta excepcionalidad salvo que sea fruto del azar y que Nintendo optase por el diseño más barato y que colateralmente tuviese la buena fortuna de permitir estas cosas.

SuperPadLand escribió:

cirote3 escribió:

Diskover escribió:
Pues a priori, en el canal de Discord aseguran que ni SMS, ni Mega Drive, ni siquiera la SNES pueden hacer esto.

Yo creo que realmente sí podrían hacerlo, pero todavía no se ha averiguado como.

Los chips gráficos de la SNES y la MD trabajan con datos situados en VRAM, no en el cartucho, así que es difícil (por no decir imposible, supongo) que el cartucho pueda alterar o interrumpir el renderizado del chip gráfico.

Por eso los SuperFX, el SVP y el MegaCD no eran capaces de mostrar nada por ellos mismos, y los tiles a mostrar debían ser copiados a la VRAM del sistema anfitrión.

Y otros sistemas 'menores' tampoco podrían?: las Ataris, GB, PCE, MSX, la AmstradGX4000, Etc? Es que es raro esta excepcionalidad salvo que sea fruto del azar y que Nintendo optase por el diseño más barato y que colateralmente tuviese la buena fortuna de permitir estas cosas.

Con la GB y la GBC (y la GBA) pasa lo mismo porque sus chips gráficos no tocan la ROM a la hora de renderizar, los datos a mostrar están en la VRAM. Supongo que Nintendo tendría un buen motivo para abandonar las ventajas de la NES con todas las consolas que hizo después (pasta ).

law escribió:Como tal, potenciadores en master system hay ram adicional en en dos juegos, terminator y the flash. Y en mega drive el svp, no recuerdo si alguno más.

Gracias por la info.

Mapeadores que añadan de manera opcional RAM a la NES, también existen. El propio MMC3 y muchos más.

Sexy MotherFucker escribió:El hardware nativo de las Famicom/NES no puede ejecutar desplazamiento vertical y horizontal al mismo tiempo sin sacrificar el sprite 0. Eso no es un "potencial bloqueado", sino una clara y documentada incapacidad del sistema. El chip ASIC MMC3 incorpora un temporizador IRQ de apoyo que hace el trabajo que la NES no puede hacer por sí misma, y gracias a éllo podemos gozar de ese suave scroll vertical/horizontal al mismo tiempo en Super Mario Bros 3 cuando volamos, sin renunciar a otras cosas.

No, pero casi. La NES puede hacer scroll vertical&horizontal, suave y fino, sin problema alguno.

Quizá por un fallo de diseño (o no), el problema es otro: la configuración de la memoria Mirroring, destinada a mostrar los backgrounds compuestos por nametables y que los atributos de color van por separado.

Primer problema: Disponemos de cuatro direcciones de memoria donde plasmar nuestros nametables (backgrounds), pero sí usamos scroll con carga de metatiles, memoria solo para cargar hasta dos nametables. Si necesitas cargar un nivel en cualquier dirección, date por jodido, porque ya te has condenado a utilizar o vertical u horizontal, y si haces diagonal, no vas a poder cargar correctamente los metatiles.

Segundo problema: la configuración de la memoria Mirroring va en el propio cartucho y no en la consola. Tienes muchas, pero tres son básicas.

- Vertical, que va bien si quieres juegos con scroll horizontal (Super Mario Bros., Megaman, The Legend of Zelda: Adventure's Link, etc...)



- Horizontal si quieres juegos con scroll vertical (Road Fighter, Ice Climber, etc...)



- 4-mirroring, pero solo puedes hacer scroll (horizontal, vertical, diagonal, etc...) en esas cuatro nametables que cargues.



Pese a estas configuraciones básicas, la cámara se puede mover libremente sobre las cuatro nametables sin problema, incluso diagonalmente. El problema va a ser siempre la carga del nametable con metatiles, que al mover la cámara, se va a ver el truco de la carga, porque se realiza justo en el borde final de la cámara, y si te has restringido a una configuración de Mirroring en concreto, no vas a poder dibujar el nivel correctamente. Verás fallos gráficos en el background.

El MMC3 o el VCR2, y siguientes mappers, permitían cambiar al vuelo el mirroring para, de esta forma, dibujar en cualquier dirección sin sacrificar errores visuales notables si se cargaba en horizontal o en vertical en cualquier momento.

Y aun así, vas a seguir viendo errores gráficos en el borde de la cámara en alguna de las direcciones de dibujado, en muchos juegos que usan estos mapeadores porque no había experiencia previa en programación para solventar estos problemas que hoy en día ya se consiguen corregir.

Como curiosidad, Hudson Soft sacó en 1984 el videojuego Raid on Bungeling Bay, donde podemos controlar mediante vista aérea un helicóptero volando en cualquier dirección, y su configuración Mirroring es Vertical. ¿Cómo es esto posible? Sacrificando detalles.

Si probáis el juego, notaréis que no va suave. Le eché un vistazo y vi que redujeron su velocidad a 30 frames, a la mitad, aunque el juego internamente trabaja a 60 frames. También me he fijado que carga nametables nuevos, PERO no atributos de color. Sospecho que ambos recortes se deben a que necesitaban liberar a la PPU de carga de trabajo para que le permitiese hacer el scroll multidireccional sin que se viesen errores gráficos luego.

Falta de experiencia

@Diskover

No, pero casi

El "casi", no me vale.

Ni el "¡aún sin hardware de apoyo se queda muy cerca neng!".

El temporizador IRQ de apoyo que calza el cartucho le añade una habilidad extra ausente en la Famicom/NES. Punto.

De todas formas pedazo post te has marcado, ¿eh? Mis diesels por la masterclass de NES

Señor Ventura escribió:
Por otro lado, ya entrando en lo que no es un mapper, ¿cuantos hardwares admiten que cada pixel pueda tener el color que quieras de toda la paleta? (former dawn proporciona 1x8, pero me suena que ya afirmaron que es posible 1x1).

Entiendo que dices de la paleta general, no de la paleta seleccionada en ese momento, no? Vamos, en el caso de la Master, cualquier color de los 64 de la paleta general, no los 16 de la paleta que hayas escogido para ese tile, no?

cirote3 escribió:Con la GB y la GBC (y la GBA) pasa lo mismo porque sus chips gráficos no tocan la ROM a la hora de renderizar, los datos a mostrar están en la VRAM. Supongo que Nintendo tendría un buen motivo para abandonar las ventajas de la NES con todas las consolas que hizo después (pasta ).

Pasta, y que en la época les limitó mucho, hasta casi el final de vida de la NES. Era un diseño que venía de los Arcades, pero casí ninguna consola usó.

kusfo79 escribió:Entiendo que dices de la paleta general, no de la paleta seleccionada en ese momento, no? Vamos, en el caso de la Master, cualquier color de los 64 de la paleta general, no los 16 de la paleta que hayas escogido para ese tile, no?

La subpaleta elegida para ese tile del plano puedes pintarla como quieras directamente, creo yo, ¿no?.

Entendí eso, que en former dawn están habilitando una subpaleta de 3 colores + transparente para cada línea horizontal de 8 pixels de un tile, por lo que "1x1", para implica que cada pixel conlleva una subpaleta, por lo que cada pixel puede elegir el color que quiera de la paleta madre.

No es direct color, pero en la práctica es como si lo fuera.


Diría que eso es lo que significa esto.

SexyMotherFucker escribió:yo soy quisquilloso con Señor Ventura ojo, no con la NES. Me molesta la manera en que difumina la realidad debido a un sentimiento propio. Es un tío que necesita hostias foriles cada X tiempo para que aterrize en la cruda, o no cruda, realidad. Es por su bien, no me cae mal, pero me irrita que un tío de casi 50 años vaya por ahí con los ojos de un niño. Hay que reprenderle, como a los niños.

Pero si eso lo haces tu con los hardwares que te interesan xD

Estoy hablando de permitirle a la nes los tiles que la propia ppu es capaz de actualizar al vuelo, tu dices que eso es difuminar la realidad, y yo digo que es precisamente una capacidad que no recibe ayuda de ningún factor externo, no un sentimiento propio, sino un hecho. Quizás deberías plantearte que tal vez te reconoces en lo que CREES ver


P.D: ¿50 años?... ¿tu te has propuesto joderme el día? xD

SuperPadLand escribió:Pero por ejemplo ,SMS podría usar un mapeador para interrumpir el escaneo como en este juego para generar las siluetas con el color del fondo? Me refiero a este tipo de cosas que parece que solo NES puede y no entiendo el porqué.

El problema es que se trataría de una interrupción MIENTRAS el line buffer va dibujando la línea de píxeles. Un hardware externo es de sobra lo suficientemente rápido como para actualizar las subpaletas al vuelo, pero la máquina tiene que permitir hacerlo, y luego ser lo suficientemente rápida para conseguirlo. No existe interrupción que no implique un wait state lo suficientemente lento como para que el haz de electrones no dibuje basura hasta que el IRQ termine su proceso para aplicar una nueva subpaleta al pixel pretendido... y este hace un buen puñado de pixels que quedó atrás. Inviable.

Hubo una conversación hace tiempo sobre la serpiente del xeno crisis, usando hdma para dibujar de un plano la sección de pixeles horizontal de una parte del cuerpo de ese enemigo, y poder conseguir muchas secciones de su cuerpo sin parpadeo... bueno, pues no es posible porque el acceso al registro, la escritura de su valor, esperar a la lectura, y comenzar su dibujado, tiene un retraso, y generaría basura.

¿La solución?, alternar una sección del cuerpo dibujada desde un plano, con una sección del cuerpo dibujada con un sprite mientras preparas que el hardware esté listo para dibujar dibujar la siguiente sección desde el plano otra vez. Reduces a la mitad la sobrecarga de sprites por línea, pero queda patente que las interrupciónes mientras el line buffer está dibujando NO son instantáneas.


Pero la NES no parece tener este problema, y puede aplicarlo a todo. Si es instantáneo. Puede hablarse de lo ilegítimo que es un procesador de apoyo que lo habilite, pero hay que reconocer siempre que el hardware es capaz de hacerlo. Sin esa capacidad, no hay ayuda ni dopaje que valga.

Sexy MotherFucker escribió:@Diskover

No, pero casi

El "casi", no me vale.

Ni el "¡aún sin hardware de apoyo se queda muy cerca neng!".

El temporizador IRQ de apoyo que calza el cartucho le añade una habilidad extra ausente en la Famicom/NES. Punto.

De todas formas pedazo post te has marcado, ¿eh? Mis diesels por la masterclass de NES

Te lo he explicado: El IRQ no tiene nada que ver con el desplazamiento multidireccional. Sus problemas son otros.

Y sí, el IRQ es una habilidad añadida a la NES que no tiene en su hardware, que de otra forma debería realizar por software, restándole procesamiento útil a la CPU.

Por lo que tengo entendido, el IRQ es básicamente una tabla ya prefijada que hace la tarea de contar los ciclos de memoria de la CPU y cuando poder interrumpir en el HBlank la línea de escaneo. Hacer esto por software, es demencial y solo útil en escenas donde no haya que calcular nada más.

¿Se usa en algún momento IRQ por software en la NES? Si, por ejemplo en el videojuego Ninja Gaiden/Shadow Warrior, en su intro.



Pero insisto: el IRQ no tiene nada que ver con el desplazamiento multidireccional en la NES.

Por si acaso. También puede hacerlo durante el juego. No mapper, ni chip de apoyo de ninguna clase.

Ninja gaiden 2, fase 2-1.





Pero no se queda ahí, va mas allá:

@Diskover si te he entendido. Pero por software no alcanzas los niveles de calidad de un Super Mario Bros 3 como cuando vas volando con el mapache, porque la NES entre otras cosas sacrifica el sprite 0.

El dopping hace que no tenga que sacrificar nada en los desplazamientos, gracias a que hace un trabajo que la NES no puede por sí sola con el mismo nivel de calidad.

A vosotros os interesa resaltar las potencialidades de la NES, y está muy bien.

A mí resaltar las limitaciones. Para que no entre nadie al hilo y se piense que Former Down es un juego nativo de NES por sí misma, porque no lo es.

@Señor Ventura

P.D: ¿50 años?... ¿tu te has propuesto joderme el día? xD

Mmm, ¿del 78 no? Estás a un tris

No lo estás entendiendo, la capacidad de actualizar 1000 y pico tiles por frame, todos los frames, y además dejando el 100% del tiempo de cpu disponible, es algo que si forma parte del hardware de la nes.

Solo necesita poder ver esos tiles.



-Puedo pintarte la gioconda, ¿me pasas el carboncillo?.
-Jaja si no es por mi inestimable ayuda no podrías pintar la gioconda, el mérito de saber pintar es mio.



P.D: ¿yooooo deeeeel 78888888? xD

@Señor Ventura Hacer desplazamiento vertical y horizontal al mismo tiempo sin sacrificar el sprite 0 no entra dentro de las capacidades de la NES.

El MMC3 hace que sí pueda. Ya que haciéndolo nativamente, sin ayudas, ese efecto está más limitado en su uso, porque tiene que hacer un sacrificio.

La RAM extra del MMC3 hace que pueda poner más cosas en escena.

D-O-P-A-J-E

P.D: Y el símil seria: Un hombre sin brazos dice; "tengo el talento mental de pintar la Gioconda, pero no tengo brazos". Y un científico responde; "yo te presto unos cibernéticos y te suministro los materiales".

Estás cambiando mi argumento.

El gif del oasis de este former dawn es justo lo que una nes está capacitada para hacer, y no es mérito de ningún dopaje. Si quieres hablar de otras cosas hacemos punto y aparte, pero justo esto es algo que no puedes atacar por ningún lado.

@Señor Ventura Es que yo estaba hablando del indiscutible dopaje en el cartucho de SMB3 con Diskover y has entrado tú de repente. El comentario del oasis por mi parte no lo mencionó desde la página anterior, porque ya me puse a divagar sobre el dopaje en NES en general.

Sexy MotherFucker escribió:@satanjosein

Menuda currada se están metiendo, parece mentira que eso vaya a funcionar en una NES

Con la AYUDA necesaria todo es posible

Y a ver que no vengo a trolear el hilo: pedazo currazo de @Diskover por crearlo e irlo actualizando, y pedazo Obra de Arte este Former Dawn; vemos eso en la época y se nos caen las pistolas al suelo.

Yo sólo entro para hacer contrapeso al exceso de optimismo casi irracional de Señor Ventura, que no es sano dejar individuos así campar a sus anchas sin supervisión.

Para eso estamos nosotros si es necesario.

Basta.

7Force escribió:Por que el SVP en 1988 seguramente no hubiera sido posible, por costes y esos rollos, pero sí lo fue en 1994... y aun así costaba un riñón. O los megabits de las roms... 4 mbits en sus primeros años vs 16/32 en los finales... ¿Por qué 6 años son "validos" y 30 no?

Para mí son igual de "válidos" 6 años que 30 o los que vengan, pero a mí me interesa mucho más el homebrew que se ciñe al hardware de la época. Hay otros que prefieren ver lo más pepino posible saliendo de su consola aunque haya que enchufar una RTX al cartucho, y también está bien. Para gustos colores

7Force escribió:O vuelvo al sonido... meterle full pcm a una consola de 8 bits y que suene como una Neo Geo sería un dopaje nivel Dios... y si saliera tanto en su época como en estos tiempos nadie, nadie, "pondría el grito en el cielo". Pero si hablamos de gráficos es como que ñe, nos rechina por algún extraño y misterioso motivo xD

Es una limitación autoimpuesta que nunca entenderé.

Supongo que es porque la gente en general se suele interesar más por los gráficos que por el sonido, pero no lo sé

Señor Ventura escribió:Por si acaso. También puede hacerlo durante el juego. No mapper, ni chip de apoyo de ninguna clase.

Ninja gaiden 2, fase 2-1.

Nop.

Ninja Gaiden 2/Shadow Warrior 2 utiliza el mapper MMC3. En ese gif utiliza el contador IRQ intensamente.

Sexy MotherFucker escribió:@Señor Ventura Hacer desplazamiento vertical y horizontal al mismo tiempo sin sacrificar el sprite 0 no entra dentro de las capacidades de la NES.

El MMC3 hace que sí pueda. Ya que haciéndolo nativamente, sin ayudas, ese efecto está más limitado en su uso, porque tiene que hacer un sacrificio.

Efectivamente, no se podría usar el sprite zero, pero técnicamente, usando el IRQ el sprite zero ni lo usan porque ya no es necesario.

Sexy MotherFucker escribió:La RAM extra del MMC3 hace que pueda poner más cosas en escena.

La RAM extra de SMB. 3 sirve más que nada para poder contener en memoria las cosas que has destruido en el escenario, así como los bloques que ya has usado.

Antes de empezar un nivel, se envían los datos de estos a la RAM, y se lee desde la RAM todo el nivel. Al ser RAM se mantiene en memoria lo que se haya destruido o no. Si hubiese sido la lectura desde la ROM, obtendríamos una y otra vez el mismo nivel, aunque hubiésemos destruido previamente algún ladrillo o cogido algun bloque interrogante.

¿Quiere decir esto que sin MMC3 no se hubiese podido recrear un nivel de SMB. 3? Tampoco. Siempre podríamos programar un array de almacenamiento de datos modificados en la propia RAM de la NES para recordar que cosas han sido destruidas u obtenidas, pero claro, esa RAM está para otras cosas.

Antes escribí que la RAM también era necesaria para poder escribir los atributos de color y metatiles sin que se viese tan apretujado. PUES NO, ha sido una cagada mía. SMB. 3 no usa la RAM para eso. Eso te lo hace la NES a pelo sin problema, al parecer.

En el caso de SMB. 3 el MMC3 ayuda con el IRQ para mantener el marcador HUB siempre en un sitio prefijado, sin necesidad de usar sprite zero (que como bien has dicho antes, no sepodría usar con los desplazamientos multidireccionales). En la RAM ya se carga el nivel completo donde vamos a jugar, y el Mirroring lo tienen configurado en horizontal, dibujando en la nametable A y B vertical, todo el alto del nivel. Les queda al borde de la cámara la generación del escenario cuando nos movemos en horizontal, que en muchos casos podemos llegar a ver fallos gráficos y de color porque la cámara va más rápida que la generación de metatiles.

Cabe señalar que SMB. 3 tiene el alto restringido siempre a dos nametables, teniendo todos sus niveles una altura nunca superior a 480 pixeles.



Esto no significa que solo se pueda hacer scroll multidireccional de esta forma. Hay varias, pero esta es una de ellas, y se sabe a día de hoy que no es siquiera la más óptima, pero es hasta donde sabía llegar Nintendo en 1988.

Sunsoft ese mismo 1988 te lo hacía de otra manera. No usa el MMC3, sino el MMC1, ojo. Ellos optaron por otra configuración peculiar del Mirroring: Single Mirroring. Como ya comenté antes, podemos mover la cámara libremente por los cuatro nametables del mirroring. Sunsoft dibujaba el desplazamiento tanto horizontal como vertical al borde de cámara, dando igual la posición donde se situase dentro de las nametables. Cosas que también hacían juegos como Battletoads y muchos otros.



Blaster Master, gracias al Single-Mirroring no tiene un límite de alto ni ancho específico más haya de las capacidades de almacenamiento del cartucho y posibilidad de lectura de la PPU.

Nos vamos a 1993 y el desplazamiento multidireccional ya estaba más que mascado en el Jurassic Park de Ocean. Para ocultar errores gráficos en el desplazamiento vertical, se optó por poner unas barras negras que escondiesen este problema.



Si la NES a pelo es capad de hacer scroll multidireccional ¿Entonces porque no se hacía desde el principio? Pues porque en 1983 no tenían ni puñetera idea de como hacerlo, y en 1988 tenían los huevos pelados ya haciendo scroll como les diese la gana a Nintendo, a Rare, a Sunsoft, etc... Simplemente ganaron experiencia.

@Diskover sigues dándome la razón: el hardware de Famicom/NES no puede ejecutar el scroll multidireccional sin sacrificar el sprite Zero. Y el IRQ del MMC3 soluciona el asunto, y ya no hay que sacrificar nada porque no hace falta. A lo que voy es eso no es un "potencial bloqueado" de la NES, sino una incapacidad que el IRQ parchea.

El scroll multidireccional que ejecuta la NES por sí misma está más limitado que el que consigue con el MMC3.

Y con la RAM extra pues dopas al sistema con más memoria como a la Saturn o a la N64, y con ello consigues ventajas que no podrías en la consola tal cual de stock, sin añadidos.

De verdad Diskover que no vengo a trollearte el hilo ni tengo nada personal contra ti; eres de los que más y mejor aporta al subforo. Simplemente quería dejar clara otra cosa y me dejé llevar de más con otra persona.

@Alejo I Entendido, trataré de no volver a caer en ese vicio.

En lo personal voy a abrir un hilo para seguir hablando del dopaje en NES. Eso sí el de Former Down sí que que lo comentaré por aquí, porque procede.

@Diskover

Ninja Gaiden 2/Shadow Warrior 2 utiliza el mapper MMC3. En ese gif utiliza el contador IRQ intensamente.

Se agradece sobremanera la información

@cirote3

Sí, claro. Y ningún problema con ello

A lo que yo iba, es que no hace falta irse al extremo más tocho, como meter un Daytona USA en una Megadrive xD. El solo hecho de que consiguieran rular un Virtua Racing o Star Fox a 60 fps via chip tocho (sin ninguna otra mejora más alla de los fps), ya levantaría muchas ampollas... y no tengo pruebas pero tampoco dudas de que sería por los VCDECIDE de la vida xD

Y lo del sonido está claro, he ahí la ironía del asunto

Por aportar mi opinión personal. Cada uno establecemos el limite o colocamos la linea roja un poquito más adelante o más atrás dependiendo de nuestros gustos, preferencias y sobretodo sensaciones, pero creo que es siempre interesante no perder el norte, y por mucho que Starwing saliese en su época y sea un juego de SNES, no lo mueve una SNES sin ayuda de un chip especial.

Esto tiene que quedar muy claro a todo el mundo, y no desmerece el juego ni a la consola, y por supuesto sigue siendo un juego más del catálogo de la consola.

Con el homebrew, es igual. Da igual que usen tecnología que en el año 93 no existiese, que si existiese, que fuese cara, que no fuese rentable, etc, etc. ¿Lo hace la consola a pelo?. Respuesta solo hay una, y a partir de ahí ya cada uno puede poner la linea roja donde quiera. Habrá quien no lo considere un juego de NES y otros que si, porque juegos de Nes con extras en el cartucho tuvo un montón en su día.

Personalmente me guío por mis sensaciones. Jugué bastante a la NES en su día a pesar de no tenerla, además a algunos de sus mejores juegos, y es una consola a la cual le guardo un cariño muy especial. Sí siento que es o no es un juego de NES, me darán igual todas las explicaciones del mundo. De todas formas, eso nunca sustituirá que este juego una NES sin ayuda no lo ejecuta.

Ponerse riguroso con la NES por el uso de Mappers es un poco exagerado, ya que en su vida comercial más del 90% de sus juegos iban dopados.

@SoNi personalmente, a diferencia de SNES y N64 que son dos consolas a las que les tengo una abierta animadversión (aunque tb las disfrute al mismo tiempo), la Famicom/NES es 1 consola que admiro y que disfruté mucho en la época aunque fuese con 1 clónica. No me pongo riguroso con élla, sino con quien no quiera llamar a las cosas por su nombre. Que vivan los mappers y/o chips de apoyo si con ellos nos viene un Súper Mario Dios 3.

Y me bajo ya del debate éste... De momento

Charla sobre Former Down señores, que bien lo vale.

SoNi escribió:Ponerse riguroso con la NES por el uso de Mappers es un poco exagerado, ya que en su vida comercial más del 90% de sus juegos iban dopados.

Opino exactamente igual