[SUPER NINTENDO] Hilo oficial.

Responder
1…46, 47, 48, 49, 50
O´Neill escribió:Con el fix hirom el juego va como un tiro.


No.

Sexy MotherFucker escribió:
O´Neill escribió:Con el fix hirom el juego va como un tiro.


De hecho tampoco se ralentizaba tanto; la zona de los hombres de barro, el puente de los murciélagos, y no mucho más.

BTW la version Pal tenía menos ralentizaciones.



Pues no sé que versión jugué, supongo que la NTSC, pero se ralentizaba bastante más. Aunque también depende de lo bien que juegues ya que muchas ralentizaciones no se producen cuando ya te sabes el nivel de memoria y vas rápido limpiando de enemigos por ejemplo. En las rotaciones y efectos de ese tipo también rasca más. No es injugable evidentemente, pero no va como un tiro con fastom y mucho menos con slowrom. No sé si sacaron hack SA1 para este que en ese caso sí debería ir como un tiro.
Si un 65816 se fabricase con el tamaño de transistores de hoy en día, tendría un tamaño de solo una mínima fracción de un grano de arena.

Literalmente sería microscópico, lo cual da miedito en contextos modernos, si nos ponemos conspiranóicos xD
Señor Ventura escribió:Si un 65816 se fabricase con el tamaño de transistores de hoy en día, tendría un tamaño de solo una mínima fracción de un grano de arena.

Literalmente sería microscópico, lo cual da miedito en contextos modernos, si nos ponemos conspiranóicos xD


No he entendido esto a que viene ni tampoco porque han vuelto a banear a Sexy
@SuperPadLand con fast rom va perfecto,esta claro que las ralentizaciones eran por utilizar memorias lentas y seguramente se podrá optimizar aun mas ,ese juego no exprime la snes ni de lejos
titorino escribió:@SuperPadLand con fast rom va perfecto,esta claro que las ralentizaciones eran por utilizar memorias lentas y seguramente se podrá optimizar aun mas ,ese juego no exprime la snes ni de lejos


Pues entonces o mi hackeo salió mal o mi SNES está petando.
Señor Ventura escribió:Estirar horizontalmente los scanlines de un plano es algo que me suena haber visto en multiples juegos de cualquier 16 bits, se trataría de elegir cuales, y cuanto.


A mí no me suena de haberlo visto (excepto con modo 7). Verticalmente sí, las puedes duplicar o eliminar. Moverlas de izquierda a derecha para crear efectos de ondulaciones también lo he visto en cantidad de juegos. Mover columnas de escenario verticalmente también lo he visto tanto en Mega como en Super.

Es más, el modo 7 está pensado para scaling y rotaciones de fondos por hardware, el super scaler de Sega también hacía su función por hardware. Son cálculos costosos de hacer por software.
SuperPadLand escribió:
titorino escribió:@SuperPadLand con fast rom va perfecto,esta claro que las ralentizaciones eran por utilizar memorias lentas y seguramente se podrá optimizar aun mas ,ese juego no exprime la snes ni de lejos


Pues entonces o mi hackeo salió mal o mi SNES está petando.

pues mira porque no es dificil conseguirlo

titorino escribió:
SuperPadLand escribió:
titorino escribió:@SuperPadLand con fast rom va perfecto,esta claro que las ralentizaciones eran por utilizar memorias lentas y seguramente se podrá optimizar aun mas ,ese juego no exprime la snes ni de lejos


Pues entonces o mi hackeo salió mal o mi SNES está petando.

pues mira porque no es dificil conseguirlo


No, si tener lo tengo, es el que jugué en el hilo del juego del mes. Estaría mal entonces.

Edit: De hecho todavía tengo los password anotados de mi partida. Aunque ya no sé si lo jugué en el hilo del mes o por mi cuenta cuando recibí el SD2SNES.
MasterDan escribió:Son cálculos costosos de hacer por software.


De ahí que solo se haya empleado en solo unos pocos scanlines, si el escalado hubiese sido frontal en lugar de inclinado el impacto en el rendimiento habría sido notable.

Y luego hay fórmulas para escalar, y fórmulas para escalar. Puedes hacerlo mediante transformaciones o proyecciones, o puedes precalcular (que no predibujar), pero, ¿que tal duplicar los píxeles de cada scanline progresivamente sin tener en cuenta el resto de la composición de la imagen?, sería una forma de escalar esa imagen sin tanto impacto en el rendimiento, y técnicamente sigue siendo escalado, ¿no? (me baso en la falta de suavidad cuando sucede la inclinación, y que debería funcionar muy bien con enteros, ¿te parece plausible?).
@Señor Ventura

Las transformaciones (que es el típico escalado) son costosas. Precalcular la imagen es poco costoso para la CPU pero ocupa espacio extra, tanto en la eprom como en VRAM (pero es muy buen truco).

Duplicar píxeles no es tan fácil o rápido como parece. Primero de todo tienes que tener un lugar dónde hacerlo, en un PC sería un framebuffer, en una SNES en modo 1 (por ejemplo) no se si dispondría de este sitio. Lo segundo es que no puedes duplicar píxeles al tuntún, si duplicas todos los píxeles del scanline estás doblando el tamaño de este, por lo que el efecto quedaría poco fluido. Se tienen que ir duplicando algunos sí y otros no para que el efecto sea suave. Esto en el fondo no es problemático ya que se puede solucionar con tablas precalculadas para saber que píxel duplicar en cada momento según el porcentaje de escalado que queramos. Luego está el último problema, la resolución horizontal de SNES es de 256 píxels (normalmente) esto significa que para un escalado de 2X (el más simple) en el tiempo de hblank ha de ejecutar 128 operaciones de duplicación de píxeles que son varias operaciones cada una. Si el escalado no es en escala 2 elevado a n además entre estas operaciones incluye consultar la tabla para ver si ese pixel se duplica o no.

No creo que diera tiempo material de hacer esto ni con fastrom en la duración de un hblank. También puede que me equivoque ;)
SuperPadLand escribió:El Castlevania IV lo jugamos en el hilo del juego del mes hace un tiempo y es un juego que se ralentiza bastante y especialmente en esos momentos de rotaciones y efectos chulos, incluso en el vídeo ese se puede percibir. Si no usase modo 7 para hacerlos digo yo que el rendimiento incluso sería peor no? Estas ralentizaciones se producen igualmente con el hack fastrom así que se salvaría sólo con usar una ROM de estas.

No es por el modo 7. Con o sin el, las ralentizaciones seguirían existiendo.

El problema del bajón de rendimiento se debe al número de colisiones que debe calcular la CPU, dado que en esa pantalla todo son sprites; excepto el background, que es modo 7. Las plataformas, los enemigos, etc... todo son sprites con colisión activada.

Y sí, en la mayoría de los videojuegos de 8 y 16 bits de Nintendo y Sega, cuando veis ralentizaciones, por lo general se debe a que en pantalla existen muchísimas colisiones a calcular (que no sprites, ojo, pues puede haber sprites sin colisión).
Diskover escribió:
SuperPadLand escribió:El Castlevania IV lo jugamos en el hilo del juego del mes hace un tiempo y es un juego que se ralentiza bastante y especialmente en esos momentos de rotaciones y efectos chulos, incluso en el vídeo ese se puede percibir. Si no usase modo 7 para hacerlos digo yo que el rendimiento incluso sería peor no? Estas ralentizaciones se producen igualmente con el hack fastrom así que se salvaría sólo con usar una ROM de estas.

No es por el modo 7. Con o sin el, las ralentizaciones seguirían existiendo.

El problema del bajón de rendimiento se debe al número de colisiones que debe calcular la CPU, dado que en esa pantalla todo son sprites; excepto el background, que es modo 7. Las plataformas, los enemigos, etc... todo son sprites con colisión activada.

Y sí, en la mayoría de los videojuegos de 8 y 16 bits de Nintendo y Sega, cuando veis ralentizaciones, por lo general se debe a que en pantalla existen muchísimas colisiones a calcular (que no sprites, ojo, pues puede haber sprites sin colisión).


De hecho es cuando más recuerdo que se ralentiza ese juego al acumular enemigos y/o proyectiles, pero también en el efecto tubular ese del modo 7 recuerdo que era más intenso. También se ralentiza bastante cuando hay plataformas desapareciendo/cayendo. Pero igual es que mi hackeo salió mal y no lo jugué con fastrom a 60fps perfectos y sufrí innecesariamente. [+risas]
SuperPadLand escribió:
No, si tener lo tengo, es el que jugué en el hilo del juego del mes. Estaría mal entonces.

Edit: De hecho todavía tengo los password anotados de mi partida. Aunque ya no sé si lo jugué en el hilo del mes o por mi cuenta cuando recibí el SD2SNES.


Me has hecho dudar.
Lo he revisado y no, no jugamos a ese juego en el hilo de juego del mes 😜

Le hubiera pegado fuego…
aleroh escribió:
SuperPadLand escribió:
No, si tener lo tengo, es el que jugué en el hilo del juego del mes. Estaría mal entonces.

Edit: De hecho todavía tengo los password anotados de mi partida. Aunque ya no sé si lo jugué en el hilo del mes o por mi cuenta cuando recibí el SD2SNES.


Me has hecho dudar.
Lo he revisado y no, no jugamos a ese juego en el hilo de juego del mes 😜

Le hubiera pegado fuego…


Entonces fue cuando me llegó el cartucho de marras, de hecho fue con este juego que probé también como iban los save/load states del cartucho y me bugueaba la música hasta llegar a la siguiente zona [carcajad]
SuperPadLand escribió:
aleroh escribió:
SuperPadLand escribió:
No, si tener lo tengo, es el que jugué en el hilo del juego del mes. Estaría mal entonces.

Edit: De hecho todavía tengo los password anotados de mi partida. Aunque ya no sé si lo jugué en el hilo del mes o por mi cuenta cuando recibí el SD2SNES.


Me has hecho dudar.
Lo he revisado y no, no jugamos a ese juego en el hilo de juego del mes 😜

Le hubiera pegado fuego…


Entonces fue cuando me llegó el cartucho de marras, de hecho fue con este juego que probé también como iban los save/load states del cartucho y me bugueaba la música hasta llegar a la siguiente zona [carcajad]


😜
Tengo que probar esa fast-rom a ver cómo funciona…
Diskover escribió:(que no sprites, ojo, pues puede haber sprites sin colisión).


Y colisión sin sprites, ¿las tumbas del plano se rompen cuando te acercas?.
aleroh escribió:
SuperPadLand escribió:
aleroh escribió:
Me has hecho dudar.
Lo he revisado y no, no jugamos a ese juego en el hilo de juego del mes 😜

Le hubiera pegado fuego…


Entonces fue cuando me llegó el cartucho de marras, de hecho fue con este juego que probé también como iban los save/load states del cartucho y me bugueaba la música hasta llegar a la siguiente zona [carcajad]


😜
Tengo que probar esa fast-rom a ver cómo funciona…


Según dicen va perfecto sin ralentizaciones, 60fps estables. Yo tuve que parchear mal el hack evidentemente.
El mayor problema es la optimizacion del propio juego.

La monstruosidad que tiene que llegar a calcular el gradius, con cajas de colisiones por triplicado, y que a sus 3,58mhz legítimos vaya muy aceptable en rendimiento pese a ser uno de los primeros juegos de la máquina, despeja dudas sobre su capacidad.

Una maravilla del procesamiento secuencial.
Señor Ventura escribió:El mayor problema es la optimizacion del propio juego.

La monstruosidad que tiene que llegar a calcular el gradius, con cajas de colisiones por triplicado, y que a sus 3,58mhz legítimos vaya muy aceptable en rendimiento pese a ser uno de los primeros juegos de la máquina, despeja dudas sobre su capacidad.

Una maravilla del procesamiento secuencial.


No sé bien que tratas de decir, yo no he hablado de las capacidades o no del sistema sino que jugué un juego e iba mal con y sin fastrom. Esto último aparentemente mal parcheado.
Señor Ventura escribió:
Diskover escribió:(que no sprites, ojo, pues puede haber sprites sin colisión).


Y colisión sin sprites, ¿las tumbas del plano se rompen cuando te acercas?.

Efectivamente.

Tú puedes poner puntos o cajas de colisión donde te dé la gana.

En muchos videojuegos, existen colisiones en ciertos puntos del background. Por ejemplo: puertas que dan acceso a otras áreas.

Hay que imaginarse las colisiones como si fuesen una capa independiente de todos los planos visuales (planos de background y planos de sprites.).

Depende de como esté diseñado el videojuego, existen ciertas colisiones que pueden estar representados por elementos del background o por sprites, pero esto no quiere decir que todo el background o todos los sprites, tengan colisiones.

Y luego existen técnicas para depurar colisiones y que estas no penalicen tanto a la CPU. Hay que tener claro siempre que una colisión es un elemento que siempre va a estar dando coordenadas a la CPU y esta tiene que compararlas con el objetivo asignado, muchas veces por ciclo. A más hercios (y bits) tenga una CPU, mejor saldrá solventado el problema dado que tiene más velocidad de procesamiento.

También existían técnicas en su época para solventar estos problemas de ralentizaciones, como era el caso de videojuegos donde algunos elementos que tenían colisión, solo representaban esta cuando había medio frame y no un frame completo, liberando de calculo a la CPU.

Hace poco el francés Upsilandre analizó en su web el videojuego arcade Ghouls'n Ghosts, y sus versiones más cercanas al original, y tiene un análisis detallado sobre el tema de las colisiones y esta técnica de ahorro de cálculo al procesador: https://upsilandre.over-blog.com/2025/0 ... hosts.html

Imagen


No es una técnica que Capcom hubiese inventado. En los años 80 muchísimas compañías hacían lo mismo con otros títulos, como por ejemplo Konami en el caso de Probotector/Contra de NES. Era algo muy habitual e imagino que hoy en día se siga usando en muchísimos videojuegos basados en polígonos.
Señor Ventura escribió:Si un 65816 se fabricase con el tamaño de transistores de hoy en día, tendría un tamaño de solo una mínima fracción de un grano de arena.

Literalmente sería microscópico, lo cual da miedito en contextos modernos, si nos ponemos conspiranóicos xD


Si un transistor moderno tuviese el tamaño de una pelota de tenis, ¿un transistor del 65816 tendría el tamaño de dos lavadoras?... esperaba mucho mas, la verdad.

MasterDan escribió:@Señor Ventura

Las transformaciones (que es el típico escalado) son costosas. Precalcular la imagen es poco costoso para la CPU pero ocupa espacio extra, tanto en la eprom como en VRAM (pero es muy buen truco).

Duplicar píxeles no es tan fácil o rápido como parece. Primero de todo tienes que tener un lugar dónde hacerlo, en un PC sería un framebuffer, en una SNES en modo 1 (por ejemplo) no se si dispondría de este sitio. Lo segundo es que no puedes duplicar píxeles al tuntún, si duplicas todos los píxeles del scanline estás doblando el tamaño de este, por lo que el efecto quedaría poco fluido. Se tienen que ir duplicando algunos sí y otros no para que el efecto sea suave. Esto en el fondo no es problemático ya que se puede solucionar con tablas precalculadas para saber que píxel duplicar en cada momento según el porcentaje de escalado que queramos. Luego está el último problema, la resolución horizontal de SNES es de 256 píxels (normalmente) esto significa que para un escalado de 2X (el más simple) en el tiempo de hblank ha de ejecutar 128 operaciones de duplicación de píxeles que son varias operaciones cada una. Si el escalado no es en escala 2 elevado a n además entre estas operaciones incluye consultar la tabla para ver si ese pixel se duplica o no.

No creo que diera tiempo material de hacer esto ni con fastrom en la duración de un hblank. También puede que me equivoque ;)


Mira, el mismo efecto en master system. Cuenta con la ventaja de repetir el patrón muchas veces, por lo que puedes rellenar la pantalla con las tiles ya calculadas, pero la parte central que permanece sin alteraciones no es tan grande, son muchos los scanlines que están "rasterizándose".

https://www.youtube.com/watch?v=4NdBKRsmJzg
Señor Ventura escribió:
Señor Ventura escribió:Si un 65816 se fabricase con el tamaño de transistores de hoy en día, tendría un tamaño de solo una mínima fracción de un grano de arena.

Literalmente sería microscópico, lo cual da miedito en contextos modernos, si nos ponemos conspiranóicos xD


Si un transistor moderno tuviese el tamaño de una pelota de tenis, ¿un transistor del 65816 tendría el tamaño de dos lavadoras?... esperaba mucho mas, la verdad.

MasterDan escribió:@Señor Ventura

Las transformaciones (que es el típico escalado) son costosas. Precalcular la imagen es poco costoso para la CPU pero ocupa espacio extra, tanto en la eprom como en VRAM (pero es muy buen truco).

Duplicar píxeles no es tan fácil o rápido como parece. Primero de todo tienes que tener un lugar dónde hacerlo, en un PC sería un framebuffer, en una SNES en modo 1 (por ejemplo) no se si dispondría de este sitio. Lo segundo es que no puedes duplicar píxeles al tuntún, si duplicas todos los píxeles del scanline estás doblando el tamaño de este, por lo que el efecto quedaría poco fluido. Se tienen que ir duplicando algunos sí y otros no para que el efecto sea suave. Esto en el fondo no es problemático ya que se puede solucionar con tablas precalculadas para saber que píxel duplicar en cada momento según el porcentaje de escalado que queramos. Luego está el último problema, la resolución horizontal de SNES es de 256 píxels (normalmente) esto significa que para un escalado de 2X (el más simple) en el tiempo de hblank ha de ejecutar 128 operaciones de duplicación de píxeles que son varias operaciones cada una. Si el escalado no es en escala 2 elevado a n además entre estas operaciones incluye consultar la tabla para ver si ese pixel se duplica o no.

No creo que diera tiempo material de hacer esto ni con fastrom en la duración de un hblank. También puede que me equivoque ;)


Mira, el mismo efecto en master system. Cuenta con la ventaja de repetir el patrón muchas veces, por lo que puedes rellenar la pantalla con las tiles ya calculadas, pero la parte central que permanece sin alteraciones no es tan grande, son muchos los scanlines que están "rasterizándose".

https://www.youtube.com/watch?v=4NdBKRsmJzg



En SNES esa calidad gráfica no es aceptable. Primero la SMS usa resolución 192p, la demo usa una buena franja negra para el HUD que está usando para el campo jugable? 140p? Solo 3 enemigos y casi ningún proyectil y a mayores lo que ya has indicado tú.

Para SMS evidentemente es genial y en SNES eso se tiene que poder hacer y mejor, pero no es algo que salga gratis ni a una ni a otra, sino todo lo contrario. La demo muestra más esto último que lo contrarío.

No sé que manía tenemos con que todo sale gratis o fácil cuando hasta procesar sonidos FX o música consume ciclos. Que hablando de esto, no puedo escuchar la demo de SMS ¿Tiene música y FX? Porque en NES la demo de axelay tenía que sacrificar el apartado sonoro para ello por ejemplo.
Buenas tardes, he rescatado de casa de mis padres mi Super Nintendo con los juegos. La consola funciona perfectamente pero las gomas sobre las que se apoya la consola están "derretidas" y pegajosas, me gustaría poder sustituirlas para que en un futuro pueda usarla sin que deje marcas.

He estado mirando en aliexpress y solo he encontrado gomas para sustituir en los mandos, pero ni idea de como puede llamarse para buscarla.

¿alguna idea?

Gracias!
Señor Ventura escribió:
Mira, el mismo efecto en master system. Cuenta con la ventaja de repetir el patrón muchas veces, por lo que puedes rellenar la pantalla con las tiles ya calculadas, pero la parte central que permanece sin alteraciones no es tan grande, son muchos los scanlines que están "rasterizándose".

https://www.youtube.com/watch?v=4NdBKRsmJzg


He estado mirándome el video un buen rato y no negaré que es impresionante (además de mareante). El tema como bien dices es que repite el patrón muchas veces, pero muchas muchas. En si lo que veo que hace es que sólo usa una columna de tiles de 16*16 y por lo tanto tanto pueden estar preanimados como calculados (doblar el tamaño sería repetir 2 veces ocho píxeles). Incluso podrían hacer el cálculo durante dos hblank repitiendo alguna línea y con todo el movimiento pasaría desapercibido.

Ahora bien, esto es un efecto muy impresionante pero con limitaciones impresionantes comparándolo al Super Castlevania. El fondo está formado por columnas idénticas, ya que el tiempo del hblank es muy reducido. Además aprovecha la capacidad de master system para espejar tiles para hacer la mitad derecha de la pantalla (que se curva para el otro lado) sin coste computacional.

¿Se podría haber hecho eso en el Super Castlevania en vez de usar el modo 7? Pues seguramente, pero con limitaciones similares: Un escenario repetitivo y algo mareante, además de tener que currarse un algoritmo eficiente que usar cada hblank para escalar una línea de 16 pixeles. Es más simple, eficiente y gráficamente más agradable tirar de modo 7 y usar un fondo más complejo.
satanjosein escribió:Buenas tardes, he rescatado de casa de mis padres mi Super Nintendo con los juegos. La consola funciona perfectamente pero las gomas sobre las que se apoya la consola están "derretidas" y pegajosas, me gustaría poder sustituirlas para que en un futuro pueda usarla sin que deje marcas.

He estado mirando en aliexpress y solo he encontrado gomas para sustituir en los mandos, pero ni idea de como puede llamarse para buscarla.

¿alguna idea?

Gracias!


Solo se me ocurre preguntar a alguien que controle de impresión 3D. Mi slot de cartuchos de Saturn es así.



MasterDan escribió:
Señor Ventura escribió:
Mira, el mismo efecto en master system. Cuenta con la ventaja de repetir el patrón muchas veces, por lo que puedes rellenar la pantalla con las tiles ya calculadas, pero la parte central que permanece sin alteraciones no es tan grande, son muchos los scanlines que están "rasterizándose".

https://www.youtube.com/watch?v=4NdBKRsmJzg


He estado mirándome el video un buen rato y no negaré que es impresionante (además de mareante). El tema como bien dices es que repite el patrón muchas veces, pero muchas muchas. En si lo que veo que hace es que sólo usa una columna de tiles de 16*16 y por lo tanto tanto pueden estar preanimados como calculados (doblar el tamaño sería repetir 2 veces ocho píxeles). Incluso podrían hacer el cálculo durante dos hblank repitiendo alguna línea y con todo el movimiento pasaría desapercibido.

Ahora bien, esto es un efecto muy impresionante pero con limitaciones impresionantes comparándolo al Super Castlevania. El fondo está formado por columnas idénticas, ya que el tiempo del hblank es muy reducido. Además aprovecha la capacidad de master system para espejar tiles para hacer la mitad derecha de la pantalla (que se curva para el otro lado) sin coste computacional.

¿Se podría haber hecho eso en el Super Castlevania en vez de usar el modo 7? Pues seguramente, pero con limitaciones similares: Un escenario repetitivo y algo mareante, además de tener que currarse un algoritmo eficiente que usar cada hblank para escalar una línea de 16 pixeles. Es más simple, eficiente y gráficamente más agradable tirar de modo 7 y usar un fondo más complejo.


Es que por muchas vueltas y trucos que busquemos nada va a igualar al modo 7 nativo de la consola que es uno de sus puntos superlativos frente al resto y, además de ser inferior calidad, costará más recursos. Están el resto de sistemas con homebrews que buscan similar lo más cercano posible el modo 7 y nunca es igual de bueno y siempre implica sacrificar por otro lado. SNES no va a generar un pseudo modo 7 nativo que vaya igual al original suyo y dudo mucho que igual que los de MD que son inferiores al original sobre todo en distancia de dibujado.
Hola,tengo un problema con mi super nintendo pal,la llevé a una tienda para hacer el mod de región mediante botón reset y desde hace unos días cada vez que la conecto tanto por rgb y av la pantalla se ve con interferencias.He cambiado cables y demás y nada,también tengo conectado una mega y una xbox clásica y cero problemas....a que puede ser debido?
ryo1975 escribió:Hola,tengo un problema con mi super nintendo pal,la llevé a una tienda para hacer el mod de región mediante botón reset y desde hace unos días cada vez que la conecto tanto por rgb y av la pantalla se ve con interferencias.He cambiado cables y demás y nada,también tengo conectado una mega y una xbox clásica y cero problemas....a que puede ser debido?


Al mod de región mediante el botón reset. Consulta los esquemas y revisa que esté todo bien. Soldaduras en condiciones, sin impurezas o conexiones puenteadas.

MasterDan escribió:¿Se podría haber hecho eso en el Super Castlevania en vez de usar el modo 7? Pues seguramente, pero con limitaciones similares: Un escenario repetitivo y algo mareante, además de tener que currarse un algoritmo eficiente que usar cada hblank para escalar una línea de 16 pixeles. Es más simple, eficiente y gráficamente más agradable tirar de modo 7 y usar un fondo más complejo.


La clave está en cuantas operaciones de multiplicación del ppu1 es capaz de de recoger el 65816 (fuera del modo 7). Ignoro si la cpu puede realizar alguna mediante si misma mientras espera sincronización con el sistema de video para leer las suyas... la lógica me dice que no porque cuesta menos ciclos leer de los registros que hacer una multiplicación, y el ppu1 es mas rápido, por lo que poco tendrá que esperar el 65816, y de hacerlo no se puede esperar que sea mas tiempo de lo que tarde en multiplicar, además no es un procesador para paralelizar, pero nunca se sabe...

Es mas cómodo desde el modo 7, y admite mas complejidad, pero fuera del modo 7 no tendrías que hacer las plataformas con sprites, e incluso poder hacerlas con un fondo que de un aspecto mas consistente, y mas grande.
Pregunta rápida, se puede usar el adaptador para jugar juegos PAL en sistema Super Famicom?

Me refiero al tipico adaptador que ponia en la SNES para jugar a juegos japos. Nunca lo probé a la inversa (por aquello de no tener Super Famicom) y ahora tengo la curiosidad XD
@thespriggan2009 Si se puede, aunque no te aseguro que todos te vayan bien. Necesitarás un juego Japo por eso para engañar a la máquina igual que en una PAL has de usar un juego PAL.
No sé si alguien me puede ayudar con lo que creo que es un problema en mi Super Famicom.

Hace poco compré una Super Famicom Japonesa para poder jugar en la CRT donde tengo desde hace un par de años, una RaspBerry por Euroconector.

Compré también el cable scart de retrocables.es que me han recomendado para ver la imagen con la mayor definición posible. Aún así, al visualizar los juegos en la CRT, veo una especie de "capa de neblina". Esta especie de neblina frontal no está presente cuando emulo los mismos juegos con la RaspBerry. Sé que mi consola no es una one chip, pero me preguntaba si esa especie de niebla frontal es normal o no. He probado con 2 everdrives diferentes y ese no parece ser el problema. Es la nitidez del pixel lo que parece que no se aprecia del todo bien. Quizás no me hubiera dado cuenta de esto si no hubiera jugado emulando antes estos juegos, pero al verlo, me he llevado una decepción.

¿Tiene arreglo este tipo de problemas? ¿A Alguien más le ocurre?
(No puedo sacar foto por que no se aprecia en detalle esa neblina, soy poco experto en sacar fotos a CRTs)
@MasterDan gracias! Pues tendré que probarlo, mi SNES murió hace mucho y tiro de una SFC que pillé hace tiempo, pero tengo mucha cartuchada pal muerta de asco XD

Probaré con alguno de los juegos japos que tengo, a ver si conecta y funciona. Nunca se me ocurrió que podría funcionar cambiando consola y cartuchos, sinceramente. Simple que es uno.
Me he puesto a buscar información y lo que he encontrado es que la salida de vídeo de Super Nintendo era de baja o mala calidad. Al parecer las onechip siguen teniendo ese problema de la neblina o "blur" que yo veo y la baja definición que de base tiene. Hay quienes han creado hardware externo para hacer que se vea bien y detallado el pixel.

Luego por eso quizás en los emuladores la imagen es tan nítida pero luego en hardware real sea tan mala teniendo que hacer las modificaciones con Edge Enhancer para mejorarla.

Vaya chasco me he llevado. Si llego a saber que para disfrutar de una imagen de calidad hay que diseccionar la consola... Tanto énfasis en los colores para luego darle esa salida de vídeo tan pobre? Imperdonable.
Diría que ya se puso antes, pero sobre el tema de las relaciones de aspecto en algunos ports de capcom en snes.

https://www.youtube.com/watch?v=LHfPA4n ... IHNuZXM%3D
Lag_Sinatra escribió:Me he puesto a buscar información y lo que he encontrado es que la salida de vídeo de Super Nintendo era de baja o mala calidad. Al parecer las onechip siguen teniendo ese problema de la neblina o "blur" que yo veo y la baja definición que de base tiene. Hay quienes han creado hardware externo para hacer que se vea bien y detallado el pixel.

Luego por eso quizás en los emuladores la imagen es tan nítida pero luego en hardware real sea tan mala teniendo que hacer las modificaciones con Edge Enhancer para mejorarla.

Vaya chasco me he llevado. Si llego a saber que para disfrutar de una imagen de calidad hay que diseccionar la consola... Tanto énfasis en los colores para luego darle esa salida de vídeo tan pobre? Imperdonable.


La mía Pal se ve absolutamente nítida, con pixeles 100% definidos conectados por RGB. Incluso por rca se ve bastante nítida. La única consola que para mi se ve borrosa en crt es la Megadrive por rca, pero incluso esa con el cable Rgb se arregla. Yo creo que algo hay mal ahí (ojo mi Snes es una juanchis, no se como irá en las otras).
Yo le recomendaría que fuera al oftalmólogo.
@Yaripon Yo es que no tengo más consolas retro que la Super Famicom, he leído en reddit y en algunos foros lo mismo que me ocurre a mí que es algo bastante generalizado, veo muchos aconsejando modificar la consola vía hardware para tener una mejor salida RGB. Tengo una Panasonic Tau CT-32SF25 japonesa y por la misma entrada lo que emulo se ve perfectamente definido, tanto emulación de SNES como de otras y la diferencia se nota muchísimo, quizás no la notaría si no hubiera probado anteriormente la emulación.

@Bimmy Lee Yo te recomendaría un test para ver qué porcentaje de discapacidad tienes. A lo mejor este año te has superado y te aumentan la ayuda que te da el gobierno. Como sugerencia.
Lag_Sinatra escribió:@Yaripon Yo es que no tengo más consolas retro que la Super Famicom, he leído en reddit y en algunos foros lo mismo que me ocurre a mí que es algo bastante generalizado, veo muchos aconsejando modificar la consola vía hardware para tener una mejor salida RGB. Tengo una Panasonic Tau CT-32SF25 japonesa y por la misma entrada lo que emulo se ve perfectamente definido, tanto emulación de SNES como de otras y la diferencia se nota muchísimo, quizás no la notaría si no hubiera probado anteriormente la emulación.


No se decirte, yo ahora las juego en tv actual con scaler, y en calidad de imagen Snes + Scaler se me ve igual que el emulador sólo que con menos latencia. No noto diferencias. Respecto a CRT hace muchos años que no juego un emu en uno, pero entiendo que sería lo mismo. Igual el cable que te han mandado para la snes es incorrecto, mira que el cable para una pal y una ntsc no es igual por dentro.
@Yaripon El cable está bien, es un scart NTSC de 40€ de retrocables.es, vamos es hasta mejor que el que uso con la Raspberry Pi. Lo usar scaler y demás... para una TV actual suena perfecto. Será cosa de probar. Gracias por tu respuesta.
Yaripon escribió:La mía Pal se ve absolutamente nítida, con pixeles 100% definidos conectados por RGB. Incluso por rca se ve bastante nítida. La única consola que para mi se ve borrosa en crt es la Megadrive por rca, pero incluso esa con el cable Rgb se arregla. Yo creo que algo hay mal ahí (ojo mi Snes es una juanchis, no se como irá en las otras).


Creo que cuando hablan de que la SNES (primeros modelos) tiene una mala calidad de imagen, se refieren solo a cuando se conecta a RGB, donde efectivamente, comparada con el resto de consolas conectadas de esta forma, la SNES no se ve tan nítida.

Pero si, si conectamos por RCA o RF, la SNES tiene una calidad de imagen excelente (que no perfecta), que no puede llegar a comparar ni la Mega Drive/Genesis.

De hecho, la Mega Drive/Genesis por RCA o RF se ve terriblemente mal. Este es uno de los aspectos por lo que durante mi niñez, me parecía esta consola muy inferior con respecto a SNES. Pocos colores, todo emborronado. Me parecía que no había competencia posible dando esa imagen.

Luego, claro, conectas por RGB a la Mega Drive/Genesis y la cosa cambia abismalmente.
Con el rca en snes tenías lo mejor de los dos mundos: nitidez aceptable, y dithering disimulado.
Señor Ventura escribió:Con el rca en snes tenías lo mejor de los dos mundos: nitidez aceptable, y dithering disimulado.


Con RCA en ninguna consola tenías nitidez 😂 Otra cosa es que el borroncho quedase mejor que los pixeles marcados. Yo después de una fiebre RGB he empezado a ver más las virtudes de RCA clásico, la única excepción N64 que al llevar ya su propio suavizado la nitidez ganada del RGB se agradece.
SuperPadLand escribió:
Señor Ventura escribió:Con el rca en snes tenías lo mejor de los dos mundos: nitidez aceptable, y dithering disimulado.


Con RCA en ninguna consola tenías nitidez 😂 Otra cosa es que el borroncho quedase mejor que los pixeles marcados. Yo después de una fiebre RGB he empezado a ver más las virtudes de RCA clásico, la única excepción N64 que al llevar ya su propio suavizado la nitidez ganada del RGB se agradece.


A mi Nes y Snes en crt se me veían cojonudas por rca, no exageremos con borrones. Curiosamente, eso sí, la nitidez variaba muchísimo de un CRT a otro, sobre todo en Nes. Tengo algún crt que la Nes se ve que parece que tiene Rgb (creo que los más modernos) y otros que las líneas quedan medio torcidas y se ven algunos artefactos. A la salida rca se le ha echado mucha mierda por lo problemática que es con tvs de hoy día. Por mucho escaler que se use y uno se rompa la cabeza, a lo más que llegas es a un nivel aceptable, pero no se logra una imagen buena. Ahora le estoy dando a saco a la Nes con los 2 scaler y.... bueeeeeno, se puede jugar y tal, pero bien bien no se ve. Sin embargo la Snes por RGB se ve espectacular con el scaler. Pero en crt el cable amarillito cumple con creces en ambas. Megadrive excepto juegos concretos Rgb si o si, pero es la única que la diferencia es abismal.
Yaripon escribió:
SuperPadLand escribió:
Señor Ventura escribió:Con el rca en snes tenías lo mejor de los dos mundos: nitidez aceptable, y dithering disimulado.


Con RCA en ninguna consola tenías nitidez 😂 Otra cosa es que el borroncho quedase mejor que los pixeles marcados. Yo después de una fiebre RGB he empezado a ver más las virtudes de RCA clásico, la única excepción N64 que al llevar ya su propio suavizado la nitidez ganada del RGB se agradece.


A mi Nes y Snes en crt se me veían cojonudas por rca, no exageremos con borrones. Curiosamente, eso sí, la nitidez variaba muchísimo de un CRT a otro, sobre todo en Nes. Tengo algún crt que la Nes se ve que parece que tiene Rgb (creo que los más modernos) y otros que las líneas quedan medio torcidas y se ven algunos artefactos. A la salida rca se le ha echado mucha mierda por lo problemática que es con tvs de hoy día. Por mucho escaler que se use y uno se rompa la cabeza, a lo más que llegas es a un nivel aceptable, pero no se logra una imagen buena. Ahora le estoy dando a saco a la Nes con los 2 scaler y.... bueeeeeno, se puede jugar y tal, pero bien bien no se ve. Sin embargo la Snes por RGB se ve espectacular con el scaler. Pero en crt el cable amarillito cumple con creces en ambas. Megadrive excepto juegos concretos Rgb si o si, pero es la única que la diferencia es abismal.


No, no es exageración, una cosa es nitidez y otra que el difuminado se vea "cojonudo".
¿Como que el rca no puede ser nítido?, una cosa es que no separe la información de cada pixel, y otra que difumine de forma incaeptable los gráficos por defecto. Una cosa es emborronar, y otra difuminar.

Compuesto vs S-video vs RGB.



Imagen
Video compuesto no es una señal nítida, no inventemos xD, es una señal emborronada. Todos sabemos que en esa conexión (y más en RF) las señales de video se distorsionan por viajar en el mismo cable.

Hablamos de lo de siempre, en un CRT lo notamos menos que en LCD.
Creo que se me ha muerto la SNES, se enciende, pero se congela a los pocos segundos. Tocará acudir a la emulación? 😅
SuperPadLand escribió:Creo que se me ha muerto la SNES, se enciende, pero se congela a los pocos segundos. Tocará acudir a la emulación? 😅

Abrirla y paciencia. Yo también creía que la mía muriera hace algún tiempo, y era óxido persistente en el zócalo de cartuchos. Tocó meter lija hasta, pero resucitó. (Como digo siempre, el zócalo de las juanchis es una mierda).
Yaripon escribió:
SuperPadLand escribió:Creo que se me ha muerto la SNES, se enciende, pero se congela a los pocos segundos. Tocará acudir a la emulación? 😅

Abrirla y paciencia. Yo también creía que la mía muriera hace algún tiempo, y era óxido persistente en el zócalo de cartuchos. Tocó meter lija hasta, pero resucitó. (Como digo siempre, el zócalo de las juanchis es una mierda).


Pues a ver si es eso nada más, pero bueno si no tiro de Wii y listo.
SuperPadLand escribió:Creo que se me ha muerto la SNES, se enciende, pero se congela a los pocos segundos. Tocará acudir a la emulación? 😅


Si la tienes mucho cariño porque sea la snes de toda vida o algo así siempre puedes dejarla en un Game para reparar a ver si tiene arreglo.
tic escribió:
SuperPadLand escribió:Creo que se me ha muerto la SNES, se enciende, pero se congela a los pocos segundos. Tocará acudir a la emulación? 😅


Si la tienes mucho cariño porque sea la snes de toda vida o algo así siempre puedes dejarla en un Game para reparar a ver si tiene arreglo.


Cariño no le tengo, pero tiene el mod SuperCiC cuando tenga tiempo miro si el zocalo está sucio y pruebo con algún juego original para descartar que sea el flashcard.
2463 respuestas
Responder
1…46, 47, 48, 49, 50
Volver a Consolas clásicas