› Foros › Retro y descatalogado › Consolas clásicas
O´Neill escribió:Con el fix hirom el juego va como un tiro.
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.
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
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
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.
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.
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
MasterDan escribió:Son cálculos costosos de hacer por software.
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.
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).
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.
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…
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
Diskover escribió:(que no sprites, ojo, pues puede haber sprites sin colisión).
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
😜
Tengo que probar esa fast-rom a ver cómo funciona…
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.
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?.
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
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
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