› Foros › Retro y descatalogado › Consolas clásicas
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
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
Dicho esto, si, la megadrive tenía mejor cpu, como es evidente... es solo que no todo está escrito, parece ser xD
Yoshin escribió:@Papitxulo La demo del Sonic está chula pero no puedo a 15fps
Yoshin escribió:Yo veo en el Sonic que hay Sprites por todos lados y en SNES está todo pegado en el plano
Yoshin escribió:@Señor Ventura obviando los ítems por supuesto me refiero al escenario en sí.
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
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
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.
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
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
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
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
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.
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í. 😏
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).
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?
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.
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.
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)
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.
mcfly escribió:@Yoshin creo que estás utilizando el traductor google.Quizás no os entendais muy bien por eso.
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.
I-rem escribió:Te agradezco la demo de Samurai, es una flipada 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.
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.
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.
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.
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.
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...)
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.
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.
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.
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?
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).
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.
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.
Gynion escribió:Nada, un placer. Escribe como te apetezca, que por mi parte si puedo como hoy respondo algo más extenso, y ya.
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
txefoedu escribió:La CPU de SNES ya sabemos que era 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
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.
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.
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.