naxeras escribió:Claro que no puede, ya te lo ha dicho el programador, esta muy limitada para animar un gran numero de enemigos
naxeras escribió:y por eso aunque toque animación ese frame lo que hace es saltarla para cuando haya posibilidad de atualizar. ¿Tu crees que si hace lo mismo que en todos los juegos comerciales de cualquier consola lo comentaria en un twitt? no has entendido lo que pasa.
naxeras escribió:Es una optimización que tambien ha tenido que hacer mucho menos bestia mauro en Final Fight MD, al principio actualizaba los marcadores a 60fps que son sprites (una locura) y tuvo que reducirlo a mitad porque no le daba y eso que es una consola mucho mejor capacitada para ello.
naxeras escribió:Totalmente que no use cinemascope a este nivel de acción es una maravilla y como dice el autor en movimiento y que es un juego con mucha acción ni te enteras.
naxeras escribió:Yo creo que este juego ya demuestra bastante lo que SNES puede hacer en buenas manos, aunque claro hay margen de maniobra para más.
naxeras escribió:El tema de SNES es lo que digo siempre, en vez de haberse programado por compañias mediocres, SNES fue programado por las compañias más top con el mejor presupuesto, roms grandes etc ya que fue la niña bonita de su generación como PSX en la suya, por lo tanto tampoco creo que veamos cosas tan alucinantes que no se creyeran posibles como si hemos podido ver en otros sistemas.
Señor Ventura escribió:Dependerá de cuanta cpu use, y por lo tanto de cuanto tiempo de dma le quede
Señor Ventura escribió:No hay diferencia en terminos de "potencia" entre esperar 4 frames para animar a 4 enemigos al mismo tiempo, que hacerlo secuencialmente frame a frame, por turnos.
Señor Ventura escribió:No es el hilo. Puedes explicar para que en otro que corresponda mas, y debatirlo ahí.
Señor Ventura escribió:Este es el problema, se ha repetido durante tantos años que estáis convencidos que 4 objetos es el nivel de una snes, pero que da igual cuanta cpu le dediques, serán solo 4, y punto.
Señor Ventura escribió:¿En términos de acción y enemigos en pantalla?. Absolutamente no.
Señor Ventura escribió:Es lo que siempre dices, a pesar de habérse demostrado que estás equivocado. ¿Como es posible afirmar que se programaba con los mejores presupuestos, cuando mas de la mitad del catálogo era lanzada con slow roms por motivos de presupuesto?.
naxeras escribió:Las otras consolas las programaban muchas veces empresas de segunda o tercera división con roms raquiticas y presupuestos y tiempos mas limitados que en SNES.
Vamos no se porque no reconoces la realidad, pasó con NES, pasó con PSX, paso con PS2... la niña bonita de la generación es la que mejores estudios, presupuestos y las que mas se aprovecha el hardware, es una obviedad vamos parece que lo sabe todo el mundo menos tú.
Señor Ventura escribió:Es mucho trabajo para una sola persona como para considerar que ese es el nivel de una snes, porque además lo está haciendo de una forma bastante poco ortodoxa, según explica el mismo.
aranya escribió:Cuanta razón tienes y muy bien explicado. En un foro como este creo que algo tan obvio no debería ni siquiera ni decirse.
Por supuesto no es un ataque a ninguna consola ni compañía.
naxeras escribió:Pues usa la justa y necesaria, no la esta desaprovechando vamos, lo que dices es una obviedad. Solo hay que jugar a su catalogo para ver en este tipo de juegos la tralla o no tralla que mete.
naxeras escribió:Hombre claro que la hay, necesitas mas VRAM y a la vez necesitas mas ancho de banda para reemplazar los tiles del cartucho a la VRAM, dicho de forma simplificada y sin marear.
Si es uno a uno solo necesitas cargar los tiles que actualizan ese enemigo.
naxeras escribió:No debato digo lo que ha comentado el programador punto, no hay debate que valga ni nada que se pueda añadir.
naxeras escribió:No se ha repetido durante años, es que se ha visto en el catalogo y se ve en los nuevos desarrollos homebrew que si usas la CPU en modo "normal" es el margen que tienes, claro si los enemigos estan y no hacen nada, no tienen ia ni colisiones ni nada pues puedes meter mas pero entonces eso no es un juego es una demo técnica.
naxeras escribió:Pues parece que todo el rato estas negando la mayor, menos mal que vas sentando la cabeza y te repliegas a la realidad que ven tus ojos.
naxeras escribió:No, al contrario se ha demostrado y te han dicho otros usuarios que lo que dices no tiene sentido, ya te he explicado que si nos ponemos asi ningun desarrollo tiene alto presupusto por no usar procesadores especiales ¿no? de hecho que existan esos cartuchos con procesadores carisimos para una consola famelica en determinados apartados de hardware demuestra que en cuanto a costes en SNES no se reparaba en gastos comparandolo como no con el resto de sistemas contemporaneos.
Vamos es pura logica, NES fue un éxito de monopolio practicamente y eso hizo que carrileara a SNES siendo la niña bonita de la generación. Que existan las slowrom solo es tacañeria de Nintendo.
El unico que piensa que en SNES programaban aficionados con menos presupuesto que en el resto de consolas eres tú, que es distinto a que tuvieran presupuesto infinito claro. Con presupuesto infinito pues si le metes 7 chips con la potencia del 386 todo fastroms de 64Mb o más y a correr (es una exageración), pero no, hay que comparar gastos en SNES con el gasto en sus contemporaneas donde te daras cuenta que es mucho mayor en SNES, con los mejores equipos de programadores de la epoca, de las compañias mas prestigiosas y exitosas de la época, con las roms mas grandes (mira la media anda) llegando incluso a meter chips especiales y usar las FastRom en muchos casos que Nintendo cobraba a precio de oro.
Las otras consolas las programaban muchas veces empresas de segunda o tercera división con roms raquiticas y presupuestos y tiempos mas limitados que en SNES.
Vamos no se porque no reconoces la realidad, pasó con NES, pasó con PSX, paso con PS2... la niña bonita de la generación es la que mejores estudios, presupuestos y las que mas se aprovecha el hardware, es una obviedad vamos parece que lo sabe todo el mundo menos tú.
Un Saludo.
Señor Ventura escribió:Las cosas no quedan demostradas solo porque sean tu opinión, porque claro, uno no puede estar equivocado, o no puede no tener toda la razón solo porque le secunden 50 personas.
Señor Ventura escribió:No es cierto que no escatimaran en recursos haciendo juegos para super nintendo. Con mas del 50% de juegos usando roms que underclockeaban la snes, no se puede decir que jugase con ventaja.
Una cosa es que tengáis argumentos, y otra que no reconozcáis ninguno.
Señor Ventura escribió:No, no hay diferencia en términos de recursos entre acumular y usar al vuelo, no voy a discutir sobre esto.
Señor Ventura escribió:Tu frase tenía dos sentencias. Dije precisamente que 4 enemigos en pantalla a ese nivel de acción no demuestra que eso es todo lo que puede hacer snes.
Señor Ventura escribió:Las cosas no quedan demostradas solo porque sean tu opinión, porque claro, uno no puede estar equivocado, o no puede no tener toda la razón solo porque le secunden 50 personas.
Señor Ventura escribió:Lo que he dicho se limita a lo que he dicho. El esfuerzo casi siempre tuvo que ser máximo, pero los recursos no, es de perogrullo. Hay factos que demuestran que los juegos no solían salir usando todo su potencial, y es algo que tampoco se puede ignorar, digo yo.
Existieron quejas sobre un mal uso de esa cpu, existió una oleada de juegos que demuestran que se underclockeaba el hardware, existió un tendencia muy considerable a recibir ports que no se optimizaban para snes (se limitaban a añadir un un plano mas, pero no obtenías algo nativo, y no era poco común que se quitaran niveles, y contenido de todo tipo), y existen los suficientes casos de juegos de los que se ha demostrado que salían demasiado prematuros.
Con todo esto en la mano, no se puede afirmar que lo que recibía la snes estaba al 100% de su potencial. ¿Tanto cuesta decir que programar para snes era la preferencia, pero que también pagaba el pato de ports directos e infrautilización del hardware?.
cirote3 escribió:Señor Ventura escribió:Las cosas no quedan demostradas solo porque sean tu opinión, porque claro, uno no puede estar equivocado, o no puede no tener toda la razón solo porque le secunden 50 personas.
Señor Ventura escribió:La clave es el fondo estático.
Señor Ventura escribió:Es lo que decía hace tiempo sobre la serpiente del xeno crisis. Dibujando las secciones también en un plano, puedes intercalar secciones con sprites + enmascaramiento para doblar la longitud del enemigo sin causar parpadeos. Los sprites sirven para que al ppu1 le de tiempo a "preparar" la siguiente sección sin "beam glitches".
Señor Ventura escribió:Señor Ventura escribió:La clave es el fondo estático.
Era evidente. Puede hacerse de dos modos, mediante un plano con patrones o colores que dibujar usando una ventana mediante hdma, o mediante la alteración de un color, ambas mediante los registros $2123 a $2129 para posición, seleccion, y activacion, y los registros $212A/$212B para mezclar dos ventanas mediante lógica combinatoria (or, and, xor, xnor), y $212E/$212F como un interruptor para encender y apagar el enmascaramiento.
Las ventanas no se desplazan, no hacen scroll, aunque siempre puedes alterar el propio dibujo frame a frame para simularlo, de la misma forma que la nes simulaba dos planos: cambiando el dibujo del único plano que tiene.
La ventaja es que no dependes de ningun ancho de banda relevante, ni prácticamente de la cpu. Es automático. Puedes servirte de una base de datos para hacerlo "proceduralmente" para simular scroll multidireccional de "uno" o "varios planos", o mediante simple flujo de datos lineal mediante $2126 y hacer un scroll simple.
El reto es calcular el lag entre cadainterrupciontransferencia hdma para que los ciclos que tarda en estar operativo no cause que el haz de electrones del crt dibuje glitches, de ahí que las estrellas no puedan estar demasiado juntas. Para las montañas no hay problema, solo retrasas lasinterrupcionestransferencias hdma para convertir los puntos en líneas.
Al final de cada scanline defines un color para toda la linea horizontal, y todo lo demás se dibuja medianteinterrupciones¡agh!. Es un enmascaramiento.
Es lo que decía hace tiempo sobre la serpiente del xeno crisis. Dibujando las secciones también en un plano, puedes intercalar secciones con sprites + enmascaramiento para doblar la longitud del enemigo sin causar parpadeos. Los sprites sirven para que al ppu1 le de tiempo a "preparar" la siguiente sección sin "beam glitches".