Batalla campal Snes Vs Megadrive, patio de colegio On

Hay que tener en cuenta que los Sonics son juegos geniales y muy bonitos y tal, pero técnicamente no son nada del otro mundo. Está genial el motor plataformero tan currado, pero no es algo que fuerce al hardware.

A eso me refería yo, que hay un punto en que la snes no podría seguirle el ritmo, pero sonic no es ese baremo.

Y eso significa, que aunque se sacó petróleo de esos hardwares, aún nos quedó por ver su límite.

Señor Ventura escribió:En realidad no tiene ningún misterio, dibujarlo es dibujarlo, y lo que hay sobre el papel puede hacerse.

Otra cosa es que el programa consiga mediante una buena optimización que corra bien, pero el número y tamaño de sprites, y pixel fillrate por scanline, es el que es en todo caso, ya sea un programa lento y mal optimizado, o rápido y bien optimizado.

Un ejemplo de partículas (que es lo que es el tema de los anillos del sonic cuando te dan un toque):
https://www.youtube.com/watch?v=BBNllKClcgw

Por aclarar.. ¿eso es un ejemplo de que SNES puede mover efectos similares o de que SNES podría mover un Sonic con todas sus características, para no ser el equivalente al DK 99?

Es que si es lo primero tengo claro que sí (de hecho, en ningún momento lo discuto), y si es lo segundo, particularmente creo que no (a expensas de que un juego me demuestre lo contrario).

gynion escribió:Por aclarar.. ¿eso es un ejemplo de que SNES puede mover efectos similares o de que SNES podría mover un Sonic con todas sus características, para no ser el equivalente al DK 99?

Es que si es lo primero tengo claro que sí (de hecho, en ningún momento lo discuto), y si es lo segundo, particularmente creo que no (a expensas de que un juego me demuestre lo contrario).

Es un ejemplo de partículas (objetos con un cálculo de físicas), a colación de lo que sucede cuando sonic pierde los anillos, y lleva muchos encima.

P.D: Yo diría que no hay muchas cosas en sonic que no puedan moverse en una snes, de hecho solo se me ocurre una (que se atasca hasta en megadrive... el modo a dos jugadores del sonic 2).

Pues yo apuesto que no se podría hacer un Sonic en Super. Mis razones, primero porque es un juego programado por Sega muy a conciencia para demostrar las virtudes de su máquina y que nadie le pudiera toser; y porque no se vio ningún juego con esas características en ningún otro sistema (no sólo por la velocidad general, sino por todo el conjunto, tamaño de sprites, resolución, fisicas, ia's, que si los anillos, los múltiples planos de parallax, etc...).

Luego hay otra cosa, aparte de las características de la máquina, también había que tener los bemoles para programarlo, que a toro pasado todo es más sencillo...

Señor Ventura escribió:

gynion escribió:Por aclarar.. ¿eso es un ejemplo de que SNES puede mover efectos similares o de que SNES podría mover un Sonic con todas sus características, para no ser el equivalente al DK 99?

Es que si es lo primero tengo claro que sí (de hecho, en ningún momento lo discuto), y si es lo segundo, particularmente creo que no (a expensas de que un juego me demuestre lo contrario).

Es un ejemplo de partículas (objetos con un cálculo de físicas), a colación de lo que sucede cuando sonic pierde los anillos, y lleva muchos encima.

P.D: Yo diría que no hay muchas cosas en sonic que no puedan moverse en una snes, de hecho solo se me ocurre una (que se atasca hasta en megadrive... el modo a dos jugadores del sonic 2).

Lo que pasa es que tú sueles mostrar esas características aisladas, y dices: "¿ves? se puede hacer", y el meollo está en hacer el juego o la escena expuesta al completo, no en un escenario sin enemigos y sin scroll, como el ejemplo del Pang que me muestras (además, incluso diría que el efecto es mucho más pobre que el de Sonic).

Te lo digo por casos como el Super Metroid, el RR, etc.. en todos esos ejemplos que decías coincide lo mismo, que tan sólo es parcial la equivalencia con el juego de Mega expuesto.

El tema del movimiento de partículas, de la dificultad de los muchos anillos en pantalla, el que se ralentiza la mega y tal, yo creo que es más por un tema de mala optimización de detección de colisiones que por otra cosa. Tener a 10 o 20 sprites de anillos por ahí no debería suponer ningún sobreesfuerzo a la mega, ni aunque fuesen 30 o 40.

robotnik16 escribió:Pues yo apuesto que no se podría hacer un Sonic en Super. Mis razones, primero porque es un juego programado por Sega muy a conciencia para demostrar las virtudes de su máquina y que nadie le pudiera toser; y porque no se vio ningún juego con esas características en ningún otro sistema (no sólo por la velocidad general, sino por todo el conjunto, tamaño de sprites, resolución, fisicas, ia's, que si los anillos, los múltiples planos de parallax, etc...).

Luego hay otra cosa, aparte de las características de la máquina, también había que tener los bemoles para programarlo, que a toro pasado todo es más sencillo...

Si se ha visto. Mas atrás he puesto un vídeo del uniracers. Y no, megadrive da para mucho mas que un sonic.

Lo que pasa es que ves el uniracers, y visualmente no parece tanto como el sonic... pero realmente sus características (las del sonic) son: dos planos, sprites, no mas de 4 o 5 IA's simultáneas (la mayoría de las veces 2 o 3), y en ciertas ocasiones está lo de perder los anillos.

y cualquiera que entienda de que va esto te lo puede decir, en el uniracers, quitando los enemigos, te encuentras técnicamente con la misma situación... solo que dibujas sobre los tiles de una forma mucho mas simple (amén de que requiere mucho menos trabajo programar un uniracers que un sonic, por lo artístico, y por la variación de la aventura en el transcurrir de las fases).

gynion escribió:Lo que pasa es que tú sueles mostrar esas características aisladas, y dices: "¿ves? se puede hacer", y el meollo está en hacer el juego o la escena expuesta al completo, no en un escenario sin enemigos y sin scroll, como el ejemplo del Pang que me muestras (además, incluso diría que el efecto es mucho más pobre que el de Sonic).

Te lo digo por casos como el Super Metroid, el RR, etc.. en todos esos ejemplos que decías coincide lo mismo, que tan sólo es parcial la equivalencia con el juego de Mega expuesto.

El meollo no lo puede calcular a ojo nadie.

Si se habla de partículas, tienes ejemplos en megadrive y snes. Ahora, yo te digo que nada le impediría al pang de la snes mover los scrolls a la velocidad que quiera, porque de eso se encarga el sistema de vídeo sin involucrar a la cpu, y luego ya que cada uno reflexione sobre si quiere tener en cuenta ese dato, o no.

De todos modos, en el pang no solo llega a haber una cantidad de bolas muy remarcable (mas que en megadrive seguro, por fill rate, que no por capacidad para calcularlas), y también tienes IA's que interactúan con el jugador y las propias bolas, pudiendo haber varias, no se si hasta 3 o 4 tranquilamente.

Manveru Ainu escribió:El tema del movimiento de partículas, de la dificultad de los muchos anillos en pantalla, el que se ralentiza la mega y tal, yo creo que es más por un tema de mala optimización de detección de colisiones que por otra cosa. Tener a 10 o 20 sprites de anillos por ahí no debería suponer ningún sobreesfuerzo a la mega, ni aunque fuesen 30 o 40.

De hecho, creo que en el sonic 2 llega a ocupar todos los slots de la tabla OAM con la pérdida de los anillos, y no se ralentiza, ¿puede ser?.

Señor Ventura escribió:El meollo no lo puede calcular a ojo nadie.

Ahí le has dao; hacen falta juegos como ejemplos, que demuestren lo expuesto. ¿Qué me pones de ejemplo un Pang sin scroll ni enemigos?, pues te lo comparo con Sonic, tal cual es y me lo muestras; no me lo voy a imaginar con un scroll a una velocidad de la hostia, con modo 7, con cámara libre y con todo lo que pueda imaginar, porque igual la SNES no puede con mi imaginación.

recordad que el scroll no es un factor muy determinante, en estas consolas es casi gratis. Solo fuerzas la cosa si tienes que cambiar tiles del fondo al vuelo.

gynion escribió:Ahí le has dao; hacen falta juegos como ejemplos, que demuestren lo expuesto. ¿Qué me pones de ejemplo un Pang sin scroll ni enemigos?, pues te lo comparo con Sonic, tal cual es y me lo muestras; no me lo voy a imaginar con un scroll a una velocidad de la hostia, con modo 7, con cámara libre y con todo lo que pueda imaginar, porque igual la SNES no puede con mi imaginación.

Lo de la cámara libre lo has mencionado varias veces, y estás confundiendo términos.

Poner una cámara automática es algo que haces en un juego 3D para tener controlado cuántos vértices calculas, entre otras cosas... pero en un entorno 2D donde ya tienes en la VRAM todos los tiles que necesitas para construir el plano, no importa si la orden llega por el mando, o por el programa, en ambos casos el cálculo es algo que sucede ajeno a la cpu.

Estás comentiendo un error, vamos.


Scroll a velocidad de la hostia, con modo 7, y cámara libre:
https://www.youtube.com/watch?v=sqkQr89wcTc

kusfo79 escribió:recordad que el scroll no es un factor muy determinante, en estas consolas es casi gratis. Solo fuerzas la cosa si tienes que cambiar tiles del fondo al vuelo.

Es lo que llevo diciéndole desde hace tiempo, pero a mi no me hace ni caso.

El único factor que puede determinar la velocidad de scroll en un plano, es la necesidad de actualizar los tiles que lo componen, y en todo caso no sería una cuestión de cálculo, sino de ancho de banda (de tener listos los tiles a tiempo en la VRAM).

Señor Ventura escribió:Estás comentiendo un error, vamos.

Ahí te quería ver.
No se como te lo haces para concluir siempre que cometo errores; coño, pues como tú, y más veces que yo además, pero ni te lo digo constantemente, ni ahora mismo he cometido ningún error como para aciertes en esa conclusión.

Tan sólo era un evidente y sencillo sarcasmo, que venía a decir "por imaginar me puedo imaginar cualquier cosa, pero no tiene por qué ser posible en la práctica"; no se donde está el error ahí, porque es de cajón.

Señor Ventura escribió:De hecho, creo que en el sonic 2 llega a ocupar todos los slots de la tabla OAM con la pérdida de los anillos, y no se ralentiza, ¿puede ser?.

Me has picado y me ha dado por echarle un ojo al Sonic 2 mientras me lavaba los piños, y he visto que suelta 32 anillos para un total de 70 sprites simultáneamente en algún momento dado. Utiliza casi los 80 que es el tope y no se ralentiza, lo que está bastante bien

@Manveru Ainu
Una duda.. más cuadros de animación sí que consumen más recursos, ¿no? es decir, un juego más fluido (con mayor frame-rate o cuadros de animación de sprites) requerirá de mayor capacidad de procesamiento, ¿verdad?

Yo el Uniracers lo veo mucho más simple, además es un juego con un motor gráfico destinado únicamente a la velocidad y saliendo a finales de generación. Y el Pang más de lo mismo, puede que las bolas se dividan en multitud de ellas pero es que no tiene más, hasta las versiones de mirco ordenador daban un buen rendimiento es ese aspecto.Repito lo que han dicho ya por ahí, la mejor forma de verlo sería corriendo el mismo juego.

Por cierto, hace muy poco me pasé el Demolition Man de MD, el caso es que me pico la curiosidad por ver cómo era la versión de SNES (que es una costumbre que siempre hago) y ocurría algo parecido a lo que venís hablando, y es que además de contar con una sensible rebaja de la velocidad en general, en la séptima pantalla creo que era, la versión de SNES se "atascaba" que daba gusto (en esa en la que vas descendiendo a alta velocidad por una tirolina). De paso recomiendo el juego, buen run&gun.

Volviendo al Sonic, no conozco un juego de características similares en SNES que se mueva de esta forma, y teniendo en cuenta lo que siempre comenta el Sr. sexymotherfucker de la mayor resolución, fps, etc... Lo mismo me equivoco.

https://www.youtube.com/watch?v=xhcK8cRQtvI#t=21m12s

Leyendaviva escribió:

Gammenon escribió:
Igual no sería, esta claro, pero el juego ese pirata cutre del DKC de Mega Drive apunta muy bien que se podría haber hecho algo mucho más cercano al original de lo que se puede suponer a priori. Por supuesto las fases de la colmena del DKC2 y tal serían donde más se notaría la diferencia entre ambas máquinas pero yo creo que podría hacerse algo muy potable. Y con más resolución

Joder. Menuda aberración. El Donkey de mega hace sangre a la vista. Desconozco si la súper no podría mover un sonic a esa velocidad -seguro que con mejores efectos gráficos y sonido si-, pero este intento de Donkey deja en muy mal lugar las capacidades técnicas de mega... es como comparar el Max payne de pc y ps2. Es que parecen juegos distintos!

Hombre claro que luce mal, pero si unos tios en algun garaje perdido han podido hacer eso a saber con qué medios a saber qué podría hacer un equipo con experiencia en la Mega Drive, es simplemente una referencia por lo bajo

No hay nada como sonic en snes y tapoco hay nada en megadrive como la saga donkey kong,f zero y muchos exclusivos mas.
A ver si ahora resulta que la demo de donkey kong es porque esta hecha en un garaje y la de sonic de snes esta al 100% y hecha por un equipo de la ostia.
Cada consola tiene sus exclusivos y estan pensandos para la máquina que corren.

titorino escribió:A ver si ahora resulta que la demo de donkey kong es porque esta hecha en un garaje y la de sonic de snes esta al 100% y hecha por un equipo de la ostia.

El Donkey Kong de Mega Drive, aun siendo malísimo, está hecho de cero, el Sonic de Super Nintendo tan solo es un hack que cambia algunos sprites y el orden de las fases...
https://youtu.be/rVtDnyxZOZI?t=6m49s

Es lógico que estos juegos solo salieran en su consola, Sonic es la mascota de Sega y Rare era de Nintendo, no sé que problema hay con si puediera o no, si se trabajara se podría dejar algo muy decente en ambos casos, pero es obvio que nunca quedarían calcados a los originales por las diferencias técnicas de cada consola... Será que no hay ports de otros juegos en los que cada consola y cada grupo de programación se tomaba sus libertades para adaptarlos... Y de todas formas, que un port sea mejor o peor tampoco tiene que ser exclusivamente problema de la máquina, ahí de lo que más depende es de las manos y las mentes de los programadores.

titorino escribió:No hay nada como sonic en snes y tapoco hay nada en megadrive como la saga donkey kong,f zero y muchos exclusivos mas.
A ver si ahora resulta que la demo de donkey kong es porque esta hecha en un garaje y la de sonic de snes esta al 100% y hecha por un equipo de la ostia.
Cada consola tiene sus exclusivos y estan pensandos para la máquina que corren.

Está claro, cada una tiene sus juegos únicos y esa es la gracia, el caso es que se venía hablando del Sonic. De todas maneras, yo prefiero tener un downgrade gráfico a uno jugable, creo que es sabido que moviendo juegos más allá del modo 7, a la Mega no hay quien la tosa. Pongo el ejemplo del Atari ST, muchos juegos son prácticamente calcados gráficamente a los de Amiga, pero échales a andar...

SieKensou escribió:

titorino escribió: Y de todas formas, que un port sea mejor o peor tampoco tiene que ser exclusivamente problema de la máquina, ahí de lo que más depende es de las manos y las mentes de los programadores.

Eso por supuesto, lo ideal sería programar desde 0 en función del hardware, pero eso supone mucho más tiempo.

¡Hola niños!

gynion escribió:@Manveru Ainu
Una duda.. más cuadros de animación sí que consumen más recursos, ¿no? es decir, un juego más fluido (con mayor frame-rate o cuadros de animación de sprites) requerirá de mayor capacidad de procesamiento, ¿verdad?

El tener animaciones más fluidas conlleva ocupar más espacio en rom, eso es inevitable. Luego para tema uso de cpu y tal pues depende.

Si tienes muchos personajes con animaciones de ese tipo, no te van a caber en vram por lo que tendrás que estar mandando de rom/ram a vram cada frame. Entonces si es por ejemplo un beatemup, eso va a ser un límite para el número de personajes en pantalla, ya que el número de información que puedes mandar por cada frame de refresco es limitado..

Por otro lado, si es un juego como Sonic por ejemplo, donde tienes un personaje principal que puedes dopar lo que quieras, y lo demás son todo fondos u objetos simples, para la cpu dará igual si tiene 3 frames por animación o 1 millón siempre y cuando la rom te lo permita.

Manveru Ainu escribió:

gynion escribió:@Manveru Ainu
Una duda.. más cuadros de animación sí que consumen más recursos, ¿no? es decir, un juego más fluido (con mayor frame-rate o cuadros de animación de sprites) requerirá de mayor capacidad de procesamiento, ¿verdad?

El tener animaciones más fluidas conlleva ocupar más espacio en rom, eso es inevitable. Luego para tema uso de cpu y tal pues depende.

Si tienes muchos personajes con animaciones de ese tipo, no te van a caber en vram por lo que tendrás que estar mandando de rom/ram a vram cada frame. Entonces si es por ejemplo un beatemup, eso va a ser un límite para el número de personajes en pantalla, ya que el número de información que puedes mandar por cada frame de refresco es limitado..

Por otro lado, si es un juego como Sonic por ejemplo, donde tienes un personaje principal que puedes dopar lo que quieras, y lo demás son todo fondos u objetos simples, para la cpu dará igual si tiene 3 frames por animación o 1 millón siempre y cuando la rom te lo permita.

Ok, gracias.
Es que uno de los puntos más negativos que le veo a SNES con respecto en Mega en muchos juegos suele ser la falta de fluidez y/o de cuadros de animación; por ejemplo, en algunos RPG de renombre, me llama la atención que los personajes tengan tan solo 2 cuadros de animación para moverse; es algo que ya en su momento no me gustaba. Por otra parte, cuando un juego pilla velocidad en SNES se nota más el bajo framerate con respecto a Megadrive; eso es algo que indudablemente influye en la experiencia jugable, y que, particularmente y al igual que los cuadros de animación de los sprites, ya noté en su momento, no sólo ahora.

El problema de las animaciones de un RPG es más cosa de espacio que de potencia. El cartucho ha de almacenar el programa, las músicas, los gráficos y en los casos de los RPG una barbaridad de texto. Si quieres ceñirte a un tamaño de cartucho (normalmente por temas económicos) entonces si pones de una cosa has de quitar de la otra. En los RPG prima el texto sobre todo lo demás y normalmente, para el tamaño de los sprites de los RPG de la época, con tres fotogramas de animación para el movimiento es suficiente. Y esto en la Super y en la Mega.

Volviendo al tema de la velocidad, los que controláis de programación soléis comentar que planos de scroll y el resto de chicha en pantalla se manejan de manera "independiente", pero es curioso que en el caso del Uniracers, que tiene una jugabilidad basada en la velocidad y con un "único sprite" en pantalla, sea un juego súper simple en cuanto a fondos, planos y demás parafernalia típica de la Snes.... No voy a negar que tengáis razón, pero cuanto menos es sospechoso que en este juego la consola no se sacara la chorra y mostrara sus típicos fuegos artificiales.

MasterDan escribió:El problema de las animaciones de un RPG es más cosa de espacio que de potencia. El cartucho ha de almacenar el programa, las músicas, los gráficos y en los casos de los RPG una barbaridad de texto. Si quieres ceñirte a un tamaño de cartucho (normalmente por temas económicos) entonces si pones de una cosa has de quitar de la otra. En los RPG prima el texto sobre todo lo demás y normalmente, para el tamaño de los sprites de los RPG de la época, con tres fotogramas de animación para el movimiento es suficiente. Y esto en la Super y en la Mega.

Claro, pero es que a lo mejor por eso se prodigaban tantos RPG en SNES, además de por ser un género que se vendía bien en su tierra (y son 17 millones de SF, creo); al igual que las aventuras gráficas en PC (en ese caso, por los problemas con el scrooll), el RPG con esas "excusas" disimularía las carencias del sistema, o facilitaría el trabajo de los desarrolladores en SNES.

Es que la falta de cuadros con respecto a Mega no sólo la noto en RPG's, sino en otros muchos juegos, y si veo uno fluido en SNES, automáticamente pienso que lo podría mover Megadrive perfectamente, aún aumentando la complejidad del juego o escena, básicamente por todo lo que he visto como jugador.
Aunque como siempre digo, no es una sentencia, ni una afirmación; estoy abierto a ver y aceptar ejemplos que me demuestren lo contrario.

Que salieran tantos RPG's diría que es un poco todo, más que carencias, este tipo de juegos explota muy bien las virtudes de la consola. Si a eso le sumas que los RPG gustan muchísimo en Japón y que la Super triunfó por aquellas tierras, pues ya tienes la ecuación.

gynion escribió:Ok, gracias.
Es que uno de los puntos más negativos que le veo a SNES con respecto en Mega en muchos juegos suele ser la falta de fluidez y/o de cuadros de animación; por ejemplo, en algunos RPG de renombre, me llama la atención que los personajes tengan tan solo 2 cuadros de animación para moverse; es algo que ya en su momento no me gustaba. Por otra parte, cuando un juego pilla velocidad en SNES se nota más el bajo framerate con respecto a Megadrive; eso es algo que indudablemente influye en la experiencia jugable, y que, particularmente y al igual que los cuadros de animación de los sprites, ya noté en su momento, no sólo ahora.

De tema técnico de la Snes no te puedo decir mucho. La cantidad de frames supongo que es un asunto de rom. Un rpg por ejemplo tiene muchos escenarios, muchos personajes buenos y malos, y por supuesto mucho texto que es importante para la rom (sin olvidar el sonido que es bastante cojonero). El tema rom siempre es jodido, si no fíjate en el incremento de texto que hubo en los jrpgs al pasar de los 16 a los 32 bits.

Por eso de la rom, todos los datos se suelen comprimir y luego se descomprimen en ram, y esta tampoco es ilimitada. Todo esto junto hace que para un género como los jrpgs donde todo son personajes pequeñitos o combates estáticos por turnos, no sea algo esencial el tener animaciones fluidas y tal.

Para otros géneros creo que esa limitación corresponde a alguna cosa que ya han comentado algunos expertos sobre el tema velocidad, anchos de banda y tal de la Snes. No se puede tener todo, si no la Snes sería una Neogeo jejeje.

gynion escribió:Es que la falta de cuadros con respecto a Mega no sólo la noto en RPG's, sino en otros muchos juegos, y si veo uno fluido en SNES, automáticamente pienso que lo podría mover Megadrive perfectamente, aún aumentando la complejidad del juego o escena, básicamente por todo lo que he visto como jugador.
Aunque como siempre digo, no es una sentencia, ni una afirmación; estoy abierto a ver y aceptar ejemplos que me demuestren lo contrario.

Has de tener en cuenta una cosa, los gráficos de super ocupan más que los mega por temas de paleta de colores. Debido a esto en el mismo espacio caben muchos menos que si fueran de megadrive. El caso más sangrante de lo que puede significar esto sería el Toy Story, el cual no tiene la fase de conducción por falta de espacio (no se puede decir que sea por otro motivo, ya que la super en temas de juegos conducción en general siempre ha tenido mejores juegos técnicamente hablando). Esto causa que muchos juegos de third-parties tengan recortes en animaciones para que quepan en un cartucho del mismo tamaño que el de la otra máquina.

MasterDan escribió:

gynion escribió:Es que la falta de cuadros con respecto a Mega no sólo la noto en RPG's, sino en otros muchos juegos, y si veo uno fluido en SNES, automáticamente pienso que lo podría mover Megadrive perfectamente, aún aumentando la complejidad del juego o escena, básicamente por todo lo que he visto como jugador.
Aunque como siempre digo, no es una sentencia, ni una afirmación; estoy abierto a ver y aceptar ejemplos que me demuestren lo contrario.

Has de tener en cuenta una cosa, los gráficos de super ocupan más que los mega por temas de paleta de colores. Debido a esto en el mismo espacio caben muchos menos que si fueran de megadrive. El caso más sangrante de lo que puede significar esto sería el Toy Story, el cual no tiene la fase de conducción por falta de espacio (no se puede decir que sea por otro motivo, ya que la super en temas de juegos conducción en general siempre ha tenido mejores juegos técnicamente hablando). Esto causa que muchos juegos de third-parties tengan recortes en animaciones para que quepan en un cartucho del mismo tamaño que el de la otra máquina.

En eso de los colores no había caído; es verdad.
De todas formas, es lo que comenta @Manveru Ainu , que no se puede tener todo, y si la falta de colores la compensaba Megadrive con más niveles o cuadros de animación en juegos exclusivos o en muchos multis, para mí era perfecto.

gynion escribió:

Señor Ventura escribió:Estás comentiendo un error, vamos.

Ahí te quería ver.
No se como te lo haces para concluir siempre que cometo errores; coño, pues como tú, y más veces que yo además, pero ni te lo digo constantemente, ni ahora mismo he cometido ningún error como para aciertes en esa conclusión.

Tan sólo era un evidente y sencillo sarcasmo, que venía a decir "por imaginar me puedo imaginar cualquier cosa, pero no tiene por qué ser posible en la práctica"; no se donde está el error ahí, porque es de cajón.

No es eso. Me estoy refiriendo al controvertido tema de la cámara libre (o precalculada) de los planos de scroll, no a la cuestión de que por detalles aislados no se puede saber si todos juntos serían viables en un juego.

Kusfo mismo te lo acaba de decir también. Formar el tileado de un scroll, y moverlo, sale casi gratis en las 16 bits. Están hechas para eso, es su punto mas fuerte, así que te aseguro que decir que un scroll automático ahorra recursos de cálculo es un error. Te lo están diciendo, vamos (y hasta donde se, kusfo no es un cualquiera).

Manveru Ainu escribió:

Señor Ventura escribió:De hecho, creo que en el sonic 2 llega a ocupar todos los slots de la tabla OAM con la pérdida de los anillos, y no se ralentiza, ¿puede ser?.

Me has picado y me ha dado por echarle un ojo al Sonic 2 mientras me lavaba los piños, y he visto que suelta 32 anillos para un total de 70 sprites simultáneamente en algún momento dado. Utiliza casi los 80 que es el tope y no se ralentiza, lo que está bastante bien

Bien, bien, eso pensaba. Si la super nes puede con un pang, la megadrive tiene que poder mostrar todos esos anillos sin problemas.

robotnik16 escribió:Yo el Uniracers lo veo mucho más simple, además es un juego con un motor gráfico destinado únicamente a la velocidad y saliendo a finales de generación. Y el Pang más de lo mismo, puede que las bolas se dividan en multitud de ellas pero es que no tiene más, hasta las versiones de mirco ordenador daban un buen rendimiento es ese aspecto.Repito lo que han dicho ya por ahí, la mejor forma de verlo sería corriendo el mismo juego.

Volviendo al Sonic, no conozco un juego de características similares en SNES que se mueva de esta forma, y teniendo en cuenta lo que siempre comenta el Sr. sexymotherfucker de la mayor resolución, fps, etc... Lo mismo me equivoco.

https://www.youtube.com/watch?v=xhcK8cRQtvI#t=21m12s

Dos cosas. Lo que se ve en el vídeo del sonic 2 que has puesto no contiene enemigos, ni tiene que centrarse en nada mas que poner a sonic sobre dos planos de scroll a toda velocidad. Es exactamente lo mismo que lo que se ve en el uniracers, solo que en este además la cpu está controlando una IA.

Cuando querais ver lo que implican estas cosas a la hora de ser procesadas, teneis que obserlo desde el prisma de continente, no del contenido. Tu ves el sonic 2 mucho mas bonito, y piensas que es mucho mas, pero siguen siendo dos planos, y los correspondientes tiles del personaje, IA's, y planos.

Precisamente, aunque no lo parezca, el vídeo que has puesto del sonic 2 es perfectamente análogo al del uniracers en términos de como entiende y procesa una máquina ambos juegos.

Sexy MotherFucker escribió:¡Hola niños!

Tu, ya te vale

robotnik16 escribió:Volviendo al tema de la velocidad, los que controláis de programación soléis comentar que planos de scroll y el resto de chicha en pantalla se manejan de manera "independiente", pero es curioso que en el caso del Uniracers, que tiene una jugabilidad basada en la velocidad y con un "único sprite" en pantalla, sea un juego súper simple en cuanto a fondos, planos y demás parafernalia típica de la Snes.... No voy a negar que tengáis razón, pero cuanto menos es sospechoso que en este juego la consola no se sacara la chorra y mostrara sus típicos fuegos artificiales.

Pues porque el uniracers se ha diseñado así. Hacer que las tiles que componen los sprites del objeto demarquen un dibujo bonito, no supone mas esfuerzo de cpu... y lo mismo para las tiles de los planos, hacer que el fondo sea fotorealista, o esa simpleza, no cambia su rendimiento (cuando el diseño de un plano no obliga a tener que andar transfiriendo tiles para actualizarlos constantemente).

La "chicha" (como dices tu), que hay en el tramo del sonic 2, y en el uniracers, es exactamente la misma.

De hecho, durante esas partes el sonic 2 el scroll se mueve de forma automática, ¿significa eso que si el scroll se tuviese que mover manualmente no podría moverse mas rápido?. La respuesta es no, da exactamente igual.

gynion escribió:En eso de los colores no había caído; es verdad.

Y no solo eso, los samples para el sonido y las músicas también ocupan mas que en megadrive.

En general la snes necesita cartuchos mas grandes para ofrecer el mismo contenido que megadrive... otras veces no se nota porque en realidad lo que se decía cuando un juego era de 16 megas, era que tenía un chip de 16 megas, o dos de 8, pero a lo mejor en megadrive se aprovechaban 12, y en snes los 16 (para ofrecer lo mismo, como digo).

Señor Ventura escribió:

gynion escribió:

Señor Ventura escribió:Estás comentiendo un error, vamos.

Ahí te quería ver.
No se como te lo haces para concluir siempre que cometo errores; coño, pues como tú, y más veces que yo además, pero ni te lo digo constantemente, ni ahora mismo he cometido ningún error como para aciertes en esa conclusión.

Tan sólo era un evidente y sencillo sarcasmo, que venía a decir "por imaginar me puedo imaginar cualquier cosa, pero no tiene por qué ser posible en la práctica"; no se donde está el error ahí, porque es de cajón.

No es eso. Me estoy refiriendo al controvertido tema de la cámara libre (o precalculada) de los planos de scroll, no a la cuestión de que por detalles aislados no se puede saber si todos juntos serían viables en un juego.

Kusfo mismo te lo acaba de decir también. Formar el tileado de un scroll, y moverlo, sale casi gratis en las 16 bits. Están hechas para eso, es su punto mas fuerte, así que te aseguro que decir que un scroll automático ahorra recursos de cálculo es un error. Te lo están diciendo, vamos (y hasta donde se, kusfo no es un cualquiera).

Es que, simple y llanamente, no he dicho la cámara libre no influya directamente en la carga de CPU; además, ya me dijiste exactamente lo mismo hace la tira de meses, y es más, el término "camara libre lo introduciste tú, mientras yo tan sólo explicaba las diferencias que veía entre TFIV y el RR que me mostraste, cuando tampoco entré en ningún momento a afirmar que eso supusiera o no una carga directa a la CPU. Sólo destacaba que, fuera una carga directa o no para la CPU, el caso es que el RR no tenía esa característica, cuando tú me la mostraste como igual.

Del mismo modo que en el aquel caso, no puedo aceptar las bolitas del Pang como ejemplo de un Sonic en SNES; no es lo mismo tirar bolitas pequeñas en un espacio cerrado, sin scroll y sobre el mismo suelo plano, a ver anillos más grandes, que caen en todas direcciones, rebotando con bordillos, plataformas diferentes, a diversos niveles de altura, a la vez que te mueves por un scroll a toda velocidad.

gynion escribió:Es que, simple y llanamente, no he dicho la cámara libre no influya directamente en la carga de CPU; además, ya me dijiste exactamente lo mismo hace la tira de meses, y es más, el término "camara libre lo introduciste tú, mientras yo tan sólo explicaba las diferencias que veía entre TFIV y el RR que me mostraste, cuando tampoco entré en ningún momento a afirmar que eso supusiera o no una carga directa a la CPU. Sólo destacaba que, fuera una carga directa o no para la CPU, el caso es que el RR no tenía esa característica, cuando tú me la mostraste como igual.

Puedes mirarlo en la búsqueda. Hablabas de la cámara automática del rendering ranger como si implicase diferencias en el rendimiento si fuese manejado por el propio jugador.

Supone exactamente lo mismo, pero bueno, ahí ya no puedo convencerte si no te valen las explicaciones. Kusfo también te lo ha dicho, y en general le puedes preguntar a quien quieras, que te dirá lo mismo.

gynion escribió:Del mismo modo que en el aquel caso, no puedo aceptar las bolitas del Pang como ejemplo de un Sonic en SNES; no es lo mismo tirar bolitas pequeñas en un espacio cerrado, sin scroll y sobre el mismo suelo plano, a ver anillos más grandes, que caen en todas direcciones, rebotando con bordillos, plataformas diferentes, a diversos niveles de altura, a la vez que te mueves por un scroll a toda velocidad.

Con esta van a ser dos veces las que te digo que las bolas del pang no significan un sonic en snes. Se habla de las físicas de los anillos de sonic, y menciono el detalle del pang.

Por lo demás, las bolas del pang también caen en todas direcciones, también rebotan en los bordillos, también en plataformas diferentes, también a diferentes alturas, y también lo hacen a mucha velocidad. No hay scroll, pero como ya te han dicho, si quisieras poner uno solo necesitas tener las tiles en la VRAM para conformar el plano que va a moverse a base de bucles.

@Señor Ventura

No, aquella vez (y te remito a la búsqueda a ti también) hablaba de la característica del RR, que tú mostraste como igual a la cámara libre del TFVI, cuando no era así. Luego, si debido a esas afirmaciones induces a errores a los demás, no es culpa mía, como comprenderás.

Por lo demás, no voy a salir de decir que un Pang rompiendo bolitas no es igual a un Sonic, y que espero ver ese Sonic (o equivalente) plausible en SNES, porque yo no lo he visto (de momento).

Por otra parte, Kusfo ha hecho una puntualización, que no he discutido ni antes ni después.

Señor Ventura escribió:

Manveru Ainu escribió:

Señor Ventura escribió:De hecho, creo que en el sonic 2 llega a ocupar todos los slots de la tabla OAM con la pérdida de los anillos, y no se ralentiza, ¿puede ser?.

Me has picado y me ha dado por echarle un ojo al Sonic 2 mientras me lavaba los piños, y he visto que suelta 32 anillos para un total de 70 sprites simultáneamente en algún momento dado. Utiliza casi los 80 que es el tope y no se ralentiza, lo que está bastante bien

Bien, bien, eso pensaba. Si la super nes puede con un pang, la megadrive tiene que poder mostrar todos esos anillos sin problemas.

En lo que sé de mega, mover +50 o 60 objetos no debe ser problema si no lo hacen con patrones supercomplejos. Lo realmente pesado en los juegos suele ser la detección de colisiones entre sprites.

Si en el Sonic 1 no se preocuparon demasiado por optimizarlo (porque un plataformas no lo necesita), cuando decidieron que al recibir un toque soltaría chorrocientos anillos se encontraron con un problema. Seguramente comprueben la colisión de cada anillo con Sonic por fuerza bruta, y por eso ralentiza.

Señor Ventura escribió:Tu, ya te vale

Ey; sabes que eres mi razón de ser en este hilo, pero no tengo ni el tiempo, ni la energía necesaria para hacerte oposición cómo te mereces.

¡2017 es nuestro año pavo, tenemos 2 debates pendientes!

Más que los colores ocupando espacio sería el formato en que se guardan no?

Snes usa planar de tipo compuesto para los sprites de 4bits (16 colores) y los tiles de 2 o 4bits que son los modos más comunes, como formato en sí es eficiente pero a la hora de comprimir esos gráficos no es tan óptimo como lo puede ser Megadrive que usa packet pixel de 4bits de forma lineal.

Juraría que algunos chips de descompresión que llevan algunos cartuchos de Snes hacen una conversión de gráficos packet pixel a planar por esto mismo.

De todas formas la consola tiene 128KB de RAM para poder usar buenos métodos de compresión y dejar cargada bastante información en el inicio de una fase, cosa que por ejemplo en PCEngine que también es planar no es tan fácil.

gynion escribió:No, aquella vez (y te remito a la búsqueda a ti también) hablaba de la característica del RR, que tú mostraste como igual a la cámara libre del TFVI, cuando no era así. Luego, si debido a esas afirmaciones induces a errores a los demás, no es culpa mía, como comprenderás.

No es así, hablabas de que tenía mas mérito el scroll del thunder force iv porque no era automático.

Un plano de scroll puede tener varias pantallas de alto, y 50 pantallas de ancho, y supone el mismo esfuerzo representarlo que un plano sin scroll, aunque te parezca mentira. y del mismo modo moverlo en una sola dirección, o en dos simultáneamente, es lo mismo... como también lo es coger un plano, dividirlo en varias secciones, y mover cada uno a una velocidad diferente. Estas máquinas están hechas para eso, no van a flojear nunca con estas tareas.

Lo que tu ves en un rendering ranger son 4 planos de scroll de varias pantallas de alto moviendose en vertical y en horizontal simultáneamente.
Lo que ves en el thund force iv son 2 planos de scroll de varias pantallas de alto moviendose en vertical y en horizontal simultáneamente.

El rendering ranger mueve la cámara automáticamente, y en el thunder force iv la mueve el jugador. Y las diferencias de rendimento en uno y otro caso son... ninguna.
Además, en ambos casos tienen instaladas en la VRAM las tiles de los planos, y por lo tanto ni siquiera dependen del ancho de banda para conformar los planos, por lo que ni siquiera se puede achacar que pueda haber alguna diferencia de rendimiento tampoco en ese sentido.

gynion escribió:Por lo demás, no voy a salir de decir que un Pang rompiendo bolitas no es igual a un Sonic, y que espero ver ese Sonic (o equivalente) plausible en SNES, porque yo no lo he visto (de momento).

Seguramente, si buscas, encontrarás cosas mas complejas que un sonic, tanto en megadrive, como en snes.

Sexy MotherFucker escribió:

Señor Ventura escribió:Tu, ya te vale

Ey; sabes que eres mi razón de ser en este hilo, pero no tengo ni el tiempo, ni la energía necesaria para hacerte oposición cómo te mereces.

¡2017 es nuestro año pavo, tenemos 2 debates pendientes!

xD

@Señor Ventura El link al Sonic era simplemente por demostrar que no hay nada así en SNES (Uniracers incluido), no es que lo ponga como una demostración de techo técnico, de hecho, parece moverse sin problema aun siendo tan rápido (seguramente por lo que dices de que no hay enemigos). Pero no hay que olvidar que Sonic es un juego cuyo motor es el de un plataformas y no un juego de velocidad como el Uniracers, con muchas otras "dificultades" técnicas con las que librar, no es sólo una recta y tira palante... Y aun así sale airoso.

Sobre lo anterior, simplemente decir que el TFIV es bastante más complejo que RR en lineas generales. Nada más que añadir a eso. Si influye o no lo del scroll vertical libre en la CPU, ni idea (si decís que no pues me imagino que será así), pero es una característica que he visto sólo en el Parodius de SNES, y a menor velocidad.

Señor Ventura escribió:

gynion escribió:Por lo demás, no voy a salir de decir que un Pang rompiendo bolitas no es igual a un Sonic, y que espero ver ese Sonic (o equivalente) plausible en SNES, porque yo no lo he visto (de momento).

Seguramente, si buscas, encontrarás cosas mas complejas que un sonic, tanto en megadrive, como en snes.

En Megadrive igual sí; no te digo que no.

Manveru Ainu escribió:Si en el Sonic 1 no se preocuparon demasiado por optimizarlo (porque un plataformas no lo necesita), cuando decidieron que al recibir un toque soltaría chorrocientos anillos se encontraron con un problema. Seguramente comprueben la colisión de cada anillo con Sonic por fuerza bruta, y por eso ralentiza.

Pues sí. El problema está en que el propio juego calcula el ángulo y posición para cada anillo perdido frame a frame (lo cual es un poco tontería puesto que el resultado es siempre el mismo), y además, cada anillo comprueba su posición constantemente para ver si está tocando el suelo y hacerlo botar de nuevo... esto multiplícalo por 32 anillos que aparecen como máximo, más los otros objetos que haya cargados en ese momento (Sonic 1 por ejemplo, carga los objetos que haya en la pantalla pero con un pequeño rango horizontalmente, sin embargo verticalmente los carga todos, aunque estén abajo del todo y Sonic arriba del todo (esto lo mejoraron en posteriores juegos de Sonic). Luego súmale que algunos objetos son más complejos y requieren más procesador, el scroll, el agua con su superficie si la hubiera, más cálculos para Sonic para comprobar si toca un objeto o el suelo.... Todo suma, y eso hace que en ocasiones (junto con lo poco optimizado del juego) pasen esas ralentizaciones... No es tan facil como algunos lo quieren hacer, y si lo es, que alguien se anime a programar un pequeño Sonic en Super Nintendo... En la Mega Drive ya sabemos que se puede (y repito que está muy mal optimizado, especialmente el primero), optimizándolo se reducirían notablemente muchas de las ralentizaciones, y que tampoco es que haya tantas... Ni que el Metal Slug funcionando en la poderosa NeoGeo no tuviera ralentizaciones .

gynion escribió:

Señor Ventura escribió:Seguramente, si buscas, encontrarás cosas mas complejas que un sonic, tanto en megadrive, como en snes.

En Megadrive igual sí; no te digo que no.

A lo mejor es que yo lo veo con muy buenos ojos, pero ya me diréis que juegos de plataformas son técnicamente mejores que el Sonic, porque no me salen las cuentas. No sé, pero para mí el Sonic es crema en todos los sentidos.

SieKensou escribió:No es tan facil como algunos lo quieren hacer, y si lo es, que alguien se anime a programar un pequeño Sonic en Super Nintendo...

Eso mismo estaba pensando yo, anda que no fueron juegos los que quisieron hacer algo parecido y si quedaron en el intento.

robotnik16 escribió:Eso mismo estaba pensando yo, anda que no fueron juegos los que quisieron hacer algo parecido y si quedaron en el intento.

Bubsy, por ejemplo.

Por cierto, ¿en cuál se mueve mejor ese juego? No es retórica eh..

Yo diría que el Dynamite headdy exige bastante más a la mega que cualquier Sonic. Sólo con los bosses... El DH también tiene niveles muy rápidos, y aunque no necesite hacer actualización de mapas como el Sonic (cosa que desconozco), no es algo que fuerce demasiado a la mega.

robotnik16 escribió:@Señor Ventura El link al Sonic era simplemente por demostrar que no hay nada así en SNES (Uniracers incluido), no es que lo ponga como una demostración de techo técnico, de hecho, parece moverse sin problema aun siendo tan rápido (seguramente por lo que dices de que no hay enemigos). Pero no hay que olvidar que Sonic es un juego cuyo motor es el de un plataformas y no un juego de velocidad como el Uniracers, con muchas otras "dificultades" técnicas con las que librar, no es sólo una recta y tira palante... Y aun así sale airoso.

Incluso con enemigos el sonic 2 podría moverse igual de rápido, o mas. El límite lo marca la optimización, de por si no debería ser una pega.

En realidad haces bien diferenciando entre el tipo de motor, porque en ambos casos es la clave. Sin embargo, no hay por qué pensar que el motor del sonic 2 sea un handicap para moverse deprisa, y que el motor del uniracer queme todo el barco para limitarse a correr, ya que en ambos casos se procesa exactamente lo mismo con respecto al fragmento que pusiste tu (incluso en el uniracer hay una IA persiguiendo al jugador).

gynion escribió:Sobre lo anterior, simplemente decir que el TFIV es bastante más complejo que RR en lineas generales. Nada más que añadir a eso. Si influye o no lo del scroll vertical libre en la CPU, ni idea (si decís que no pues me imagino que será así), pero es una característica que he visto sólo en el Parodius de SNES, y a menor velocidad.

Si es mas complejo que el rendering ranger, diría que en casi todos los aspectos es así.

Los dos planos de scroll están divididos en varios tramos con distintas prioridades que se mueven a diferentes velocidades (aunque suene complejo, no supone una carga para la cpu, pero hay que perder el tiempo en indicarlo en el código, y requiere mas dedicación programarlo, porque hay que idearlo y planificarlo). También mas tipos de scripts para el comportamiento de las naves, y en general artísticamente está mejor concebido.

Tal vez el super parodius tenga demasiado ocupada a la cpu como para mover las naves y las balas mas deprisa, pero el scroll no se ve influenciado en esto a menos que el programa llegue al punto en que ralentice su proceso... entonces si el scroll se ralentizaría. Pero no es el scroll el que causa, o requiere de cpu, sino que simplemente se ve arrastrado si la ejecución del programa fracasa.

gynion escribió:En Megadrive igual sí; no te digo que no.

Complejidad no es solo mover las cosas super deprisa. Los sonic mismamente mueven muy deprisa entornos muy amigables... pocos objetos en pantalla, planos con tiles ya predefinidos en VRAM la mayor parte del tiempo, animaciones normales...

El flink por ejemplo no se mueve a toda máquina, aunque podría... y ves un mejor empleo del color, mejores animaciones, e incluso scaling de sprites. Sonic es mas resultón, pero flink a la chita callando es mas complejo.


En snes un donkey kong country ofrece hasta 4 planos de scroll, mejor profundidad de color, animaciones muchísim mas complejas, y de nuevo no va mas rápido porque no está concebido así. Soporta hasta 7 enemigos simultáneos antes de ralentizarse (seguramente a causa de la animación si coinciden varios tipos de enemigos).

Y luego está esto, que no se basa en correr, pero de nuevo es mas complejo que un sonic:
https://www.instagram.com/p/BL_wNhGALF8/

Señor Ventura escribió:En snes un donkey kong country ofrece hasta 4 planos de scroll, mejor profundidad de color, animaciones muchísim mas complejas, y de nuevo no va mas rápido porque no está concebido así. Soporta hasta 7 enemigos simultáneos antes de ralentizarse (seguramente a causa de la animación si coinciden varios tipos de enemigos).

Y luego está esto, que no se basa en correr, pero de nuevo es mas complejo que un sonic:
https://www.instagram.com/p/BL_wNhGALF8/

Pero un diseño artístico detallado no equivale a una mayor complejidad técnica, ¿no?. Nos puede llevar a más espacio requerido en la rom, por cantidad colores y/o detalle gráfico, como comentaba el compañero antes, pero no necesariamente a una mayor complejidad para la consola.
Sobre el el DKC en concreto, algunos dicen que no dejan de ser sprites y fondos de lo mas básicos, aún siendo preciosos. Si eso es así, es evidente que le tendría que quedar margen a la consola para hacer algo más que el preciosismo, sobre todo habiendo sido una saga de última hornada y contando con 2 secuelas.

gynion escribió:Pero un diseño artístico detallado no equivale a una mayor complejidad técnica, ¿no?. Nos puede llevar a más espacio requerido en la rom, por cantidad colores y/o detalle gráfico, como comentaba el compañero antes, pero no necesariamente a una mayor complejidad para la consola.

No, a menos que implique muchos cuadros de animación que impliquen requerir mas del ancho de banda. No solo es que ocupes mas en la ROM, es que a lo mejor el programa lo exige a un ritmo que DMA no puede satisfacer.

En estos casos megadrive siempre será notablemente mas solvente. Y si, esto si significa mayor complejidad para la consola.

Sonic no le pide nada a la megadrive la mayor parte del tiempo. Es gracioso porque en su día se ponía como ejemplo de aquello del blast processing, y quitando la monstruosidad de los anillos, el juego no necesitaba mucha máquina.

El batman & robin, el comentado dynamite headdy, vectorman, flink, another world, chuck rock 2... hay muchísimos plataformas mas complejos que sonic.

Eso si, el sonic se mueve mas rápido que ninguno, no hay otro plataformas con esas características, pero lo cierto es que necesita menos máquina que los mencionados.

gynion escribió:Sobre el el DKC en concreto, algunos dicen que no dejan de ser sprites y fondos de lo mas básicos, aún siendo preciosos.

Eso es, es justamente esto de lo que va todo. Lo que tu dibujes en los tiles de sprites y planos es irrelevante para estas máquinas, ellas solo ven tiles. Por eso, aunque parezca mentira, el uniracers no es tan diferente de las fases del sonic 2 en las que se mueve deprisa. En ambos casos no hay que procesar nada mas que el muñeco, tal vez algún enemigo, y el resto es mover los planos deprisa (en ambos casos, dos planos).

@Señor Ventura
No pienses que que cuando hablo de velocidad me refiero bajo cualquier condición; tienes que recordar cuando hablamos del Super Metroid y el Jim Power de Mega, como me reconociste que efectivamente existía una complejidad notable para la CPU en el caso del juego de Mega.

Es decir, yo no me quedo "esto va a toda leche y no lo he visto en SNES"; no; matizo bastante más, y en ese ejemplo te lo dejé claro; hablo de elementos presentes, posibilidades jugables, rutinas, fluidez, etc..

No me basta con ver un plano de fondo moviéndose a toda hostia, mientras los sprites del primer plano se siguen moviendo lentos (RR), o ver una samus corriendo como un rayo (que no es Samus, sino que sigue siendo el/los plano/os de fondo lo que se mueve), con escasa o nula interacción con su entorno y con una notablemente baja fluidez, que no se nota a la velocidad normal del juego.

A ver, seamos honestos, el Sonic como juego está bien (salvando gustos) pero no es ninguna maravilla técnica. Las proezas técnicas más grandes del primer Sonic son a mi entender las fases de bonus, por lo demás es un plataformas técnicamente normalito. Rápido, pero normalito.
Salvando distancias en temas de calidad, no ofrece mucho más que un lo que ofrece u Bubsy previamente mencionado. Gunstar Heroes si es técnicamente impresionante, el Adventures of Batman and Robin también, y muchos más que podría mencionar.

Donkey Kong Country es tres cuartos de lo mismo. Su factura es impecable, pero no es una maravilla de la técnica si no del diseño.

A mi opinión el juego de plataformas técnicamente más bestia de los 16bits es el Yoshi's Island. Aunque este es algo de trampa por el tema del SuperFx.

MasterDan escribió:A ver, seamos honestos, el Sonic como juego está bien (salvando gustos) pero no es ninguna maravilla técnica. Las proezas técnicas más grandes del primer Sonic son a mi entender las fases de bonus, por lo demás es un plataformas técnicamente normalito. Rápido, pero normalito.
Salvando distancias en temas de calidad, no ofrece mucho más que un lo que ofrece u Bubsy previamente mencionado. Gunstar Heroes si es técnicamente impresionante, el Adventures of Batman and Robin también, y muchos más que podría mencionar.

Bueno una cosa es que Sonic no fuerce demasiado a la mega y otra que su motor de plataformeo no sea la repera para lo que existía. Es bastante más que una simple detección de cajas 8x8 o 16x16, como lo son la mayoría de juegos plataformeros en ambas consolas.

La detección de cajas la ha de hacer (aunque en el caso del Sonic utiliza pseudotiles más grandes), si nos ponemos tiquismiquis tiene unas físicas bastante interesantes (con aceleraciones que te permiten subir cuestas) y un cálculo de loopings muy eficiente. Aun no son nada que lo haga la repera técnicamente. Las de Mr. Gimmick (juego de 8 bits) diría que son más bestias.