Es SNES objetivamente la mejor consola de la historia?

14, 5, 6, 7, 8
@Papitxulo La demo del Sonic está chula pero no puedo a 15fps siempre jugué a sonic Pal y al pasar a NTCS a mis amigos les encantaba al igual que el Mario 64 NTCS pero el Sonic para mi en Pal está perfecto al igual que el Mario 64 NTCS es perfecto.

Señor Ventura escribió:
puch666 escribió:Recuerdo que antes de que saliera esa demo había un par de trolls que afirmaban que no era posible por el DMA y no se que más 🤣

Y @Señor Ventura batallando, poniendo gifs de The Mask para hacer entender que sí era posible (y el tiempo le dió la razón).


No es que yo dijese que si porque me diese un pálpito, es que sonic construye sus planos basándose en tiles ya instaladas en la vram, igual que el the mask, y por lo tanto ya hablamos de otras cuestiones, No se utiliza el DMA para hacer scroll en ambos juegos, y en esas condiciones estas máquinas se vuelven MUY rápidas.

De hecho, seguro que a mas de uno le volaría la cabeza descubrir que la que era rápida, era en realidad la super nintendo [sonrisa]


Este juego es sonic, el paradigma del scroll super rápido, modificado para poner a prueba cuanto aguanta la máquina... y buguea hasta crashear:
https://youtu.be/eZNK_yPFM5s?t=148

Este es el famoso vídeo del the mask, moviéndose aún mas rápido, y poniendo tres planos:
https://youtu.be/YOWaIvKbhpE?t=131



Es lo que decía de la concepción que tenemos de ciertos sesgos, que luego de alguna manera nos hacen ver problemas de rendimiento donde no los hay, o asumir que las cosas funcionan de una manera, y no pueden ser de otra (snes es lenta y parpadea con tres sprites). En el vídeo del hack del sonic no se pasa por alto el pertinente chascarrillo

"Hombre, tiene bastante aguante esta consola, ¿no?. Otras hubieran empezado ya a parpadear"
https://youtu.be/eZNK_yPFM5s?t=591

Y hombre, ejem...
https://youtu.be/Znf-fnkchBI?t=49

[sonrisa]



Dicho esto, si, la megadrive tenía mejor cpu, como es evidente... es solo que no todo está escrito, parece ser xD




Yo veo en el Sonic que hay Sprites por todos lados y en SNES está todo pegado en el plano
Yoshin escribió:@Papitxulo La demo del Sonic está chula pero no puedo a 15fps


60fps.

Yoshin escribió:Yo veo en el Sonic que hay Sprites por todos lados y en SNES está todo pegado en el plano


No es cierto, cada item que recoges se mueve hacia el marcador.

Por otra parte, hablo de la capacidad para construir y mover planos en esos juegos, no dependiendo del DMA para absolutamente nada mas que actualizar las tablas de registros del mismo, y poco mas. Un puñado de Bytes, y a correr..
@Señor Ventura obviando los ítems por supuesto me refiero al escenario en sí.

ponme un vídeo del Sonic a 60 yo la veo a 15 a causa del frameskip

En Sonic tienes movimientos de spritres con tiles en flores y palmeras con 0 y 1 para que Sonic pase por detrás o por delante. tienes también plataformas con movimiento y virguerías varias, tengo entendido que un Sprite es aquella formación de titles que tienen movimiento y en el juego de la máscara todo está dibujado como prereenderizado de mala manera es lo que pienso si tengo en cuenta la definición de Sprite y el porque son difíciles de estabilizar hackeando el juego triplicando la velocidad.

Vectorman por ejemplo lo veo más rápido a pesar de que tenga más carga gráfica, en definitiva, un escenario con vida a lo que me vengo a referir. minuto 7:30 en particular

Qué curioso. Al Mega Final Fight le restan importancia porque es un desarrollo nuevo, que aunque lo haga una sola persona y pretenda hacer el juego completo, resulta que no vale porque es posible gracias a la contribución, documentación, e investigación de muchas personas durante décadas..

Luego ponen la demo actual del Sonic, que el dev abandonó sin llegar a igualar todas las características del juego de Mega Drive, pero ya dejando claro que se encontró con limites y que no iba a seguir adelante con el proyecto. Sin embargo, este ejemplo sí que vale, supongo que para intentar demostrar que Sonic (1, 2, 3 y Knuckles) no fue una saga inalcanzable tecnicamente para SNES.

Hay que distinguir entre opinión e información. Está claro que para buscar la información real os tenéis poner a leer a los creadores originales, que para algo están accesibles; si no ellos, porque se hayan pirado, por lo menos lo que hayan dicho. Esto de quedarse con lo que deseamos, pero no es real, no creo que sea para un foro de debate, sino para un blog o para un canal particular.
Yoshin escribió:@Señor Ventura obviando los ítems por supuesto me refiero al escenario en sí.


¿Que tiene de especial?.

Yoshin escribió:En Sonic tienes movimientos de spritres con tiles en flores y palmeras con 0 y 1 para que Sonic pase por detrás o por delante. tienes también plataformas con movimiento y virguerías varias, tengo entendido que un Sprite es aquella formación de titles que tienen movimiento y en el juego de la máscara todo está dibujado como prereenderizado de mala manera es lo que pienso si tengo en cuenta la definición de Sprite y el porque son difíciles de estabilizar hackeando el juego triplicando la velocidad.

Vectorman por ejemplo lo veo más rápido a pesar de que tenga más carga gráfica, en definitiva, un escenario con vida a lo que me vengo a referir. minuto 7:30 en particular



Todos esos efectos gráficos son comunes en toda máquina que basa el dibujado de sus gráficos en un line buffer.

Snes también puede hacer eso:
https://youtu.be/7LAY4ulp63Y?t=463
Señor Ventura escribió:
Yoshin escribió:@Señor Ventura obviando los ítems por supuesto me refiero al escenario en sí.


¿Que tiene de especial?.

Yoshin escribió:En Sonic tienes movimientos de spritres con tiles en flores y palmeras con 0 y 1 para que Sonic pase por detrás o por delante. tienes también plataformas con movimiento y virguerías varias, tengo entendido que un Sprite es aquella formación de titles que tienen movimiento y en el juego de la máscara todo está dibujado como prereenderizado de mala manera es lo que pienso si tengo en cuenta la definición de Sprite y el porque son difíciles de estabilizar hackeando el juego triplicando la velocidad.

Vectorman por ejemplo lo veo más rápido a pesar de que tenga más carga gráfica, en definitiva, un escenario con vida a lo que me vengo a referir. minuto 7:30 en particular



Todos esos efectos gráficos son comunes en toda máquina que basa el dibujado de sus gráficos en un line buffer.

Snes también puede hacer eso:
https://youtu.be/7LAY4ulp63Y?t=463


yo simplemente he venido al hilo porque afirmas que el Sonic una vez que es hackeado a velocidad X3 se crashea obteniendo un resultado de sprites incompletos y lo has comparado con un juego que no utiliza sprites en el escenario, solo los típicos que tiene cualquier juego como personajes, ítems o un par de frames perdidos en el escenario dejando entrever un Sprite.

Solo te quería informar que utilizar Sprites dentro de un escenario basado en tiles es complicado de manejar al multiplicar la velocidad mediante Hacks y más siendo el primer Sonic.

Snes no tiene ningún juego que vaya tan rápido como vectorman y a su vez tenga sprites y virguerías varias, en el juego de la máscara los detalles del escenario forman parte de él en su gran mayoría, en Sonic los sprites son formaciones de titles con su lógica, ya sea movimientos en sus ejes tanto horizontal como vertical. Véase flores, palmeras, puentes, cataratas etc. Pero si estamos comparando el Sonic con el juego de la máscara yo no le veo al juego de la máscara nada remarcable aparte de los personajes en pantalla y los ítems típicos de cualquier juego (sin menospreciar su jugabilidad). Puedes ver cómo se abre alguna ventana en 3 frames y lo comparo con una flor de Sonic que se mueve en 3 frames pero mientras que Sonic 2 por ejemplo tiene una resolución de 320/480 el juego de la máscara es de 256/240 o mientras que Sonic tiene sprites gigantescos véase los cilindros, los cubos de roca en diferentes fases o el suelo de hasta 512 que no se pueden reproducir en Snes a no ser que bajes la resolución o te deshagas del fondo del escenario o multipliques sus sprites haciendo el juego injugable es que se me hace extraño que los compares con cualquier otro juego que se te ocurra. Snes lo hace bien a su manera pero no le pidas que mueva los sprites de Megadrive a su velocidad
El juego de la máscara es verdad que se mueve rápido, pero parece que todo ocurre en una caja de zapatos.
eknives escribió:El juego de la máscara es verdad que se mueve rápido, pero parece que todo ocurre en una caja de zapatos.


Eso me recuerda al Uniracers, el.cual también se ponían de ejemplo de juego rápido en SNES y luego te fijas y apenas tiene carga gráfica.
Yoshin escribió:
Señor Ventura escribió:
Yoshin escribió:@Señor Ventura obviando los ítems por supuesto me refiero al escenario en sí.


¿Que tiene de especial?.

Yoshin escribió:En Sonic tienes movimientos de spritres con tiles en flores y palmeras con 0 y 1 para que Sonic pase por detrás o por delante. tienes también plataformas con movimiento y virguerías varias, tengo entendido que un Sprite es aquella formación de titles que tienen movimiento y en el juego de la máscara todo está dibujado como prereenderizado de mala manera es lo que pienso si tengo en cuenta la definición de Sprite y el porque son difíciles de estabilizar hackeando el juego triplicando la velocidad.

Vectorman por ejemplo lo veo más rápido a pesar de que tenga más carga gráfica, en definitiva, un escenario con vida a lo que me vengo a referir. minuto 7:30 en particular



Todos esos efectos gráficos son comunes en toda máquina que basa el dibujado de sus gráficos en un line buffer.

Snes también puede hacer eso:
https://youtu.be/7LAY4ulp63Y?t=463


yo simplemente he venido al hilo porque afirmas que el Sonic una vez que es hackeado a velocidad X3 se crashea obteniendo un resultado de sprites incompletos y lo has comparado con un juego que no utiliza sprites en el escenario, solo los típicos que tiene cualquier juego como personajes, ítems o un par de frames perdidos en el escenario dejando entrever un Sprite.

Solo te quería informar que utilizar Sprites dentro de un escenario basado en tiles es complicado de manejar al multiplicar la velocidad mediante Hacks y más siendo el primer Sonic.

Snes no tiene ningún juego que vaya tan rápido como vectorman y a su vez tenga sprites y virguerías varias, en el juego de la máscara los detalles del escenario forman parte de él en su gran mayoría, en Sonic los sprites son formaciones de titles con su lógica, ya sea movimientos en sus ejes tanto horizontal como vertical. Véase flores, palmeras, puentes, cataratas etc. Pero si estamos comparando el Sonic con el juego de la máscara yo no le veo al juego de la máscara nada remarcable aparte de los personajes en pantalla y los ítems típicos de cualquier juego (sin menospreciar su jugabilidad). Puedes ver cómo se abre alguna ventana en 3 frames y lo comparo con una flor de Sonic que se mueve en 3 frames pero mientras que Sonic 2 por ejemplo tiene una resolución de 320/480 el juego de la máscara es de 256/240 o mientras que Sonic tiene sprites gigantescos véase los cilindros, los cubos de roca en diferentes fases o el suelo de hasta 512 que no se pueden reproducir en Snes a no ser que bajes la resolución o te deshagas del fondo del escenario o multipliques sus sprites haciendo el juego injugable es que se me hace extraño que los compares con cualquier otro juego que se te ocurra. Snes lo hace bien a su manera pero no le pidas que mueva los sprites de Megadrive a su velocidad

sonic 2 320x480??

Megadrive tiene el microprocesador rápido.Y para demostrarlo,lo hizo con el peor juego de sonic de 8/16 bits.
Yoshin escribió:yo simplemente he venido al hilo porque afirmas que el Sonic una vez que es hackeado a velocidad X3 se crashea obteniendo un resultado de sprites incompletos y lo has comparado con un juego que no utiliza sprites en el escenario, solo los típicos que tiene cualquier juego como personajes, ítems o un par de frames perdidos en el escenario dejando entrever un Sprite.

Solo te quería informar que utilizar Sprites dentro de un escenario basado en tiles es complicado de manejar al multiplicar la velocidad mediante Hacks y más siendo el primer Sonic.

Snes no tiene ningún juego que vaya tan rápido como vectorman y a su vez tenga sprites y virguerías varias, en el juego de la máscara los detalles del escenario forman parte de él en su gran mayoría, en Sonic los sprites son formaciones de titles con su lógica, ya sea movimientos en sus ejes tanto horizontal como vertical. Véase flores, palmeras, puentes, cataratas etc. Pero si estamos comparando el Sonic con el juego de la máscara yo no le veo al juego de la máscara nada remarcable aparte de los personajes en pantalla y los ítems típicos de cualquier juego (sin menospreciar su jugabilidad). Puedes ver cómo se abre alguna ventana en 3 frames y lo comparo con una flor de Sonic que se mueve en 3 frames pero mientras que Sonic 2 por ejemplo tiene una resolución de 320/480 el juego de la máscara es de 256/240 o mientras que Sonic tiene sprites gigantescos véase los cilindros, los cubos de roca en diferentes fases o el suelo de hasta 512 que no se pueden reproducir en Snes a no ser que bajes la resolución o te deshagas del fondo del escenario o multipliques sus sprites haciendo el juego injugable es que se me hace extraño que los compares con cualquier otro juego que se te ocurra. Snes lo hace bien a su manera pero no le pidas que mueva los sprites de Megadrive a su velocidad


Por partes.

Que sonic se buguea cuando alteras sus reglas para que se mueva mas rápido, es algo que has visto tu mismo. Sucede porque al vdp no le da tiempo a construir la información gráfica que el line buffer debe dibujar.

Y claro que the mask utiliza sprites en el escenario, lo que no se muy bien es que pretendes decir con eso, ¿que snes no puede hacerlo?.

Efectivamente los sprites usan tiles, pero cuesta entenderte. Un escenario está formado por planos, y estos a su vez por tiles, disponiendo de una tabla de atributos para determinar en que orden se utilizan para su construcción, sus coordenadas, posición, etc. Cuando existen sprites, estos están en su propio plano, con sus propios atributos en su propio registro, que en super nintendo consta de dos tablas de 512 Bytes y 32 Bytes respectivamente (se denomina OAM, y define las coordenadas, posición, tamaño del sprite x1 o x2, y otras cuestiones mas). Sprites y planos pueden moverse en conjunción con solo indicarlo en sus tablas de atributos, o hacer variaciones cuando exista alguna interacción.

Mover los sprites, así como mover los planos, es una alteración de dichas coordenadas, y es algo que realizan los sistemas gráficos sin la supervisión de los procesadores. Las cpu's solo intervienen para leer y escribir en dichas tablas, y mandarlo a la vram mediante el DMA para que el/los procesadores de vídeo hagan con eso lo que tengan que hacer.

Lo que intento decir es que es competencia del sistema gráfico, pero da la impresión de que quieres hablar de cpu's.

Y claro que snes tiene juegos que van tan rápido como vectorman, al mismo tiempo que sprites, planteas un problema que no existe. Snes tiene mejores condiciones para hacer esas "virguerías" con los planos, simplemente porque su sistema gráfico es superior.


El problema que detecto es que se tiene un sesgo tan inculcado, que cuando se dicen estas cosas es casi como si no debieran decirse, y ya va tocando aclararlo.

Interrupciones por línea, alteración de paletas de color, offset por tile, son cosas que snes hace mejor que megadrive, pero luego tenemos adicionalmente una serie de funciones propias que solo encuentras en snes (matemática de color, hdma, transformación de matrices, etc).


En el siguiente post añado algo (si tengo tiempo).
Objetivamente si ese port del Sonic os parece decente es que no habéis jugado nunca al original.

Ale, a seguir fantaseando que si la snes es tan tal o tan pascual
Enrique_NS escribió:Objetivamente si ese port del Sonic os parece decente es que no habéis jugado nunca al original.

Ale, a seguir fantaseando que si la snes es tan tal o tan pascual


Si, es justo esto. De la manera que sea snes tiene que no poder hacer lo que hace megadrive, y si se dice es como si fuese contra el orden establecido.

Megadrive tiene una cpu mejor, no solo considerablemente mas potente, sino también mas preferible a la hora de programar para ella porque es mas cómoda, por unos cuantos motivos.

Pero de ahí a que la cpu de la snes sea manca... ¿que se supone que tiene el sonic que no pueda hacerse en una snes?. Vamos a documentarlo, igual puede ser bueno para el hilo.

Cpu -> megadrive
Sprites -> 50%/50%
Planos y "efectos gráficos" sobre estos -> snes
Ancho de banda -> depende del caso.


Esta es la realidad en toda esta historia.
Enrique_NS escribió:Objetivamente si ese port del Sonic os parece decente es que no habéis jugado nunca al original.

Ale, a seguir fantaseando que si la snes es tan tal o tan pascual

Si hubieses probado la demo de SNES, no dirías lo mismo. Yo lo he hecho en hardware original, y funciona a las mil maravillas. [Ooooo]

También tengo y he jugado el Sonic original de Mega Drive para comparar (por si lo dudas :-| ).
No entiendo muy bien el empeño en ignorar al creador de la demo, para tratar de transmitir otra versión como la buena.

La realidad es que el creador de la demo dijo que la CPU de Mega Drive es entre un 40 y un 70% más rápida (o sea, hasta 3 veces más rápida, afirmación que también se negó por aquí por no querer asumir ese hecho), y que debido a ello se encontraría con problemas a la hora de tratar de igualar al original, que se sumarían a los ya presentes. Esta demo ya sufre caídas, usa más sprites para hacer lo mismo que Mega Drive por el propio diseño de SNES, etc. No somos usuarios tan casuales, como para no ver que hay una reducción de esas características evidente. Hay ciertas mejoras visuales en SNES, pero ninguna relacionada con el rendimiento, donde baja en todo.

Es destacable verlo así en SNES, de todas formas. Sería un port decente.
@gynion en el tema del 40%,se refiere en concreto a la velocidad a la que trabaja la megadrive.En el tema del 70%,a la velocidad de una neogeo.
No creo que NADIE esté diciendo que la cpu de snes trabaja a la misma frecuencia que la de megadrive.

Señor Ventura escribió:
Enrique_NS escribió:Objetivamente si ese port del Sonic os parece decente es que no habéis jugado nunca al original.

Ale, a seguir fantaseando que si la snes es tan tal o tan pascual


Si, es justo esto. De la manera que sea snes tiene que no poder hacer lo que hace megadrive, y si se dice es como si fuese contra el orden establecido.

Megadrive tiene una cpu mejor, no solo considerablemente mas potente, sino también mas preferible a la hora de programar para ella porque es mas cómoda, por unos cuantos motivos.

Pero de ahí a que la cpu de la snes sea manca... ¿que se supone que tiene el sonic que no pueda hacerse en una snes?. Vamos a documentarlo, igual puede ser bueno para el hilo.

Cpu -> megadrive
Sprites -> 50%/50%
Planos y "efectos gráficos" sobre estos -> snes
Ancho de banda -> depende del caso.


Esta es la realidad en toda esta historia.

Obviando otros aspectos,como sonido o colorido.
@mcfly

Ya, ¿y por qué no dicen directamente lo que dice el autor? sin dar versiones, y que cada uno piense con esa información.

Da la impresión de que creen que estamos en el pueblo de The Village de Shyamalan, o algo así. 😏
gynion escribió:@mcfly

Ya, ¿y por qué no dicen directamente lo que dice el autor? sin dar versiones, y que cada uno piense con esa información.

Da la impresión de que creen que estamos en el pueblo de The Village de Shyamalan, o algo así. 😏

Te vuelvo a repetir que yo no veo,donde alguien diga que la cpu de snes,sea más rápida que la de megadrive.
Sin embargo,tu afirmas que el creador de la demo,dice que la megadrive puede ser un 70%,más rápida que la snes(curiosamente la diferencia de frecuencia con neogeo).También te digo,que por ahí he leído el motorola 68000 ha llegado hasta los 20mhz.Lo que no quiere decir,que mega llega a 20mhz [beer]

En lo personal,te diré que cojer a sonic de mega,como referente de las virtudes de el motorolla aplicadas a un juego,es muy mal ejemplo.Ya que parece un cruce de correcaminos y pinball lateral,con una jugabilidad muy por debajo de su versión de 8bits,precisamente por el detalle de la velocidad,de la que tanto gusta hablar.
Me resulta más interesante el apartado items/personajes en pantalla Pero,como digo,es algo personal.
@gynion

¿Lo del 70 es un dato que no concuerda con lo que ha dicho el autor? ¿qué otros datos estás leyendo en los comentarios que no concuerden con la opinión de Tiago?
Señor Ventura escribió:
Yoshin escribió:yo simplemente he venido al hilo porque afirmas que el Sonic una vez que es hackeado a velocidad X3 se crashea obteniendo un resultado de sprites incompletos y lo has comparado con un juego que no utiliza sprites en el escenario, solo los típicos que tiene cualquier juego como personajes, ítems o un par de frames perdidos en el escenario dejando entrever un Sprite.

Solo te quería informar que utilizar Sprites dentro de un escenario basado en tiles es complicado de manejar al multiplicar la velocidad mediante Hacks y más siendo el primer Sonic.

Snes no tiene ningún juego que vaya tan rápido como vectorman y a su vez tenga sprites y virguerías varias, en el juego de la máscara los detalles del escenario forman parte de él en su gran mayoría, en Sonic los sprites son formaciones de titles con su lógica, ya sea movimientos en sus ejes tanto horizontal como vertical. Véase flores, palmeras, puentes, cataratas etc. Pero si estamos comparando el Sonic con el juego de la máscara yo no le veo al juego de la máscara nada remarcable aparte de los personajes en pantalla y los ítems típicos de cualquier juego (sin menospreciar su jugabilidad). Puedes ver cómo se abre alguna ventana en 3 frames y lo comparo con una flor de Sonic que se mueve en 3 frames pero mientras que Sonic 2 por ejemplo tiene una resolución de 320/480 el juego de la máscara es de 256/240 o mientras que Sonic tiene sprites gigantescos véase los cilindros, los cubos de roca en diferentes fases o el suelo de hasta 512 que no se pueden reproducir en Snes a no ser que bajes la resolución o te deshagas del fondo del escenario o multipliques sus sprites haciendo el juego injugable es que se me hace extraño que los compares con cualquier otro juego que se te ocurra. Snes lo hace bien a su manera pero no le pidas que mueva los sprites de Megadrive a su velocidad


Por partes.

Que sonic se buguea cuando alteras sus reglas para que se mueva mas rápido, es algo que has visto tu mismo. Sucede porque al vdp no le da tiempo a construir la información gráfica que el line buffer debe dibujar.

Y claro que the mask utiliza sprites en el escenario, lo que no se muy bien es que pretendes decir con eso, ¿que snes no puede hacerlo?.

Efectivamente los sprites usan tiles, pero cuesta entenderte. Un escenario está formado por planos, y estos a su vez por tiles, disponiendo de una tabla de atributos para determinar en que orden se utilizan para su construcción, sus coordenadas, posición, etc. Cuando existen sprites, estos están en su propio plano, con sus propios atributos en su propio registro, que en super nintendo consta de dos tablas de 512 Bytes y 32 Bytes respectivamente (se denomina OAM, y define las coordenadas, posición, tamaño del sprite x1 o x2, y otras cuestiones mas). Sprites y planos pueden moverse en conjunción con solo indicarlo en sus tablas de atributos, o hacer variaciones cuando exista alguna interacción.

Mover los sprites, así como mover los planos, es una alteración de dichas coordenadas, y es algo que realizan los sistemas gráficos sin la supervisión de los procesadores. Las cpu's solo intervienen para leer y escribir en dichas tablas, y mandarlo a la vram mediante el DMA para que el/los procesadores de vídeo hagan con eso lo que tengan que hacer.

Lo que intento decir es que es competencia del sistema gráfico, pero da la impresión de que quieres hablar de cpu's.

Y claro que snes tiene juegos que van tan rápido como vectorman, al mismo tiempo que sprites, planteas un problema que no existe. Snes tiene mejores condiciones para hacer esas "virguerías" con los planos, simplemente porque su sistema gráfico es superior.


El problema que detecto es que se tiene un sesgo tan inculcado, que cuando se dicen estas cosas es casi como si no debieran decirse, y ya va tocando aclararlo.

Interrupciones por línea, alteración de paletas de color, offset por tile, son cosas que snes hace mejor que megadrive, pero luego tenemos adicionalmente una serie de funciones propias que solo encuentras en snes (matemática de color, hdma, transformación de matrices, etc).


En el siguiente post añado algo (si tengo tiempo).


Mientras que Megadrive maneja todo tipo de tamaños de Sprites ( 8x16, 24x32, 16x32...) Snes se conforma con dos por línea a la vez de (8x8 y 16x16 por ejemplo). Mientras que para hacer a Ryu del Streer Fighter Snes utiliza 11 Sprites la Megadrive lo hace con 5. Ahora imagina la demo del Sonic que según se creador supera los 100 Sprites haciendo que la CPU colapse teniendo que sacrificar frames tanto en enemigos como en la velocidad general a causa de toda la lógica del juego que se hace mediante hardware las multiplicaciones. (El Sonic de Megadrive mediante Software) Snes como máximo puede mostrár 128 sprites contra los 80 de Megadrive pero portar un juego de Megadrive a Snes hace que ésta tenga que deshacerse de entre el 40 y el 70% de ellos para dejar a la CPU libre para todo lo demás y que la velocidad no se resiente. En cambio multiplicar la velocidad de Sonic mediante hack X2 no debería suponer ningún problema, en Snes correr el juego porteado a la velocidad de Sonic lo hace imposible. No en vano el mismo creador afirma que los siguientes niveles de Sonic no se pueden portar 1:1 debido a los sprites de 512 píxeles ya que en Snes utiliza los 8x8 y 16x16 haciendo sobrepasar los límites.

El mismo creador de la demo que está haciendo ahora un port del MegamanX a megadrive afirma que en el modo H32 la Snes utiliza 70 Sprites de 128 para mostrar a MegaMan y un enemigo gigante mientras que en Megadrive para mostrar lo mismo en el mismo modo utiliza 28 Sprites de 64

En SNES mmx ( 70 sprites utilizados de 128 )
MD mmx ( 28 sprites utilizados de 64)

Megadrive como mínimo puede utilizar el doble de Sprites sin despeinarse ya que la lógica del juego se hace a través de Software. Que Snes podía utilizar varios de sus modos para mostrar Sprites y replicar a Megadrive está sobre papel pero nadie lo ha podido realizar porque solo se puede utilizar replicando Sprites. Algún truco hay una vez traspasado el límite de Sprites pero lo que ganas lo pierdes de otra manera. Literalmente para ganar velocidad podrías utilizar el SA1 tipo como los Hacks que utiliza el Fastrom para la RAM como la demo del Sonic pero si la energía supera los límites permitidos podrías dañar algún componente con el tiempo, estariamos hablando de Overlock. Ahora con éstos datos espero que veas a lo que me refiero con el juego de la máscara y como una decisión de 2 chips para VRam en paralelo es peor que solo un chip para leer y escribir al mismo tiempo como hace la Megadrive (básicamente en Snes tendrías que duplicar el ancho de banda del bus de 16 bits para utilizar los dos a la vez (modificando Hardware), mientras que en Megadrive los 16 bits que también tiene podrías duplicarlos (de mentira) para utilizar el doble de Vram mediante frameskip (juegos poligonales sobre todo). (en Sonic por ejemplo puedes crear el doble de Anillos de los permitidos por ejemplo pongamos 64, 32 de ellos desaparecerán, pero la lógica sigue latente ya que cuando recojas los Anillos visibles aparecerán los que estaban ocultos y dispondrás siempre de 32 hasta que acabes de recoger el número 32 y descienda a 0 sin despeinarse)
gynion escribió:@gynion

¿Lo del 70 es un dato que no concuerda con lo que ha dicho el autor? ¿qué otros datos estás leyendo en los comentarios que no concuerden con la opinión de Tiago?

Hablas conmigo?
@mcfly

Sí, perdona. No revisé el error. Estaba repasando el hilo de nesdev.
@gynion de lo comentado,es el dato del 70%,el que no me cuadra(que sí,el del 40%).Puedes citarle y preguntarle,si se refiere a la capacidad real,de diferencia de velocidad,entre cpus,en ámbas consolas.O hasta donde puede llegar esa diferencia de velocidad,si cojemos las especificaciones técnicas del motorolla,sin limitarlo a la velocidad que tiene en la megadrive.
Yo no tengo el placer de conocerlo.Solo he leído comentarios suyos con traducción al español,como buenamente puedo.
@mcfly

Bueno, 40 o 70%, no es tan importante, cuando nos separa un 2% de diferencia con los monos, y ya ves la diferencia (bromas aparte). El caso es que hay un porcentaje de diferencia de velocidad y rendimiento, que notamos los jugadores y nota el desarrollador en un port para SNES del primer Sonic de Mega. A partir de ahí, mi capacidad para hacer entender esa idea está agotadísima, o bien no soy la persona indicada.
@gynion es que la verdad,entender que un supuesto 70%,equivale a 3 veces más rápido.es muy difícil de entender.3 veces más rápida que la snes,es la neogeo.
Yo no soy muy ducho en mates.Pero siempre entendí,que el doble sería un 100%,.
Dicho esto,velocidades a parte,volvamos a la idea del hilo.Si se hiciera un hilo con un enunciado cambiando solo los nombres de la consola por cualquier otra,estaríamos en la misma tesitura.Salvo que fuera de pcengine,donde solo los que ostenten el título de Lord,
nos pondrían en el sendero de la verdad.
@mcfly

2 veces, quise decir. Hoy no tengo mucha concentración en esto. Estoy matando el tiempo. Pero vamos, si lo que te interesan es la información de primera mano, ya te digo que no le des importancia al mensajero, y vete al hilo de nesdev.

Yo a los devs no tengo que preguntarles nada, a no ser que realmente tenga interés en programar. Pero para discusiones por aquí, me basto solo, esté acertado o me equivoqué.
Señor Ventura escribió:No creo que el super fx como ppu3 sirviese para lo mismo que desde el cartucho. Si es cierto que se planteó para la snes americana, pero se debió desestimar bastante rápido porque para la snes pal no se conoce ningún dato (si se llegó a plantear, o no).

Como apoyo a la cpu es vital tener acceso directo a la wram todo el tiempo que quieras, y eso es posible desde el cartucho, pero desde el sistema de vídeo los accesos deben ser mas limitados, según las dudas que he leído.

Ahora, puedes usar la vram como memoria de trabajo, y postprocesar todos los tiles que quieras, o enviar tiles sin descomprimir, y descomprimirlos en la vram, aumentando virtualmente el ancho de banda... cosas así... pero precalcular polígonos, algoritmos varios, rutinas de ia o físicas, comparar resultados para la cpu, y un considerable etcétera... pues no parece.

P.D: me he enterado que hubo un killer instinct 2 para snes completamente terminado, y que la única copia fué enviada a nintendo.

Enviarle una copia de un juego cancelado a nintendo debe ser el equivalente a meterlo en una trituradora.


Gracias por aclarárnoslo, tenía entendido que era indiferente y es un jarro de agua fría para mí, pero es bueno saber la verdad aunque no se amolde a lo que uno desea o prefiere.

Enviarle una copia de un juego cancelado a Nintendo debe ser como el chiste de la pareja de novios y McGyver.. o más letal aún..

Esta una pareja haciendo el amor y cada vez que el tio empujaba, la
mujer decia:
- si sale niño, Pepito.
Y el tio mosqueado, y empujando.
- si sale niña, Pepita.
Y el tio mosqueado y empujando.
- si sale niño, Pepito.
Y el tio más mosqueado todavía y empujando
- si sale niña , Pepita.
Total que el tio ya cabreado del todo, acaba la faena, se quita el condon, le
hace un nudo y lo tira por la ventana:
- Y si sale de esta le llamaremos McGyver.



Gynion escribió:No recuerdo ahora si he dicho eso alguna vez, si se trata de algún comentario lejano. En este hilo al menos creo que sólo comenté de pasada lo de las animaciones.

Igual las discrepancias pueden estar en la consideración que se le da a un chip de apoyo, según cada uno. Como te dije, ese mismo chip (no me refería al FX en este caso) pudo suponer un salto grande de calidad. Imagina que todos los juegos pudieran haber llevado datos comprimidos, aumentando la calidad de sonido, las animaciones y todo lo relacionado con el espacio disponible de datos, sin necesidad de chips externos.

A partir de ahí, por mi parte no encuentro motivo para reducir la importancia de la ayuda que aporta un chip así, si vas a trabajar con cartuchos de un tamaño limitado para toda la capacidad de otras características de la consola, y explotar esas características lo consideras clave. Cada pieza del hardware vale dinero. Igual la CPU o los PPU de SNES eran más baratos que ese chip; vete a saber. Si cada pieza vale y aporta, el no incluir una determinada es significativo. Puede ser por fechas, que no estuviese listo ese chip, o fuese muy caro, y tal. Sabemos de otros chips que sí existían en la fecha de diseño de la consola, y no se incluyeron.

¿Es razonable considerar que una consola solo se compone de chips gráficos y procesador, y la ayuda que aporta el resto de su hardware no debe ser considerada al mismo nivel? ¿por qué, si todo lo tengo que pagar igual? ¿acaso no tenemos que comprar una unidad de CD para PC Engine para aprovechar toda su potencia, por mucho que se diga que PCE usa el addon CD sólo como formato de datos?

Veo probable que el reto de los ingenieros no estuviese tanto en meter una CPU y gráfica muy potentes o con buenas prestaciones, sino en encontrar la arquitectura ideal, calidad-precio, que permitiese precisamente que hubiera la mínima potencia desaprovechada. De modo que cuando se insiste tanto en que la potencia de SNES no fue exprimida por las limitaciones "externas", en realidad eso para mí es un palo para la consola, la cual podía haber incluido ese chip de SFA 2 o uno similar para solventarlo. No disponer de ello, dejando características sin usar, supone un fallo enorme; al menos, solo en el caso de que pensasen explotarlas, claro. Creo que no pensaron en explotarlas, en principio, y tampoco pudieron ajustar mucho la máquina manteniendo el precio. Pero igual juegos como Sonic y lo que demuestra hicieron necesario usar chips de apoyo en juegos comercialmente estratégicos, porque de poco servirían el modo 7 y los colores frente a algunas bestias del catálogo de Mega Drive. No siempre iba a aparecer una Rare por ahí, con la burrada del DKC, o una Natsume. Hacía falta que cualquier compañía pudiera desarrollar holgadamente para la consola, también de cara a los plazos de desarrollo, especialmente en el caso de algunos juegos.

Sobre el SFA 2, tampoco tengo por qué poner en duda eso que dices, y para nada es mi intención. Es más, para SNES también está saliendo alguna demo, que veremos en qué acaba a nivel jugable:



Yo estuve a punto de pedir un juego de SNES por 24.000 pts; pero claro, eran otros tiempos, por el 93 aproximadamente, y era por ser de importación. Si no llego a ver el anuncio de que saldría pal lo hubiese pillado, sin duda. Pero un SFA 2 de SNES, a precio oficial de juego de Neo-Geo AES, en unas fechas en las que hasta la propia SNK había apostado por el CD precisamente para reducir el PVP de sus títulos, sinceramente no lo veo posible a nivel comercial; y menos teniendo en cuenta que ese mismo juego lo tenías mejoradísimo en Saturn y PSX.


Te agradezco la demo de Samurai, es una flipada :O supongo que habrán jugado con el fondo, reduciéndolo a tiles o dejándolo 'estático' (bitmap completamente plano) y que al moverse más los dos personajes podría darse un lógico flickering. Me recuerda -Señor Ventura lo comentó ayer- en cierta forma a aquella Alpha de Killer Instinct que lucía bastante más impresionante que el juego final que todos conocemos.

Por supuesto el comentario no iba dirigido hacia tí, menos aún si esa no fué tu intención unos mensajes más atrás, además lo dijeron otros compañeros hace años, tampoco pretendí per sé reducir la importancia del Chip para 'justificar' a SNES, sólo quise matizar que no ayuda en nada técnicamente... sin embargo, al mismo tiempo, fríamente, si me razonas (siendo verdad ahora que lo pienso, con gran parte de lógica), que ya es suficiente apoyo el hecho de evitar pagar 35.000 Pesetas por un cartucho de SFA 2 cuando por 9.000 lo tenías mil veces mejor en Saturn, pues.. sí, te tengo que dar la razón, lo hago de corazón y con gusto; hubiera sido tremendo poder ver numerosos juegos y otros ports Arcade con S-DD1, Chip que 'sólo' comprime la memoria, porque es cierto que podríamos haber tenido títulos equivalentes a 64 Mg a un precio mucho más económico que si hubieran llevado esa cantidad real de Megas, con la consiguiente ganancia de contenido y calidad al mínimo coste, pero te ruego me permitas, ese es otro tema (otro tipo de ayuda diferente a la que quise referirme en el post anterior) y, muy en especial, observa que explicando todo lo que has escrito admites que SNES era una bestia enjaulada, que todo el elenco de la máquina estaba limitadísimo por unas Eproms enanas y SloRom que no permitían desatar todo su potencial ni por asomo, algo que no afectaba tanto a MegaDrive al utilizar un sistema de sonido mucho menos costoso de 'alimentar' mientras gracias a su paleta de color se ahorraba a su vez mucha memoria. Sé que todo esto es bien sabido aunque algunas personas a lo largo de los años parezcan -pienso- pasarlo por alto o minimizarlo.

Como con torpeza llevo diciendo desde hace unos quince años, 'grandes poderes conllevan grandes responsabilidades'. Como tu mismo muy bien has explicado, SNES estaba mal diseñada desde el punto de vista de poseer una serie de altas capacidades a las que los cartuchos de la época no podían dar réplica para ser debidamente desplegadas y plasmadas en los juegos, principalmente esas capacidades eran en lo básico almacenar Midi/samples de sonido con calidad considerable y Nº de colores en pantalla. Bien has dicho que parece un fallo de bulto en el planteamiento de la máquina, y estoy francamente de acuerdo contigo, sea así en realidad o no. Toy Story es un buen ejemplo; la fase de conducción incluida en MegaDrive es inexistente en SN. Ambos juegos tienen 32 Mg, en MD esta fase pudo entrar por lo hablado, en SNES no cupo, sobre el papel fueron su sistema de sonido y mayor paleta de color los que lo impidieron, porque era impensable hacer un cartucho de 36 Megas para SNES encareciéndolo dos o tres mil Pesetas más de la pasta que ya de por sí costaba.

Imagen


Es destacable, ahora que entramos en la materia del coste de memoria del Nº de colores y de los samples de sonido, que la fase de conducción, en extremo meritoria, a su vez es más monocroma de lo normal junto a parca en el contenido del escenario, lo que me hace pensar en que tuvieron que apurar los 32 Mg a tope, a pesar de las virtudes de MD en ese sentido.



Por ello, insisto, te doy toda la razón si lo enfocamos de esta forma, fué un palo para la consola no disponer antes de un chip así que pudiera permitir desatar toda su capacidad sin necesidad de que los juegos costaran lo mismo que los de Neo Geo.. piénsalo, llevas tanta razón que la implementación del S-DD1 quizás hubiera cambiado el rumbo de este debate en buena medida; adiós al sonido de alcantarilla/muffled, a la falta de frames, a la repetición infinita de tiles.. en conclusión, adiós en torno al 60% de todos los defectos a los que suelen aferrarse los detractores de la máquina de forma habitual.

A nivel de ingeniería imagino que los diseñadores optaron por incluir todos esos avances tan demandantes de memoria porque aunque el tamaño de los cartuchos no iba a estar a su altura por tener un coste demasiado elevado, siempre era preferible apostar por una mayor tecnología, como una especie de 'por si acaso y porque toca'.. luego, como de nuevo bien has apuntado, puntualmente llegaron Rare y otras bestias pardas para marcar, de vez en cuando, las diferencias sacando a relucir buena parte de todos esos recursos. Por todo esto, y ahora que lo recuerdo tras años en barbecho, a la Super le hubiera venido de fábula un CD-Rom en 1991 o 1992, supongo que justo por eso (cinismo al poder), jamás pudo tenerlo operativo.

Un buen amigo pagó unas 26 o 27.000 Pesetas por SF 2 Turbo Hyper Fighting Japonés(+adaptador Honey Bee=más pastizal), fué quizás de los primeros usuarios de a pié en tener el cartucho en España, pues recuerdo que en H.C lo analizaron muchos meses después de él estar disfrutándolo..

PD, en lo personal y aunque, tratando de ser honesto, no creo que tenga demasiada relevancia en este debate, pienso y reconozco que es más meritorio Final Fight MD que Sonic en SNES, pero a su vez permitidme opinar que Sonic se muestra de fábula en SN, un poco claustrofóbico en relación a MD, cierto si estas acostumbrado a jugar al original en un monitor permanentemente pequeño (1996-2008 CRT de 19"/ 2009-2023 LCD de 20") pero hasta la temida pérdida de múltiples anillos está ejecutada con dignidad, se ralentiza un poco, y aunque sí, en MegaDrive es más fluida y espectacular, ahí queda el buen trabajo junto a imagino la posibilidad de pulir algo más el código para rascar rendimiento.

Supongo que leer mis tochos es algo así como tomarse un MaxiBon acompañado de un Cola-Cao y al rato beber un chocolate caliente, pido perdón, soy espesito, además considerando que este es un hilo troll creado por un troll, ya hice mi trabajo, que es ser una especie de sucedáneo involuntario de troll cizañero con indigencia mental.

En fin, si el primer Sonic resulta un tanto quimerístico en SNES por la CPU y otros, siempre nos quedará nuestro hombre lobo en París, o dicho de otra forma, monstruo brutal en Axelay, siendo un poco menos romanticón (quién no se consuela...)

Yoshin escribió:Mientras que Megadrive maneja todo tipo de tamaños de Sprites ( 8x16, 24x32, 16x32...) Snes se conforma con dos por línea a la vez de (8x8 y 16x16 por ejemplo). Mientras que para hacer a Ryu del Streer Fighter Snes utiliza 11 Sprites la Megadrive lo hace con 5. Ahora imagina la demo del Sonic que según se creador supera los 100 Sprites haciendo que la CPU colapse teniendo que sacrificar frames tanto en enemigos como en la velocidad general a causa de toda la lógica del juego que se hace mediante hardware las multiplicaciones. (El Sonic de Megadrive mediante Software) Snes como máximo puede mostrár 128 sprites contra los 80 de Megadrive pero portar un juego de Megadrive a Snes hace que ésta tenga que deshacerse de entre el 40 y el 70% de ellos para dejar a la CPU libre para todo lo demás y que la velocidad no se resiente. En cambio multiplicar la velocidad de Sonic mediante hack X2 no debería suponer ningún problema, en Snes correr el juego porteado a la velocidad de Sonic lo hace imposible. No en vano el mismo creador afirma que los siguientes niveles de Sonic no se pueden portar 1:1 debido a los sprites de 512 píxeles ya que en Snes utiliza los 8x8 y 16x16 haciendo sobrepasar los límites.

El mismo creador de la demo que está haciendo ahora un port del MegamanX a megadrive afirma que en el modo H32 la Snes utiliza 70 Sprites de 128 para mostrar a MegaMan y un enemigo gigante mientras que en Megadrive para mostrar lo mismo en el mismo modo utiliza 28 Sprites de 64

En SNES mmx ( 70 sprites utilizados de 128 )
MD mmx ( 28 sprites utilizados de 64)

Megadrive como mínimo puede utilizar el doble de Sprites sin despeinarse ya que la lógica del juego se hace a través de Software. Que Snes podía utilizar varios de sus modos para mostrar Sprites y replicar a Megadrive está sobre papel pero nadie lo ha podido realizar porque solo se puede utilizar replicando Sprites. Algún truco hay una vez traspasado el límite de Sprites pero lo que ganas lo pierdes de otra manera. Literalmente para ganar velocidad podrías utilizar el SA1 tipo como los Hacks que utiliza el Fastrom para la RAM como la demo del Sonic pero si la energía supera los límites permitidos podrías dañar algún componente con el tiempo, estariamos hablando de Overlock. Ahora con éstos datos espero que veas a lo que me refiero con el juego de la máscara y como una decisión de 2 chips para VRam en paralelo es peor que solo un chip para leer y escribir al mismo tiempo como hace la Megadrive (básicamente en Snes tendrías que duplicar el ancho de banda del bus de 16 bits para utilizar los dos a la vez (modificando Hardware), mientras que en Megadrive los 16 bits que también tiene podrías duplicarlos (de mentira) para utilizar el doble de Vram mediante frameskip (juegos poligonales sobre todo). (en Sonic por ejemplo puedes crear el doble de Anillos de los permitidos por ejemplo pongamos 64, 32 de ellos desaparecerán, pero la lógica sigue latente ya que cuando recojas los Anillos visibles aparecerán los que estaban ocultos y dispondrás siempre de 32 hasta que acabes de recoger el número 32 y descienda a 0 sin despeinarse)



Todo esto no tiene nada que ver con lo que estabas intentando rebatirme, pero bueno.


-Los datos de como utilizan los sprites sf2 y mm no son una demostración de máxima eficiencia. El uso de sprites en ambos juegos se puede optimizar.

-Que snes tenga que deshacerse del 70% de los anillos para que el rendimiento no se resienta es un dato sacado de la nada.

-Sonic nunca pierde 100 anillos, no puede dibujarlos (Hay formas de incrementar el número de sprites en pantalla, pero con otro tipo de diseño, sonic no permite hacer eso).

-Aumentar la velocidad del sonic alterando el valor del scroll si supone un problema, lo has visto en el vídeo.

-No existen sprites de 512 píxeles. Tampoco metasprites de 512 pixeles. Tampoco una suma de sprites de 512 píxeles.

-Que sea imposible que "snes corra el juego porteado a la velocidad de sonic", es como máximo una conjetura basada en premisas falsas, no un dato. El único dato que existe, que es la propia demo en si, demuestra precisamente lo contrario.

-Megaman X usa 70 sprites, y podría utilizar bastantes menos. Super Pang utiliza 128 sprites en pantalla, y se desperdician pocos, permitiendo una mayor eficiencia de su configuración que su competencia de la suya.

-Megadrive no puede utilizar el doble de sprites que snes, ni por línea, ni en pantalla. En algunos casos le cunde mas a la megadrive, y en otros le cunde mas a la snes.

-No entiendo la referencia de que usando modos gráficos puede usarse un truco para replicar los sprites de megadrive, pero que lo que se gana por un lado se pierde por otro.

-No se que tiene que ver utilizar un SA-1 o una fast rom para dañar algún compontente por un exceso de tensión. Utilizar un SA-1 o una fast rom está diseñado para que eso no suceda.

-Snes no permite overclockear su cpu.

-Las dos PPU's "para la vram en paralelo" no es peor que el VDP para leer y escribir, eso es un dato inventado, de hecho son procesadores mucho mas rápidos. Tampoco se puede leer y escribir al mismo tiempo, simplemente no es cierto.

-No puedes modificar el hardware para transformar el bus de datos de 8 bits a 16 bits.

-El ancho de banda no sirve de nada por encima de los resultados. Decir que la snes tiene la mitad de ancho de banda porque es de 8 bits, secillamente no es cierto. Solo tiene un 12,46% menos de ancho de banda.

-Tirar de frameskip lo pueden hacer todas las máquinas.

-Hacer desaparecer sprites en frames alternos también lo pueden hacer todas.
Señor Ventura escribió:
Yoshin escribió:Mientras que Megadrive maneja todo tipo de tamaños de Sprites ( 8x16, 24x32, 16x32...) Snes se conforma con dos por línea a la vez de (8x8 y 16x16 por ejemplo). Mientras que para hacer a Ryu del Streer Fighter Snes utiliza 11 Sprites la Megadrive lo hace con 5. Ahora imagina la demo del Sonic que según se creador supera los 100 Sprites haciendo que la CPU colapse teniendo que sacrificar frames tanto en enemigos como en la velocidad general a causa de toda la lógica del juego que se hace mediante hardware las multiplicaciones. (El Sonic de Megadrive mediante Software) Snes como máximo puede mostrár 128 sprites contra los 80 de Megadrive pero portar un juego de Megadrive a Snes hace que ésta tenga que deshacerse de entre el 40 y el 70% de ellos para dejar a la CPU libre para todo lo demás y que la velocidad no se resiente. En cambio multiplicar la velocidad de Sonic mediante hack X2 no debería suponer ningún problema, en Snes correr el juego porteado a la velocidad de Sonic lo hace imposible. No en vano el mismo creador afirma que los siguientes niveles de Sonic no se pueden portar 1:1 debido a los sprites de 512 píxeles ya que en Snes utiliza los 8x8 y 16x16 haciendo sobrepasar los límites.

El mismo creador de la demo que está haciendo ahora un port del MegamanX a megadrive afirma que en el modo H32 la Snes utiliza 70 Sprites de 128 para mostrar a MegaMan y un enemigo gigante mientras que en Megadrive para mostrar lo mismo en el mismo modo utiliza 28 Sprites de 64

En SNES mmx ( 70 sprites utilizados de 128 )
MD mmx ( 28 sprites utilizados de 64)

Megadrive como mínimo puede utilizar el doble de Sprites sin despeinarse ya que la lógica del juego se hace a través de Software. Que Snes podía utilizar varios de sus modos para mostrar Sprites y replicar a Megadrive está sobre papel pero nadie lo ha podido realizar porque solo se puede utilizar replicando Sprites. Algún truco hay una vez traspasado el límite de Sprites pero lo que ganas lo pierdes de otra manera. Literalmente para ganar velocidad podrías utilizar el SA1 tipo como los Hacks que utiliza el Fastrom para la RAM como la demo del Sonic pero si la energía supera los límites permitidos podrías dañar algún componente con el tiempo, estariamos hablando de Overlock. Ahora con éstos datos espero que veas a lo que me refiero con el juego de la máscara y como una decisión de 2 chips para VRam en paralelo es peor que solo un chip para leer y escribir al mismo tiempo como hace la Megadrive (básicamente en Snes tendrías que duplicar el ancho de banda del bus de 16 bits para utilizar los dos a la vez (modificando Hardware), mientras que en Megadrive los 16 bits que también tiene podrías duplicarlos (de mentira) para utilizar el doble de Vram mediante frameskip (juegos poligonales sobre todo). (en Sonic por ejemplo puedes crear el doble de Anillos de los permitidos por ejemplo pongamos 64, 32 de ellos desaparecerán, pero la lógica sigue latente ya que cuando recojas los Anillos visibles aparecerán los que estaban ocultos y dispondrás siempre de 32 hasta que acabes de recoger el número 32 y descienda a 0 sin despeinarse)



Todo esto no tiene nada que ver con lo que estabas intentando rebatirme, pero bueno.


-Los datos de como utilizan los sprites sf2 y mm no son una demostración de máxima eficiencia. El uso de sprites en ambos juegos se puede optimizar.

-Que snes tenga que deshacerse del 70% de los anillos para que el rendimiento no se resienta es un dato sacado de la nada.

-Sonic nunca pierde 100 anillos, no puede dibujarlos (Hay formas de incrementar el número de sprites en pantalla, pero con otro tipo de diseño, sonic no permite hacer eso).

-Aumentar la velocidad del sonic alterando el valor del scroll si supone un problema, lo has visto en el vídeo.

-No existen sprites de 512 píxeles. Tampoco metasprites de 512 pixeles. Tampoco una suma de sprites de 512 píxeles.

-Que sea imposible que "snes corra el juego porteado a la velocidad de sonic", es como máximo una conjetura basada en premisas falsas, no un dato. El único dato que existe, que es la propia demo en si, demuestra precisamente lo contrario.

-Megaman X usa 70 sprites, y podría utilizar bastantes menos. Super Pang utiliza 128 sprites en pantalla, y se desperdician pocos, permitiendo una mayor eficiencia de su configuración que su competencia de la suya.

-Megadrive no puede utilizar el doble de sprites que snes, ni por línea, ni en pantalla. En algunos casos le cunde mas a la megadrive, y en otros le cunde mas a la snes.

-No entiendo la referencia de que usando modos gráficos puede usarse un truco para replicar los sprites de megadrive, pero que lo que se gana por un lado se pierde por otro.

-No se que tiene que ver utilizar un SA-1 o una fast rom para dañar algún compontente por un exceso de tensión. Utilizar un SA-1 o una fast rom está diseñado para que eso no suceda.

-Snes no permite overclockear su cpu.

-Las dos PPU's "para la vram en paralelo" no es peor que el VDP para leer y escribir, eso es un dato inventado, de hecho son procesadores mucho mas rápidos. Tampoco se puede leer y escribir al mismo tiempo, simplemente no es cierto.

-No puedes modificar el hardware para transformar el bus de datos de 8 bits a 16 bits.

-El ancho de banda no sirve de nada por encima de los resultados. Decir que la snes tiene la mitad de ancho de banda porque es de 8 bits, secillamente no es cierto. Solo tiene un 12,46% menos de ancho de banda.

-Tirar de frameskip lo pueden hacer todas las máquinas.

-Hacer desaparecer sprites en frames alternos también lo pueden hacer todas.


Estás confundiendo mis datos que son los que aporta el creador de la demo y el Port de megamanX a Megadrive y los estás revolviendo en cosas que no tiene nada que ver junto a conceptos que no existen junto a la mezcla de modos gráficos haciendo un revoltijo que no conduce a nada en la comparación original.

En cualquier caso en el foro en inglés donde está el creador de la demo te vi posteando y no vi que le respondieras a que no existía los 512 píxeles. (aunque parecen ser bytes). El orden de factores no altera el producto [carcajad]

16x32=512

MegaDrive puede utilizar hasta 17 tamaños de Sprites (16 tamaños en pantalla)
(8×8, 8×16, 8×24, 8×32, 16×8, 16×16, 16×24, 16×32, 24×8, 24×16, 24×24, 24×32, 32×8, 32×16, 32×24, 32×32), No oficiales (64×64)

Super Nintendo solo puede utilizar 6 tamaños de Sprites (solo 2 tamaños en pantalla)
(8x8, 16x16, 32x32, 64x64), No oficiales (16x32, 32x64)

SNes solo puede utilizar 2 tipos a la vez y en la demo utiliza 8x8 y 16x16 en el nivel, en los siguientes niveles no puede hacerlo porque replicar los sprites gigantes de 512 haría sobrepasar el límite y estarías encadenado al segundo modo gráfico ya sea el de 8x8 o 16x16 deformandolo todo y sin posibilidad de hacer un port. Por eso no sale el jefe final como también tuvo que utilizar otro plano para replicar la viga de pinchos en movimiento y por eso no podrá (dicho por el) seguir con el proyecto ya que los siguientes niveles abusa de los 512 píxeles. A Snes se le da muy bien replicar píxeles sin duda(copy and paste), véase rpgs o juegos tipo puzzle.

el frameskip lo puede hacer todas claro, pero no entiendes que los 16 bits de ancho de banda en Snes es para los 2 vram dividiendo las características (vease la demo del Sonic) en cuanto al VRAM de Megadrive puedes saltarlo de un FPS a otro distinto y repetir ciclo (veaso demo de starwimg)

Los anillos en Sonic era simplemente como con el debug mode se puede hacer, la snes no puede calcular los datos de sprites latentes con la soltura de Megadrive. Y digo soltura asumiendo un juego sin carga gráfica, un juego normal sería imposible.

Claro que no se puede modificar el bus, por eso digo que sería cambiando la arquitectura y no sería la Snes que conocemos, en cambio la Megadrive puede utilizar ese ancho multiplicandolo X2 de forma alterna sin prejuicios (véase juegos poligonales) solo aprovechar la alternancia de frames. Y no, Snes no puede porque el bus lee 2 chips de VRAM y tendría que sacrificar uno de ellos o dividir sus características, es lo que tiene vivir en paralelo ya que la Snes está planteada así.

Lo del SA1 sucede porque si lo utilizas es porque la Snes no da más de si y es necesario la ayuda de ese componente, una ayuda en el caso del Sonic que puede ser hasta del triple de trabajo en comparación con Megadrive, el SA1 se puede utilizar como apoyo para descargar que es como está planteado pero cuando le pides más se calienta, y cuando otros componentes leen de este se calientan también.
@Yoshin creo que estás utilizando el traductor google.Quizás no os entendais muy bien por eso.
mcfly escribió:@Yoshin creo que estás utilizando el traductor google.Quizás no os entendais muy bien por eso.


bueno he actualizado mi último post para que se entienda mejor lo que decía, es lo que entiendo del chaval de la demo y sus multiples respuestas tanto de él como de otros usuarios en su hilo en ingles.
Yoshin escribió:Estás confundiendo mis datos que son los que aporta el creador de la demo y el Port de megamanX a Megadrive y los estás revolviendo en cosas que no tiene nada que ver junto a conceptos que no existen junto a la mezcla de modos gráficos haciendo un revoltijo que no conduce a nada en la comparación original.


Voy a ignorarte. Yo estaba hablando de una cosa muy concreta, y quien ha empezado a meter de todo sin orden ni concierto has sido tu.

No puedo responder a nada de esta forma, afirmas cosas que no son ciertas y no quieres verlo de otra manera, así que no voy a perder mi tiempo.

Mejor así (edit: no pasa nada, simplemente no tengo tiempo y al final me lío a responder, y no me lo puedo permitir xD).
La batalla campal en el patio del colegio volvió y olvidarán de llamarme?
I-rem escribió:Te agradezco la demo de Samurai, es una flipada :O supongo que habrán jugado con el fondo, reduciéndolo a tiles o dejándolo 'estático' (bitmap completamente plano) y que al moverse más los dos personajes podría darse un lógico flickering. Me recuerda -Señor Ventura lo comentó ayer- en cierta forma a aquella Alpha de Killer Instinct que lucía bastante más impresionante que el juego final que todos conocemos.


No sería el primer caso de que en un E3 una compañía presenta algo superior a lo que finalmente sale a la venta. Siendo justos, habría que saber qué dijeron exactamente cuando presentaron eso, para valorar si hubo downgrade con engaño o no.

I-rem escribió:Por supuesto el comentario no iba dirigido hacia tí, menos aún si esa no fué tu intención unos mensajes más atrás, además lo dijeron otros compañeros hace años, tampoco pretendí per sé reducir la importancia del Chip para 'justificar' a SNES, sólo quise matizar que no ayuda en nada técnicamente... sin embargo, al mismo tiempo, fríamente, si me razonas (siendo verdad ahora que lo pienso, con gran parte de lógica), que ya es suficiente apoyo el hecho de evitar pagar 35.000 Pesetas por un cartucho de SFA 2 cuando por 9.000 lo tenías mil veces mejor en Saturn, pues.. sí, te tengo que dar la razón, lo hago de corazón y con gusto; hubiera sido tremendo poder ver numerosos juegos y otros ports Arcade con S-DD1, Chip que 'sólo' comprime la memoria, porque es cierto que podríamos haber tenido títulos equivalentes a 64 Mg a un precio mucho más económico que si hubieran llevado esa cantidad real de Megas, con la consiguiente ganancia de contenido y calidad al mínimo coste, pero te ruego me permitas, ese es otro tema (otro tipo de ayuda diferente a la que quise referirme en el post anterior) y, muy en especial, observa que explicando todo lo que has escrito admites que SNES era una bestia enjaulada, que todo el elenco de la máquina estaba limitadísimo por unas Eproms enanas y SloRom que no permitían desatar todo su potencial ni por asomo, algo que no afectaba tanto a MegaDrive al utilizar un sistema de sonido mucho menos costoso de 'alimentar' mientras gracias a su paleta de color se ahorraba a su vez mucha memoria. Sé que todo esto es bien sabido aunque algunas personas a lo largo de los años parezcan -pienso- pasarlo por alto o minimizarlo.


Bueno, lo de que SNES estuviese limitadísima, y que no podía desatar todo su potencial ni por asomo, no lo comparto, teniendo en cuenta ese grado alto que le has dado a la limitación. [carcajad]

Creo que toda consola estaba autolimitada de alguna forma, pero también creo que eso no tenía por qué ser un problema. Supongo que lo adecuado era que hubiese margen de potencia suficiente, por ejemplo para que ninguna compañía necesitase ningún chip externo, al menos durante los primeros años. En el caso de Mega Drive, no tuvo ni chips hasta Virtua Racing, ni unidad CD simple para sacar toda su potencia. Todos los Sonic de la linea principal salieron sin apoyo externo, incluido el del Knuckles, y creo que tampoco tenían un tamaño especial. Igualmente en el caso de todos sus grandes juegos a lo largo de toda su historia, exceptuando al mencionado VR y a algún multi.

El permiso ni te hace falta pedirlo, compañero, porque son simples intercambios de pensamientos, y no quiero que me des la razón si realmente piensas otra cosa. En este caso, lo que pasas es que para verlo de otra forma me tendrías que poner ejemplos que conviertan en anécdota un caso como el de Sunset Riders (el que se me ha ocurrido ahora, no por nada más), y me hagan pensar sólo en SNES como consola que resultó considerablemente limitada por el tamaño de los cartuchos. Le puedes echar un ojo a las tres versiones del juego: la de SNES, la oficial de Mega Drive, y la demo que están (o estaban) haciendo para Mega Drive.

¿Crees que la gestión del sonido y la menor cantidad de colores realmente ayudó a Mega Drive con ese Sunset Riders oficial, o bien se vio seriamente perjudicada por un escaso espacio en el cartucho?

Se puede entender al menos de dos formas: o bien considerando que SNES hizo las cosas con peros pero de forma satisfactoria en general (sin duda, esa es mi opinión), normalizando el hecho de que Mega Drive destacase sobre ella en ciertos aspectos; o bien se puede considerar que los cartuchos limitados y lentos de SNES eran un fiasco y nos timaron. En verdad yo en las fastroms no veo nada más que juegos más fluidos, con menos rascadas, pero siguen siendo los mismos juegos. Eso no creo que hubiera abierto puertas tan grandes como para cambiar la situación, porque los casos de slowroms no son los únicos responsables de la sensación de menor soltura, mayor lentitud y brusquedad que Mega Drive. Pensando en positivo, puede ser simplemente que MD era muy buena en eso, sin que SNES dejase por ello ser decente o buena si se desarrollaba con mimo y tiempo suficiente (creo que el Axelay que dices al final puede ser un buen ejemplo de juego desarrollado con especial cariño y detalle).

I-rem escribió:Como con torpeza llevo diciendo desde hace unos quince años, 'grandes poderes conllevan grandes responsabilidades'. Como tu mismo muy bien has explicado, SNES estaba mal diseñada desde el punto de vista de poseer una serie de altas capacidades a las que los cartuchos de la época no podían dar réplica para ser debidamente desplegadas y plasmadas en los juegos, principalmente esas capacidades eran en lo básico almacenar Midi/samples de sonido con calidad considerable y Nº de colores en pantalla. Bien has dicho que parece un fallo de bulto en el planteamiento de la máquina, y estoy francamente de acuerdo contigo, sea así en realidad o no. Toy Story es un buen ejemplo; la fase de conducción incluida en MegaDrive es inexistente en SN. Ambos juegos tienen 32 Mg, en MD esta fase pudo entrar por lo hablado, en SNES no cupo, sobre el papel fueron su sistema de sonido y mayor paleta de color los que lo impidieron, porque era impensable hacer un cartucho de 36 Megas para SNES encareciéndolo dos o tres mil Pesetas más de la pasta que ya de por sí costaba.

Imagen


Es destacable, ahora que entramos en la materia del coste de memoria del Nº de colores y de los samples de sonido, que la fase de conducción, en extremo meritoria, a su vez es más monocroma de lo normal junto a parca en el contenido del escenario, lo que me hace pensar en que tuvieron que apurar los 32 Mg a tope, a pesar de las virtudes de MD en ese sentido.



A ver, aquí tendría que volver a la demo de Sonic para SNES, porque ciertos datos podrían explicar eso de la falta de fases (creo que se da en algún otro juego multi) en cartuchos del mismo tamaño. No digo que sea por esto, sino que lo planteo como posibilidad o incluso duda, no como afirmación:

Según dicen, el autor de la demo uso más sprites en SNES que los que necesitaba Mega Drive para hacer exactamente lo mismo. Lo que leemos a veces, sobre si las compañías que desarrollaban para SNES malgastaban sus recursos por dejadez, ojo, que igual no es cierto, y es la forma de funcionar de SNES, sin que los devs pudiesen hacer nada al respecto. Entonces, si ese mismo caso surgió también en multis, los desarrolladores no se verían unicamente limitados por el color, porque eso además no hubiera sido un problema; hubiese bastado con usar la misma cantidad de colores en ambas versiones, y SNES todavía tendría la posibilidad de lucir mejor, gracias a su enorme paleta. Tendría más sentido si el problema fuesen los sprites, que ocupasen más espacio en el caso de SNES, ya que eso tiene pinta de ser más dificil de solucionar.

Aunque también puede que sea lo que dices, y prefirieran hacer destacar a la versión de SNES por colores antes de incluir la fase faltante. Si no había algún otro problema que se me escape, claro.


I-rem escribió:Por ello, insisto, te doy toda la razón si lo enfocamos de esta forma, fué un palo para la consola no disponer antes de un chip así que pudiera permitir desatar toda su capacidad sin necesidad de que los juegos costaran lo mismo que los de Neo Geo.. piénsalo, llevas tanta razón que la implementación del S-DD1 quizás hubiera cambiado el rumbo de este debate en buena medida; adiós al sonido de alcantarilla/muffled, a la falta de frames, a la repetición infinita de tiles.. en conclusión, adiós en torno al 60% de todos los defectos a los que suelen aferrarse los detractores de la máquina de forma habitual.

A nivel de ingeniería imagino que los diseñadores optaron por incluir todos esos avances tan demandantes de memoria porque aunque el tamaño de los cartuchos no iba a estar a su altura por tener un coste demasiado elevado, siempre era preferible apostar por una mayor tecnología, como una especie de 'por si acaso y porque toca'.. luego, como de nuevo bien has apuntado, puntualmente llegaron Rare y otras bestias pardas para marcar, de vez en cuando, las diferencias sacando a relucir buena parte de todos esos recursos. Por todo esto, y ahora que lo recuerdo tras años en barbecho, a la Super le hubiera venido de fábula un CD-Rom en 1991 o 1992, supongo que justo por eso (cinismo al poder), jamás pudo tenerlo operativo.


Dentro de la consola es mejor que en un juego aislado, pero eso también hubiese multiplicado el desarrollo de esos chips y aumentado el coste de la consola, o (lo que es peor desde el punto de vista de Nintendo en este caso) hubiese reducido el beneficio. Como dices, sería una cuestión de ajuste presupuestario, mezclado con la experiencia que tuvieron con NES, la cual fueron potenciando con mejoras en los cartuchos y no tuvo rival. Es decir, que creo que a SNES no quisieron mejorarla de serie, igual que Sega no quiso mejorar la paleta de MD, pensando ambas compañías que con lo puesto era suficiente. En el caso de SNES, lo que pasa es que aguantó muy poco sin recurrir a chips; no fue como el caso de NES, ni como el de Mega Drive.

I-rem escribió:Un buen amigo pagó unas 26 o 27.000 Pesetas por SF 2 Turbo Hyper Fighting Japonés(+adaptador Honey Bee=más pastizal), fué quizás de los primeros usuarios de a pié en tener el cartucho en España, pues recuerdo que en H.C lo analizaron muchos meses después de él estar disfrutándolo..

PD, en lo personal y aunque, tratando de ser honesto, no creo que tenga demasiada relevancia en este debate, pienso y reconozco que es más meritorio Final Fight MD que Sonic en SNES, pero a su vez permitidme opinar que Sonic se muestra de fábula en SN, un poco claustrofóbico en relación a MD, cierto si estas acostumbrado a jugar al original en un monitor permanentemente pequeño (1996-2008 CRT de 19"/ 2009-2023 LCD de 20") pero hasta la temida pérdida de múltiples anillos está ejecutada con dignidad, se ralentiza un poco, y aunque sí, en MegaDrive es más fluida y espectacular, ahí queda el buen trabajo junto a imagino la posibilidad de pulir algo más el código para rascar rendimiento.

Supongo que leer mis tochos es algo así como tomarse un MaxiBon acompañado de un Cola-Cao y al rato beber un chocolate caliente, pido perdón, soy espesito, además considerando que este es un hilo troll creado por un troll, ya hice mi trabajo, que es ser una especie de sucedáneo involuntario de troll cizañero con indigencia mental.

En fin, si el primer Sonic resulta un tanto quimerístico en SNES por la CPU y otros, siempre nos quedará nuestro hombre lobo en París, o dicho de otra forma, monstruo brutal en Axelay, siendo un poco menos romanticón (quién no se consuela...)





Nada, un placer. Escribe como te apetezca, que por mi parte si puedo como hoy respondo algo más extenso, y ya. [carcajad] [beer]
Gynion escribió:No sería el primer caso de que en un E3 una compañía presenta algo superior a lo que finalmente sale a la venta. Siendo justos, habría que saber qué dijeron exactamente cuando presentaron eso, para valorar si hubo downgrade con engaño o no.


Sí, habría que verlo dentro de su contexto, creo que a veces tiraban muy hacia arriba en cuanto al tamaño de la Eprom, otras veces directamente la Demo estaba corriendo en otra plataforma distinta y más potente que la consola real.. se hacían cosillas extravagantes, o eso tengo tengo entendido. Por ejemplo, la demo de K.I podría ser quizás de una SN legítima y tirar la casa por la ventana a nivel de gráficos, pero en apariencia, a lo mejor a cambio estaban sacrificando otros aspectos para que el juego luciera tan diferente -y tan mejorado- respecto a la versión final, sacrificios que puede ser no vieron después viables de ser mantenidos, porque el juego aún no estaba listo (faltaban escenarios y personajes por incluir), o porque esa calidad tan elevada iba a repercutir luego en una falta de rendimiento en una determinada parcela, no visible en el video de esa Alpha o Beta. Por ejemplo imagina Shadow Dancer o Altered Beast de Master con el planteamiento opuesto a los sprites por software (si los hubieran enfocado como Double Dragon o Vigilante), serían mucho menos visuales y a cambio mucho más jugables, tal vez en esta demo pasase un poco esto mismo, en apariencia la demo era una maravilla, pero de haber comercializado el juego así, quizás presentara algún problema jugable, y eso en 16 Bits era menos admisible que en 8.. al margen de ser tal vez una Eprom de prueba con mayor cantidad de megas, o bien otra probabilidad; estar los 32 dirigidos en exclusiva a dos personajes 'completos' y un único escenario.


Gynion escribió:Bueno, lo de que SNES estuviese limitadísima, y que no podía desatar todo su potencial ni por asomo, no lo comparto, teniendo en cuenta ese grado alto que le has dado a la limitación. [carcajad]


Bien, pero piénsalo, ese grado alto que le he dado a la limitación fué una ingente limitación y una realidad en sí mismas [looco] el sonido de alcantarilla, los ''samples gangosos'', -definición acuñada hace años por un compañero nuestro-, y otras tantas limitaciones en exceso indeseables campaban a sus anchas por la consola, fueron rémoras permanentes que padeció Snes.. no es un, 'quién vigila al vigilante', o pretender rizar el rizo, la Super sufrió como la que más la falta de espacio en los juegos, por eso dije que ese 'desfase' entre lo que ofrece la máquina y el tamaño de las Eproms fué en cierto modo producto de su tiempo.. y también tal vez de una planificación algo errática por parte de los ingenieros.

Gynion escribió:Creo que toda consola estaba autolimitada de alguna forma, pero también creo que eso no tenía por qué ser un problema. Supongo que lo adecuado era que hubiese margen de potencia suficiente, por ejemplo para que ninguna compañía necesitase ningún chip externo, al menos durante los primeros años. En el caso de Mega Drive, no tuvo ni chips hasta Virtua Racing, ni unidad CD simple para sacar toda su potencia. Todos los Sonic de la linea principal salieron sin apoyo externo, incluido el del Knuckles, y creo que tampoco tenían un tamaño especial. Igualmente en el caso de todos sus grandes juegos a lo largo de toda su historia, exceptuando al mencionado VR y a algún multi.

El permiso ni te hace falta pedirlo, compañero, porque son simples intercambios de pensamientos, y no quiero que me des la razón si realmente piensas otra cosa. En este caso, lo que pasas es que para verlo de otra forma me tendrías que poner ejemplos que conviertan en anécdota un caso como el de Sunset Riders (el que se me ha ocurrido ahora, no por nada más), y me hagan pensar sólo en SNES como consola que resultó considerablemente limitada por el tamaño de los cartuchos. Le puedes echar un ojo a las tres versiones del juego: la de SNES, la oficial de Mega Drive, y la demo que están (o estaban) haciendo para Mega Drive.


También Mario funcionaba sin chip :Ð el detalle es que, como quise decir, SNES tiene una serie de necesidades que MegaDrive no, 'alimentarla' para que estuviera en forma y pudiera rendir era más caro que en el caso de MegaDrive, por eso pude el ejemplo de la fase de conducción en Toy History, es el mejor que puedo poner para que se me comprenda, ¿MegaDrive estaba mejor hecha en ese sentido por saber hacer más con menos?, sí, imposible negarlo, pero esa no es la realidad completa, diría es sólo una parte, la realidad bajo mi punto de vista es que SNES tenía un sistema de sonido más evolucionado que por contra presentaba el nada desdeñable problema de requerir más capacidad en Mb que el sistema de MD para poder funcionar a plenitud, era ''muy tragón'', y el precio a pagar, se la alimentara adecuadamente o no, era muy elevado en ambos casos, o te salia un truño de Midi como Death Brade, o debías ''sonar a alcantarilla'' o pagar una Eprom más grande que seguramente recortaría más de lo deseable el margen de beneficios por la venta de las copias del juego, una encrucijada que solía saldarse con Midis de baja calidad, a bajo sampleado -18 Khz-

No te dí la razón como a los locos precisamente por lo que acabo de tratar de explicar, diste un vuelco a mi planteamiento, yo nunca lo ví así, (no soy una persona con demasiada imaginación) y aunque es verdad que me vine arriba hablando contigo, creo con sinceridad que llevas mucha razón en que un S-DD1 'recurrente', bien empleado, hubiera sido de gran utilidad para quitarte el lastre a la consola por el hecho de necesitar mucha memoria para un sonido correcto y Nº de colores adecuado, un gran apoyo, porque si bien por sí mismo no aportaba, sí permitía quitar o aliviar cadenas a determinados aspectos técnicos de la consola que habitualmente estaban lastrados... es como, en otra analogía macarrónica de las mías, cuando Gepetto obliga a Pinocho a ir a la escuela, Pinocho mira uno de los libros y le contesta, ¡pero estas letras no se comen!, y el buen Gepetto le responde, ''no se comen, pero te darán de comer''.. el S-DD1 no ''dá de comer'' a SN, pero hubiera propiciado que la consola tuviera medios para ''comer por si misma'', para extender su capacidad sonora y, en parte, gráfica, más allá de disponer de 20 o 24 Megas en determinados juegos, ¡hubiera dispuesto de 42 a 66 Mb de manera habitual! que hubieran sido oro para afrontar determinados desarrollos. Por desgracia el Chip también tenía su propio coste extra, y creo, no existía antes de 1995.

Gynion escribió:¿Crees que la gestión del sonido y la menor cantidad de colores realmente ayudó a Mega Drive con ese Sunset Riders oficial, o bien se vio seriamente perjudicada por un escaso espacio en el cartucho?


Pienso que es una buena pregunta, porque tú mismo ejemplificas lo que ocurre cuando una consola de 16 Bits pasa un hambre canina, también en MegaDrive a pesar de su optimización. Creo utilizas un ejemplo extremo, porque no sólo el tamaño de la Eprom fué exiguo hasta decir basta, es que el juego ni siquiera está bien hecho y como resulta obvio desde hace años y ahora más gracias a la escena, MegaDrive podría haber albergado un juego infinitamente mejor, mejor incluso que la ver de Super (mayor res, más chicha en pantalla). Aunque sea en parte rebatirme a mi mismo, esta es SN con cuatro megas, Midi de baratillo un Domingo a las doce de la noche y mil carencias más, pero está resultón.. Konami no sólo utilizó una ridiculez de Mb; ni siquiera se esforzó en sacarles partido, cuando MD dá mucho juego para hacerlo.. mucho más que SN.



Gynion escribió:Se puede entender al menos de dos formas: o bien considerando que SNES hizo las cosas con peros pero de forma satisfactoria en general (sin duda, esa es mi opinión), normalizando el hecho de que Mega Drive destacase sobre ella en ciertos aspectos; o bien se puede considerar que los cartuchos limitados y lentos de SNES eran un fiasco y nos timaron. En verdad yo en las fastroms no veo nada más que juegos más fluidos, con menos rascadas, pero siguen siendo los mismos juegos. Eso no creo que hubiera abierto puertas tan grandes como para cambiar la situación, porque los casos de slowroms no son los únicos responsables de la sensación de menor soltura, mayor lentitud y brusquedad que Mega Drive. Pensando en positivo, puede ser simplemente que MD era muy buena en eso, sin que SNES dejase por ello ser decente o buena si se desarrollaba con mimo y tiempo suficiente (creo que el Axelay que dices al final puede ser un buen ejemplo de juego desarrollado con especial cariño y detalle).


Axelay es una obra de arte por muchos motivos y uno de ellos es ese, la artesanía y dedicación que tuvieron hacia la consola, mucho más considerando cuando se lanzó.. podría pasar por un juego de 1995, es orfebrería videojueguil pura, hasta las piruetas, ese saber cuando arriesgar y cuando no hacerlo, el descaro con cabeza que tuvieron para llevar al límite al sistema, que se mostrara flickering pero sin vergüenza y aportando argumentos que lo justificaran, Konami cuando destapaba el tarro de las esencias era mucha Konami, por eso me dá tanta pena que años después no supieran o pudieran adaptarse. SNES hubiera agradecido más ''Axelays'' y ''DKC'', sí, los tuvo y muy buenos, pero a su vez padeció otras producciones infernalmente malas.

Snes hizo lo que pudo.. y no, no lo veo del todo con ese planteamiento dual que expones, porque es imposible que como tal nos timaran, en aquellos años -al menos es lo que siempre nos explicaron-, los megas eran algo así como Maná mezclado con oro, Zafiros y Rubíes, es decir, la memoria era carísima y las compañías no podían afrontar facilmente utilizar más de 32 Megas sin que el precio del cartucho se disparara, de ahí que no acabe de comprender la arquitectura de SNES, que al menos a nivel de sonido -omitiré el Nº de colores-, estaba, en cuanto a nivel de requisitos, casi en otra generación posterior.

Claro, pero es que al menos en mi caso nunca he dicho lo contrario :) por supuesto que el S-DD1 hubiera sido maravilloso, pero las virtudes de MegaDrive sobre SN están ahí, nunca las he negado, registros de 32 Bits en su Motorola, un VDP excelente, ancho de banda, Bus, flexibilidad, hasta yo que no tengo ni idea puedo citar algunas de sus virtudes y decir sin pudor -aunque si con cierta melancolía-, que tras jugar Sonic en MD y hacer luego lo propio en SN me siento como cuando acabo de escuchar un vinilo y luego escucho la misma canción en CD, o como cuando escucho este gran tema tal cual era,

https://www.youtube.com/watch?v=g_ffLVMcGhE

y luego lo escucho en un sinte Midi

https://www.youtube.com/watch?v=LnrS0QzcOe0

no me refiero sólo a la música, es en general, en Mega hay más res -mas libertad-, la falta de colores se vuelve una ventaja en ciertos juegos, no sé bien porqué ni como explicarlo, quizás en parte por utilizar dithering .. en SNES algunos juegos quedan más 'sintéticos', mientras en MD son más salvajes y 'crepitosos', es el conjunto global.. no sé definirlo con palabras.. lo cierto es que jugando al catálogo de una y otra a MD se le ven varias ventajas, mientras que SN tiene otras, que en su mayoría, sí, pueden ser en conjunto mas estéticas o 'cosméticas', mientras MD es más de acción, jugabilidad y espectacularidad en la ejecución.

Gynion escribió:A ver, aquí tendría que volver a la demo de Sonic para SNES, porque ciertos datos podrían explicar eso de la falta de fases (creo que se da en algún otro juego multi) en cartuchos del mismo tamaño. No digo que sea por esto, sino que lo planteo como posibilidad o incluso duda, no como afirmación:

Según dicen, el autor de la demo uso más sprites en SNES que los que necesitaba Mega Drive para hacer exactamente lo mismo. Lo que leemos a veces, sobre si las compañías que desarrollaban para SNES malgastaban sus recursos por dejadez, ojo, que igual no es cierto, y es la forma de funcionar de SNES, sin que los devs pudiesen hacer nada al respecto. Entonces, si ese mismo caso surgió también en multis, los desarrolladores no se verían unicamente limitados por el color, porque eso además no hubiera sido un problema; hubiese bastado con usar la misma cantidad de colores en ambas versiones, y SNES todavía tendría la posibilidad de lucir mejor, gracias a su enorme paleta. Tendría más sentido si el problema fuesen los sprites, que ocupasen más espacio en el caso de SNES, ya que eso tiene pinta de ser más dificil de solucionar.

Aunque también puede que sea lo que dices, y prefirieran hacer destacar a la versión de SNES por colores antes de incluir la fase faltante. Si no había algún otro problema que se me escape, claro.


Sí, creo que es por la rigidez de los tamaños de sprites en Super, MD tiene más libertad, es más moldeable a la hora de gestionar sprites y sus tamaños, en SN se derrocha más porque tienes que elegir entre 64 y 128 sin -por ejemplo- disponer de 32 de manera natural, y con frecuencia te ves obligado a hacer poco con mucho, yo lo visualizo como el tamaño de Cluster en los discos, (FAT32/NTSC) y el aprovechamiento, en consecuencia, del tamaño total del disco

https://usuaris.tinet.cat/pcarmona/info ... usters.htm

es desde la ignorancia mi forma de ilustrarlo..

Vamos vuelves a llevar razón, algunas compañias (Cof cof, Capco.. cof cof, atchoo) eran más desidiosas y en otras -muchas quizás- ocasiones era ciertamente muy complicado apurar mas, o bien requeria tanto trabajo que excedía el tiempo de desarrollo planteado por la desarrolladora, si lo rebasabas, era dinero que perdías.

Capcom, creo, es un buen ejemplo de lo que has comentado sobre el color, porque por ejemplo en Captain Commando los colores son tan horribles porque creo que, si bien tuvieron que redibujar los gráficos, diría que restaron colores respecto a CPS-1, quiero decir, adaptaron la paleta de CPS-1 a SN a saco, en lugar de utilizar una selección de color desde cero que aproveche la paleta de la consola... por fortuna la escena ya lo hizo de la manera adecuada, artesanal, pero es que de lo contrario, si vas a hacer una chufa, ¿para qué?, quizás, sólo quizás, entonces sea mejor no hacer nada.

Con la cabeza más fría, parece muy lógico y posible lo que me explicas sobre Toy History en referencia a la demo de Sonic, al margen del sonido y los colores, al ser un juego complejo, quizás la forma de trabajar con sprites de SN fué la otra parte de la causa, y de poderse saltar esa rigidez de tamaños de sprites, el tiempo y el esfuerzo con compensaban o directamente eran imposibles. Recuerdo que esto se debatió hace años en el foro.

Gynion escribió:Dentro de la consola es mejor que en un juego aislado, pero eso también hubiese multiplicado el desarrollo de esos chips y aumentado el coste de la consola, o (lo que es peor desde el punto de vista de Nintendo en este caso) hubiese reducido el beneficio. Como dices, sería una cuestión de ajuste presupuestario, mezclado con la experiencia que tuvieron con NES, la cual fueron potenciando con mejoras en los cartuchos y no tuvo rival. Es decir, que creo que a SNES no quisieron mejorarla de serie, igual que Sega no quiso mejorar la paleta de MD, pensando ambas compañías que con lo puesto era suficiente. En el caso de SNES, lo que pasa es que aguantó muy poco sin recurrir a chips; no fue como el caso de NES, ni como el de Mega Drive.


Es muy muy probable, estas máquinas fueron diseñadas pensando en recortar todo lo posible porque el enfoque de mercado era justo el opuesto que el de Neo Geo, tenían que venderse lo más baratas posible para poder llegar al público y que el parque de consolas instaladas en los hogares fuese gigantesco, eso significa recortar hasta puntos a veces críticos, e incluso acabando por demorar la salida de la consola -su comercialización-, el S-DD1 (ni hablar del resto de copros) tenía un precio, y a pesar de ser, creo, muy útil, mas de lo que nunca pensé, porque aunque parezca mentira nunca me lo planteé de esa forma, luego su rentabilidad es cuestionable desde el punto de vista de las compañías, además, hace falta que las empresas lo aprovecharan porque por tiempo y ganas pudieran hacerlo, y en última instancia, que la memoria Ram de la consola no impidiese agregar más frames o animaciones, por ejemplo la tan manida vanguardia/retaguardia de SF II,.. la demo técnica que adjuntó Señor Ventura en el hilo de novedades retro tiene por fin vanguardia/retaguardia, la res es mucho más elevada que en el juego original -que partía de la ver SNES-, así como el tamaño de los sprites, se muestra un SF II en MD muy cercano al Arcade, ¿es posible ver eso mismo en Super?, probablemente no tal cual, por la res, pero creo que demuestra que con los devs actuales y una Rom mas grande pueden hacerse virguerías que antes eran inviables por un tema económico.

Que Super muestre menos en pantalla, parezca sufrir más con explosiones, chicha en pantalla, que ''tenga resabios de input lag en determinados juegos multi donde MD parece la Paulova en sus mejores tiempos'', yo no sé a que es debido, no sé si MD es mejor o peor, y sin quitarle a MD su innegable mérito porque data de 1988, si te soy sincero cada vez que leo o participo de este tipo de debates me acaba dando un poco más igual, porque sí, recurro al topicazo, lo importante es el catálogo, y SN tiene uno de bandera que por sí mismo es capaz de encaramarla en un hipotético Top 5 o Top 7, siempre por debajo de 'las Plays' que fueron una bestialidad en todo sentido, el resto, está ahí y es innegable, ya un poco en modo abuelete, me quedaría hoy día con el hecho de observar lo complementarias que ambas máquinas resultaban, eran todo un Yin y Yang, fué algo muy curioso e irrepetible, como Leo y Cristiano en el Fútbol, como Federer y Rafa en Tenis, pero más irrepetible, porque la senda de la tecnología es la que es, y salvo hecatombe jamás retrocederá a aquel estado anterior.

Gynion escribió:Nada, un placer. Escribe como te apetezca, que por mi parte si puedo como hoy respondo algo más extenso, y ya. [carcajad] [beer]


El placer es mío, si tuviera tiempo -no lo tengo, estoy con un curso y mil problemas en casa-, respondería mucho mejor y más extenso, no era mi intención entrar debatir porque tampoco creí tener demasiado que decir, en todo caso haber respondido como quisiera me hubiera llevado horas sólo para hacer uno de los tocho-post y no me es posible (ni habría forero que soportase semejante somnífero [tomaaa]). Saludos.
La CPU de SNES ya sabemos que era lenta, pero los chips gráficos que tenía permitían efectos muy chulos. Un Super Mario Kart en 1992, es que no había nada igual en ningún sistema (diría que ni recreativo). Ya estaría empezando Virtua Racing y los polígonos en los arcade, pero era otra cosa. El Modo 7 no debería ser tan mala idea cuando para Mega CD y Saturn se preocuparon en incluir chips para poder hacer cosas de ese estilo.

En velocidad que solían ser más lentos que las recreativas/MD... pues sí, entre que la SNES era lenta, cartuchos lentos y que jugábamos los juegos en PAL a 50 Hz, pues más lentos todavía. Pero el Modo 7 era mucho Modo 7

txefoedu escribió:La CPU de SNES ya sabemos que era lenta, pero los chips gráficos que tenía permitían efectos muy chulos. Un Super Mario Kart en 1992, es que no había nada igual en ningún sistema (diría que ni recreativo). Ya estaría empezando Virtua Racing y los polígonos en los arcade, pero era otra cosa. El Modo 7 no debería ser tan mala idea cuando para Mega CD y Saturn se preocuparon en incluir chips para poder hacer cosas de ese estilo.

En velocidad que solían ser más lentos que las recreativas/MD... pues sí, entre que la SNES era lenta, cartuchos lentos y que jugábamos los juegos en PAL a 50 Hz, pues más lentos todavía. Pero el Modo 7 era mucho Modo 7


Es que eso es lo que se ha intentado explicar.La snes no es lenta.Lo es cuando limitas su procesador con una slowrom.Y eso se veía reflejado en cierto tipo de juegos.
En cuanto a la velocidad de las versiones PAL,es algo que han sufrido todas las consolas europeas,hasta lque llegó el selector de hz.
txefoedu escribió:La CPU de SNES ya sabemos que era lenta


Nada de acuerdo. Lástima que no existan benchmarks, pero puedes esperar que sea alrededor de un tercio mas lenta que la de su competencia (en el peor de los casos, es decir, como mucho).

Durante la construcción de un frame, una cpu no mantiene su rendimiento de forma constante, varía según lo que el código demande, y no digamos ya el resto de frames.

Luego sucede que la cpu no actúa sola, puede hacer uso de los multiplicadores del ppu1, aunque solo puede recibir una fracción de ese trabajo, pero igualmente es reseñable.

Si la snes es lenta, entonces todas lo son. Otra cosa es que su cpu sea mas lenta, eso si es cierto, pero no mucho mas lenta.
txefoedu escribió:La CPU de SNES ya sabemos que era lenta, pero los chips gráficos que tenía permitían efectos muy chulos. Un Super Mario Kart en 1992, es que no había nada igual en ningún sistema (diría que ni recreativo). Ya estaría empezando Virtua Racing y los polígonos en los arcade, pero era otra cosa. El Modo 7 no debería ser tan mala idea cuando para Mega CD y Saturn se preocuparon en incluir chips para poder hacer cosas de ese estilo.

En velocidad que solían ser más lentos que las recreativas/MD... pues sí, entre que la SNES era lenta, cartuchos lentos y que jugábamos los juegos en PAL a 50 Hz, pues más lentos todavía. Pero el Modo 7 era mucho Modo 7



Sí, la verdad es que el Modo 7 estaba muy bien, y era algo que diferenciaba bastante a la SNES de las demás consolas de su época.

Por otro lado, ya que se ha visto que Sonic era posible en SNES (gracias a la demo mostrada anteriormente), sería interesante investigar cómo se le podrían aplicar además las posibilidades de este modo gráfico, y así aprovechar alguna de las ventajas propias de la máquina de Nintendo en este juego. [Ooooo]
Señor Ventura escribió:
txefoedu escribió:La CPU de SNES ya sabemos que era lenta


Nada de acuerdo. Lástima que no existan benchmarks, pero puedes esperar que sea alrededor de un tercio mas lenta que la de su competencia (en el peor de los casos, es decir, como mucho).

Durante la construcción de un frame, una cpu no mantiene su rendimiento de forma constante, varía según lo que el código demande, y no digamos ya el resto de frames.

Luego sucede que la cpu no actúa sola, puede hacer uso de los multiplicadores del ppu1, aunque solo puede recibir una fracción de ese trabajo, pero igualmente es reseñable.

Si la snes es lenta, entonces todas lo son. Otra cosa es que su cpu sea mas lenta, eso si es cierto, pero no mucho mas lenta.

Pues eso, lo que dices. Que la CPU es un poco más lenta que los Motorola en la mayoría de los casos. No hay una diferencia del 100% como algunos pensarán por la diferencia de MHz, pero entre una cosa y otra teníamos juegos un pelín más lentos de "media" cuando los juegos tiraban de CPU pura y dura. Que SNES con las PPU y no digamos juegos con chips equilibraba a su modo el asunto en muchos casos... seguramente. Ahí estaba la gracia del asunto.
txefoedu escribió:Pues eso, lo que dices. Que la CPU es un poco más lenta que los Motorola en la mayoría de los casos. No hay una diferencia del 100% como algunos pensarán por la diferencia de MHz, pero entre una cosa y otra teníamos juegos un pelín más lentos de "media" cuando los juegos tiraban de CPU pura y dura. Que SNES con las PPU y no digamos juegos con chips equilibraba a su modo el asunto en muchos casos... seguramente. Ahí estaba la gracia del asunto.


Pero esa diferencia tampoco es una norma, lo que si que te da es que no te penaliza tanto cuando no optimizas. Hay mas margen.

Cuando ves el tmnt iv a dos jugadores con 8 enemigos... ¿realmente hace menos que la competencia?.

Gradius 3 fast rom, super aleste slow rom, aero fighters slow rom... son inmejorables. Thunder force 3 fast rom rinde igual que la versión megadrive.... super swiv, lo mismo, no encuentras diferencias...

Rendering ranger, ¿también parece mentira que sea una super nintendo?, es que llega un momento en que hay 800 excepciones, y así no se sostiene el argumento [+risas]
SNES en la mayoria de multis se veia y escuchaba igual o mejor que MD (hay excepciones desde luego que iban mejor en MD), y ya si hacemos un top grafico de exclusivos la SNES creo que gana por goleada.
Lord dice que PC-Engine tiene juegos más rápidos que Snes. Y un Lord es un Lord. [rtfm]
Es posible que snes sea la mas lenta de las tres, pero es una lentitud relativa. Hay condiciones bajo las que una snes aplasta a su competencia en eso, en rapidez.

Hay diseños bajo los que transferir gráficos a penas deje un 10% de tiempo de cpu, pero en snes acabar antes esa tarea y permitir un 50%.

Todo es taaaaan relativo xD
Como dato de la mejor consola objetivamente, estoy midiendo los consumos de las consolas y me he puesto la SNES con SMW (juego emblema del sistema) y en ls fase 4 de la isla de Yoshi (la anterior al primer castillo) hay un momento donde puedes pillar la estrella y correr palante pues eso hice montado en Yoshi y tiré palante "ralentizarse" es una palabra que se le queda corta y sólo habia 3 enemigos: dos peces y una bola de pinchos, más Mario montado en Yoshi con el parpadeo de la estrella. Ya por joder escupí las llamas que tenía con Yoshi al comer una tortuga y todavía ahora mientras escribo esto estoy esperando al siguiente frame.

Que seguro que usa slowrom, pero es que objetivamente hablando SMW se recibió y jugó así, no con hacks venidos de 30 años en el futuro. Y tengo dudas de que semejante ralentización desaparezca sólo con fastrom.

Evidentemente esto es una situación concreta porque hoy en día juego corriendo sin parar. De enano iba saltito a saltito calculando y a veces se me acaba el tiempo del nivel.
Ralentizaciones absurdas hay en muchos juegos de todas las plataformas. Sonic incluído.


P.D: ¿Esta?:
https://youtu.be/YkL1lf6_t_M?si=eUzAyh_vU-qRndwt


Da la impresión de que no tiene nada que con lo que hay en pantalla.
SuperPadLand escribió:Como dato de la mejor consola objetivamente, estoy midiendo los consumos de las consolas y me he puesto la SNES con SMW (juego emblema del sistema) y en ls fase 4 de la isla de Yoshi (la anterior al primer castillo) hay un momento donde puedes pillar la estrella y correr palante pues eso hice montado en Yoshi y tiré palante "ralentizarse" es una palabra que se le queda corta y sólo habia 3 enemigos: dos peces y una bola de pinchos, más Mario montado en Yoshi con el parpadeo de la estrella. Ya por joder escupí las llamas que tenía con Yoshi al comer una tortuga y todavía ahora mientras escribo esto estoy esperando al siguiente frame.

Que seguro que usa slowrom, pero es que objetivamente hablando SMW se recibió y jugó así, no con hacks venidos de 30 años en el futuro. Y tengo dudas de que semejante ralentización desaparezca sólo con fastrom.

Evidentemente esto es una situación concreta porque hoy en día juego corriendo sin parar. De enano iba saltito a saltito calculando y a veces se me acaba el tiempo del nivel.

Existe la versión.Estaría bien que lo comprobaras.
@mcfly o que lo compruebe otro por ejemplo. Que parece que soy el único del foro que prueba las cosas se primera mano.
¿smw fast rom?.

De todos modos ni a 0,5mhz debería petardear una cosa tan sencilla. Claramente se debe a algo ajeno.
@SuperPadLand
Esa ralentización no me suena, y es mi juego fetiche. Al menos en la consola original, con el cartucho pal original creo que no. Pero vamos, cualquier excusa me vale para ponerlo de nuevo y probar.
@SuperPadLand
Lo voy a probar.Una ralentización de esa índole en un juego de nintendo,no me suena.
Pero claro,pruebo pal,ntsc o versión fast??

Puedes indicar en que minuto anda el nivel?.Hará más de 25 años,que lo jugué.
399 respuestas
14, 5, 6, 7, 8