Bueno, vamos allá, que hay mucho que explicar, y voy pelao de tiempo.
Sexy MotherFucker escribió:@Señor Ventura ¿Qué vicio tenía Capcom en Snes por dejar líneas vacías en la vertical no?
Porque madre mía, luego nos quejamos de los marcadores de Konami y Treasure en Mega Drive:
Creo que habría consenso si se pregunta si capcom hacía esto mas por sistema, que por necesidad, y es que efectivamente ocurría demasiadas veces.
Poner franjas negras hace que la resolución vertical sea menor, y por lo tanto la CPU se ve mas liberada. En mi opinión, capcom recurría a esto cuando sus juegos, una vez programados, iniciaban el proceso de optimización... es como decir: "bueno, y ahora que corra fino"... y entonces llega alguien y dice: "y si bajamos la resolución a 192 pixels verticales y nos vamos al bar a tiempo para el vermut?".
Seguramente te habrás dado cuenta de los problemas que tiene el SFA2 cuando llegas al escenario de charlie, con el avión, y tal. Pues imagina ahora que el juego se ejecuta a 224 pixels reales... ni modo turbo, ni hostias, tu.
Capcom nunca quiso, o nunca le interesó optimizar sus juegos en la snes, y la consecuencia es que nos comemos bandas negras, y encima con problemas de rendimiento aunque sean ocasionales.
Sexy MotherFucker escribió:Se libran los Rockman, Breath of Fire, Goof Troop, Area 88, Chomakaimura, Tenchi wo Kurau, Magical Quest, Circus Mistery, Mickey Mania, Bonkers, Capcom MVP Football, Toy Story, Soccer Shootout y... creo que no me dejo ninguno.
¿Toy story es de capcom?, ¿seguro?.
Es que lo veo radicalmente diferente a lo que solían hacer, creo que es demasiado ambicioso para lo que capcom se hubiese propuesto hacer, viendo los precedentes (con esas animaciones, y tal).
Sexy MotherFucker escribió:No es cierto, muchas veces una cámara on-rails, o una trayectoria guiada, se emplean para disimular las carencias de un engine o de una consola (o de unos malos programadores). Un motor con cámara libre, o uno que te deje total libertad de movimientos con vista trasera, es algo mucho más honrado; ya que te deja comprobar hasta donde llega la solidez del entorno y/o la capacidad del hardware.
Piensa que estamos hablando de escenarios 3D compuestos por cubos, rotarlo no va a descubrir zonas con mil aristas extras... y para todo lo demás está el poping, que no es algo que sucede al libre albedrío de una cpu inteligente, sino que hay un tope para renderizar, y to lo que lo exceda, se queda fuera.
Se lo que quieres decir, y obviamente una cámara libre lleva consigo el riesgo de procesar mas de lo que se puede, decayendo el rendimiento, pero en este caso la complejidad es tan simple que la cámara no es un factor que afecte al mismo.
Un cubo que queda detrás de otro no deja de ser procesado por estar oculto detrás de otro. Y todas las caras son iguales, por lo que rotar la cámara libremente, o no, supone exactamente lo mismo.
Sexy MotherFucker escribió:No me conozco las entrañas del FX tan bien cómo tú, así que no afirmo nada en contra ni a favor, pero lo que expongo arriba es un hecho.
Conozco las cuatro cosas superficiales que conoce la mayoría de la gente. Hasta donde se, no se conoce toda la documentación del chip, tampoco me he preocupado mucho de saber si es así.
Señor Ventura escribió:Zangief vs Zangief (versión sin franjas negras ajustado a monitor 4:3):
Esta es un poco tramposilla xD, porque estás asumiendo que si se rellenase el área visible los programadores también aumentarían el tamaño de los luchadores en consecuencia, y lo mismo no les sale rentable.
Por partes...
A la hora de dibujar sprites hay que tener en cuenta dos consideraciones. El primero es el límite por scanline, y el segundo es el límite total... esto que es de perogrullo, lo explico para que quede constancia de la situación con este juego,.
Los dos zangiefs ocupan 64 sprites en el momento del pantallazo (un derroche innecesario de recursos, pero te lo puedes permitir en este tipo de géneros), y aunque horizontalmente se acercan a los 30 sprites (ya digo, porque les da la gana), verticalmente queda espacio de sobra en la tabla OAM para hacerlos mas altos si se desea.
Bien, no es que asuma que si se rellenase el area ocupada por las franjas negras los programadores harían los personajes mas grandes, es que sucede que a menudo queda en la VRAM entre un 15 y un 20% de memoria libre durante el juego (probablemente menos durante el momento del pantallazo, aunque sea marginal), que hay capacidad de sobra para hacer mas alargados los personajes (no así a lo ancho, aunque ya digo que se puede optimizar), y presumiblemente el DMA puede asumir la transferencia extra de unos pocos sprites mas.
La resolución total es inferior a los 224 pixels, y por lo tanto el escenario aumentaría el número de tiles en memoria para ser conformado, pero también es un contratiempo asumible, ya que, como digo, espacio hay en la VRAM.
Sexy MotherFucker escribió:¡Y la versión CPS-II es más nítida! Y esto lo digo ya porque soy jugador de competición de la saga Zero y he tenido cabinets ARCADE en mi colección además del cartucho de Snes (y bueno, cualquier versión del juego...).
En realidad la falta de nitidez de la foto simulada a 224 pixels verticales es culpa del paint, ya que he alargado la imagen en vertical (en horizontal tiene exactamente el mismo ancho), provocando que el editor interprete inventándose pixels, e interpolándolos.
En una situación como la que describo, la nitidez sería la del zangief en la versión estirada a la resolución de un monitor 4:3, pero con el tamaño del zangief de la resolución simulada de 224 pixels verticales. Es decir, que la diferencia de nitidez no sería tanta como se aprecia en la foto.
Es decir, sería la nitidez de esta foto:
Pero con este tamaño:
¿Por qué?, pues porque la única borrosidad sería la provocada por hacer mas ancho los gráficos, ya que la gananacia de tamaño en vertical es por la adición de mas sprites (no por estirarlos)... y sucede que es mas crítico para nitidez la resolución vertical que la horizontal, y la vertical no se toca.
En todo caso este ejemplo es una opinión, y está basado en una seria de conclusiones, que obviamente podrían no ser todas las que habría que contemplar... pero por poderse...
Sexy MotherFucker escribió:
Esta imagen sin embargo si que establece premisas que no son correctas.
Los zangiefs del SFA2 de cps2 y snes aparecen en frames en los que su tamaño varía muy oportunamente. La posición del zangief de cps2 está en una postura que aumenta bastante el tamaño que suele tener en el resto de movimientos.
Y el tamaño del ryu de snes no es lo mas grande que ha habido en juegos de lucha, sino mas bien de lo mas normalito.
Sexy MotherFucker escribió:Muchos juegos de lucha en Mega Drive tienen personajes más grandes que los del SFZ 2 de Snes, y a 320x224.
Si, ya digo que por características de hardware, y por requerimientos en cuánto a demanda de recursos de un 1 vs 1 como programa, las 16 bits de snes y sega podría poner personajes tan grandes como la pantalla entera.
La parte en la que realmente toma ventaja megadrive es en el número de frames por segundo que puede proveer en la animación de los personajes, pero no en el tamaño. Ahí andan sobradas las dos.
¿Sería posible un street fighter alpha 2 en megadrive?. Pues así a ojo, diría que la máxima pega radica en el uso de la memoria de trabajo... snes tiene el doble que megadrive, y me da que por ahí vienen los tiros.
Se podría simplificar el programa (que influiría en el comportamiento de los enemigos, entre otras cuestiones), limitar el número de colores, y simplificar el número de planos de scroll en alguna fase.
Se vería mas alejado del arcade que snes, pero sin duda permitiría añadir mas frames de animación, y un margen extra de velocidad de acción.
Sexy MotherFucker escribió:Los disparos suenan mejor que en Snes, pero la música se oye cómo el puto culo sí; a baja frecuencia, con degradación de ruido, y aprovechando 0 al Yamaha YM2612. Es hasta la fecha el FM más cutre que he escuchado en el sistema.
Aunque evidentemente eso no es culpa del sistema, ya que así suena DOOM cuando se emplea bien el circuito de sonido de una Mega Drive:
Tampoco se puede decir que en snes sea el máximo exponente en cuánto a calidad sonora.
Sobre el juego, la versión snes no solo tiene mas fases, sino que el mapeado de cada una de ellas fué porteado directamente desde el original de pc, en lugar de las versiones recortadas y limitadas de la versión 32X.
Sinceramente, me hubiese encantado ver un doom con el SVP en megadrive, me hubiese parecido muchísimo mas meritorio, y me invitaría mucho mas a jugarlo que su versión 32X.
P.D: Los programadores dijeron que el doom de snes apenas pudo empezar su etapa de optimizaciónm, y que esperaban haber conseguido una mejora del 25% solo reescribiendo algunas partes del código de C, a ASM.
Con esas declaraciones, da a pensar cosas muy buenas sobre las posibilidades de ese motor. Un doom en snes a 15fps hubiera sido mas que suficiente...