[SUPER NINTENDO] Hilo oficial.

naxeras escribió:Claro que no puede, ya te lo ha dicho el programador, esta muy limitada para animar un gran numero de enemigos

Esto es totalmente impreciso.

Dependerá de cuanta cpu use, y por lo tanto de cuanto tiempo de dma le quede, así que depende de la exigencia del programa, no es una norma fija, porque no es lo mismo un juego complejo que un juego poco complejo. Al primero no le podrás añadir muchas animaciones, pero al segundo si.

Este juego realiza las animaciones de una forma diferente, y presumiblemente está manteniendo a la cpu bastante ocupada, pero eso no significa que las condiciones de este juego impliquen siempre este resultado si se realiza de forma ordinaria. Estamos hablado de un jugador y 4 enemigos, y reducimos esa condición mas estos resultados para validar el manoseado "snes no puede con mas de 4 entidades".


Vamos, es que es hasta razonable, no se.

naxeras escribió:y por eso aunque toque animación ese frame lo que hace es saltarla para cuando haya posibilidad de atualizar. ¿Tu crees que si hace lo mismo que en todos los juegos comerciales de cualquier consola lo comentaria en un twitt? no has entendido lo que pasa.

Aquí hay una confusión. Todos los objetos del juego actualizan su estado a 60fps, son las animaciones las que se reparten entre frames. Durante la etapa comercial había una media de 3 frames entre una petición de transferencia de tiles, y la animación efectiva.

No hay diferencia en terminos de "potencia" entre esperar 4 frames para animar a 4 enemigos al mismo tiempo, que hacerlo secuencialmente frame a frame, por turnos.

naxeras escribió:Es una optimización que tambien ha tenido que hacer mucho menos bestia mauro en Final Fight MD, al principio actualizaba los marcadores a 60fps que son sprites (una locura) y tuvo que reducirlo a mitad porque no le daba y eso que es una consola mucho mejor capacitada para ello.

No es el hilo. Puedes explicar para que en otro que corresponda mas, y debatirlo ahí.

naxeras escribió:Totalmente que no use cinemascope a este nivel de acción es una maravilla y como dice el autor en movimiento y que es un juego con mucha acción ni te enteras.

Este es el problema, se ha repetido durante tantos años que estáis convencidos que 4 objetos es el nivel de una snes, pero que da igual cuanta cpu le dediques, serán solo 4, y punto.

naxeras escribió:Yo creo que este juego ya demuestra bastante lo que SNES puede hacer en buenas manos, aunque claro hay margen de maniobra para más.

¿En términos de acción y enemigos en pantalla?. Absolutamente no.

naxeras escribió:El tema de SNES es lo que digo siempre, en vez de haberse programado por compañias mediocres, SNES fue programado por las compañias más top con el mejor presupuesto, roms grandes etc ya que fue la niña bonita de su generación como PSX en la suya, por lo tanto tampoco creo que veamos cosas tan alucinantes que no se creyeran posibles como si hemos podido ver en otros sistemas.

Es lo que siempre dices, a pesar de habérse demostrado que estás equivocado. ¿Como es posible afirmar que se programaba con los mejores presupuestos, cuando mas de la mitad del catálogo era lanzada con slow roms por motivos de presupuesto?.

Lo que tiene snes es una predisposición para verse todo muy bonito, y parecer que se están volcando en ella, pero su catálogo está repleto de ejemplos que desmienten ese esmero, y no se acepta el argumento (no había tiempo para ponserse a optimizar, y si argumentamos que snes es una máquina mas difícil de dominar, entonces no debería sorprendernos tanto que efectivamente existan muchos casos de faltas de optimización tontas).

Señalar estas cuestiones no es negar que eran unos monstruos programando.

Señor Ventura escribió:Dependerá de cuanta cpu use, y por lo tanto de cuanto tiempo de dma le quede

Pues usa la justa y necesaria, no la esta desaprovechando vamos, lo que dices es una obviedad. Solo hay que jugar a su catalogo para ver en este tipo de juegos la tralla o no tralla que mete.

Señor Ventura escribió:No hay diferencia en terminos de "potencia" entre esperar 4 frames para animar a 4 enemigos al mismo tiempo, que hacerlo secuencialmente frame a frame, por turnos.

Hombre claro que la hay, necesitas mas VRAM y a la vez necesitas mas ancho de banda para reemplazar los tiles del cartucho a la VRAM, dicho de forma simplificada y sin marear.

Si es uno a uno solo necesitas cargar los tiles que actualizan ese enemigo.

Señor Ventura escribió:No es el hilo. Puedes explicar para que en otro que corresponda mas, y debatirlo ahí.

No debato digo lo que ha comentado el programador punto, no hay debate que valga ni nada que se pueda añadir.

Señor Ventura escribió:Este es el problema, se ha repetido durante tantos años que estáis convencidos que 4 objetos es el nivel de una snes, pero que da igual cuanta cpu le dediques, serán solo 4, y punto.

No se ha repetido durante años, es que se ha visto en el catalogo y se ve en los nuevos desarrollos homebrew que si usas la CPU en modo "normal" es el margen que tienes, claro si los enemigos estan y no hacen nada, no tienen ia ni colisiones ni nada pues puedes meter mas pero entonces eso no es un juego es una demo técnica.

Señor Ventura escribió:¿En términos de acción y enemigos en pantalla?. Absolutamente no.

Pues parece que todo el rato estas negando la mayor, menos mal que vas sentando la cabeza y te repliegas a la realidad que ven tus ojos.

Señor Ventura escribió:Es lo que siempre dices, a pesar de habérse demostrado que estás equivocado. ¿Como es posible afirmar que se programaba con los mejores presupuestos, cuando mas de la mitad del catálogo era lanzada con slow roms por motivos de presupuesto?.

No, al contrario se ha demostrado y te han dicho otros usuarios que lo que dices no tiene sentido, ya te he explicado que si nos ponemos asi ningun desarrollo tiene alto presupusto por no usar procesadores especiales ¿no? de hecho que existan esos cartuchos con procesadores carisimos para una consola famelica en determinados apartados de hardware demuestra que en cuanto a costes en SNES no se reparaba en gastos comparandolo como no con el resto de sistemas contemporaneos.

Vamos es pura logica, NES fue un éxito de monopolio practicamente y eso hizo que carrileara a SNES siendo la niña bonita de la generación. Que existan las slowrom solo es tacañeria de Nintendo.

El unico que piensa que en SNES programaban aficionados con menos presupuesto que en el resto de consolas eres tú, que es distinto a que tuvieran presupuesto infinito claro. Con presupuesto infinito pues si le metes 7 chips con la potencia del 386 todo fastroms de 64Mb o más y a correr (es una exageración), pero no, hay que comparar gastos en SNES con el gasto en sus contemporaneas donde te daras cuenta que es mucho mayor en SNES, con los mejores equipos de programadores de la epoca, de las compañias mas prestigiosas y exitosas de la época, con las roms mas grandes (mira la media anda) llegando incluso a meter chips especiales y usar las FastRom en muchos casos que Nintendo cobraba a precio de oro.

Las otras consolas las programaban muchas veces empresas de segunda o tercera división con roms raquiticas y presupuestos y tiempos mas limitados que en SNES.

Vamos no se porque no reconoces la realidad, pasó con NES, pasó con PSX, paso con PS2... la niña bonita de la generación es la que mejores estudios, presupuestos y las que mas se aprovecha el hardware, es una obviedad vamos parece que lo sabe todo el mundo menos tú.

Un Saludo.

Entiendo que con till & hat ha ideado un sistema para animar los personajes """proceduralmente""" con tiles ya instalados en vram para ahorrarse tener que parar la cpu para transferir nada. De momento ha tenido un impacto adicional en la sobrecarga de sprites por línea con este sistema, aunque ha conseguido su objetivo de tener muy liberada la cpu (pero tampoco sabemos cual es la eficiencia del código, del comportamiento de los enemigos, de como es la base de datos para realizar las animaciones, colisiones, etc).

Es mucho trabajo para una sola persona como para considerar que ese es el nivel de una snes, porque además lo está haciendo de una forma bastante poco ortodoxa, según explica el mismo.

Es que el no intenta otro tipo de juego ni otro tipo de solución. El siguiente nivel a esto que el está haciendo es el "rag doll". Los piratas del espacio del super metroid usan esta forma de animación, y la acción es fluída con algunos enemigos en pantalla.

Por norma general cuando un juego se salía de orden para alguna solución gráfica, lo pagaba.

naxeras escribió:Las otras consolas las programaban muchas veces empresas de segunda o tercera división con roms raquiticas y presupuestos y tiempos mas limitados que en SNES.

Vamos no se porque no reconoces la realidad, pasó con NES, pasó con PSX, paso con PS2... la niña bonita de la generación es la que mejores estudios, presupuestos y las que mas se aprovecha el hardware, es una obviedad vamos parece que lo sabe todo el mundo menos tú.

Cuanta razón tienes y muy bien explicado. En un foro como este creo que algo tan obvio no debería ni siquiera ni decirse.
Por supuesto no es un ataque a ninguna consola ni compañía.

Señor Ventura escribió:Es mucho trabajo para una sola persona como para considerar que ese es el nivel de una snes, porque además lo está haciendo de una forma bastante poco ortodoxa, según explica el mismo.

Mas dificultad.

https://youtu.be/fpfS53mZBcs?si=rcEOKGMS8xFJjOf6

Muchas bala,pero poca chicha.

aranya escribió:Cuanta razón tienes y muy bien explicado. En un foro como este creo que algo tan obvio no debería ni siquiera ni decirse.
Por supuesto no es un ataque a ninguna consola ni compañía.

No es cierto que no escatimaran en recursos haciendo juegos para super nintendo. Con mas del 50% de juegos usando roms que underclockeaban la snes, no se puede decir que jugase con ventaja.

Una cosa es que tengáis argumentos, y otra que no reconozcáis ninguno.

naxeras escribió:Pues usa la justa y necesaria, no la esta desaprovechando vamos, lo que dices es una obviedad. Solo hay que jugar a su catalogo para ver en este tipo de juegos la tralla o no tralla que mete.

El está usando recursos para hacer el juego mas eficiente en cuanto a no ocupar demasiada rom, y por otro lado también la acción que mete puede ser mas o menos exigente para el hardware de la snes. Si es tan obvio para ti, ¿que estás rebatiendo entonces?. Discutir por discutir.

naxeras escribió:Hombre claro que la hay, necesitas mas VRAM y a la vez necesitas mas ancho de banda para reemplazar los tiles del cartucho a la VRAM, dicho de forma simplificada y sin marear.

Si es uno a uno solo necesitas cargar los tiles que actualizan ese enemigo.

No, no hay diferencia en términos de recursos entre acumular y usar al vuelo, no voy a discutir sobre esto.

naxeras escribió:No debato digo lo que ha comentado el programador punto, no hay debate que valga ni nada que se pueda añadir.

Yo también estoy diciendo lo que ha comentado el programador.

naxeras escribió:No se ha repetido durante años, es que se ha visto en el catalogo y se ve en los nuevos desarrollos homebrew que si usas la CPU en modo "normal" es el margen que tienes, claro si los enemigos estan y no hacen nada, no tienen ia ni colisiones ni nada pues puedes meter mas pero entonces eso no es un juego es una demo técnica.

Ni tu ni yo sabemos el margen que tiene el programador de este juego si empleara otra forma de desarrollarlo.

naxeras escribió:Pues parece que todo el rato estas negando la mayor, menos mal que vas sentando la cabeza y te repliegas a la realidad que ven tus ojos.

Tu frase tenía dos sentencias. Dije precisamente que 4 enemigos en pantalla a ese nivel de acción no demuestra que eso es todo lo que puede hacer snes.

naxeras escribió:No, al contrario se ha demostrado y te han dicho otros usuarios que lo que dices no tiene sentido, ya te he explicado que si nos ponemos asi ningun desarrollo tiene alto presupusto por no usar procesadores especiales ¿no? de hecho que existan esos cartuchos con procesadores carisimos para una consola famelica en determinados apartados de hardware demuestra que en cuanto a costes en SNES no se reparaba en gastos comparandolo como no con el resto de sistemas contemporaneos.

Vamos es pura logica, NES fue un éxito de monopolio practicamente y eso hizo que carrileara a SNES siendo la niña bonita de la generación. Que existan las slowrom solo es tacañeria de Nintendo.

El unico que piensa que en SNES programaban aficionados con menos presupuesto que en el resto de consolas eres tú, que es distinto a que tuvieran presupuesto infinito claro. Con presupuesto infinito pues si le metes 7 chips con la potencia del 386 todo fastroms de 64Mb o más y a correr (es una exageración), pero no, hay que comparar gastos en SNES con el gasto en sus contemporaneas donde te daras cuenta que es mucho mayor en SNES, con los mejores equipos de programadores de la epoca, de las compañias mas prestigiosas y exitosas de la época, con las roms mas grandes (mira la media anda) llegando incluso a meter chips especiales y usar las FastRom en muchos casos que Nintendo cobraba a precio de oro.

Las otras consolas las programaban muchas veces empresas de segunda o tercera división con roms raquiticas y presupuestos y tiempos mas limitados que en SNES.

Vamos no se porque no reconoces la realidad, pasó con NES, pasó con PSX, paso con PS2... la niña bonita de la generación es la que mejores estudios, presupuestos y las que mas se aprovecha el hardware, es una obviedad vamos parece que lo sabe todo el mundo menos tú.

Un Saludo.

Las cosas no quedan demostradas solo porque sean tu opinión, porque claro, uno no puede estar equivocado, o no puede no tener toda la razón solo porque le secunden 50 personas.

Lo que he dicho se limita a lo que he dicho. El esfuerzo casi siempre tuvo que ser máximo, pero los recursos no, es de perogrullo. Hay factos que demuestran que los juegos no solían salir usando todo su potencial, y es algo que tampoco se puede ignorar, digo yo.

Existieron quejas sobre un mal uso de esa cpu, existió una oleada de juegos que demuestran que se underclockeaba el hardware, existió un tendencia muy considerable a recibir ports que no se optimizaban para snes (se limitaban a añadir un un plano mas, pero no obtenías algo nativo, y no era poco común que se quitaran niveles, y contenido de todo tipo), y existen los suficientes casos de juegos de los que se ha demostrado que salían demasiado prematuros.

Con todo esto en la mano, no se puede afirmar que lo que recibía la snes estaba al 100% de su potencial. ¿Tanto cuesta decir que programar para snes era la preferencia, pero que también pagaba el pato de ports directos e infrautilización del hardware?.

Señor Ventura escribió:Las cosas no quedan demostradas solo porque sean tu opinión, porque claro, uno no puede estar equivocado, o no puede no tener toda la razón solo porque le secunden 50 personas.

Señor Ventura escribió:No es cierto que no escatimaran en recursos haciendo juegos para super nintendo. Con mas del 50% de juegos usando roms que underclockeaban la snes, no se puede decir que jugase con ventaja.

Una cosa es que tengáis argumentos, y otra que no reconozcáis ninguno.

Y dale erre que erre, nadie te ha dicho que no se escatimaran recursos porque evidentemente dinero infinito no tenian, el juego tenia que ser rentable asi que meter 6 CPUS SA-1 o roms como neogeo de grandes con mappers pues no lo iban a hacer, lo que se está diciendo es que se escatimaba menos en SNES que en el resto de consolas domesticas de su generación por ser la niña bonita y como pasa en todas las gens que la consola mas exitosa se lleva los mejores presupuestos te pongas como te pongas es una realidad incuestionable desde usar roms mas grandes que la compentencia, a ser programados por mejores y mas talentosos estudios a incluso usarse chips de apoyo cuando la consola no da de si.

Señor Ventura escribió:No, no hay diferencia en términos de recursos entre acumular y usar al vuelo, no voy a discutir sobre esto.

Pero que dices, la VRAM es la que es, si mejor no discutas anda que cuando te des cuenta que SNES tiene menos memoria para sprites que sus contemporaneas te va a dar algo.

Señor Ventura escribió:Tu frase tenía dos sentencias. Dije precisamente que 4 enemigos en pantalla a ese nivel de acción no demuestra que eso es todo lo que puede hacer snes.

Hombre pues sus buenos parpadeos tiene ya el juego tal y como está, ya se que a ti te da igual los parpadeos pero seamos serios.

Señor Ventura escribió:Las cosas no quedan demostradas solo porque sean tu opinión, porque claro, uno no puede estar equivocado, o no puede no tener toda la razón solo porque le secunden 50 personas.

Tu eres el tipico que va por una autopista se equivoca de carril y acusa a los demás conductores de son ellos los que van contradirección y tú vas perfectamente, son ellos los que van mal claro.

Señor Ventura escribió:Lo que he dicho se limita a lo que he dicho. El esfuerzo casi siempre tuvo que ser máximo, pero los recursos no, es de perogrullo. Hay factos que demuestran que los juegos no solían salir usando todo su potencial, y es algo que tampoco se puede ignorar, digo yo.

Existieron quejas sobre un mal uso de esa cpu, existió una oleada de juegos que demuestran que se underclockeaba el hardware, existió un tendencia muy considerable a recibir ports que no se optimizaban para snes (se limitaban a añadir un un plano mas, pero no obtenías algo nativo, y no era poco común que se quitaran niveles, y contenido de todo tipo), y existen los suficientes casos de juegos de los que se ha demostrado que salían demasiado prematuros.

Con todo esto en la mano, no se puede afirmar que lo que recibía la snes estaba al 100% de su potencial. ¿Tanto cuesta decir que programar para snes era la preferencia, pero que también pagaba el pato de ports directos e infrautilización del hardware?.

SNES no está menos explotada en su generación que PSX en la suya, o que PS2 o que NES, SNES en la niña bonita de la GEN la que mas se explotó y la que tuvo los estudios mas talentosos del momento, eso es lo que estoy diciendo y te estan diciendo que es una realidad incuestionable y no dejas de retorcer lo que te dicen para no reconocer que SNES en su época es la consola más explotada y mas aprovechada y con los presupuestos mas altos DE SU GENEREACIÓN, nadie te esta hablando de terminos absolutos pero tu sigues y dale y dale y la verdad no entiendo por qué.

cirote3 escribió:

Señor Ventura escribió:Las cosas no quedan demostradas solo porque sean tu opinión, porque claro, uno no puede estar equivocado, o no puede no tener toda la razón solo porque le secunden 50 personas.

El caso de ventura es este:



No no si yo voy bien, son todos los demás que se equivocan...

Un Saludo.

Se sabe algo del demake de Resident evil 1 para sega/snes? Lleva mucho tiempo estancado
https://www.shdownloads.com.ar/2023/05/ ... on-de.html

Que yo sepa, eso solo lo estaban haciendo para la Mega Drive.

Señor Ventura escribió:La clave es el fondo estático.

Era evidente. Puede hacerse de dos modos, mediante un plano con patrones o colores que dibujar usando una ventana mediante hdma, o mediante la alteración de un color, ambas mediante los registros $2123 a $2129 para posición, seleccion, y activacion, y los registros $212A/$212B para mezclar dos ventanas mediante lógica combinatoria (or, and, xor, xnor), y $212E/$212F como un interruptor para encender y apagar el enmascaramiento.

Las ventanas no se desplazan, no hacen scroll, aunque siempre puedes alterar el propio dibujo frame a frame para simularlo, de la misma forma que la nes simulaba dos planos: cambiando el dibujo del único plano que tiene.
La ventaja es que no dependes de ningun ancho de banda relevante, ni prácticamente de la cpu. Es automático. Puedes servirte de una base de datos para hacerlo "proceduralmente" para simular scroll multidireccional de "uno" o "varios planos", o mediante simple flujo de datos lineal mediante $2126 y hacer un scroll simple.

El reto es calcular el lag entre cada interrupcion transferencia hdma para que los ciclos que tarda en estar operativo no cause que el haz de electrones del crt dibuje glitches, de ahí que las estrellas no puedan estar demasiado juntas. Para las montañas no hay problema, solo retrasas las interrupciones transferencias hdma para convertir los puntos en líneas.

Al final de cada scanline defines un color para toda la linea horizontal, y todo lo demás se dibuja mediante interrupciones ¡agh!. Es un enmascaramiento.

Es lo que decía hace tiempo sobre la serpiente del xeno crisis. Dibujando las secciones también en un plano, puedes intercalar secciones con sprites + enmascaramiento para doblar la longitud del enemigo sin causar parpadeos. Los sprites sirven para que al ppu1 le de tiempo a "preparar" la siguiente sección sin "beam glitches".

Disfruta del juego cuando salga.

Señor Ventura escribió:Es lo que decía hace tiempo sobre la serpiente del xeno crisis. Dibujando las secciones también en un plano, puedes intercalar secciones con sprites + enmascaramiento para doblar la longitud del enemigo sin causar parpadeos. Los sprites sirven para que al ppu1 le de tiempo a "preparar" la siguiente sección sin "beam glitches".

No doblar la longitud de la serpiente, sino DUPLICAR el número de secciones de su cuerpo sin parpadeos.

Para ellos necesitas dibujar en un plano las diferentes posiciones de las secciones que vayas a dibujar mediante hdma.


Quedó mucho por ver de esta máquina, pero mucho.

Señor Ventura escribió:

Señor Ventura escribió:La clave es el fondo estático.

Era evidente. Puede hacerse de dos modos, mediante un plano con patrones o colores que dibujar usando una ventana mediante hdma, o mediante la alteración de un color, ambas mediante los registros $2123 a $2129 para posición, seleccion, y activacion, y los registros $212A/$212B para mezclar dos ventanas mediante lógica combinatoria (or, and, xor, xnor), y $212E/$212F como un interruptor para encender y apagar el enmascaramiento.

Las ventanas no se desplazan, no hacen scroll, aunque siempre puedes alterar el propio dibujo frame a frame para simularlo, de la misma forma que la nes simulaba dos planos: cambiando el dibujo del único plano que tiene.
La ventaja es que no dependes de ningun ancho de banda relevante, ni prácticamente de la cpu. Es automático. Puedes servirte de una base de datos para hacerlo "proceduralmente" para simular scroll multidireccional de "uno" o "varios planos", o mediante simple flujo de datos lineal mediante $2126 y hacer un scroll simple.

El reto es calcular el lag entre cada interrupcion transferencia hdma para que los ciclos que tarda en estar operativo no cause que el haz de electrones del crt dibuje glitches, de ahí que las estrellas no puedan estar demasiado juntas. Para las montañas no hay problema, solo retrasas las interrupciones transferencias hdma para convertir los puntos en líneas.

Al final de cada scanline defines un color para toda la linea horizontal, y todo lo demás se dibuja mediante interrupciones ¡agh!. Es un enmascaramiento.

Es lo que decía hace tiempo sobre la serpiente del xeno crisis. Dibujando las secciones también en un plano, puedes intercalar secciones con sprites + enmascaramiento para doblar la longitud del enemigo sin causar parpadeos. Los sprites sirven para que al ppu1 le de tiempo a "preparar" la siguiente sección sin "beam glitches".

Lo de "dibujar" las estrellas mediante interrupciones en el enmascaramiento que enseña el plano brillante que hay detrás, me ha dejado partiéndome de risa

@Diskover mi prosa es limitada xD

Básicamente usar un registro para cambiar el color de uno o varios pixels, o copiar un patrón de ellos, tiene una latencia que requiere 8 master clocks entre uso de registros, pero el haz de electrones es mas rápido, así que pueden pasar entre 2 y 4 pixels hasta que el hdma está listo para reanudar de nuevo el proceso de pintado.

Mediante interrupciones ya si se trata de involucrar a la cpu, y ya es otra historia... 8 ciclos de cpu para interrumpir lo que esté haciendo, guardar el estado 16 ciclos adicionales, lo que supone mas dd un centenar de master clocks... 25, 30, 40 pixels de distancia entre un pintado, y tener disponible el siguiente.

25 a 40 pixels de distancia (o incluso mas), no parece un cálculo muy exacto... es que no se puede calcular. Aparte de todo esto está la situación de no poder interrumpir otras instrucciones a mitad de ejecución, lo que supone una espera adicional.

Y esto teniendo en cuenta que el 65816 es una máquina de hacer interrupciones.

Fun fact:

-Aproximadamente solo el 4% del catálogo de snes usa chips de apoyo, y al menos un tercio de esa cantidad no están ahí para aportar ventajas de rendimiento. El relato del dopaje sistémico es un mito adrede.

-Snes tiene un ancho de banda de 370KB/s. Por arquitectura no es posible alterar esto para ninguna clase de beneficio, ni es posible descomprimir en vram salvo cuestiones relativas al sistema planar de almacenamiento, que de nuevo son cosa solo de la snes, y no de ningún chip de apoyo.

Señor Ventura escribió:ni es posible descomprimir en vram salvo cuestiones relativas al sistema planar de almacenamiento, que de nuevo son cosa solo de la snes, y no de ningún chip de apoyo.

Durante el V-Blank se puede descomprimir en la VRAM de la SNES sin ningún problema.

No. Puedes descomprimir lo que quieras en la WRAM o en la SRAM, e incluso en la ARAM (pongo un asterisco gigante aquí), y enviarlo descomprimido a la VRAM. No es posible trabajar en la VRAM de la snes, en su caso no puedes siquiera copiar nada de vram a vram porque durante la pantalla activa tienes el puntero ocupado por el line buffer, y durante el hdma tienes capados los registros.

Puedes tratar de romper un poco las reglas usando hdma indirecto para muchas cosas chulas, porque es super análogo, pero lo mas que se puede llegar a hacer en estas máquinas para ahorrar ancho de banda (que yo haya visto), es definir menos profundidad de color de la que impone un tile para poder transferir mas, aunque ya una vez en vram volverán a ocupar su tamaño definido.

En ningún caso es posible usar chips de apoyo para conseguir mas ancho de banda, o trabajar en la vram.



edit: En definitiva, todo lo que se ve en el road blaster o dragon's lair, es mérito única y exclusivamente de la snes, ni el msu1 ni un pentium 3 pintan nada ahí.

Señor Ventura escribió:No. Puedes descomprimir lo que quieras en la WRAM o en la SRAM, e incluso en la ARAM (pongo un asterisco gigante aquí), y enviarlo descomprimido a la VRAM. No es posible trabajar en la VRAM de la snes, en su caso no puedes siquiera copiar nada de vram a vram porque durante la pantalla activa tienes el puntero ocupado por el line buffer, y durante el hdma tienes capados los registros.

La CPU de la SNES sí puede escribir en la VRAM durante el V-Blank usando los registros VMDATA:
https://snes.nesdev.org/wiki/Reading_an ... ta_to_VRAM

También puede leer de la VRAM durante el V-Blank, por lo que también puede copiar de VRAM a VRAM sin problemas:
https://snes.nesdev.org/wiki/Reading_an ... rd_of_VRAM
https://snes.nesdev.org/wiki/Reading_an ... ck_of_VRAM

¿Qué te hizo pensar que eso no era posible? ¿Lo has leído en algún sitio?

Si es merito sólo de la SNES para que cojones necesitamos el MSU1?

No puedes mover o copiar datos dentro de la vram, luego, no puedes trabajar dentro de la vram. Todo lo tienes que hacer fuera, y usar ancho de banda para traerlo a la memoria de vídeo.

Durante el v-blank puedes realizar transferencias, pero si hablamos de tiles, merece mas la pena usar hdma iniciando el proceso completo, que usar la cpu.

Poderse se podrá, no te voy a decir que no, pero si es peor trabajar en la vram con la cpu que usar DMA, entonces no se puede.

SuperPadLand escribió:Si es merito sólo de la SNES para que cojones necesitamos el MSU1?

Para obtener una rom de 540MB (y hasta 4TB si se quisiera). Y ojo, que esa rom está troceada en mapas de 16MB, pero la gracia es que te permite evitar la redundancia.

También permite varios canales de audio adicionales que inyecta directamente en el DSP.

Señor Ventura escribió:No puedes mover o copiar datos dentro de la vram, luego, no puedes trabajar dentro de la vram. Todo lo tienes que hacer fuera, y usar ancho de banda para traerlo a la memoria de vídeo.

Durante el v-blank puedes realizar transferencias, pero si hablamos de tiles, merece mas la pena usar hdma iniciando el proceso completo, que usar la cpu.

Poderse se podrá, no te voy a decir que no, pero si es peor trabajar en la vram con la cpu que usar DMA, entonces no se puede.

SuperPadLand escribió:Si es merito sólo de la SNES para que cojones necesitamos el MSU1?

Para obtener una rom de 540MB (y hasta 4TB si se quisiera). Y ojo, que esa rom está troceada en mapas de 16MB, pero la gracia es que te permite evitar la redundancia.

También permite varios canales de audio adicionales que inyecta directamente en el DSP.

Pues no me hagas mucho caso, pero entonces no es todo merito de la SNES a pelo.

Señor Ventura escribió:Fun fact:

-Aproximadamente solo el 4% del catálogo de snes usa chips de apoyo, y al menos un tercio de esa cantidad no están ahí para aportar ventajas de rendimiento. El relato del dopaje sistémico es un mito adrede.

-Snes tiene un ancho de banda de 370KB/s. Por arquitectura no es posible alterar esto para ninguna clase de beneficio, ni es posible descomprimir en vram salvo cuestiones relativas al sistema planar de almacenamiento, que de nuevo son cosa solo de la snes, y no de ningún chip de apoyo.

O dicho de otra forma, SNES en la consola de su generación que usa más CPUS de apoyo frente a 1 juego de Megadrive y 0 de PCE

Y no sólo eso SNES es la consola de cartucho que más CPU de apoyo ha usado en la historia frente a:

0 Jaguar.
0 N64
0 NES (Creo que solo usa mappers).
0 Master System.

Y no solo eso la consola de la historia en general que mas CPU de apoyo ha usado en la historia frente a:

0 PSX
0 PS2
0 Wii
.....

Asi que si SNES es la consola más dopada de la historia en cuanto a CPUS de apoyo por lo que el relato del dopaje tiene todo el sentido del mundo y está muy bien argumentado... en fin SNES y sus dopajes...

SuperPadLand escribió:Pues no me hagas mucho caso, pero entonces no es todo merito de la SNES a pelo.

Pues claro que no, vamos es tan evidente que hasta sonroja, como he dicho en hilo de novedades no es que NECESITA un chip extra para funcionar es que necesita un chip totalmente futurista e imposible tecnologicamente para la época en la que se lanzó SNES...

Un Saludo.

Señor Ventura escribió:No puedes mover o copiar datos dentro de la vram, luego, no puedes trabajar dentro de la vram.

Sí se puede, acabo de enlazar documentación con código de ejemplo para hacerlo con la CPU.

Señor Ventura escribió:Durante el v-blank puedes realizar transferencias, pero si hablamos de tiles, merece mas la pena usar hdma iniciando el proceso completo, que usar la cpu.

Si son tiles comprimidos y hay suficiente V-Blank, es más eficiente y gasta menos WRAM descomprimir tiles con la CPU. En ese caso merece más la pena evitar el DMA.

Señor Ventura escribió:Poderse se podrá, no te voy a decir que no, pero si es peor trabajar en la vram con la cpu que usar DMA, entonces no se puede.

Has dicho que no es posible descomprimir en la VRAM, que no se puede "trabajar" en la VRAM y que no se puede copiar de VRAM a VRAM. Las tres son mentira. Por eso te preguntaba dónde habías leído todo eso, por saber si te lo estabas inventando o no.

Como he dicho, si hay suficiente V-Blank, es más eficiente y gasta menos WRAM descomprimir directamente en la VRAM que descomprimir en la WRAM y copiar el resultado a la VRAM. También es más eficiente por ejemplo a la hora de implementar un sistema de texto con ancho de caracteres variable (variable width fonts), como el que tienen la mayoría de los JRPG populares de la SNES. Hay muchos casos en los que no "es peor trabajar en la VRAM con la CPU". Como dices tú, entonces sí se puede

Si no fuera útil leer o escribir la VRAM con la CPU, ¿pará que cojones Nintendo se molestó en meter registros para permitirlo?

naxeras escribió:

SuperPadLand escribió:Pues no me hagas mucho caso, pero entonces no es todo merito de la SNES a pelo.

Pues claro que no, vamos es tan evidente que hasta sonroja, como he dicho en hilo de novedades no es que NECESITA un chip extra para funcionar es que necesita un chip totalmente futurista e imposible tecnologicamente para la época en la que se lanzó SNES...

Para mí, los juegos que tiran de MSU-1 tienen el mismo mérito que el port del Xeno Crisis para la SNES o el Paprium: no solo usan hardware que no existía en su época, sino que hubiera sido imposible que lo sacaran en su época o unos años después. Claro que tienen su mérito, pero no el mismo que los juegos que se limitan al hardware de la época.

Yo lo que entiendo es que esos chips ayudan de alguna forma a la consola a hacer lo que por ella misma no puede...

Creo que el problema no es que haya un 4% de chips, sino que ese 4% represente el 40 o el 60% de muchas listas "top 10" que últimamente he mirado para buscar recomendaciones de juegos y que no estoy pudiendo jugar con mi everdrive que no tiene los chips:

Mario Kart, Starwind, Megaman X-2-3, DBZ Hyper Dimension, los Kirby, Super Mario World 2, Star Ocean, Mario RPG...

Los veo en demasiadas listas y claro, por una parte pues hay un porcentage pequeño de ellos, por otro, suelen ser los más tops, justamente los que la consola por si misma no tiene capacidad de moverlos.

No sé, es mi punto de vista mirando y buscando buenos juegos para jugar y reprimirme a no poder usarlos por no tener un everdrive que los mueva.

no se que problemas hay con los chips en los cartuchos si la consola nacio asi ,es una caracteristica y un añadido mas que interesante .
y listas habra miles ,muchas ni incluyen ninguno con chip o no los ponen en en top ,de jhecho por poner un ejemplo super mario world 1 esta ,mejor valorado que el dos ,megaman x lo mismo con sus secuelas .
anda que no hay titulos buenos que se pueden jugar si le tienes mania a los chips (que no lo entendere nunca esto porque hoy dia los puedes jugar con casi todo) y es una peculiaridad buena de la consola .
aun asi es un cuatro por ciento pero vamos que poco importaria que fuese un cincuenta por ciento si disen titulos novedosos y llamativos .
que la consola no puede moverlos? como que no ? mete el cartucho o la rom y a jugarlos ,lo demas lo veo un poco cogido con pinzas .
lo que hay es que jugar mas

como listas hay miles he puesto la primera que me ha salido buscando un top 50
https://www.nintendolife.com/guides/50-best-super-nintendo-snes-games-of-all-time
de la lista habra unos cuantos con chips y muchos no estan ni en el tiop 20.

Sobre todo en esa generación cada consola enfocó formas diferentes de expandir su hardware base.
PC Engine con el CD-ROM y tarjetas de RAM extra (la Arcade Card para la época es una locura con 2 Megabytes de RAM), Mega Drive con MegaCD y 32X (y la "rareza" de Virtua Racing con su SVP) y SNES con chips especiales en los cartuchos (aunque también estuvo sobre la mesa la idea del CD durante bastante tiempo).
Al final todas las ideas nos trajeron juegos que con el hardware base no serían posibles, pero comercialmente lo que mejor funcionó a nivel global fue lo que hizo Nintendo. Era más asumible un pequeño aumento de coste en el juego, que tener que comprar un periférico tan caro o más que la consola para jugar a esos juegos mejorados.

titorino escribió:no se que problemas hay con los chips en los cartuchos si la consola nacio asi ,es una caracteristica y un añadido mas que interesante .
y listas habra miles ,muchas ni incluyen ninguno con chip o no los ponen en en top ,de jhecho por poner un ejemplo super mario world 1 esta ,mejor valorado que el dos ,megaman x lo mismo con sus secuelas .
anda que no hay titulos buenos que se pueden jugar si le tienes mania a los chips (que no lo entendere nunca esto porque hoy dia los puedes jugar con casi todo) y es una peculiaridad buena de la consola .
aun asi es un cuatro por ciento pero vamos que poco importaria que fuese un cincuenta por ciento si disen titulos novedosos y llamativos .
que la consola no puede moverlos? como que no ? mete el cartucho o la rom y a jugarlos ,lo demas lo veo un poco cogido con pinzas .
lo que hay es que jugar mas

Lo malo del tema chips es que como tu flashcart no los soporte, te quedas sin poder jugarlos en una SNES de verdad. Y los flashcart que los soportan no incluyen los chips de verdad, los emulan, por lo que ya se pierde el rollo pureta

titorino escribió:como listas hay miles he puesto la primera que me ha salido buscando un top 50
https://www.nintendolife.com/guides/50-best-super-nintendo-snes-games-of-all-time
de la lista habra unos cuantos con chips y muchos no estan ni en el tiop 20.

De esa lista, en el top 20 hay tres juegos con chip: el Super Mario RPG, el Kirby Super Star SA1 y el Super Mario World 2. En ese top 20 yo metería otros tres juegos que sí llevan chip: el Super Mario Kart, el Street Fighter Alpha 2 y el Star Ocean.

@cirote3 y yo quitaria algunos con chips y meteria muchos que faltan ,no porque lleven chips ,porqiue hay otros que me gustan mas por lo que sea.
las listas hay miles y para todos los gustos ,lo que no entiendo es la mania de querer mutilar un juego .
lo que el tiempo ha demostrado que la decision de expander la consola asi fue todo un acierto.

cuanto vale un flash cart que soporte los chips ? joder estoy viendo que el sd2snes esta ahora a 78 euros en cierta tienda ,si te gusta la consola que son 78 euros y encima puedes poner los de msu1 ,aun asi no creo que sea justo valorar un catalogo por el hecho de poder ponerlo en un copion ,
me da que eso solo ocurre cuando se habla de snes por lo que parece ser.

Yo no veo nada de malo que la SNES usara chips de ayuda en su época, salió con una CPU muy limitada y sabiendo esto pues la propia Nintendo y las thirds pensaron en meter estos chips porque se les quedaba corta a su visión artistica que querian para esos juegos y de esta manera no tenian que recortar tanto esa visión.

Lo que pasa es que se intenta negar desde ciertos frentes que o no existen o no los necesita y puede dar los mismos resultados sin ellos... se ha llegado a decir que en este foro que no hace falta FX para el Yoshis Island o ahora mismo hace unos pocos post que no hace falta chip alguno para el road avenger que lo mueve la SNES a pelo y eso todo es directamente una mentira.

En SNES los chips son importantes porque la consola base se diseño con unas limitaciones importantes que la propia Nintendo sabia y conocía, varios de los mejores juegos del sistema los usan y no serian lo mismo sin ellos, negar que no existen, negar su importancia, negar que es algo intrinseco del sistema es no entender a SNES como hardware y plataforma.

cirote3 escribió:Lo malo del tema chips es que como tu flashcart no los soporte, te quedas sin poder jugarlos en una SNES de verdad. Y los flashcart que los soportan no incluyen los chips de verdad, los emulan, por lo que ya se pierde el rollo pureta

Pues juega a lo juegos que no usen estos chips, jugar con el SD2SNES es muy parecido a jugar en fpga/mister que tanto reniegan algunos en cuanto a purismo y lo mismo que jugar SegaCD con el everdrive pro.

cirote3 escribió:Para mí, los juegos que tiran de MSU-1 tienen el mismo mérito que el port del Xeno Crisis para la SNES o el Paprium: no solo usan hardware que no existía en su época, sino que hubiera sido imposible que lo sacaran en su época o unos años después. Claro que tienen su mérito, pero no el mismo que los juegos que se limitan al hardware de la época.

Si, todo es debatible, para mi veo mas merito en un juego con el MSU-1 o Paprium (que solo son datos y sonido) que Xeno Crisis que directamete skipea la CPU de la consola, o sea para mi depende un poco de lo que haga ese chip de apoyo aunque siempre prefiero que lo mueva el sistema a pelo como el hat o un FinalFight MD pero tambien alguien puede decir que usan roms grandes imposibles a nivel economico en su epoca entonces volveria a empezar la rueda, por eso creo que es algo personal de cada uno. Lo que no se puede hacer en en ningun caso es decir que algo que usa chip no lo usa porque patata.

titorino escribió:lo que el tiempo ha demostrado que la decision de expander la consola asi fue todo un acierto.

Más bien todo lo contrario, la mayoria de consolas exitosas no necesitan chips de expansión que encarecen el precio de los juegos y es mucho mejor que una consola no se quede corta de nacimiento prueba es que una consola use chip de apoyo, expansiones y demas para darla potencia es una rareza mas que una norma.

Hay una otra cosa que leo mucho en este hilo que no entiendo, se dice que SNES nació con particularidades para ser expandida, pero realmente todas las tienen, osea que yo sepa puedes meter chip de apoyo/expansion en un cartucho o puerto de expansion de la misma manera en Megadrive, en SNES o en PCE, ¿que ventaja tiene SNES en este menester?

Un Saludo.

titorino escribió:lo que el tiempo ha demostrado que la decision de expander la consola asi fue todo un acierto.

Nunca sabremos cómo hubieran sido los juegos de la SNES si hubiera llevado una CPU más potente de serie.

naxeras escribió:Hay una otra cosa que leo mucho en este hilo que no entiendo, se dice que SNES nació con particularidades para ser expandida, pero realmente todas las tienen, osea que yo sepa puedes meter chip de apoyo/expansion en un cartucho o puerto de expansion de la misma manera en Megadrive, en SNES o en PCE, ¿que ventaja tiene SNES en este menester?

Buena pregunta. Supongo que las HuCards eran demasiado pequeñas como para llevar chips de apoyo potentes en la época, pero que yo sepa en los cartuchos de la Mega Drive no había problema.

cirote3 escribió:Buena pregunta. Supongo que las HuCards eran demasiado pequeñas como para llevar chips de apoyo potentes en la época, pero que yo sepa en los cartuchos de la Mega Drive no había problema.

Si, estoy de acuerdo con las hucard pero por el puerto de expansion se pueden poner chip como en SNES, de hecho hoy en dia se hace metiendo supergrafx por ahi, en cuanto a Megadrive incluso sin usar el puerto de expansion pues mas de lo mismo, de hecho hay 1 juego en la epoca que usa uno y hoy en día hasta la MegaCD va por el puerto de cartuchos, asi que no entiendo poque se habala de que SNES estaba diseñada para ser expandida especialmente cuando no tiene ninguna particularidad que yo sepa mas allá de que SNES salió con una CPU raquitica que simplemente lo hizo mas "necesario" o simplemente que al ser la consola más exitosa de su generación y tener mas parque o un parque de usuarios con mayor poder adquisitivo era posible encarecer los juegos al tener mas presupuesto y esto no se podia hacer con las consolas con presupuesto mucho mas bajos como PCE o MD...

Meter un chip en un cartucho era aumentar el riesgo de que como no fuera éxito perdias dinero, necesitabas mas inversión y seguramente menos margen de beneficio por cada juego vendido y por eso es un modelo que no se ha usado mucho y solo lo veo viable para consolas de éxito o con fuerte herencia de éxito pero de ahi a que el tiempo ha demostrado que eso es bueno cuando el resto de consolas de éxito no ha usado ese modelo... En tal caso hemos aprendido que el ADDON es más caca que dopar el cartucho a la hora de expandir un poco la potencia del hardware.

Un Saludo.

Aquí la cuestión está clara: ¿chip para suplir carencias o para ampliar posibilidades? Yo diría que alguno como el SA-1 era para corregir carencias y otro como el chip Super FX para ampliar posibilidades. No sé qué opináis vosotros que os veo mucho más puestos en el tema.

gaditanomania escribió:Aquí la cuestión está clara: ¿chip para suplir carencias o para ampliar posibilidades? Yo diría que alguno como el SA-1 era para corregir carencias y otro como el chip Super FX para ampliar posibilidades. No sé qué opináis vosotros que os veo mucho más puestos en el tema.

Yo si lo pienso alegremente puedo llegar a esa misma conclusión que no deja de ser sensata, pero realmente creo que es algo que puede ser muy subjetivo en ciertos casos, se me ocurren expansiones que son una delgada línea entre corregir carencias o ampliar posibilidades asi que bueno al final lo mejor es que lo haga todo la consola a pelo aunque si pasara no tendriamos estos debates tan frikis ...

Creo que este vídeo viene bien al tema, juegos de SNES con chips que en principio parece que no mejoran mucho los juegos:

Usar chips de apoyo no tiene nada de malo, pero si los usa los usa y no puede afirmarse que todo lo hace la SNES como si el chip estuviese de adorno. Otra cosa es que la scene mejore y sea capaz de lograr cosas similares sin usar chips, pero en la época los juegos con chip (sea coprocesador o sea mapeador) fueron necesarios para mover los juegos y en la actualidad una SNES a pelo no mueve Super Road sin MSU1, podemos decir que hace poca cosa o lo que sea, pero algo hace.

cirote3 escribió:

titorino escribió:lo que el tiempo ha demostrado que la decision de expander la consola asi fue todo un acierto.

Nunca sabremos cómo hubieran sido los juegos de la SNES si hubiera llevado una CPU más potente de serie.

pues igual que estaba segurmante ,hubiesen añadido chips igualmente porque fue diseñada con ese fin .
no todos los chips sirven para lo mismo ,
todo el debate viene por las palabras de ventura sio no me equivoco ,evidentemente los chips no estan de adorno ,pero sinceramente a mi por lo menos como si lleva dentro un reactor de la nasa ,lo que me importa realmente y me importaba es poder jugar esos titulos en mi consola .

me entere que kirby llebaba chip 25 años despues ,que concluision saco? pues que el juego me flipo en su momento y lo sigue haciendo ,nada ha cambiado,como ese ejemplo la mayoria .

titorino escribió:

cirote3 escribió:

titorino escribió:lo que el tiempo ha demostrado que la decision de expander la consola asi fue todo un acierto.

Nunca sabremos cómo hubieran sido los juegos de la SNES si hubiera llevado una CPU más potente de serie.

pues igual que estaba segurmante ,hubiesen añadido chips igualmente porque fue diseñada con ese fin .
no todos los chips sirven para lo mismo ,

Si la CPU de la SNES hubiera sido más potente, el SuperFX lo más normal es que hubiera salido igual, pero otros como el DSP-1 (Super Mario Kart) o el SA-1 (Super Mario RPG) igual no habrían salido o se habrían usado mucho menos.

@cirote3 puede ser pero lo notariamos? no creo
seguramente nintendo se plantearia meter esos chip de serie en la consola y por lo que fuese pues no fue,pero mira al final las cosas salieron y nada mal ,asi que seria un poco jugar a adivinar o cambiar el futuro y si...y si lo otro...

hay un poco de paranoia con ese tema en casi todos lo que no les gusto snes y no les gusta ,para mi son una maravilla tecnologica y es mas deberia de haber mas chips y la scene aprovecharlos a saco que para eso son del entorno del sistema y permioten cosas muy guapas .
fuera del deporte : VIVA EL DOPAJE!

titorino escribió:@cirote3 puede ser pero lo notariamos? no creo

Claro que lo notaríamos: más juegos con menos ralentizaciones o sin ellas, más juegos con modo 7, menos juegos con bandas negras, más juegos con modo a dobles, etc. Algunos juegos también habrían sido más largos porque hubieran podido salir en una SlowROM más grande en vez de en una FastROM más pequeña.

titorino escribió:deberia de haber mas chips y la scene aprovecharlos a saco que para eso son del entorno del sistema y permioten cosas muy guapas.

Otro de los problemas de los chips extra antiguos es que la scene en general no puede aprovecharlos porque muy poca gente tiene cartuchos con chips que permitan desarrollar con ellos. Como los flashcart emulan los chips en vez de llevarlos de verdad, no puedes fiarte de ellos.

@cirote3 estamos derivando la conversdacion
comente que lo de la inclusion de chips especiales para hacwer cosas diferentes como poligonos y demas fue un acierto ,viendo lo que hizo la competencia .
comentaste esto:

Nunca sabremos cómo hubieran sido los juegos de la SNES si hubiera llevado una CPU más potente de serie

.

y te comente que los chips para hacer ese tipo de cosas saldria igualmente .
lo de las ralñentizaciones ,juegos a dobles ect no creo que tenga que ver en ese tema ,no se.
en la consola hay ejemplos de juegos que tenian ralentizaciones y se han quitado o mermado con solo cambiar a fast rom ,juegos a dobles que no lo tenian con un simple hack .
que la cpu de snes va justa para ciertas cosas es imnegable ,basar una consola como snes en solo la cpu creo que es un error tambien.
las consolas no solo son cpus ,si no un f zero tal cual seria posible en una megadrive por ejemplo al tener una cpu mas potente bastaria y sobraria para moverlo ,incluso mejor y no parece ser el caso en este titulo en concreto.

pero vamos no quiero crear el enesimo versus ,lo que quiero decir que la jugada no le salio nada mal a nintendo teniendo en cuenta que las ideas que tenian con la consola no pudieron hacerlas realidad .

Sabes que algo anda mal cuando no se tienen en cuenta factos del tamaño de una montaña, y se intenta desviar la atención hacia otros del tamaño de una canica. Snes, 4% de juegos con chip, mas del 50% de juegos que underclockean la consola, 0% de juegos con add on. Eso de "la consola mas dopada de la historia" lo podemos dejar a un lado tranquilamente, de hecho es la consola que mas juegos tiene por debajo de sus límites, que no es lo mismo... y eso sin entrar en toda la cantidad de ports sin adaptar a sus propias capacidades.

Por otro lado, el argumento de usar la vram como memoria de trabajo, sabemos que no está siendo real. Formas indirectas de obtener resultados no son formas directas de trabajar, y esto sin entrar en debates sobre la eficiencia, ¿que es lo próximo?, ¿que se pueden hacer transferencias sin DMA?, realmente no se de que estamos hablando aquí... NO existe forma de dopar el ancho de banda, ni con chip, ni con trucos. La unidad DMA carece de divisores para variar su frecuencia de trabajo, tal y como si hace el 65816, es una cuestión FÍSICA, y eso no te lo puedes saltar con nada.

Solo existen formas indirectas de que ciertos resultados cundan un poco mas, y esas no te las proporciona ningún chip, sino la propia snes. No es lo mismo.

SuperPadLand escribió:Pues no me hagas mucho caso, pero entonces no es todo mérito de la SNES a pelo.

Pues no se, obviamente el dragon's lair no cabe entero en 128 megabits, pero las escenas que si cupiesen tendrían exactamente las mismas características.

Caben menos fragmentos de vídeo, menos escenas, pero las que quepan son renderizadas igual, y reproducidas a la misma tasa, luego, es la super nintendo la que lo está procesando, no el msu1.

cirote3 escribió:Si la CPU de la SNES hubiera sido más potente, el SuperFX lo más normal es que hubiera salido igual, pero otros como el DSP-1 (Super Mario Kart) o el SA-1 (Super Mario RPG) igual no habrían salido o se habrían usado mucho menos.

Lo curioso es que muchos de esos chips se usaron desde el principio de la vida de la consola...siendo esta la última en salir de las tres 16 bits (sacando de la ecuación a Neo Geo). Mientras que las otras dos no tuvieron juegos dopados (excepción hecha de Virtua Racing) cuando eran más antiguas y supuestamente los hubieran necesitado para competir con SNES. Lo lógico es que hubieran salido estos juegos con chip al final de su vida comercial para aguantar el tirón de la siguiente generación de 32 bits. Da que pensar.

gaditanomania escribió:

cirote3 escribió:Si la CPU de la SNES hubiera sido más potente, el SuperFX lo más normal es que hubiera salido igual, pero otros como el DSP-1 (Super Mario Kart) o el SA-1 (Super Mario RPG) igual no habrían salido o se habrían usado mucho menos.

Lo curioso es que muchos de esos chips se usaron desde el principio de la vida de la consola...siendo esta la última en salir de las tres 16 bits (sacando de la ecuación a Neo Geo). Mientras que las otras dos no tuvieron juegos dopados (excepción hecha de Virtua Racing) cuando eran más antiguas y supuestamente los hubieran necesitado para competir con SNES. Lo lógico es que hubieran salido estos juegos con chip al final de su vida comercial para aguantar el tirón de la siguiente generación de 32 bits. Da que pensar.

Exactamente para mi SNES salio con una tara en la CPU muy grande.

Señor Ventura escribió:Sabes que algo anda mal cuando no se tienen en cuenta factos del tamaño de una montaña, y se intenta desviar la atención hacia otros del tamaño de una canica. Snes, 4% de juegos con chip, mas del 50% de juegos que underclockean la consola, 0% de juegos con add on. Eso de "la consola mas dopada de la historia" lo podemos dejar a un lado tranquilamente, de hecho es la consola que mas juegos tiene por debajo de sus límites, que no es lo mismo... y eso sin entrar en toda la cantidad de ports sin adaptar a sus propias capacidades.

No se underclockea la consola es que para ahorrar costes pusieron esa memoria y esa CPU pocha, es algo intrinseco de la arquitectura no es algo que haga el desarrollador deliberadamente, es una limitación de la consola para que nintendo ganara mas dinero en su monopolio de facto con NES.

Y claro que no se puede dejar de lado no, es la consola de toda la historia con mas cartuchos dopados, es una realidad y tiene su razón de ser que es la que quieres negar.

SNES se aprocechó al mismo nivel o más que una PSX con los mejores estudios y los mejores presupuestos de la época, de hecho que existan juegos con esos cartuchos te enseña que no se reparaba en gastos con la favorita de la gen, SNES no te va a dar magicamente en un beatemup 2 players y 5 enemigos con sprites tochos sin parpadeos y con fluidez porque la consola no esta diseñado para ella.

SNES tiene una serie de caracteristicas que fomentan ciertos tipos de generos y otras consolas tienen otros...

Señor Ventura escribió:Pues no se, obviamente el dragon's lair no cabe entero en 128 megabits, pero las escenas que si cupiesen tendrían exactamente las mismas características.

Y si la abuela llevaba ruedas seria una bicicleta, al realidad es la que es el juego no es posible sin el chip y deberias reconocer tu error.

gaditanomania escribió:

cirote3 escribió:Si la CPU de la SNES hubiera sido más potente, el SuperFX lo más normal es que hubiera salido igual, pero otros como el DSP-1 (Super Mario Kart) o el SA-1 (Super Mario RPG) igual no habrían salido o se habrían usado mucho menos.

Lo curioso es que muchos de esos chips se usaron desde el principio de la vida de la consola...siendo esta la última en salir de las tres 16 bits (sacando de la ecuación a Neo Geo). Mientras que las otras dos no tuvieron juegos dopados (excepción hecha de Virtua Racing) cuando eran más antiguas y supuestamente los hubieran necesitado para competir con SNES. Lo lógico es que hubieran salido estos juegos con chip al final de su vida comercial para aguantar el tirón de la siguiente generación de 32 bits. Da que pensar.

Salió con limitaciones clamorosas llegando mas tarde pero también tiene cosillas que no tienen las consolas mas antiguas asi que como al final hay que repercutir el coste al usuario, simplemente cortaron unas cosas para añadir otras, ya el equilibrio y tal que decida cada uno, lo que al final importa es que la consola pese a sus luces y sombras fue un éxito con juegardos terribles haciendola indispensable para entender su generación.

Un Saludo.

Señor Ventura escribió:el argumento de usar la vram como memoria de trabajo, sabemos que no está siendo real.

Yo en mi juego descomprimo paletas de colores, tiles y tilemaps en VRAM sin DMA y renderizo texto en VRAM sin DMA, porque es más eficiente hacer eso que trabajar en la WRAM y luego copiar el resultado a la VRAM. Hay muchos juegos comerciales en SNES que hacen lo mismo. Son casos reales, aunque te hagan quedar mal. Una vez más, si no fuera útil escribir en la VRAM con la CPU, Nintendo no habría añadido registros a la SNES para hacerlo posible.

Y si no te fías de mí, arranca mi juego con un emulador y busca la región de WRAM en la que imprimo el texto de los diálogos antes de copiarlo a la VRAM. Te va a costar encontrarla.

gaditanomania escribió:

cirote3 escribió:Si la CPU de la SNES hubiera sido más potente, el SuperFX lo más normal es que hubiera salido igual, pero otros como el DSP-1 (Super Mario Kart) o el SA-1 (Super Mario RPG) igual no habrían salido o se habrían usado mucho menos.

Lo curioso es que muchos de esos chips se usaron desde el principio de la vida de la consola...siendo esta la última en salir de las tres 16 bits (sacando de la ecuación a Neo Geo). Mientras que las otras dos no tuvieron juegos dopados (excepción hecha de Virtua Racing) cuando eran más antiguas y supuestamente los hubieran necesitado para competir con SNES. Lo lógico es que hubieran salido estos juegos con chip al final de su vida comercial para aguantar el tirón de la siguiente generación de 32 bits. Da que pensar.

El Pilotwings, juego de salida de Nintendo, ya llevaba el DSP-1, por lo que desde el principio la SNES se diseñó con la idea de añadir chips extra a los cartuchos.

naxeras escribió:

Señor Ventura escribió:Pues no se, obviamente el dragon's lair no cabe entero en 128 megabits, pero las escenas que si cupiesen tendrían exactamente las mismas características.

Y si la abuela llevaba ruedas seria una bicicleta, al realidad es la que es el juego no es posible sin el chip y deberias reconocer tu error.

cirote3 escribió:Yo en mi juego descomprimo paletas de colores, tiles y tilemaps en VRAM sin DMA y renderizo texto en VRAM sin DMA, porque es más eficiente hacer eso que trabajar en la WRAM y luego copiar el resultado a la VRAM. Hay muchos juegos comerciales en SNES que hacen lo mismo. Son casos reales, aunque te hagan quedar mal. Una vez más, si no fuera útil escribir en la VRAM con la CPU, Nintendo no habría añadido registros a la SNES para hacerlo posible.

Y si no te fías de mí, arranca mi juego con un emulador y busca la región de WRAM en la que imprimo el texto de los diálogos antes de copiarlo a la VRAM. Te va a costar encontrarla.

Espera espera, ¿estas haciendo algo para SNES o es GBA que también tiene WRAM?

@cirote3 vas a sacar cirote 2 para snes

naxeras escribió:

cirote3 escribió:Yo en mi juego descomprimo paletas de colores, tiles y tilemaps en VRAM sin DMA y renderizo texto en VRAM sin DMA, porque es más eficiente hacer eso que trabajar en la WRAM y luego copiar el resultado a la VRAM. Hay muchos juegos comerciales en SNES que hacen lo mismo. Son casos reales, aunque te hagan quedar mal. Una vez más, si no fuera útil escribir en la VRAM con la CPU, Nintendo no habría añadido registros a la SNES para hacerlo posible.

Y si no te fías de mí, arranca mi juego con un emulador y busca la región de WRAM en la que imprimo el texto de los diálogos antes de copiarlo a la VRAM. Te va a costar encontrarla.

Espera espera, ¿estas haciendo algo para SNES o es GBA que también tiene WRAM?

La GBA tiene dos tipos de WRAM, la rápida de 32KB y la lenta de 256KB. La rápida se suele usar para el código que más ciclos chupa, como el engine 3D o las librerías de audio. La lenta se suele usar para el resto.

titorino escribió:@cirote3 vas a sacar cirote 2 para snes

Antes de la SNES va la N64

De nuevo, la vram de estas maquinas no son memorias de trabajo. Se pueden hacer cosas de forma indirecta, y por supuesto limitada, pero eso no las convierte en memorias de trabajo, no hay mas.

Es un lujazo venir al hilo de snes a decir que tiene una cpu raquítica y defectuosa, si alguien hace eso en otros hilos con otras consolas acaba reportado.

No, no es raquítica ni defectuosa. Hay que entender lo que hizo nintendo para poder hablar.

Y no estoy equivocado, cada frame generado del dragon's lair no se procesa gracias al msu1, ni gracias a ningún chip externo. Reconoced vosotros vuestro error.