Batalla campal Snes Vs Megadrive, patio de colegio On

@titorino si la versión de Snes es superior a la MD aunque no me parece un run and gun es más estilo Alien 3 ya que tiene bastantes plataformas y exploración, lento para que vaya etiquetarlo en dicho género y que conste con eso no digo que sea un mal juego.

@Harbinger no para nada es malo, me ha sorprendido para bien.
Divertido.

@titorino Si es un juego divertido, jugable y el personaje y escenarios tiene su encanto.

SNES:
Input lag de los star wars:
-desplazamiento: 4 frames.
-salto: 4 frames.
-disparo: 4 frames.

Input lag del super mario world:
-desplazamiento: 3 frames.
-salto: 3 frames.

Input lag del yoshi's island:
-desplazamiento: 3 frames.
-salto: 3 frames.

Input lag del rendering ranger:
-desplazamiento: 2 frames.
-salto: 2 frames.
-disparo: 2 frames.

Input lag del the mask:
-desplazamiento: 3 frames.
-salto: 2 frames.
-disparo: 2 frames

Input lag del megaman 7:
-desplazamiento: 2 frames.
-salto: 2 frames
-disparo: 2 frames.

Input lag del Thunder spirits (thunder force III):
-desplazamiento: 2 frames.
-disparo: 2 frames.

Super probotector:
-desplazamiento: 2 frames.
-salto: 2 frames.
-disparo: 2 frames.


MEGADRIVE:
Input lag del sonic:
-desplazamiento: 2 frames.
-salto: 2 frames.

Input lag del thunder force IV:
-desplazamiento: 2 frames.
-dispario: 2 frames.

Input lag del thunder force III:
-desplazamiento: 2 frames.
-disparo: 2 frames.

Robocop vs terminator:
-desplazamiento: 3 frames.
-salto: 2 frames.
-disparo: 2 frames.

Alien soldier:
-desplazamiento: 3 frames.
-salto: 3 frames.
-disparo: 2 frames.

Gunstar heroes:
-desplazamiento: 2 frames.
-salto: 2 frames.
-disparo: 2 frames.

Contra hard corps:
-desplazamiento: 3 frames.
-salto: 2 frames (pero a veces falla y necesita 3 frames, es el único juego al que veo que le pasa esto).
-disparo: 2 frames.

@Señor Ventura
Eso no es posible, la snes tiene que tener 100 de input lag, si es lenta y tiene exceso de pesadez.

titorino escribió:Apuntad otro que acabo de probar en ambas versiones.
Bob.
En megadrive scroll más brusco, diría que va a la mitad que snes.
Peor sonido y faltan muchos detalles gráficos.
Y lo que más me ha sorprendido es que es de electrónic arts.
En serio probarlos.
Diría que es un run and gun y es muy divertido

Pues agárrate que vienen curvas.

B.O.B de megadrive:
-desplazamiento: 6 frames.
-salto: 3 frames.
-disparo: a veces 3 frames, a veces 4 frames, lo mismo que el contra.

B.O.B de snes:
-desplazamiento: 2 frames.
-salto: 2 frames.
-disparo: 3 frames.


Movimiento de trampolín: 7 frames en megadrive, y 4 frames en snes.

Recuerdo que el B.O.B era bastante malo tirando a mediocre en mega drive y no mucho mejor en SNES. Vamos a ver es el típico juego malo de narices.

gordon81 escribió:Recuerdo que el B.O.B era bastante malo tirando a mediocre en mega drive y no mucho mejor en SNES. Vamos a ver es el típico juego malo de narices.

A mi me han contado que en la mega todos los juegos eran mejores y frenéticos, gracias al procesador que ahora usará la ps5.

gordon81 escribió:Recuerdo que el B.O.B era bastante malo tirando a mediocre en mega drive y no mucho mejor en SNES. Vamos a ver es el típico juego malo de narices.

Digo lo mismo que el de arriba, yo tenía entendido que en megadrive esas cosas no pasaban

blade133bo escribió:

gordon81 escribió:Recuerdo que el B.O.B era bastante malo tirando a mediocre en mega drive y no mucho mejor en SNES. Vamos a ver es el típico juego malo de narices.

A mi me han contado que en la mega todos los juegos eran mejores y frenéticos, gracias al procesador que ahora usará la ps5.

Procesa mejor los juegos para que tu los veas a 16:9 en tu psvita

gordon81 escribió:Procesa mejor los juegos para que tu los veas a 16:9 en tu psvita

xD

@gordon81
Que va tío, la mega CD, se ve igual de mal en 16:9 o 4:3. Pero no te quitaré la razón, Final Fight de mega es mejor que la versión de snes en contenido y música.

B.O.B = Sonic Spinball = Desarrollo 100% en C.

Es normal que el rendimiento sea el que es.

Ya podían haber metido chip que pusieron al mario rpg a todo el catálogo de la snes que básicamente era el mismo que tenía el cerebro de la bestia pero a 10 mhz jajajajajajaja

@gordon81 pues poca broma con el chip SA-1 cómo CPU...

Y no, no era el mismo chip, esta evolución natural del 65816 estaba armado con todo un nuevo set de instrucciones, multiplicadores/divisores, y memoria caché.

Star Fox no hubiese necesitado chip FX para tener una versión decente del mismo (10-12 frames), con eso te digo todo. Y los escalados de sprites por software los hubiésemos visto a cascoporro a lo largo del catálogo de SNES.

B.O.B = Blast of Blosesing

Por eso no cuenta BOB, es marketing explosivo

Oye donde anda el patriarca espiritual retro de estos últimos días, el ser de luz cósmica?

Sexy MotherFucker escribió:@gordon81 pues poca broma con el chip SA-1 cómo CPU...

Y no, no era el mismo chip, esta evolución natural del 65816 estaba armado con todo un nuevo set de instrucciones, multiplicadores, y memoria caché.

Star Fox no hubiese necesitado chip FX para tener una versión decente del mismo (10-12 frames), con eso te digo todo. Y los escalados sprites por software los hubiésemos visto a cascoporro a lo largo del catálogo de SNES.

Esa es la pena, y es lo que he dicho mi y una veces en este topic, que en cuanto a chips de apoyo la snes era un portento tecnológico, pero que no les sacaban el partido.

Sí sólo la cpu princpial de SNES hubiese tenido al menos 7 mhz este topic quizás no existiría.

@gordon81 un WDC-65816 a 5 MHz y una RAM funcionando a una velocidad gemela, junto a roms equivalentes, hubiese sido suficiente para que la CPU de Super NES sobrepasase al M68k a 7,67 MHz de la MD en rendimiento global, salvo por temas menores como el cálculo de geometría donde los Ricoh son algo inferiores, y ciertas rutinas bucle ancladas en registros, qué pueden hacerse más rápidas en los Motorola. Programación developer friendly al margen.

No hacía falta irse a un S-A 1, el cual es un monstruo de 16 bits inalcanzable, aunque desgraciadamente nunca estuvo preparado a nivel de arquitectura para otra cosa que no sea ser un chip de apoyo.

Sexy MotherFucker escribió:B.O.B = Sonic Spinball = Desarrollo 100% en C.

Es normal que el rendimiento sea el que es.

El BOB es uno de los pocos juegos de SNES del que se filtró su código fuente (lo tengo en mi HDD por si te interesa) y está en ensamblador todo.

@magno me refiero a su versión Megadrive, en Sega-16 dijeron que estaba hecho a trancas y barrancas por plazos de entrega, y tiraron de C para acelerarlos.

Sexy MotherFucker escribió:@magno me refiero a su versión Megadrive, en Sega-16 dijeron que estaba hecho a trancas y barrancas por plazos de entrega, y tiraron de C para acelerarlos.

Pues si el de Mega Drive está en C, y el de SNES en ensamblador, ahí está la explicación, ¿no?

Sexy MotherFucker escribió:@gordon81 un WDC-65816 a 5 MHz y una RAM funcionando a una velocidad gemela, junto a roms equivalentes, hubiese sido suficiente para que la CPU de Super NES sobrepasase al M68k a 7,67 MHz de la MD en rendimiento global, salvo por temas menores como el cálculo de geometría donde los Ricoh son algo inferiores, y ciertas rutinas bucle ancladas en registros, qué pueden hacerse más rápidas en los Motorola. Programación developer friendly al margen.

Totalmente cierto, porque de hecho el 65C816 sólo tiene 1 registro de acumulación y 2 de índice, mientras que el 68000 tiene 16 registros.
Por cierto, sueles decir mucho "el Ricoh" pero realmente el procesador es de Western Digital, Ricoh lo fabricó junto con la lógica del DMA, decodificadores y demás para Nintendo. Pero el core es de Western Digital.

Sexy MotherFucker escribió:@magno me refiero a su versión Megadrive, en Sega-16 dijeron que estaba hecho a trancas y barrancas por plazos de entrega, y tiraron de C para acelerarlos.

Ah, ok, no había seguido la conversación completa.

@magno

Totalmente cierto, porque de hecho el 65C816 sólo tiene 1 registro de acumulación y 2 de índice, mientras que el 68000 tiene 16 registros.

Si me tengo el tema tan bien empollado es precisamente gracias a tus aportes mamón xDDD. Los devoro.

Y es que es así; aunque un 65816 a la misma frecuencia gane sobrado un benchmark a un 68000, lo cierto es que sus múltiples registros dan muchísimo juego para que incluso bajo estas circunstancias ciertas rutinas pueden ejecutarse más rápido en el Motorola. La verdad que no me extraña que estos micros se extendiesen como la pólvora, son súper prácticos, elegantes, y llenos de recursos pese a toda su latencia, imagino que sería un procesador de ciencia ficción cuando apareció en 1979, un sueño hecho realidad para los programadores.

Del mismo modo ya es hora también de que en las comunidades retro el usuario medio dejé de infravalorar a los 65816, ya que pese/o gracias a su extrema sencillez VUELAN.

Ah, ok, no había seguido la conversación completa.

De todas formas lo que se dice en los foros de Sega-16 siempre hay que cogerlo con pinzas a no ser que venga por boca directa de algunos de los desarrolladores que por allí se pasan de vez en cuando.

Ya que sale el tema y nunca he acabado de entenderlo; ¿Es cierto que los 65816 tienen muy bajo rendimiento bajo C? Al menos es lo que se dice del WDC de SNES, mientras que del Motorola cualquier programador dice justo lo contrario, y por eso se tira muy a menudo de programación alto nivel en esos micros.

Por cierto, sueles decir mucho "el Ricoh" pero realmente el procesador es de Western Digital, Ricoh lo fabricó junto con la lógica del DMA, decodificadores y demás para Nintendo. Pero el core es de Western Digital.

Gracias por la aclaración

No hubiera hecho falta ampliar tanto las capacidades del hardware, solo con que la WRAM hubiese corrido a la misma frecuencia que la cpu ya se hubiese conseguido ganar rendimiento (al poder operar siempre a esa frencuencia), y supuestamente el DMA podría estar preparado para alcanzar esa frencuencia, por lo que también lo hubiese hecho, y su ancho de banda hubiese rondado los 8,5KB.

Sobre el SA-1, la gracia para mi no está en su mayor frecuencia, en su caché, o en su set de instrucciones mejorado (incluyendo instrucciones para multiplicar y dividir, y pudiendo trabajar a una precisión por pixel, que no se muy bien que implica esto, ya que con el actual 65816 puedes alterar los píxeles de un tile usando la memoria ram principal, así que seguramente se refiera a otra cosa diferente que no comprendo).

Para mi la gracia del SA-1 está en su bus de datos de 16 bits para comunicarse con la ram interna de los cartuchos, del que me gustaría pensar que con ingeniería inversa podría establecerse un pipeline de 16 bits dentro de un hardware (no en un cartucho), desde la ROM, hasta la VRAM, y pasando por la WRAM.

Solo a 3.58mhz hablaríamos de 19KB por frame, y a 10.74mhz... no quiero ni pensarlo. Eso suponiendo que el DMA esté integrado en la CPU, que solo he leído que no está claro, a lo mejor un día salgo de dudas.


Lo que si me he preguntado veces, es a que hardware pudo haber aspirado la snes realmente en 1989/1990 (que fué la fecha en la que mas o menos cerraron el hardware), si nintendo hubiese decidido no escatimar en gastos.

¿Que componentes?, ¿con que características?, ¿sería posible por aquel entonces un sistema gráfico que te permitiese alternar tiles de diferentes profundidades de color en un mismo plano?, ¿sería posible implementar algún modo gráfico 100% custom en lugar de los 8 modos con funcionalidades preestablecidas?, ¿se podrían haber usado los multiplicadores del PPU1 para hacer otras cosas en modos gráficos fuera del modo 7? (como por ejemplo manipular las tiles de los sprites).

Y sobre todo, ¿es mejorable la arquitextura de la snes?, ¿es mejor conservar las memorias compartimentadas?, o un único pool de memoria, pero dividido en muchas rams de 8KB's para permitir múltiples accesos simultáneos.

¿Y un PPU3?, ¿super fx?, ¿a que hubiese sido equivalente todo esto junto?.


Nunca lo sabremos... ¿nunca lo sabremos?.

Sexy MotherFucker escribió:¿Es cierto que los 65816 tienen muy bajo rendimiento bajo C?

El secreto está en la masa.

No es solo por ser en C en si mismo, sino por la calidad del compilador. Si el compilador convierte en código sin dar demasiadas vueltas, rendirá bien, y si no, pues rendirá mal.

@Señor Ventura

Para mi la gracia del SA-1 está en su bus de datos de 16 bits

Juraría que @magno aclaró hace tiempo que el bus de datos externo del SA-1 seguía siendo de 8 bits... Que confirme o desmienta.

No hubiera hecho falta ampliar tanto las capacidades del hardware, solo con que la WRAM hubiese corrido a la misma frecuencia que la cpu ya se hubiese conseguido ganar rendimiento (al poder operar siempre a esa frencuencia), y supuestamente el DMA podría estar preparado para alcanzar esa frencuencia, por lo que también lo hubiese hecho, y su ancho de banda hubiese rondado los 8,5KB.

Aún así 3'58 MHz siguen antojándose pocos para manejar óptimamente los entornos más extremos del software de aquella generación, un pelín más de frecuencia le hubiese venido de lujo, además que lo bueno que tienen los 65816 es que no hace falta subirles un porrón de MHz cómo a los Motorola. Con un clock de 5 MHz y unas memorias/ROMs adaptadas ya si hubiese sido inalcanzable a nivel global.

Sexy MotherFucker escribió:Juraría que @magno aclaró hace tiempo que el bus de datos externo del SA-1 seguía siendo de 8 bits... Que confirme o desmienta.

Se comunica con la la snes mediante el bus de 8 bits del DMA de la consola, pero en el cartucho se comunica con su propia ram mediante un bus de 16 bits.

Ese bus es el que me intriga, y me pregunto si con ingeniería inversa podría servir como bus de datos para el pipeline ROM->CPU->WRAM->VRAM.

Sexy MotherFucker escribió:Aún así 3'58 MHz siguen antojándose pocos para manejar óptimamente los entornos más extremos del software de aquella generación, un pelín más de frecuencia le hubiese venido de lujo, además que lo bueno que tienen los 65816 es que no hace falta subirles un porrón de MHz cómo a los Motorola. Con un clock de 5 MHz y unas memorias/ROMs adaptadas ya si hubiese sido inalcanzable a nivel global.

Supongo que si, pero en terminos realistas, una WRAM a 3.58mhz como el procesador podría desbloquear mas ancho de banda del que tiene megadrive, siempre y cuando el DMA realmente esté habilitado para funcionar a 3.58mhz.

@Señor Ventura

Supongo que si, pero en terminos realistas, una WRAM a 3.58mhz como el procesador podría desbloquear mas ancho de banda del que tiene megadrive, siempre y cuando el DMA realmente esté habilitado para funcionar a 3.58mhz.

A mí eso me parece una mejora marginal, que además más rara vez se aprovecharía hasta el límite. Los 65816 a 5 Mhz estaban tiradisimos de precio en 1990, dependiendo de lo que costase una memoria a esa velocidad, hubiese válido más la pena porque eso ya sí implica una mayor capacidad de proceso lógica importante.

docobo escribió:Pues a mí me parece que el único problema que tienen los star wars es solo haber salido en SNES.

Desde China se ha oído.

Siempre me gustó mucho esa trilogía. Actualmente sólo tengo el primero, que sin embargo diría que es el mejor.

Sexy MotherFucker escribió:@Señor Ventura

Supongo que si, pero en terminos realistas, una WRAM a 3.58mhz como el procesador podría desbloquear mas ancho de banda del que tiene megadrive, siempre y cuando el DMA realmente esté habilitado para funcionar a 3.58mhz.

A mí eso me parece una mejora marginal, que además más rara vez se aprovecharía hasta el límite. Los 65816 a 5 Mhz estaban tiradisimos de precio en 1990, dependiendo de lo que costase una memoria a esa velocidad, hubiese válido más la pena porque eso ya sí implica una mayor capacidad de proceso lógica importante.

El problema es que la wram también tendría que tener 5 mhz, y las roms, y vete tu a saber si la vram también tiene que ir sincronizada.

Entre renovar todo el pipeline, y ajustar la wram, lo mas realista hubiera sido esto último.

Ahora, por pedir que no quede, no voy a ser yo quien no pida un mostrenco xD

gynion escribió:

Sexy MotherFucker escribió:@magno me refiero a su versión Megadrive, en Sega-16 dijeron que estaba hecho a trancas y barrancas por plazos de entrega, y tiraron de C para acelerarlos.

Pues si el de Mega Drive está en C, y el de SNES en ensamblador, ahí está la explicación, ¿no?

Evidentemente, porque el entorno de B.O.B no es nada del otro Jueves.

Sexy MotherFucker escribió:Evidentemente, porque el entorno de B.O.B no es nada del otro Jueves.

Estando el Gunstar Heroes, el Contra Hard Corps, los devs de CupHead, y nuestros propios sentidos para comprobar la realidad, no problem. El problema surge cuando no hay juegos que desmientan ideas o conclusiones razonables.

Anda que no he visto de veces en B.O.B. en los videoclubs y tiendas. De ese debieron lanzar una gran tirada, o no lo compraba nadie.

Es que es lógico. La megadrive tiene mas cpu.

Esto es el Mega Drive cuando todos sus recursos se utilizan al máximo, pixelart calidad casi SNK, un colorido que podría competir contra cualquier rival, voces super nítidas, sonido top, jugabilidad furiosa, poca o ninguna ralentizacion, algo que sólo se veía usualmente en recreativas a funcionar en negrita de SEGA.


recomendable ver en HD

Sexy MotherFucker escribió:Si me tengo el tema tan bien empollado es precisamente gracias a tus aportes mamón xDDD. Los devoro.

Me alegro de que mis tochos le sirvan a alguien

Sexy MotherFucker escribió:Ya que sale el tema y nunca he acabado de entenderlo; ¿Es cierto que los 65816 tienen muy bajo rendimiento bajo C? Al menos es lo que se dice del WDC de SNES, mientras que del Motorola cualquier programador dice justo lo contrario, y por eso se tira muy a menudo de programación alto nivel en esos micros.

Eso depende del compilador, pero en general, los compiladores de C se llevan mejor con micros con muchos registros como el 68000, x86, i64, Cortex, etc... Realmente la tendencia de los micros siempre es a tener un banco de registros de uso general considerable, creo que eso hace tan especialito al 65C816, que tiene 3 y de uso específico, no general.
Así a botepronto se me vienen varias limitaciones a la hora de optimizar código en C si usaras el 65C816:
* Cada variable declarada tendría que estar en memoria: no se podrían optimizar variables locales asignándolas a registros internos para reducir el número de accesos a memoria externa al tener sólo 3 registros.
* El acceso a arrays se podría hacer usando el registro X o Y dependiendo del tamaño del array, lo cual dificulta la optimización: si quieres acceder a arrays de cualquier tamaño y en cualquier banco, has de usar el registro Y, pero la ejecución de esas instrucciones LDA.b [DP],y son muy lentas. Si quieres más velocidad, indexarías con el registro X pero con ciertas limitaciones (has de cambiar el banco de datos, y no puedes salirte de los 64KBytes de un banco)
* Para hacer código realmente rápido, es mejor que todos los accesos se hagan en la página directa. Esto implica cambiar ese registro cada bloque de código que quieras optimizar, lo cual incrementa el tamaño del código. Pero además, la página directa es sólo para el banco $00, por lo que te obliga a tener ahí la memoria RAM (por eso la SNES tiene un mirror de la memoria RAM en ese banco).
* La convención de llamada "stdcall" se podría hacer normalmente, pero "fastcall" sería imposible de implementar con más de 3 parámetros de entrada (por los tres registros que tiene).
Igual hay más cosas, pero no se me ocurren ahora y además, no soy ningún experto en C. Seguro alguien puede corregirme en esto que he dicho.

Sexy MotherFucker escribió:Juraría que @magno aclaró hace tiempo que el bus de datos externo del SA-1 seguía siendo de 8 bits... Que confirme o desmienta.

Sí, el bus de datos con la SNES sigue siendo de 8 bits, eso no puede variarse. El bus de 16 bits sólo lo usa con la RAM que lleva el cartucho, ya que ésta se usa como caché para instrucciones y para datos que procesa el SA-1. No es ningún misterio el que tenga 16 bits: simplemente para la época que se lanzó el SA-1 ya eran muy comunes y baratas este tipo de RAM (ahora dudo de si era DRAM o SRAM, tendría que mirarlo, aunque apostaría por la primera) y como se usa tanto para datos como para instrucciones, lo suyo es incrementar el ancho de banda entre procesador y RAM para no tener un cuello de botella.

EPSYLON EAGLE escribió:Esto es el Mega Drive cuando todos sus recursos se utilizan al máximo, pixelart calidad casi SNK, un colorido que podría competir contra cualquier rival, voces super nítidas, sonido top, jugabilidad furiosa, poca o ninguna ralentizacion, algo que sólo se veía usualmente en recreativas a funcionar en negrita de SEGA.


recomendable ver en HD

Una pasada, también ten en cuenta que es un juego de pantalla estática, se centra todos los recursos en mover los sprites.
No hay scrolles ni nada que consuma más recursos, con un tamaño generoso.
Otros que he ido probando y que están mejor eb snes.
Bart nightmare, más rápido en snes y con mejores gráficos y sonidos.
Rock and roll racing, Igual en velocidad, mejores gráficos y sonido.
La familia Adams, igual en velocidad, mejores gráficos y sonidos.
Soldier of fortune, muy parecidos Gráficamente, la versión megadrive se ralentiza más y van a la misma velocidad.
Seguiré probando

@titorino
No sigas, alguien va a dar el grito en el cielo.
La Snes es muy lenta para seguirle el ritmo a la mega.

@titorino en cualquier caso aclara que estás probando versiones de emulador, y temas como el sonido (especialmente en MD) deben ser cogidos con muchas pinzas.

titorino escribió:

EPSYLON EAGLE escribió:Esto es el Mega Drive cuando todos sus recursos se utilizan al máximo, pixelart calidad casi SNK, un colorido que podría competir contra cualquier rival, voces super nítidas, sonido top, jugabilidad furiosa, poca o ninguna ralentizacion, algo que sólo se veía usualmente en recreativas a funcionar en negrita de SEGA.


recomendable ver en HD

Una pasada, también ten en cuenta que es un juego de pantalla estática, se centra todos los recursos en mover los sprites.
No hay scrolles ni nada que consuma más recursos, con un tamaño generoso.

Conviene aclarar también que Xenocrisis ha sido en gran medida programado con un compilador de C, luego tampoco nos encontramos un juego que aproveche a muy bajo nivel la MD. No es ninguna crítica negativa ojo, realmente un juego de este estilo tampoco necesita reventar el hardware más allá del VDP.

blade133bo escribió:@titorino
No sigas, alguien va a dar el grito en el cielo.
La Snes es muy lenta para seguirle el ritmo a la mega.

Hay más de 250 juegos que salieron tanto en MD como en SNES. Si alguien se pica porque unos fueron mejores en una consola y otros lo fueron en la otra, es que es idiota.

Sexy MotherFucker escribió:@titorino en cualquier caso aclara que estás probando versiones de emulador, y temas como el sonido (especialmente en MD) deben ser cogidos con muchas pinzas.

No creo que haya muchas diferencias Sexy.
Los Simpsons por ejemplo faltan voces, en rock and roll racing por ejemplo cuando hablan se para la música y la música está a años luz de snes.
Voces en general peores y faltan efectos graficos, ne parece que hasta los fondos están inanimados en megadrive.
Las mismas diferencias tiene que haber entre jugar ambas versiones emuladas que ambas en hard real.
Además tengo las opciones correctamente configuradas para que se asemejen lo más posible al sonido real.
Como digo basta para ver las diferencias.
A ver si ahora ninguna versión de snes va ser mejor.
Y en concreto me ha sorprendido que algunos de los que he probado son más suaves en snes.
Teniendo en cuenta lo de las cpus.

@titorino

A ver si ahora ninguna versión de snes va ser mejor.

Que yo no lo digo por eso, sino porque llevo años haciendo comparativas entre diferentes versiones, y en ciertos detalles los emuladores muchas veces llevan al engaño. Simplemente digo que lo honesto y conveniente para ti es que aclares que no estás usando hardware real, más que nada porque puedes estar pinchando en algún sitio y luego llegará alguien a corregirte, haciéndote perder credibilidad.

Y en concreto me ha sorprendido que algunos de los que he probado son más suaves en snes.

Ya se ha hablado; dependiendo del género/entorno el trabajar a 256x224 es un alivio para la CPU de SNES, mientras que Mega Drive por contra casi siempre pinta 320x224 contra viento y marea. Añade más abundante programación en C en MD, las habilidades de los programadores, etc.

titorino escribió:

Sexy MotherFucker escribió:@titorino en cualquier caso aclara que estás probando versiones de emulador, y temas como el sonido (especialmente en MD) deben ser cogidos con muchas pinzas.

No creo que haya muchas diferencias Sexy.
Los Simpsons por ejemplo faltan voces, en rock and roll racing por ejemplo cuando hablan se para la música y la música está a años luz de snes.
Voces en general peores y faltan efectos graficos, ne parece que hasta los fondos están inanimados en megadrive.
Las mismas diferencias tiene que haber entre jugar ambas versiones emuladas que ambas en hard real.
Además tengo las opciones correctamente configuradas para que se asemejen lo más posible al sonido real.
Como digo basta para ver las diferencias.
A ver si ahora ninguna versión de snes va ser mejor.
Y en concreto me ha sorprendido que algunos de los que he probado son más suaves en snes.
Teniendo en cuenta lo de las cpus.

No puedo decir nada de esos juegos porque no los he probado. Pero si puedo decir que ninguno de ellos estaba en la lista de "los 40 juegos que quieres para Megadrive Mini". La comparación debería de hacerse con juegos importantes. Ya sea entre diferetes versiones (Aladdin, Contra, Castlevania) o el mismo juego (Street Fighter, Lion King).

Que por cierto, esto es algo muy esclarecedor y que tiene cierta lógica:

Alien soldier:
-desplazamiento: 3 frames.
-salto: 3 frames.
-disparo: 2 frames.

Gunstar heroes:
-desplazamiento: 2 frames.
-salto: 2 frames.
-disparo: 2 frames.

Lo primero que pensé es; ¿Cómo un juego posterior a Gunstar Héroes, el cual proviene de la misma compañía la cual se caracteriza por exprimir a bajo nivel todos los hardwares que toca, puede estar un pelín menos pulido que aquel? Y entonces recordé de pronto que el 75% del código de Alien Soldier está escrito básicamente por una sola persona, ya que era un proyecto paralelo muy libre sin fecha de salida, y en última instancia Treasure presionada por SEGA mandó un equipo de apoyo para que el juego estuviese terminado para una determinada fecha, luego teniendo presente esto podemos conjeturar que no dio tiempo a pulirse el código todo lo que hubiese sido deseable, máxime cuándo éste casi obra exclusiva de una sola persona.

@equidna y?
Que tendrá que ver una cosa con la otra.
A ti mo te gustan, habrá gente que si les gusten.
No es cuestión si te gusta o no, si no que son mejores por x motivos.
Que casualidad que cuando algo es mejor en snes miramos a otro lado
Y Rock and roll racing es um puto juegazo, más quisiera yo que lo hubiesen metido en cualquier mini.
@Sexy MotherFucker cuando quieran que lo. Prueben en hard real, mo creo que haya una diferencia como para inclinar la balanza rn estos casos.
Si megadrive sonara diferente, snes también.
Y es que las diferencias que digo son falta de efectos o planos, sonido que se corta ect.
No creo que jugandolo en hard real eso no pase.

Hard real, los mismos fallos que digo, además suena igual a como lo tengo.
Y los otros igual.
Añado familia Adams value.
Probaré más en caso contrario por supuesto lo pondré igual.
@Sexy MotherFucker una pregunta.
Si el resultado es mediocre en megadrive es porque no se han empleado bien?
En snes que es según tu opinión?
Que la consola se ha empleado a fondo y no da para más o el mismo caso que megadrive?
Es que me dejas un poco en duda por la manera de exponer las cosas.

@titorino cara al rendimiento la SNES tiene más taras propias en su propio diseño que la limitan respecto a Mega Drive, la cual por otro lado cuando rinde mal suele ser porque programan a muy alto nivel (alto = - aprovechamiento) la gran mayoría de veces, ambos son hechos contrastables.

No obstante por supuesto que a la Súper NES se la aprovecha fatalmente en cantidad de ocasiones, sólo necesito poner un ejemplo: CAPCOM, compañía la cual en muchos lanzamientos no se molestaba en optimizar demasiado, y en la actualidad podemos coger cosas cómo Chomakaimura, meterle un parche, y dejar en evidencia a los programadores de aquel entonces. Del mismo modo siendo justos a la SNES hay que concederle un margen de mejora en la mayor parte del catálogo, ya que casi todos los juegos emplean lo-rom, ergo el WDC funciona a 2.68 MHz en lugar de a sus potenciales 3.58 MHz la mayor parte de veces.

Si megadrive sonara diferente, snes también.

Cuidado: SNES tiende a sonar mejor en emuladores que en hardware real, mientras que la MD suele perder bastante en emulador, vamos Mega Drive y todos los sistemas que empleen síntesis FM. Por poner un ejemplo dependiendo del emulador todos aquellos que usen el driver de sonido GEMS (Aladdin, Earth Worm Jim, etc), sufren de conocidos bugs emulados, y mucha gente se ha llegado a pensar que él "ppi-ppp-ppppii" clásico que suena cuando aflora el bug forma parte del juego original en MD

Así que lo dicho; yo no digo que te equivoques en eso juegos, digo que potencialmente puedes equivocarte, ya que las 16 bits, sobre todo la Mega, son muchísimo más difíciles de emular al 100% que por ejemplo una Dreamcast o PlayStation, las cuales no tienen ningún misterio.

Por eso no está de más de que aclares siempre que no usas hard real en tus comparativas, las cuales siempre habrá que coger con pinzas en cierta medida.

Juegazo el Rock 'n Roll tampoco diría. Ni es muy vistoso, ni si quiera en Snes es que vaya muy bien. La música sí, pero diría que es lo único en lo que destaca. Para mi gusto no está entre los mejores de ese estilo:

https://www.youtube.com/watch?v=fWt_cvh5lo8&t=1m45s
https://www.youtube.com/watch?v=Vu6nD4zMJv8#t=4m28s
https://www.youtube.com/watch?v=d2CN4UMUf4w#t=0m6s
https://www.youtube.com/watch?v=-9Q_1qAcM1Y#t=0m4s


@Sexy MotherFucker ¿pero realmente hay gente en plan scene que sepa programar en bajo nivel?

@robotnik16 para gustos, para mi es un juegazo, muy divertido.
Gráficamente está muy bien y sonoramente muy chulo.
De ese estilo es de los mejores.
@Sexy MotherFucker sobre el sonido, hay formas de acercarse bastante.
Y lo que te decía una diferencia que no es lo que estoy tratando.
Pon que suena diferente, que no, lo que digo es que se corta la música para poner voces, en este caso las típicas voces de mega.
Eso no lo arregla el hard real.

@robotnik16 el señor de tu avatar por ejemplo xD

Lo que sucede es que muchas veces no hace falta hilar tan fino para obtener buenos resultados. Por ejemplo en Pier Solar y Paprium se usa un buen compilador de C para casi todo, no obstante según el bigotes dijo en una de sus entrevistas para todo lo concerniente a accesos CPU>Rom, y usos concretos del DMA, se curró su propio codigo ensamblador para ganar eficiencia a bajo nivel

Los programas en C no quiere decir que tengan que ser una mierda per se, sino que simplemente no aprovechan el hardware tan a fondo cómo se podría.

Xenocrisis huele a C por casi todos lados, y pinta DIOS.

@titorino que me parece muy bien titorino, pero que si somos estrictos comparar con un emulador no es la mejor de las ideas, y siempre tendrás que manejar la posibilidad de que te puedes equivocar en algo.

@Sexy MotherFucker pero a ver.
Si te he puesto un video grabado en Hard real y pasa eso que digo.

titorino escribió:@Sexy MotherFucker pero a ver.
Si te he puesto un video grabado en Hard real y pasa eso que digo.

@Sexy MotherFucker

Así que lo dicho; yo no digo que te equivoques en esos juegos, digo que potencialmente puedes equivocarte, ya que las 16 bits, sobre todo la Mega, son muchísimo más difíciles de emular al 100% que por ejemplo una Dreamcast o PlayStation, las cuales no tienen ningún misterio.

@Sexy MotherFucker
Conclusion entonces?
Son mejores son peores, cualquier cosa que se vea mejor es que no te puedes fiar?
Porque esto mismo lo notaba en la época, tuve acceso a las dos.
Y cosas como el sonido ya se podía intuir.
De hecho se para cuando hay voces y música.
Pero bueno no quiero tampoco ponerme pesado, seguiré probando y pondré lo que veo.