¿Paprium en Snes?

Archivado
1, 2, 3, 4
El mejor port, el que disfrutaríamos de verdad sería en Neo Geo.

La máquina perfecta para que este juego muestre su potencial.
@neofonta
En eso estoy totalmente de acuerdo sin ningún tipo de duda . De hecho para mi ese sistema ha sido súper desaprovechado para este tipo de juegos pudiendo haber creado auténticas maravillas .
@robotnik16 La gente no termina de atar cabos,toda recreativa llevo un M68000,todo sistema domestico de alto level llevo un M68000.

pero llega Super Famicom y no...un Ricoh super veloz,y sale bien baratita...

la publicidad ya ves cual fue y a que componente la dirigian...,el caBolo de la bestia,si es que esta claro,si ya sabian ellos lo que hacian.

una Consola mas barata,muy bien pensada y con lo mas importante que son los juegos,con la de empresas que tenian de su lado todo lo tenian ganado.

lo importante en una Consola son los juegos,y vaya si los tenian,y supieron trabajar bien para la maquina,juego como Area88 o Valken son una maravilla,a mi el Axelay me gusta tanto que ya quisiera verlo en toda Consola.

para mi no esta reñido que un sistema te guste y ver la realidad,esa consola con una CPU mas poderosa habria sido mejor,y mas cara,como Game Boy con Retroiluminacion habria sido mejor,y mas cara.

@neofonta Si Paprium de MD tardo en finalizarse 700 años y ahora cuesta 150$,imagino que en NeoGeo cuando lo terminaran todo tendriamos Motos como la de Kaneda y costaria como 10000$.

pero si...yo quisiera que eso se hiciera realidad.
robotnik16 escribió:Acabo de terminar mi periplo de beat's para Snes, me apetecía y también para contestarte Ventura aquí en el hilo, con sensaciones en caliente.

He jugado una pequeña muestra, han sido Captain Commando, Combat Tribes, FF3 y Undercover Corps (he dejado aparte los que simepre he considerado los mejores en Snes). CC no lo ha podido definir mejor @emerald golvellius , ha elegido el adjetivo exacto, es soso. Tiene encanto, se ve bien, se deja jugar pero le falta gracia; el CT es muy simpático y original, súper simple pero funciona, no es top pero me vale sólo por ser padre del Wresltlefest (o hijo, o hermano, no lo sé bien); FF3 posiblemente el mejor de los 3, ágil, sólido en gráficos y buenas piezas musicales, aunque no he llegado a coincidir con más de 3 enemigos en "expert"; y el Undercover es rarete pero eso le da su punto, es jodido a pesar de que no hay muchos enemigos tampoco, entre 2 y 3 hasta donde he llegado. No controlo sus homónimso en recreativa así que me ahorro comparaciones, serán mejor claro, pero en general, los juegos me han gustado poniéndome con ojos de la época y siendo conscientes de dónde corren.


De los tres, el mejor transladado es el combat tribes. El final fight 3 es potente, pero tiene altibajos muy pronunciados (personajes grandes, pero pobremente animados... puedes elegir camino, pero el dibujo de los fondos es pobre... hasta 5 personajes en pantalla, pero el dibujado de sprites por scanline no está para nada optimizado), y esto sin mencionar la música, que es horrorosa, y unos efectos de sonido para las voces excesivamente comprimidas.

Luego están el captain commando, que ni siquiera acierta con las paletas de color, y el undercover cops, que con 16 megas el contenido gráfico del arcade queda muy disperso en el cartucho de snes.

Los dos primeros pasan el corte, pero los otros dos me frustran, sobre todo por su baja calidad gráfica.

robotnik16 escribió:Todo este párrafo Ventura para resumirte que pienso que este género no es el fuerte de la consola. Como te han dicho antes, para mí el problema es que la máquina se ahoga a poco que algo se revolucione, no sé qué pasa que siempre que hay elementos rompibles en escenarios u objetos a usar y tal, muchas veces rasca (he jugado todo en NTSC) y ralentización al canto, y no necesariamente en momentos de mucha acción (casualidad o no, sobre todo en los juegos con sprites grandes). Lo mejor que tienen es que como siempre, los gráficos son llamativos, con buenos degradados, sin excesivo dithering, colores sin contrastes altos, etc... La puesta en escena siempre cumple en Snes.


Todos sabemos que snes usa una cpu de menor potencia de proceso que la megadrive, pero no creo que sea una buena cpu para este género porque ejemplos hay que demuestran que puede aguantar el tipo de la acción perfectamente.

No es la mejor cpu, si, pero no es una cpu insuficiente, también. Ni tanto, ni tan calvo.

robotnik16 escribió:Sobre una hipotética versión de Paprium, sí, se vería muy bien (con su handicap de resolución, que es importante para este género aunque una suerte también para la consola en el fondo), seguro podría aportar algunos efectos "made in snes" con sus transparencias y tal, pero in game, me cuesta seriamente creer que estuviera cómoda en ningún momento, creo que sería un festival slowdowns y no sé si parpadeos. Del sonido olvidate, a años luz del Datenmeinster, ahí o metes MSU1 o no hay nada que hacer.


Si se trata de cuidar una versión snes tanto como lo ha sido en megadrive, lo asumible es que se cuiden de optimizarlo bien para su cpu... y no es tan potente, pero capaz es.

Y además pùedes ser mas versatil con las opciones gráficas... puedes elegir resoluciones entre 256x224 y 512x224 para los planos, puedes elegir entre 2 y 4 planos de scroll, con 256 colores, o incluso un solo plano a 4096 colores usando la matemática de color y con scroll parallax para compensar su simpleza. Cada fase puede ofrecer algo diferente.

En snes habría variedad, con un resultado gráfico siempre diferente, y casi siempre mejor. Algo mas propensa al flickering, y con menos distancia de visión, pero con un rendimiento igual o muy parecido, nada como para echarse las manos a la cabeza, ¿por qué?, pues porque hay ejemplos que demuestran que es posible si se cuida el detalle del rendimiento.

robotnik16 escribió:Si Paprium está hecho en medida de MD, como parece ser, yo creo que imposible un port cercano en lo referido a la jugabilidad. Algo parecido a lo que pasa con los shooters y run' guns. Tampoco digo que no se pudiera hacer algo con tiempo que superase todo lo visto en la consola, pero creo que su problema de caña en pantalla es crónico.


La cpu de la snes es entre un 20 y un 30% mas lenta que la cpu de la megadrive, todo lo que exceda de esa brecha cuando en megadrive el programa esté totalmente optimizado, incurrirá en ese problema de caña crónico, como dices tu.

En ese caso, tocaría adaptar, recortar, o tirar de chip de apoyo, dependiendo del caso.

robotnik16 escribió:Para no dejar un mal sabor de boca, para mí los mejores beat em ups en Super, muy dignos y que saben adaptarse al sistema serían: Turtles in Time, Batman Returns y King of Dragons, redondos los 3. Tampoco conozco tanto la parte japonesa, sé que el Kunio tiene buena fama pero no le tengo controlado.


No te dejes el ninja warriors again, que es para mi el beat em up mas sólido del sistema.

El turtles in time es una joyita, lo tiene todo, excepto quizás que haya mas acción en pantalla de forma mas recurrente, porque está claro que poder, podía (llega a meter hasta 9 enemigos en pantalla y a 2 jugadores, pero solo lo hace una vez en todo el juego).

El batman returns es pura contundencia, pero solo es para un jugador, y el apartado sonoro me llega incluso a desagradar... efectos especiales, música...

No puede uno olvidarse del super double dragon. Va a 30fps, con personajes enanos, y parece que está sin terminar porque... está sin terminar [+risas]... pero jugablemente es de las experiencias mas completas que puedes encontrar en toda su generación con permiso de,,,+

Los dos juegos de kunio... solo se les puede achacar que son un poco pesados con el texto, pero cuando llega la hora de las tortas cada combate ofrece unas posibilidades inmensas.
A mi partiendo que street of rage 2 me parece superior al paprium, sobre todo en animaciones, físicas y demás.
Comentar que no todos los brawlers de megadrive son Street of rage.
Los hay tanto o más cutres que los cutres de snes.
En snes los hay muy conseguidos, como todo.
Y los que hay chulos rayan a un buen nivel teniendo en cuenta que son consolas de 16 bits con sus limitaciones.
Sin ir más lejos hay adaptaciones que me gustan más que el arcade, jugablente y en contenido como las tortugas.
Y el ninja warrior es una maravilla también.
Batman o the king of dragon también me gustan.
Paprium en snes adaptadolo a las virtudes de snes pues perfectamente posible.
Pero no solo en snes, cualquier consola tendría su versión, como siempre ha sido.
Punisher mismamente, yo creo que habria salido mejor en snes. O ya para bordarlo, en Mega CD.

Sigue siendo un juego divertido y es loable que no perdiera nada de material con la conversion pero el apartado grafico lo desluce mucho. Mega (o al menos la mega de entonces) ya no daba para aquello.

Tambien pienso que con Paprium, la gente esta sufriendo el sindrome de ``juego nuevo desprecintado´´ a la hora de valorarlo en global lo cual es maravilloso, pero hay que esperar un poco mas en tiempo (y horas de juego) antes de poder hacer un analisis (minimamente) objetivo y frente a los otros beat em up del sistema.
Antes de pensar sacar una conversión a SNES lo lógico sería probar si Paprium corre en SNES a través del RetroGEN Adaptor.
@titorino

A mí de SNES, me encantaba de pequeño el Rival Turf. Creo que lo alquilé un par de veces, y me habría encantado tenerlo. Claro, no es lo que propone Paprium, despuntando por el tema técnico y eso, pero un juego podía ser muy divertido o más sin despuntar en lo estético.

También estoy de acuerdo contigo en que las animaciones no las veo al nivel de perfección del SoR2, de todas formas. En Paprium las noto muy irregulares, con algunas buenas y otras bastante meh.
@robotnik16 Se me olvidó mencionar, que hay efectivamente una brecha de rendimiento entre las cpu's de snes y megadrive, y que la de esta última tiene entre un 20 y un 30% mas de rendimiento, PERO, siempre que la snes no se encuentre bajo el modo gráfico 7, siempre tendrá multiplicaciones *casi* gratis, y eso le da un empuje a la potencia de proceso muy notable.

Apoyada en el PPU1, no diría que la cpu de la snes sea precisamente menos potente que la cpu de la megadrive. Me encantaría saber donde se encontraría cada máquina comparando la POTENCIA GLOBAL, y no solo la POTENCIA DE SUS CPU`s, pero siendo la cosa que hay quien estima que puede usarse el ppu1 incluso como coprocesador matemático para operaciones de coma flotante, no me atrevería mucho a afirmar que no se invierten las tornas en esto de la potencia.


edit: De hecho, muchos de los juegos que sufren ralentizaciones, lo hacen por culpa de bugs, y no por falta de potencia, como se ha estado creyendo.

Un ejemplo de esto es el super ghouls'n ghosts:
https://youtu.be/SFN972KabBQ?t=1882

Pero hay muchos mas títulos que han arreglado sus problemas a base de corregir bugs, y no solo mediante el parcheo para añadir potencia bruta con el SA-1.


@Sexy MotherFucker Ya sabemos como ha solucionado el super ghouls'n ghosts las ralentizaciones sin parcheos de SA-1 o fast-rom: era un bug.
@Señor Ventura cosas que no me cuadran, ya sé que cada procesador tiene su arquitectura y bla bla bla, pero el 68000 sobre el papel tiene una superioridad de más del 100% en operaciones, o sea, más del doble, ¿cómo narices esa ventaja disminuye al final a sólo un 20%? (3.5 vs 7,7). Sin acritud, los cálculos me la traen al pairo, no por nada, obviamente lo primero es conocer el hardware donde quieres hacerlo correr, pero no empecemos con las ventajas sobre el papel, cuando esas ventajas nunca se han hecho notar en 9 años de vida comercial ni ahora, al contrario. Hemos comprobado ya sobradamente a base de juegos y demos los pros y contras de ambas, y tus cálculos no siempre son fiables, y perdón pero es así. Tampoco contemplas otras cosas, como la dificultad de programación de la máquina, su escasa documentación, cuellso de botella y el poco desarrollo en juegos homebrew.

Yo me retiro de una conversación sobre datos hipotéticos, porque no puedo seguirla, y porque creo que carecen de sentido y no son fiables AQUÍ. Vamos a entrar en un bucle de suposiciones imaginarias que lo único que van a conseguir es dar "falsos" argumentos y esperanzas al sector Nintendo. Sé perfectamente que en el MD vs SNES Parium ha hecho daño, y no voy a entrar en un juego de "apoyemos a la Súper en estos momentos difíciles". Veo bien el hilo para hablar distendidamente del asunto, pero poco más.

Mi resumen como simple jugador en tres preguntas: ¿Se podría hacer algo espectacular también con otras cosas aportadas por la SNES? Seguro que sí. ¿Se podría hacer igualmente un buen beat'm up de estilo similar? Seguro que sí. ¿Funcionaría igual que en MD y bajo las mismas condiciones que lo presenta la MD? (que es la gracia del asunto). No lo creo, y en el punto en que estamos, estaría listo para 2040.
robotnik16 escribió:@Señor Ventura cosas que no me cuadran, ya sé que cada procesador tiene su arquitectura y bla bla bla, pero el 68000 sobre el papel tiene una superioridad de más del 100% en operaciones, o sea, más del doble, ¿cómo narices esa ventaja disminuye al final a sólo un 20%? (3.5 vs 7,7). Sin acritud, los cálculos me la traen al pairo, no por nada, obviamente lo primero es conocer el hardware donde quieres hacerlo correr, pero no empecemos con las ventajas sobre el papel, cuando esas ventajas nunca se han hecho notar en 9 años de vida comercial ni ahora, al contrario. Hemos comprobado ya sobradamente a base de juegos y demos los pros y contras de ambas, y tus cálculos no siempre son fiables, y perdón pero es así. Tampoco contemplas otras cosas, como la dificultad de programación de la máquina, su escasa documentación, cuellso de botella y el poco desarrollo en juegos homebrew.


Esos porcentajes aparecen por el tema de los ciclos necesarios para las operaciones, por ejemplo: tenemos un procesador A que va a 10Mhz y otro B que va a 5Mhz. A primera vista parece que el primero va a ser mejor que el segundo, pero resulta que el procesador A para hacer una suma gasta 2 ciclos de reloj, mientras que el B para hacer la misma operación gasta sólo 1 ciclo. Esto provoca que los dos procesadores tarden lo mismo en realizar la misma operación, por mucho que el primero tenga una velocidad superior que el segundo.

Hay operaciones del procesador de SNES que son más eficientes que las mismas en el procesador de Megadrive (y al revés). Eso hace que la superioridad de el de Megadrive no sea más del doble que la de SNES.

Luego están todos los temas de efectos por hardware de SNES, que le quitan trabajo al procesador mientras que en Megadrive si se quieren los mismos se han de programar a mano con el gasto de recursos que ello conlleva.
robotnik16 escribió:@Señor Ventura cosas que no me cuadran, ya sé que cada procesador tiene su arquitectura y bla bla bla, pero el 68000 sobre el papel tiene una superioridad de más del 100% en operaciones, o sea, más del doble, ¿cómo narices esa ventaja disminuye al final a sólo un 20%? (3.5 vs 7,7).


Porque el 65816 trabaja internamente a 3,58mhz, y el 68000 trabaja internamente a 1,92mhz. La frecuencia externa de 7,67mhz sirve para transportar rápido los resultados, pero estos son procesados a 1,92mhz.

Además, la diferencia no está solo en la diferencia de frecuencias, sino que el 65816 es mas eficiente usando sus instrucciones (necesita menos ciclos que el 68000 para efectuar cada una de ellas).

Y así, a golpe de eficiencia, el 65816 va reduciendo una diferencia del 100%, a una diferencia estimada, a grandes rasgos, de entre un 20 y un 30%. Tanto es así, que un 65816 a 5mhz sería bastante equivalente a ese 68000 a 7,67mhz.


Todo esto no lo digo yo, pero los tiros van bastante por ahí.

robotnik16 escribió:Sin acritud, los cálculos me la traen al pairo, no por nada, obviamente lo primero es conocer el hardware donde quieres hacerlo correr, pero no empecemos con las ventajas sobre el papel, cuando esas ventajas nunca se han hecho notar en 9 años de vida comercial ni ahora, al contrario. Hemos comprobado ya sobradamente a base de juegos y demos los pros y contras de ambas, y tus cálculos no siempre son fiables, y perdón pero es así.


Tengo mucho que aprender todavía, si.

Pero no es cierto que esas ventajas nunca se hicieran notar en los 9 años de vida que convivieron ambas máquinas. Juegos como el wolfenstein 3D no tenían igual en megadrive, la fase en raycaster del toy story son muy equivalentes, y unos cuantos títulos mas. Incluso el inalcanzable sonic ha resultado que estaba al alcance.

Eso si, que estuviese el ppu1 disponible para apoyar a la cpu no significa que se utilizase siempre, o que se utilizase bien.

robotnik16 escribió:Tampoco contemplas otras cosas, como la dificultad de programación de la máquina, su escasa documentación, cuellso de botella y el poco desarrollo en juegos homebrew.


Tengo en cuenta todo, pero si hablamos puramente de la cpu, las estimaciones son esas. Otra cosa es que luego veas las escenas del flashback y observes que una rinde el doble que la otra... bueno, pues no es solo por la cpu, sino por las características del sistema de vídeo, optimizaciones varias, etc.

robotnik16 escribió:Mi resumen como simple jugador en tres preguntas: ¿Se podría hacer algo espectacular también con otras cosas aportadas por la SNES? Seguro que sí. ¿Se podría hacer igualmente un buen beat'm up de estilo similar? Seguro que sí. ¿Funcionaría igual que en MD y bajo las mismas condiciones que lo presenta la MD? (que es la gracia del asunto). No lo creo, y en el punto en que estamos, estaría listo para 2040.


Lo que no tendría sentido es tratar de que la snes sea una megadrive. Cada una tiene sus ventajas y sus debilidades, y lo que si que podemos decir es que una tiene paprium, y la otra no XD
robotnik16 escribió:@Señor Ventura cosas que no me cuadran, ya sé que cada procesador tiene su arquitectura y bla bla bla, pero el 68000 sobre el papel tiene una superioridad de más del 100% en operaciones, o sea, más del doble, ¿cómo narices esa ventaja disminuye al final a sólo un 20%? (3.5 vs 7,7). Sin acritud, los cálculos me la traen al pairo, no por nada, obviamente lo primero es conocer el hardware donde quieres hacerlo correr, pero no empecemos con las ventajas sobre el papel, cuando esas ventajas nunca se han hecho notar en 9 años de vida comercial ni ahora, al contrario. Hemos comprobado ya sobradamente a base de juegos y demos los pros y contras de ambas, y tus cálculos no siempre son fiables, y perdón pero es así. Tampoco contemplas otras cosas, como la dificultad de programación de la máquina, su escasa documentación, cuellso de botella y el poco desarrollo en juegos homebrew.

Yo me retiro de una conversación sobre datos hipotéticos, porque no puedo seguirla, y porque creo que carecen de sentido y no son fiables AQUÍ. Vamos a entrar en un bucle de suposiciones imaginarias que lo único que van a conseguir es dar "falsos" argumentos y esperanzas al sector Nintendo. Sé perfectamente que en el MD vs SNES Parium ha hecho daño, y no voy a entrar en un juego de "apoyemos a la Súper en estos momentos difíciles". Veo bien el hilo para hablar distendidamente del asunto, pero poco más.

Mi resumen como simple jugador en tres preguntas: ¿Se podría hacer algo espectacular también con otras cosas aportadas por la SNES? Seguro que sí. ¿Se podría hacer igualmente un buen beat'm up de estilo similar? Seguro que sí. ¿Funcionaría igual que en MD y bajo las mismas condiciones que lo presenta la MD? (que es la gracia del asunto). No lo creo, y en el punto en que estamos, estaría listo para 2040.


Las explicaciones del @Señor Ventura me suele costar entenderlas muchas veces y hace poco he leído alguna explicación sobre lo de la velocidad de CPU que va en su línea, pero un pelín más comprensible. Tema de chips, CPUs y demás. No sé si todo será 100% como lo cuenta, pero me pareció un artículo muy interesante, aunque tampoco lo entendía todo.
https://disruptiveludens.wordpress.com/2018/07/01/graficos-retro-super-famicom-super-nintendo-entertainment-system/

Yamauchi quería compatibilidad hacía atrás en el nuevo sistema pero Uemura y su equipo habían hecho los cambios suficientes para que el hardware de la consola fuese completamente distinto pese a tener un funcionamiento aparentemente evolucionado en teoría respecto a la Famicom/NES. Todos los procesadores se re-diseñaron desde cero excepto la CPU que es un vestigió de la étapa inicial del proyecto.

La CPU de SNES es un clon modificado del 65c816 que es la versión de 16 bits del 6502, es la misma CPU que Apple utilizo en el Apple II GS para la compatibilidad hacía atrás con el Apple II original y en este caso la elección por parte de Nintendo fue inicialmente para ello ya que dicha CPU tiene un modo “Famicom” donde puede ejecutar nativamente código de su antecesora, en dicho modo la CPU se coloca a unos 1.79 Mhz de velocidad.

En realidad debería verse como una extensión a 16 bits del 6502 y la polémica que ha seguido durante años es el hecho de que como extensión que es realmente no tiene más capacidad de calculo que un 6502 a la misma velocidad de reloj. ¿Que cambios incorpora entonces? Pues registros de 16 bits, un direccionamiento de memoria de 24 bits (puede tener hasta 16MB/128 Mbits) y una instrucción que permite enviar datos en bloque que el 6502 no podía. Es curioso que Nintendo rechazará el HuC6280 que les ofreció Hudson Soft/NEC y que disponía de la mayoría de estas cosas de antemano para que en un año y medio más tarde presentar la Super Famicom. Nintendo completamente centrada en la Game Boy retraso el lanzamiento de su consola de 16 bits hasta 1990 en Japón.

Ahora bien… ¿Donde esta la polémica con la CPU? Primero esta en su velocidad de reloj que es variable dependiendo de la velocidad de la ROM del cartucho. Las dos velocidades estándar son 2.68 Mhz y 3.58 Mhz y su rendimiento como es obvió depende de la velocidad de la ROM de los cartuchos y he aquí un secreto que no comente en su día, a Genesis/Mega Drive y PC-Engine les pasaba lo mismo solo que Nintendo fue sincera en ese hecho desde el principio. La polémica esta en el hecho que el 68K es mejor procesador por el hecho de ser más avanzado y facilitar enormemente el trabajo a los desarrolladores, era una CPU estandar en la CPU de los 16 bits ya que todos los sistemas lo utilizaban y el ensamblador en el 65C816 complicaba enormemente las cosas a no ser que vinieras del 6502 que es de donde venía Nintendo y los licenciatarios/editores independientes de la Famicom. No obstante el 68K tiene un problema enorme que es la la latencia con la memoria externa. A nivel de registros internos el resultado era inmediato, a nivel de memoria externa el rendimiento bajaba a 1/4 por la latencia de 4 ciclos por lo que el 68K de Genesis/Mega Drive que funcionaba a 7.67 Mhz en realidad operaba como si trabajase a 1.92 Mhz.

En realidad es paradójico que el 68K se convirtiese en una CPU para sistemas de videojuegos precisamente por su lentitud. La mayoría de sistemas basados en el 68K con esa función tuvieron que desarrollar mecanismos para paliar dicho problema y especialmente en el envió y recepción de datos tanto si se tenía una máquina con búfer de imagen como una con generador de patrones/sprites. Cosas como las unidades Blitter de los ordenadores de 16 bits como el Amiga y el Atari ST por un lado y los mecanismos DMA de Genesis/Mega Drive se desarrollaron para paliar ese problema. Además fijaos como comente que la unidad DMA de Genesis/Mega Drive esta en el VDP y no como co-procesador del 68K. ¿El motivo? La horrenda latencia de acceso a memoria y se ha de tener en cuenta que en algunos casos puede llegar hasta los 14 ciclos. El 65816 y el 6502 tienen una latencia media de 0 ciclos aunque hay instrucciones que tardan unos 2 ciclos en completarse, pero eso solo es la mitad de la historia, en realidad el 65C816 a igualdad de velocidad de reloj efectiva es más lento que el 68000 por lo que el recorte en velocidad del 68K en cuanto a memoria externa se ve paliado por… Bueno, hay un benchmark en la revista Byte, precisamente en su número de Enero de 1983 donde se hace una comparación entre el 68K y el 65C816 donde se demuestra que el procesador de Motorola es más rápido.

¿El otro punto de la polémica? El bus de 8 bits, el cual hace que en el caso del 5A22/65C816 sea necesario gastar 2 ciclos por 1 instrucción de 16 bits por el hecho que el bus de memoria es de 8 bits, esto signifa que cualquier transferencia hacía y desde la S-CPU se hará a 1.79 MB/s, 2.68 MB/s o 3.58 MB/s dependiendo de la velocidad de reloj a la que funcione el 5A22, la cual dependerá de la velocidad de reloj de la ROM del cartucho y la velocidad a la que funcione esa sección de la RAM en concreto.


Al final supongo que no se puede hacer un calculo tan inmediato como decir que un coche que corre a 200 Km/h es el doble de rápido que otro que va a 100 Km/h.

Si ahora te digo que el coche rápido tiene un maletero de 300 litros y puedes cargarle con 500 kg, y al coche lento tiene un maletero de 500 litros y puedes cargarle con 1000 kg, saber que coche puede desplazar antes 5 toneladas de Madrid a Barcelona, ya sería algo que dependería del tamaño/densisdad de los artículos a transportar. Habría que estudiar los casos específicos para ver cuál de los dos te va a hacer el trabajo más rápido (aunque está claro que el coche de 200 Km/h es en términos de velocidad "pura" más rápido).
@MasterDan @Señor Ventura si las explicaciones y tal ya las he leído, pero me cuesta creer que pase a sólo un 20%, cuando hablamos de un micro elegido en la gran mayoría de sistemas y placas, entre ellos, los mejores de la época, y con muy buena fama. He visto mismo juego en ambas donde sí se percibe esa superioridad al ojo de mínimo el doble en MD, al igual que en demos (la de "oxygeno" por ejemplo), como he visto multitud de juegos poco exigentes de Snes que rascan. Ya lo sé, slow roms, mala optimización... lo que sea, pero no vislumbro una eficiencia parecida a la del 68k, sin descartar esas operaciones más eficientes que también tiene el 68k.
En fin, ahí os dejo [oki]

@txefoedu si estamos de acuerdo, también he leído eso otras veces, y también he leído decir al que hizo el port de Megaman X (y también el famoso Sonic de Snes) otras diferentes. Es complejo y dependerá de muchos factores, no creo que se pueda establecer una sentencia firme de "alrededor de 20%", yo me quedo con lo veo en los juegos, que me parece la mejor pista.
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
@Señor Ventura
edit: De hecho, muchos de los juegos que sufren ralentizaciones, lo hacen por culpa de bugs, y no por falta de potencia, como se ha estado creyendo.


Eso a poco que te paras a investigar catálogos en hard real te das cuenta que sucede en TODOS los sistemas de 16 bits, desde el Sharp-X68000 hasta la Neo Geo AES. La diferencia es que para géneros de alta demanda de CPU muchos de esos sistemas no se esconden, o no disponen, tras resoluciones-trinchera de 256x224 para aplacar un poco la presión y así disimular algo sus limitaciones, por no hablar del abuso de bandas negras en ese mismo contexto.

Vamos con unos ejemplos, a ver si ahora la única pobrecita maltratada por un código sin pulir es la SNES:

- Salamander, Sharp-X68000, te hace pirulas en plan ralentizarse sin enemigos en pantalla, y acelerarse cuando está petada, incluso con un M68k @16 Mhz :-| También es cierto que el Sharp corre muchos de sus juegos con ratios de 512x256, o incluso a 512×512, y hablo de modos completos (fondos y sprites) "HDReady/Full HD" del momento, no como el fraudulento modo "hi-res" de la SNES, nótense las comillas.

- Metal Slug 2, Neo Geo, FESTIVAL de petardeos fase tras fase. Que ese código es 1 despropósito a muchos niveles lo reconocen hasta los propios creadores.

- Double Dragon II, Mega Drive. La MD a 256x224, una vergüenza ya de por sí, pero es que encima dentro de esa nube sufre slowdowns con apenas 3 personajes en pantalla, que un Street of Rage 2 no sufre en contextos como el siguiente:

Imagen

Curiosamente el sistema que estadísticamente menos ralentizaciones sufre es la Pc-Engine, con un micro de 8 bits, pero con tan buena configuración custom que es probablemente la consola con el entorno de CPU más equilibrado respecto al resto del hardware de todas, y estamos hablando de una que emplea habitualmente ratios de 256x239, y a veces incluso 336x224/39 en géneros como los shooters o run and gun.

@Sexy MotherFucker Ya sabemos como ha solucionado el super ghouls'n ghosts las ralentizaciones sin parcheos de SA-1 o fast-rom: era un bug.


Coño, gracias x la info [oki]

La verdad es que con el parche ya va muy fino, aunque sigue habiendo alguna que otra rascada en según qué tramos. Anyway; sigo pensando que con un speed-up a 3,58 Mhz este juego alcanza el resultado que siempre debió tener, de las primeras cosas que voy a probar en la Mister.

@robotnik16 No hagas ni caso a Ventura; aunque no te está mintiendo la diferencia a favor del 65816 en esos contextos no es tan grande como el clama, ya que la versatilidad en su uso del M68k permite que con su mayor eficiencia en la multitarea compense con ciertas algorritmos sus debilidades.
Acabo de leer que una de las posibles explicaciones de los slowdonws que producía el Super G&G es que por lo visto el juego se dedicaba a buscar un chip de seguridad en la consola y el parche lo suprime , pero por lo visto al haber eleminado esa función del juego este no funciona en todos los flashcards . Joder con los de Nintendo ya en los 90 con el puto denuvo [facepalm]
Hookun escribió:Acabo de leer que una de las posibles explicaciones de los slowdonws que producía el Super G&G es que por lo visto el juego se dedicaba a buscar un chip de seguridad en la consola y el parche lo suprime , pero por lo visto al haber eleminado esa función del juego este no funciona en todos los flashcards . Joder con los de Nintendo ya en los 90 con el puto denuvo [facepalm]


El juego lo programó Capcom no Nintendo.
@MasterDan
El chip de seguridad de dentro de la consola es de Nintendo no de Capcom ...
@Sexy MotherFucker ya yaaaa... si le conocemos al colega, está de bajona por el Paprium y se quiere reivindicar, pero que no venda lo maravilloso de esa CPU, que he JUGADO a bastantes juegos (tengo unos poco en Super Famicom y cuando emulo lo hago en NTCS) y me he encontrado mil rascadas en juegos insospechados. Raro que todos estén mal programados, raro que todas las compañías en los juegos de primera hornada de los gordos tuvieran ralentizaciones importantes, raro que al velocidad de juego siempre inferior a MD... en fin. Te lo dejo a tí que controlas mucho más del tema, pero que ahí dentro hay algo que no da la talla (y como dices, a resolución 8bits) lo ve hasta el apuntador.
Hookun escribió:@MasterDan
El chip de seguridad de dentro de la consola es de Nintendo no de Capcom ...


El chip de seguridad de Nintendo comprueba por hardware que el cartucho es original y si no no te lo deja arrancar (Sega también hacía cosas de estas). El juego no tiene que comprobar que exista ni nada, por lo que si Capcom lo programó así es cosa de Capcom.
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
@Señor Ventura
Incluso el inalcanzable sonic ha resultado que estaba al alcance


A 256x224, sin tener la CPU ocupada cargando parcialmente con el engine de sonido como el M68k en Sonic 1, sin gastar rendimiento extra en el bug de los anillos, etc, no sé Rick... A mí aún no me han demostrado que la SNES pueda con 1 Sonic tal cual lo mueve la MD, del mismo modo que el Rockman X de Mega Drive tampoco queda 1:1 con respecto al de SNES.

Yo lo siento pero es que nunca voy a poder respetar el entorno de CPU en la SNES; resulta que le calzan un 65816, un micro el cual a pesar de su cuello de botella nativo y escasez de registros/instrucciones resulta IDEAL para consolas basadas en mapa de tiles + DMA, para luego coger una barra de hierro oxidada y ponerse a darle hostias con una configuración tan horrorosa que la CPU al final se queda tullida:

- Clock muy bajo. Por eficiente que sea un 65816 3'58 Mhz resultan insuficientes para las demandas más PRO de ciertos géneros en 16 bits.

- Roms limitantes. Por si fuese poco lo de arriba, Nintendo tuvo la brillante idea de producir cartuchos que limitaban aún más la frecuencia (2'68 Mhz).

- Wram pone-zancadillas. El 65816 tiene la capacidad de operar externamente a la misma velocidad que la memoria, y en cambio incluso con roms a 3'58 Mhz castra a la CPU cuando va a leer/escribir en ella al estar por debajo de ese clock.

Afortunadamente la SNES opera a 256x224 en el 99% de sus juegos, lo cual cada día estoy más convencido que fué una medida de prevención por parte de Nintendo, y gracias a ello estas taras no afligen todo lo que podrían a los shooters y brawlers de este sistema.
@Sexy MotherFucker
El gigante de pies de barro !! A snes se le daban bien los géneros de RPG y otros juegos más pausados con poca acción y actividad en la pantalla . Si le exigía velocidad frenética y acción caía el rendimiento en picado . Me acuerdo perfectamente en su época cuando la tuve como me chocaba la diferencia de velocidad y acción frente a la megadrive .
@gynion ese no lo he probado, también te digo que solo juego al sof2 que me parece sublime y a los que he mencionado y no mucho.
Sobre paprium, es precioso, pero le veo eso mismo, que parece que no está pulido.
Que son 80 megas y chip gordo y sor 2 es más discreto en megas pero esta para mi gusto por encima, diría que en todo o casi.
Aún así como me queda probarlo y no tengo megadrive pues tocará esperar o a steam o emulador si se pudiese.
Ganas le tengo, me encanta la estética
robotnik16 escribió:@MasterDan @Señor Ventura si las explicaciones y tal ya las he leído, pero me cuesta creer que pase a sólo un 20%, cuando hablamos de un micro elegido en la gran mayoría de sistemas y placas, entre ellos, los mejores de la época, y con muy buena fama. He visto mismo juego en ambas donde sí se percibe esa superioridad al ojo de mínimo el doble en MD, al igual que en demos (la de "oxygeno" por ejemplo), como he visto multitud de juegos poco exigentes de Snes que rascan. Ya lo sé, slow roms, mala optimización... lo que sea, pero no vislumbro una eficiencia parecida a la del 68k, sin descartar esas operaciones más eficientes que también tiene el 68k.
En fin, ahí os dejo [oki]


No es una norma, son estimaciones, y varía dependiendo del programa, de sus requerimientos, de como esté optimizado... y del resto del hardware también, que por supuesto influye.

Hablamos de las cpu´s sin mas, y aquí la cosa es clara porque quitas de en medio muchas variables. Al hablar de las cpu´s y nada mas, sus números son los que son, y la diferencia no es de un 100% ni por asomo.

Sexy MotherFucker escribió:Eso a poco que te paras a investigar catálogos en hard real te das cuenta que sucede en TODOS los sistemas de 16 bits, desde el Sharp-X68000 hasta la Neo Geo AES. La diferencia es que para géneros de alta demanda de CPU muchos de esos sistemas no se esconden, o no disponen, tras resoluciones-trinchera de 256x224 para aplacar un poco la presión y así disimular algo sus limitaciones, por no hablar del abuso de bandas negras en ese mismo contexto.


Super nintendo nunca ha llevado la bandera de la potencia. Se lleva hablando del blast processing desde que salió la snes, así que veo injusto cuando hablas de reivindicar la potencia de la megadrive como si nunca hubiese sido así.

De hecho lo que siempre se ha dicho es que la snes no da para mucho mas que un pong, así que si hay que reivindicar algo aquí, es que ni la potente era tan potente, ni la lenta era tan lenta.

Sexy MotherFucker escribió:@robotnik16 No hagas ni caso a Ventura; aunque no te está mintiendo la diferencia a favor del 65816 en esos contextos no es tan grande como el clama, ya que la versatilidad en su uso del M68k permite que con su mayor eficiencia en la multitarea compense con ciertas algorritmos sus debilidades.


Yo no me la jugaría a que el 65816 + ppu1 no quita de un plumazo las diferencias de rendimiento (y me refiero a la etapa de procesamiento puro, que luego entra en juego en resto de componentes, y cada una tiene sus virtudes).

robotnik16 escribió:@Sexy MotherFucker ya yaaaa... si le conocemos al colega, está de bajona por el Paprium y se quiere reivindicar, pero que no venda lo maravilloso de esa CPU, que he JUGADO a bastantes juegos (tengo unos poco en Super Famicom y cuando emulo lo hago en NTCS) y me he encontrado mil rascadas en juegos insospechados. Raro que todos estén mal programados, raro que todas las compañías en los juegos de primera hornada de los gordos tuvieran ralentizaciones importantes, raro que al velocidad de juego siempre inferior a MD... en fin. Te lo dejo a tí que controlas mucho más del tema, pero que ahí dentro hay algo que no da la talla (y como dices, a resolución 8bits) lo ve hasta el apuntador.


No me afecta en nada el paprium. No me interesa megadrive, y además es que no me interesa de verdad. No me quiero reivindicar en nada, este hilo ni siquiera lo he abierto yo, y si me preguntan que pienso del tema, pues respondo.

Ahora, si me piden que me extienda, y luego me lo van a echar en cara... [sonrisa]

No siempre la velocidad era siempre inferior, igual que no siempre el tiempo de respuesta era siempre inferior, como tampoco tenía menos juegos que usasen el ratón. Aquí se han dicho muchas cosas, y se han desmitificado bastante, lo que pasa es que luego no nos acordamos.

Megadrive tiene mas potencia de forma mas directa, snes solo alcanza esos grados de potencia si dominas el hardware. Por eso vimos lo que vimos, pero no te comas de vista a la snes, que demuestra potencia cuando toca, y esto es cierto.

Sexy MotherFucker escribió:A 256x224, sin tener la CPU ocupada cargando parcialmente con el engine de sonido como el M68k en Sonic 1, sin gastar rendimiento extra en el bug de los anillos, etc, no sé Rick... A mí aún no me han demostrado que la SNES pueda con 1 Sonic tal cual lo mueve la MD, del mismo modo que el Rockman X de Mega Drive tampoco queda 1:1 con respecto al de SNES.


No. El sonic de snes carga con el mismo código de la megadrive transladado a la snes, con todo lo que impone procesar en esta, incluídos bugs, etc.

Que luego se pula es evidente, pero recordemos que lo ha hecho solo un tío en unos meses, no querremos compararlo al rendimiento de la megadrive por todo un equipo de trabajo durante años, mas aún cuando se trata de hacer correr el propio código de la megadrive en snes.

Si no es potencia bruta que se trague el código tal y como se lo traga la mega, apaga y vámonos (de ahí que por otro lado en su primera versión estuviese por debajo en rendimiento, es que es normal si no optimizas desde un hardware diferente).

Sexy MotherFucker escribió:Yo lo siento pero es que nunca voy a poder respetar el entorno de CPU en la SNES; resulta que le calzan un 65816, un micro el cual a pesar de su cuello de botella nativo y escasez de registros/instrucciones resulta IDEAL para consolas basadas en mapa de tiles + DMA, para luego coger una barra de hierro oxidada y ponerse a darle hostias con una configuración tan horrorosa que la CPU al final se queda tullida:

- Clock muy bajo. Por eficiente que sea un 65816 3'58 Mhz resultan insuficientes para las demandas más PRO de ciertos géneros en 16 bits.

- Roms limitantes. Por si fuese poco lo de arriba, Nintendo tuvo la brillante idea de producir cartuchos que limitaban aún más la frecuencia (2'68 Mhz).

- Wram pone-zancadillas. El 65816 tiene la capacidad de operar externamente a la misma velocidad que la memoria, y en cambio incluso con roms a 3'58 Mhz castra a la CPU cuando va a leer/escribir en ella al estar por debajo de ese clock.


Esto es como si subes a un púgil de 1,60m y 50 kilos a pelear con mike tyson, y todavía dices que el aspirante raquítico va de fuerte y que ya va siendo hora de que se demuestre que tyson es mejor.

Aquí a quien hay que reivindicar es al boxeador bajito y delgado, que lleva toda la vida aguantando burlas. Que fácil es apostar por el favorito, sexy XD

Sabemos que la snes sufre muchas zancadillas... y aún así mira donde está. Es lo que es, un hardware barato... pero me gusta su filosofía. Estoy seguro de que si llevas al extremo la filosofía de ambas máquinas, la snes llegaría mas lejos, pero esto son opiniones personales, claro.

Sexy MotherFucker escribió:Afortunadamente la SNES opera a 256x224 en el 99% de sus juegos, lo cual cada día estoy más convencido que fué una medida de prevención por parte de Nintendo, y gracias a ello estas taras no afligen todo lo que podrían a los shooters y brawlers de este sistema.


No fué una medida de prevención de nintendo para no exponer a su cpu, fué una idea de diseño para materializar la retrocompatibilidad con la nes.

Hookun escribió:@Sexy MotherFucker
El gigante de pies de barro !! A snes se le daban bien los géneros de RPG y otros juegos más pausados con poca acción y actividad en la pantalla . Si le exigía velocidad frenética y acción caía el rendimiento en picado . Me acuerdo perfectamente en su época cuando la tuve como me chocaba la diferencia de velocidad y acción frente a la megadrive .


No es cierto, pero para nada, ni siquiera en shoot em ups se puede afirmar que eso sea así por defecto.
titorino escribió:@gynion ese no lo he probado, también te digo que solo juego al sof2 que me parece sublime y a los que he mencionado y no mucho.
Sobre paprium, es precioso, pero le veo eso mismo, que parece que no está pulido.
Que son 80 megas y chip gordo y sor 2 es más discreto en megas pero esta para mi gusto por encima, diría que en todo o casi.
Aún así como me queda probarlo y no tengo megadrive pues tocará esperar o a steam o emulador si se pudiese.
Ganas le tengo, me encanta la estética


No, es que pulido no está. Para las pretensiones principalmente audiovisuales que tiene el juego, no es nada grave, ni mucho menos, y a mi modo de ver vale mucho la pena disfrutarlo, el despliegue técnico, y tenerlo incluso por el hardware especial que use (a precios anteriores, eso sí), pero un juego redondo no lo veo.

Tampoco creo que ese sea su objetivo, sino que es un juego que ha venido a dar lo que ha prometido, que es potencia bruta nunca vista en Megadrive, y lo demás será secundario. Me imagino que por eso tendrás esa sensación previa en la comparativa con un gran clásico como es el juego en el que se basa Paprium. No es cuestión de megas esto, sino de algo diferente.
Hookun escribió:@Señor Ventura
Pero sigues sin tener en cuenta varias consideraciones : Lo primero que los titles tienen que ser troceados y después reconstruidos en el " mosaico " . Eso es un gasto menor de recursos en vez de tirar de sprites a lo bestia pero estas atado a la capacidad de la CPU en la preparación y a la velocidad y capacidad del ancho de banda junto con el VDP para ir colocándolos. Con lo que tu idea del coste casi 0 de recursos no es así . Si de verdad fuera como dices no existirían las ralentizaciones en los juegos , ni el flickering .


Cuando afirmo algo tengo en cuenta mas consideraciones de las que puedas imaginar.

Las tiles ya están troceadas en la rom, y como tales pueden servir para un sprite, para un plano, o para ambas simultáneamente. Es irrelevante.

La cpu no coloca los sprites, eso lo hace el sistema gráfico por medio de una tabla de atributos que contiene la información de la coordenada vertical y horizontal del sprite (su posición dentro del objeto), de si está invertido o conserva su orientación normal, de su prioridad, de su paleta, y de su tamaño (puedes “escalarlo”. Nota las comillas).

Lo único que hace la cpu es enviarle las instrucciones al PPU1, y esta hace todo el trabajo de componer un objeto con un sprite, o con varios si está compuesto por mas de uno. Y puedes creer que al sistema gráfico le sobra potencia para hacer esa tarea sin demora: están hechos para eso.

La modificación de esas “instrucciones” se hacen manualmente mediante el código previamente introducido por el programador (a menos que este pretenda conformarlos de forma procedural, pero un juego estándar nunca ha pretendido eso, ni son máquinas para meterles esa tralla).

Lo que si es cierto es que actualizar la tabla OAM, que es la tabla de atributos, debe enviarse a la VRAM para que el PPU1 la lea y pueda hacer su trabajo “montando” sprites, y esta tiene un peso máximo de 544 Bytes.

En resumen. Hacer esta tarea ocupa un máximo de 544 Bytes de ancho de banda, y de tiempo de proceso para la cpu, absolutamente nada. Sobra decir que cuantas menos cosas necesites actualizar de la tabla OAM, o cuantos menos slots utilices, menos Bytes ocupará.

emerald golvellius escribió:@robotnik16 Tiene gracia lo que comentas,de que la maquina se ahoga con estos juegos,luego ves un Shoot em up como por ejemplo Bio Metal"muchos...no nos engañemos"y un Flickering...


Un inciso. Un biometal es un juego del “segmento B” en snes. Los juegos de esa categoría en megadrive también tienen sus lacras.

No podemos comparar un Thunderbolt Force vi con un biometal, las ambiciones no fueron las mismas.

Hookun escribió:@robotnik16
Solo tienes que ver qué los " arreglos " de algunos juegos que hacen en la scene pasan siempre por usar el manido chip SA-1 que es la CPU de la snes a 10mhz y 2kb extra de RAM ...


En realidad no es así. Él Gracias III tuvo un parche para que la cpu pudiese funcionar al 100% de su rendimiento, y el juego arreglaba la mayoría de las ralentizaciones, además de que maquillaba mucho las que aún quedaban. No hace tanta falta un SA-1.

La cuestión es que el gradius III sobrecargaba innecesariamente de tareas a la cpu para un resultado que se podía conseguir sin ser tan redundante. Y en general, el juego que tiene problemas, si no los tiene porque no está programado con inteligencia, los tiene porque los provoca un bug.

Luego hay juegos que evidentemente tienen un mal rendimiento infranqueable, pero te sorprenderías de la cantidad de juegos que van mal por errores de programación, y que se lo achacamos injustamente a esa cpu.

Su mala fama es tan merecida como inmerecida. El 65816 es un procesador rudimentario, pero en mi opinión para la clase de software que tenían que manejar las 16 bits, es la opción que mas potencia te puede dar. Un 65816 a los mismos 7,67mhz que el Motorola de megadrive sería mucho mas potente... y no digamos ya si le pones un bus de 16 bits (que tiene su explicación, en teoría no se puede, pero el SA-1 tiene uno para comunicarse con su ram en el cartucho, que a su vez sería el equivalente a una WRAM si estuviese dentro de su propio sistema, en su propia arquitectura).
Señor Ventura escribió:
Hookun escribió:@Señor Ventura
Pero sigues sin tener en cuenta varias consideraciones : Lo primero que los titles tienen que ser troceados y después reconstruidos en el " mosaico " . Eso es un gasto menor de recursos en vez de tirar de sprites a lo bestia pero estas atado a la capacidad de la CPU en la preparación y a la velocidad y capacidad del ancho de banda junto con el VDP para ir colocándolos. Con lo que tu idea del coste casi 0 de recursos no es así . Si de verdad fuera como dices no existirían las ralentizaciones en los juegos , ni el flickering .


Cuando afirmo algo tengo en cuenta mas consideraciones de las que puedas imaginar.

Las tiles ya están troceadas en la rom, y como tales pueden servir para un sprite, para un plano, o para ambas simultáneamente. Es irrelevante.

La cpu no coloca los sprites, eso lo hace el sistema gráfico por medio de una tabla de atributos que contiene la información de la coordenada vertical y horizontal del sprite (su posición dentro del objeto), de si está invertido o conserva su orientación normal, de su prioridad, de su paleta, y de su tamaño (puedes “escalarlo”. Nota las comillas).

Lo único que he hace la cpu es enviarle las instrucciones al PPU1, y esta hace todo el trabajo de componer un objeto con un sprite, o con varios si está compuesto por mas de uno. Y puedes creer que al sistema gráfico le sobra potencia para hacer esa tarea sin demora: están hechos para eso.

La modificación de esas “instrucciones” se hacen manualmente mediante el código previamente introducido por el programador (a menos que este pretenda conformarlos de forma procedural, pero un juego estándar nunca ha pretendido eso, ni son máquinas para meterles esa tralla).

Lo que si es cierto es que actualizar la tabla OAM, que es la tabla de atributos, debe enviarse a la VRAM para que el PPU1 la lea y pueda hacer su trabajo “montando” sprites, y esta tiene un peso máximo de 544 Bytes.

En resumen. Hacer esta tarea ocupa un máximo de 544 Bytes de ancho de banda, y de tiempo de proceso para la cpu, absolutamente nada. Sobra decir que cuantas menos cosas necesites actualizar de la tabla OAM, o cuantos menos slots utilices, menos Bytes ocupará.

emerald golvellius escribió:@robotnik16 Tiene gracia lo que comentas,de que la maquina se ahoga con estos juegos,luego ves un Shoot em up como por ejemplo Bio Metal"muchos...no nos engañemos"y un Flickering...


Un inciso. Un biometal es un juego del “segmento B” en snes. Los juegos de esa categoría en megadrive también tienen sus lacras.

No podemos comparar un Thunderbolt Force vi con un biometal, las ambiciones no fueron las mismas.

Hookun escribió:@robotnik16
Solo tienes que ver qué los " arreglos " de algunos juegos que hacen en la scene pasan siempre por usar el manido chip SA-1 que es la CPU de la snes a 10mhz y 2kb extra de RAM ...


En realidad no es así. Él Gracias III tuvo un parche para que la cpu pudiese funcionar al 100% de su rendimiento, y el juego arreglaba la mayoría de las ralentizaciones, además de que maquillaba mucho las que aún quedaban. No hace tanta falta un SA-1.

La cuestión es que el gradius III sobrecargaba innecesariamente de tareas a la cpu para un resultado que se podía conseguir sin ser tan redundante. Y en general, el juego que tiene problemas, si no los tiene porque no está programado con inteligencia, los tiene porque los provoca un bug.

Luego hay juegos que evidentemente tienen un mal rendimiento infranqueable, pero te sorprenderías de la cantidad de juegos que van mal por errores de programación, y que se lo achacamos injustamente a esa cpu.

Su mala fama es tan merecida como inmerecida. El 65816 es un procesador rudimentario, pero en mi opinión para la clase de software que tenían que manejar las 16 bits, es la opción que mas potencia te puede dar. Un 65816 a los mismos 7,67mhz que el Motorola de megadrive sería mucho mas potente... y no digamos ya si le pones un bus de 16 bits (que tiene su explicación, en teoría no se puede, pero el SA-1 tiene uno para comunicarse con su ram en el cartucho, que a su vez sería el equivalente a una WRAM si estuviese dentro de su propio sistema, en su propia arquitectura).


@Señor Ventura No conozco el Thunderbolt Force pero con ese nombre debe ser la ostia!
@emerald golvellius , ¿en serio?. Deberías probar el prototipo junto con el Gracias III y hacer un video para el hilo de los matamarcianos, son la leche [fumando] .

Benditos correctores del móvil :Ð
isacin escribió:@emerald golvellius , ¿en serio?. Deberías probar el prototipo junto con el Gracias III y hacer un video para el hilo de los matamarcianos, son la leche [fumando] .

Benditos correctores del móvil :Ð

Pues te voy a decir una cosa,Thunderbolt Force suena la ostia,es como Operation Thunderbolt y Contra Force en uno,muy fuerte.
@emerald golvellius @isacin [qmparto] [qmparto] [qmparto]

El puto ipad es horroso para escribir con teclado porque no te das ni cuenta de las que te lía [+risas]


Lo cual me recuerda a que @Sexy MotherFucker podría usar un teclado bluetooth cuando tenga que escribir desde el movil [rtfm]
emerald golvellius escribió:
isacin escribió:@emerald golvellius , ¿en serio?. Deberías probar el prototipo junto con el Gracias III y hacer un video para el hilo de los matamarcianos, son la leche [fumando] .

Benditos correctores del móvil :Ð

Pues te voy a decir una cosa,Thunderbolt Force suena la ostia,es como Operation Thunderbolt y Contra Force en uno,muy fuerte.

[+risas]
@Señor Ventura
No voy a entrar en más discusiones pero vamos si crees en la magia ya está . Cuando dibujas , mueves y pones objetos actúa todo en un hardware . Todo son ciclos , lo que algunos cuestan menos que otros pero cuestan . Pero si en snes es todo gratis pues nada . A ver si algún día vemos algo como Neo GEO en ella o este Paprium sin acritud ehh que lo digo porque la scene de esta máquina está casi muerta .
Pues sin querer mira lo que hiciste,ahora Thunderbolt Force no se me va d ela cabeza,me imagino un juegazo de naves con ese nombre,deberia hacerlo,en SNES que se que te gusta.

deberia ser algo asi como un Thunderforce como con mas Force,cuanto cuesta patentar un nombre?es para pensarselo.
Hookun escribió:@Señor Ventura
No voy a entrar en más discusiones pero vamos si crees en la magia ya está . Cuando dibujas , mueves y pones objetos actúa todo en un hardware . Todo son ciclos , lo que algunos cuestan menos que otros pero cuestan . Pero si en snes es todo gratis pues nada . A ver si algún día vemos algo como Neo GEO en ella o este Paprium sin acritud ehh que lo digo porque la scene de esta máquina está casi muerta .


Bueno, pues mira, me está bien empleado por intentar explicar las cosas a alguien que llama magia al esfuerzo de dar una explicación, pero que si que cree que sus ideas preconcebidas son como el las piensa por ciencia infusa (ya que reconocidamente afirma que no sabe, y no las entiende).

Pues como tu quieras. No es lo mismo un metasprite, que varios objetos. Ambos involucran a varios sprites, pero ni de coña "todo son ciclos", y si te interesa conocer sobre lo que afirmas, puedes usar google.
@Señor Ventura
Hombre no vayas de sobrado tampoco. Te he dicho que de programación no entiendo pero si algo del funcionamiento del hardware . Y como te he remarcado ya muchas veces siempre hay un trabajo detrás de cada cosa . Que tu no lo entiendas o no lo percibes no es lo mismo . Pero está ahí , lo que la capacidad del hardware de hacerlo se notará más o menos según el tiempo y las latencias que lleven esos ciclos de trabajo .
El caso es que mucho plano , mucho ppu y mucho tittle , pero nada que aún que le haya sacado partido ni demuestre tus teorías .
Hookun escribió:El caso es que mucho plano , mucho ppu y mucho tittle , pero nada que aún que le haya sacado partido ni demuestre tus teorías .


Ya te he puesto antes un ejemplo que demuestra lo que digo, porque no es una teoría.


Imagen

Imagen
@Señor Ventura
Eso no es ningún portento técnico la verdad . Para mi el mejor juego en todo fue Super Metroid . Con unos bosses enormes , una velocidad música , sonido y animaciones buenísimas . Incluso me atrevo a decir que fue y será el mejor juego de esa generación y por mucho .
Hookun escribió:@Señor Ventura
Eso no es ningún portento técnico la verdad .


Es lo que llevo diciendo todo el rato. De eso se ocupa el PPU1 automáticamente, y la cpu no tiene que hacer nada:
hilo_paprium-en-snes_2406354_s50#p1750674129

Tu vienes diciendo que hacer una cosa como la que muestro en las capturas es tan demandante de cpu como mostrar muchos objetos simultáneos... que no hay diferencia entre un objeto formado por muchos sprites que hay que colocar uno a uno, o muchos objetos formados por uno, o muy pocos sprites:
hilo_paprium-en-snes_2406354#p1750662513
hilo_paprium-en-snes_2406354#p1750662008
Hookun escribió:@Señor Ventura
Eso no es ningún portento técnico la verdad . Para mi el mejor juego en todo fue Super Metroid . Con unos bosses enormes , una velocidad música , sonido y animaciones buenísimas . Incluso me atrevo a decir que fue y será el mejor juego de esa generación y por mucho .

Valken.

aunque contra gustos...
emerald golvellius escribió:
Hookun escribió:@Señor Ventura
Eso no es ningún portento técnico la verdad . Para mi el mejor juego en todo fue Super Metroid . Con unos bosses enormes , una velocidad música , sonido y animaciones buenísimas . Incluso me atrevo a decir que fue y será el mejor juego de esa generación y por mucho .

Valken.

aunque contra gustos...


No me extraña, se lían unas muy pardas...

https://youtu.be/NJqpALJUgFM?t=2995
@emerald golvellius
Ese es Cybernator aquí no ? Si tiene muy buena pinta pero intenté jugar a él en su época y no sé porque pese a entrar por los ojos no me gustó .
Le daré un tiento en la snes mini que permite salvar partidas cómodamente . Al que le estoy dando actualmente es el Blackthorne que me gusta .
@Hookun Si...Konami se atrevio a soltarlo 4 rupias a Masaya para distribuirlo fuera de Japon...,lo censuro bien,quito escenas e imagenes que pudieran herir nuestra sensibilidad"como el suicidio del tipo del escritorio al final" y ale Cybernator.

Blackthorne es un juegazo.
emerald golvellius escribió:@Hookun Si...Konami se atrevio a soltarlo 4 rupias a Masaya para distribuirlo fuera de Japon...,lo censuro bien,quito escenas e imagenes que pudieran herir nuestra sensibilidad"como el suicidio del tipo del escritorio al final" y ale Cybernator.

Blackthorne es un juegazo.

El cybernator está chulo, me queda por probar la segunda parte o eso creo metal warrior que también hablan muy bien de él
titorino escribió:
emerald golvellius escribió:@Hookun Si...Konami se atrevio a soltarlo 4 rupias a Masaya para distribuirlo fuera de Japon...,lo censuro bien,quito escenas e imagenes que pudieran herir nuestra sensibilidad"como el suicidio del tipo del escritorio al final" y ale Cybernator.

Blackthorne es un juegazo.

El cybernator está chulo, me queda por probar la segunda parte o eso creo metal warrior que también hablan muy bien de él

Es bueno tambien,en Megadrive salio lo que seria como la primera parte aquel Leynos,pero esta muy lejos de el nivel de esos dos de SNES,aunque si te gustan este tipo de juegos tambien creo que merece la pena.

en Saturn salio el Assault Suits Leynos 2 que ya es la BOMBA.
@emerald golvellius los he jugado todos y si me gustan, tanto el de mega como el de saturn.
El de saturn es la bomba padre, espectacular.
Me falta el metal warrior pero es que se me acumulan juegos.
En cuanto termine con los parodius empezaré esta saga, me habéis picao
@titorino El que no entendi es el de PS2,lo compre pensando que seria como el de SNES mas o menos,pero es imposible de jugar,me parecio de una dificultad absurda.
En Super Nes hay también el bueníssimo Front Mission Gun Hazard.
Creo que fue @robotnik16 el que dijo que la CPU de Snes le da la sensación de que cuando la cosa se pone exigente se nota que asfixia. Yo estoy estos días dándole caña y probando juegos en hardware original y lo poco que he probado por ahora tengo que darle la razón, ya llevo un par de juegos que las ralentizaciones se notan, todavía estoy empezando a probar juegos así que tampoco puedo decir si es una constante, pero es algo que no me esperaba. En concreto en estos dos:

-Ace no Nerae!: Es un juego de tenis muy bueno que usa el modo 7 para generar ya este deporte en "3D", el juego cuando funciona fluido es una maravilla, pero a veces cuando el rival golpea la cámara (bueno el plano) tiene que girar y en esos giros pega unas ralentizaciones que me han hecho ya fallar varias pelotas porque pulso el botón calculando una velocidad y al ralentizarse la pelota todavía no hay llegado a mi. https://www.youtube.com/watch?v=QQvVD6IuwYQ

-Aero Fighters: Este se ralentiza continuamente en cuanto en la pantalla se acumulan enemigos y disparos, en los bosses que hay tormenta de disparos es casi una constante.

Que conste que no es una critica a ambos juegos, el primero es una locura para su momento y, creo, que en Megadrive no hay un simulador de tenis "3D" así que para aquellos años es de lo mejorcito supongo. Lo que me resulta extraño es que se ralentice porque el modo 7 de la consola es lo que genera el plano de profundidad y aunque lo mueva se supone que es para lo que se creó, tampoco es que tenga que rotar el plano tanto. Me suena haber leído que Super Mario Kart usaba chip DSP porque el modo 7 de la consola a pelo sufriría para mover fluidamente el plano de los circuitos ¿Podría ser esto?

El Aero Fighters es un port de un árcade bastante exigente de la época, me sorprende lo bien llevado que está y la cantidad de enemigos y disparos que muestra (no sé si hay recortes del original), pero que se ralentiza es un hecho. Tampoco puedo decir que en MD no se ralentizaría de haberse porteado a ella, a saber. Y seguramente hoy en día alguien mañoso podría hacer que este juego funcionase fino en ambas máquinas, pero me ciño a los 90 que si supieran hacer eso, no sacarían los juegos como lo sacaron (al menos la mayoría).

7th Saga usa el modo 7 en los combates y va fino aunque apenas hay movimiento del plano.
No se si se le puede achacar al ace o nerae que se ralentice cuando se le ve mantener el tipo en momentos como este:
https://youtu.be/QQvVD6IuwYQ?t=2293

A saber que es lo que provoca esas ralentizaciones, pero en un principio tampoco he visto nada de eso, ¿podrías señalar en que momento sucede eso?. Lo que si le puedo achacar es que gráficamente sea tan simple cuando el plano podría cumplir un poquito mas con la complejidad de color.

Habría que mirarlo, pero la cancha seguramente esté guardada entera en la VRAM. Si cada tiles va a seguir costando 64 Bytes igualmente, ¿por qué no emplear 256 colores en lugar de hacerlo a base de un color plano?.


Del aero fighters, no se si es que se me escapa algo, pero no puedo estar de acuerdo con eso de que se ralentiza. No tengo recuerdos de eso, he echado un vistazo en youtube, y tampoco he visto ninguna ralentización:
https://youtu.be/5Phj-735p30?t=29


¿No será que vais con la predisposición de detectar ralentizaciones y magnificar cualquier manchita?.
@SuperPadLand también te digo que yo tengo uan Super Famicom, los 60hz pueden jugar alguan mala pasada pero es así, rasca en situaciones "fáciles" dónde una consola de esa generación no debería, no es un tema velocidad de scrolls, sino de elementos en pantalla. Es como si le costara procesar lo que surge expontaneamente mientras juegas. A mí me sorprendió en el ISS Soccer, ya no es que rasque en los córnes cuando hay más jugadores a la vez y tal, en jugadas en el medio del campo con 3 tíos te rasca.

Ventura se pasó antes, Bio Metal una producción mediana? No hombreee
193 respuestas
Archivado
1, 2, 3, 4
Volver a Consolas clásicas