gynion escribió:Bueno, voy a rebajar el tono yo, y a hablar con calma, porque lo que importan son los datos; por tanto, que hablen los datos y las opiniones que cada uno haya dado. No voy a utilizar adjetivos contra nadie, ya que eso aburre y no sirve de nada; sólo voy a utilizar un espejo, para reflejar de esas ocurrencias que dije antes.
Opinaré lo justito y sin descalificativos, para que esos comentarios reflejados hablen por si solos:
Una vez dije (y me mantengo) que
no creía que SNES pudiera con 10 personajes enormes en un Beat'em up... bien, sale el
@Señor Ventura, y... ¿qué ejemplo recibo de él que demuestra que estoy equivocado? este:
NBA Give 'n' Go.png)
Sin comentarios.
No estás rebajando nada, sigues en tu plan de querer echar mierda.
Si quieres demostrar que yo haya dicho alguna vez que la snes puede con un 10 enemigos enormes en un beat em up, lo que tienes que hacer es demostrarlo exponiendo mis propias palabras, no con una foto que dudo horrores que haya podido poner yo, porque hay otras mejores que demuestran mi postura.
De hecho fué esta otra la que usé, porque de hecho la saqué yo mismo del emulador, así que se de sobra de que foto hablo... pero mejor manipular para seguir echando mierda los demás, ¿verdad, gynion?:
Ocho objetos:
Toma, que sean diez (no todos a tamaño grande, con ocho ya casi saturas el pixel fill rate por scanline):
En mi pueblo, cuando te demuestran que has mentido para echar mierda, lo mínimo es pedir perdón, pero sobre todo dejando de insistir en contar mentiras, porque no es la primera vez que te contesto a esto.
gynion escribió:Otra vez, opiné (y me mantengo) que para mí SNES no podría con Thunder Force IV, basándome en que no he visto ninguno igual; ¿el ejemplo que puso el mismo compi? este:
Rendering Ranger
Controla con lo de "compi", que ya bastantes licencias te has permitido por hoy.
Ese gif saltó a la palestra una vez que afirmaste que la snes no podía mover planos de scroll como los del TFIV de megadrive. Esa era la discusión en el momento del gif, y no otra, así que vas a tener que demostrar lo que dices, no basta con poner una imagen, y decir que lo puse como afirmación de lo que te apetezca añadir sobre el tema.
Es que se cual es mi opinión al respecto, y el tema es demaisado complejo como para afirmar que por un puñado de planos de scroll ya se puede transladar el TFIV tal cual es en megadrive. Eso no lo sabe nadie.
gynion escribió:Puntualización:
Es una falacia de libro usar el "como se equivoca en una cosa, entonces se equivoca en todo", pero además literal, que es lo que estás haciendo tu.
Si, sabía que me aventuraba, y sigo acordándome de por qué dije lo que dije.
Cuando divides un plano en varios fragmentos que se desplazan a distinta velocidad, todos y cada uno de ellos tienen la característica de que ninguno de sus tiles se superpone al de otro fragmento. Sin embargo eso sucede, no en el gif que pones tu, sino en este otro:
Y se me ocurrió decir que eran 7 capas. Pero no solo eso, también dije que de ser así, 3 de ellos no podían ser planos, sino tiles dibujadas a base de cpu. Eran mis palabras y me las como con patatas, ¿y que?. Lo que tu creas que demuestras con eso es muy, muy pobre.
Diría que cada fragmento dividido de los planos "afectados", deben cambiar su prioridad parcialmente (cada cacho de cada BG, a una altura diferente). Y si me equivoco, pues me vuelvo a equivocar, no se que problema tienes tu con eso, ni que crees que demuestras sobre lo que se, o puedo llegar a saber.
gynion escribió:Luego está lo que ha pasado en este hilo estos días, que viene a ser una extensión de lo mismo, con ejemplos de la misma índole, sólo que con otros juegos como protagonistas, por tanto mi postura es la misma, la legítima y razonada no aceptación, que tanto le molesta.
Legítimo es siempre, aunque sea absurdo. Otra cosa es lo de que hayas razonado tu postura, porque eso si que no lo hemos visto nadie.
Razonar un argumento es explicar como funciona la fase del jim power con el tema de las monedas, cosa que hice resumidamente para que lo comprendieras... pero ni con esas.
El ejemplo del super mario world con las monedas, con respecto al jim power en la misma fase de las monedas (evitaré decir análoga, no vaya a ser que me recuerdes que son dos juegos diferentes), el funcionamiento viene a ser el mismo porque internamente se procesan a groso modo el mismo tipo de cosas.
En snes tienes dos planos de scroll, uno de ellos es el suelo, y el otro el fondo.
En el jim power tienes dos planos de scroll, y al fondo del todo salen algunas columnas compuesta por sprites, como si fueran un tercer plano (pero que no lo son, porque la megadrive solo puede mostrar dos).
La forma en que son compuestos los planos se sucede cogiendo varios tiles, y uniéndolos correlativamente formando un dibujo que se sucede contínuamente en un bucle "infinito".
La memoria que consume esto en la VRAM, es tan solo la que ocupan los tiles originales, y no todo el tileset surgido a base de "copiar y pegar".
En conclusión, en ambos juegos (super mario world y jim power), están trabajando los planos de la misma manera a la hora de formarlos, y ocupando recursos que de ningún modo rebasan los límites de sus respectivas máquinas.
¿Y que sucede para moverlos deprisa?, pues que el sistema de vídeo se encarga de realizar la tarea de forma autónoma sin que la cpu tenga que hacer nada. Esto implica que si el ancho de banda lo permite (cosa que sucede tanto en el caso del super mario world, como en el caso del jim power), la velocidad a la que puedas mover los tiles de los planos será tan rápida como lo pueda ser el frame buffer de las consolas (y no la cpu... espera, repito, NO LA CPU). Y si, son muy, muy rápidas. AMBAS.
Luego está el tema de las colisiones con las monedas, que no es una tarea para la que tengas que escribir 500 líneas de código precisamente. En ambas funciona exactamente igual, y en ambas se detectan las colisiones de montones de monedas, PORQUE ES UNA CHORRADA QUE NO REQUIERE POTENCIA DE PROCESO NI EN LAS 8 BITS. Por lo tanto, lo que tu crees que debe ser costoso de procesar, en realidad no lo es... ni el tema de las monedas y sus colisiones, ni el tema del scroll.
gynion escribió:Pero lo mejor de todo, y lo que origina que dude de todo lo que afirma este compañero, vino cuando yo opiné que la SNES tenía un procesador lento, después de haberlo aprendido de él (Señor Ventura), y es aquí cuando podemos comprobar que este señor, si le apetece, no está de acuerdo ni consigo mismo.
De acuerdo. Le diremos a magno que se equivoca, de tu parte xD
Lo que te he dicho siempre es que la lentitud es relativa. En algunas cuestiones tienen un rendimiento equivalente, y en otras no... y luego además está la habilidad para programar, y la habilidad para implementar un código que funcione con un resultado similar, pero de una forma diferente.
El 65c816 es mas lento que el motorola de megadrive, pero no por eso tiene que ser una cpu necesariamente lenta. Ejemplos hay a paladas.
gynion escribió:Como se puede ver, insistí con moderación en ese punto, porque estaba flipando, he incluso le hice un copypaste parcial de lo que él había dicho (sin decirle que eran afirmaciones suyas), pero seguía igual; incluso dijo "afirmáis cosas sin saber".
Tiempo después, ya en este mismo hilo, me aseguré que su actitud era esa, discutirme todo lo que yo diga, aunque lo hubiera dicho él mismo, y el resultado fue el mismo:
Estás mezclando cosas, y no sabes ni de donde vienen las campanas.
Cuando yo escribo una cosa en base a un contexto, si tu usas mis mismas palabras en un debate con un contexto diferente, puede ocurrir que no esté de acuerdo con eso, y eso que son mis propias palabras.
Afirmar que la cpu de la snes solo sirve para manejar "las tablas OAM, las I/O's, y poco mas", no es cierto de base.
Cuando dije eso, no fué como afirmación de que el 65c816 sea inoperante para todo lo que pase de las tablas de sprites, e I/O's,
sino como consecuencia de lo que hubiera podido suponer incluir el SFX dentro de la consola.¿Te das cuenta de hasta que punto metes la pata?.
Ahora añado. Es una equivocación de concepto y tengo que retractarme, porque un SFX como PPU3, por muy programable que sea no puede ser empleado para resultados lógicos, y por lo tanto, en dicho supuesto caso de un SFX dentro de la consola, no le hubiese librado a la cpu de limitarse a las tareas ya mencionadas. y no hay nada mas que añadir, ni es importante siquiera.
gynion escribió:En esa ocasión se lo podría haber dicho, pero ahí queda clara mi actitud conciliadora, ofreciéndole dejar las tiranteces y simplemente tratar de no hacerle mucho caso a todo lo que me dijera después, pero ya se ve que basta con que no aceptes lo que dice para que te arme el pollo.
La sensación es de bastante impotencia, la verdad, cuando te citan y te meten en estas discusiones sin sentido, pero a partir de ahora prefiero no responderle; que se quede siempre con su verdad por delante, y a seguir con mis cosas.
¿A ti te parece que tienes una actitud conciliadora?, ¿con mensajes intentando dejar en evidencia cada vez que puedes?.
Venga.
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
). 
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
![[ginyo]](/images/smilies/nuevos/guinyo_ani1.gif "guiñando")
![[beer]](/images/smilies/nuevos2/brindando.gif "brindis")
![[360º]](/images/smilies/nuevos/vueltas.gif "como la niña del exorcista")
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
![[facepalm]](/images/smilies/facepalm.gif "facepalm")
/Update%2064/41-image048.gif)
