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...
) que ha estado toda su vida en una cueva, no basta con que alguien le diga que el cielo es azul; lo tendrá que ver, porque del mismo modo que le ha dicho la verdad le puede colar una trola, y decir que el cielo de día es negro, y todo está igual de oscuro que en la cueva, "por las refracciones de la luz y los elementos presentes en la atmósfera y...". Tendrá que asomarse él mismo y verlo por su cuenta.![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
![[tadoramo]](/images/smilies/adora.gif "Adorando")
![[Ooooo]](/images/smilies/nuevos/sorprendido_ani1.gif "Oooooo")
![[sati]](/images/smilies/nuevos2/demonio.gif "demoniaco")
![[amor]](/images/smilies/nuevos/enamorado.gif "enamorado")
![[burla2]](/images/smilies/nuevos/burla_ani1.gif "burla2")
![[beer]](/images/smilies/nuevos2/brindando.gif "brindis")
![[borracho]](/images/smilies/nuevos/borracho_ani1.gif "borracho")
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
![[rtfm]](/images/smilies/rtfm.gif "Lee!")
