[SUPER NINTENDO] Hilo oficial.

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.
2421 respuestas
145, 46, 47, 48, 49