Análisis MD Vs SN por James Rolfe (Angry Video Game Nerd)

Anda no lo había visto , gracias.

EDITO:

LOL , la SuperNintendo tiene mejor retrocompatibilidad? los beat'em up son mejores en Super Nintendo(y encima pone como ejemplo el Streets of rage y no el 2) ? Los final fight en mi opinión son caca , podria haber puesto de ejemplos el super double dragon.

A ver,James Rolfe ya dijo en alguno de sus videos que el se declara Nintendero o fan de Nintendo de siempre y por siempre...

Asi que no me extraña que haga cosas tan ilogicas como meter al SoR en vez del 2 que se come al que le pongas delante en cualquier cosa,o que diga que la ergonomia del mando de la SNES es mejor que el de MD,cuando el de MD otra cosa no se,pero su ergonomia es perfecta directamente,ya mas que comprobado...

En fin,que si,que sabia que iba a ganar SNES por que el tio es un defensor a capa y espada de Nintendo,pero esperaba que comparase bien las cosas y no se dedicara a decir que es mejor esto por que si y ya esta,tambien ridiculiza los anuncios de Sega por "engañar" a los compradores pero es genial como de cosas como -La potencia de la tecnologia SUPER 16 BIT ya nadie se acuerda...

El blast processing parte la pana xD

No hay nada que recriminarle, el analisis creo que lo hace teniendo en cuenta su propia experiencia y lo que vivio dia a dia.

A mi me han molado los analisis del mini-nerdo... del que el mismo se descojona... me ha hecho reflexionar en, la de chorradas y mierdas que diriamos de pequeño, rollo "mi padre es el mejor y el tuyo no"

Lo vi hace ya bastante, y la verdad es que es sorprendentemente imparcial, considerando que James Rolfe es nintendero hasta la muerte. Lo que me hace gracia es que se equivocó con lo de la resolución: aunque es verdad que la SNES podía hacer 512x448, ningún juego lo utilizó. La inmensa mayoría de juegos de SNES usaban 256x224, que es inferior a 320x224, que es lo que usaban la mayoría de juegos de MegaDrive. ¡JA!

MinaseTaki escribió:Lo vi hace ya bastante, y la verdad es que es sorprendentemente imparcial, considerando que James Rolfe es nintendero hasta la muerte. Lo que me hace gracia es que se equivocó con lo de la resolución: aunque es verdad que la SNES podía hacer 512x448, ningún juego lo utilizó. La inmensa mayoría de juegos de SNES usaban 256x224, que es inferior a 320x224, que es lo que usaban la mayoría de juegos de MegaDrive. ¡JA!

si, pero la menor resolución otorga indirectamente una ventaja de la que megadrive no puede servirse.

Menor area de renderización + mayor memoria de vídeo = mas disponibilidad para mostrar gráficos coloristas, y almacenar todavía mas sprites, animaciones, etc.

Lo que dices es cierto Ralph, pero también al portear un sidescroller multi a menor resolución pierdes área de visión/reacción. Es precisamente el problema que dan los dispositivos portátiles por eso a esos juegos a veces les bajan la dificultad. Obviamente eso no pasa con juegos especialmente adaptables tipo juegos de lucha/ puzzles o desarrollados para esas resoluciones.

Lo habia visto en ingles, gracias por poner el link a la version subtitulada.

Blaster Master escribió:A ver,James Rolfe ya dijo en alguno de sus videos que el se declara Nintendero o fan de Nintendo de siempre y por siempre...

eso iba a decir, ya sin verlo me imaginaba que iba a ganar super nes (aunque lo merece, y en el tema de beat em ups igual tambien, porque aunq SOR2 sea para mi mejor que cualquier beat em up en super nintendo, la lista general de este genero en super nes quiza sea mas completa y con mas calidad global. tenia bastantes conversiones de capcom y muy dignas, creo recordar).

MinaseTaki escribió:Lo vi hace ya bastante, y la verdad es que es sorprendentemente imparcial, considerando que James Rolfe es nintendero hasta la muerte. Lo que me hace gracia es que se equivocó con lo de la resolución: aunque es verdad que la SNES podía hacer 512x448, ningún juego lo utilizó. La inmensa mayoría de juegos de SNES usaban 256x224, que es inferior a 320x224, que es lo que usaban la mayoría de juegos de MegaDrive. ¡JA!

mira esto no lo sabia.

Yo de crio siempre se entendia que la SNEs era mejor que la MD por una cuestion simplemente de tiempo, salio mas tarde= tenia mejor tecnologia disponible
A mi me gustan ambas maquinas son muy dos buenas consolas y la version de Mega turrican es mejorq ue la super turrican

¿quereis ira visceral y fanboys segeros y nintis hasta la muerte? entonces pasaos por el hilo de Canal Piarata Namek, porque este sábado habrá sangre.

EDIT: toma SPAM

La supernintendo gana... ¡¡¡¡JO%&#E SEGA!!

Nahhh, en serio, parte de la diversion era defender tu consola a muerte y digo tu consola, porque antes no era como ahora -al menos no en la gran mayoria de gente-, antes tenias una Supernintendo o una Megadrive porque no podias tener las dos (no ibas a convencer a tus padres ni por todos los sobresalientes del mundo de que te compraran la otra si ya tenias una), asi que habia que defender lo tuyo a muerte como es de rigor.

Ambas consolas fueron muy buenas y muy longevas y eso es algo que nos beneficio a todos, pero claro... La Supernintendo siempre fue mejor.

Dado que comienza el video afirmando que más que un análisis es una opinión personal, entonces nada que objetar, pero al hombre se le nota la vena fan en algunos momentos del video, como no incluir el mando oficial de 6 botones de MD y en cambio considerar un adaptador no oficial de NES como un punto positivo.

Crescent escribió:Dado que comienza el video afirmando que más que un análisis es una opinión personal, entonces nada que objetar, pero al hombre se le nota la vena fan en algunos momentos del video, como no incluir el mando oficial de 6 botones de MD y en cambio considerar un adaptador no oficial de NES como un punto positivo.

Venga al lio!!! -pero de buen rollo que luego nos chapan la paraeta-. Esta claro que tiene una opinion formada desde niño, asi que la conclusion final no podia ser otra, pero en los dos aspectos que puntualizas en realidad no estas en lo cierto.

Si que aparece el mando de 6 botones pero como no venia por defecto con la consola, sino que habia que comprarlo por separado, obviamente es una desventaja clara y respecto al adaptador no oficial u oficial esto resulta indiferente si en realidad se podia comprar y funcionaba correctamente -ahi no entro porque no lo habia visto en mi vida- que mas da que fuera oficial o no, las ventajas eran las mismas.

joder me he identificado con el james enano,nací en el mismo año que el, y recuerdo perfectamente defender la megadrive, que fue la primera que tuve, que si mega cd, que si 7 mhz frente a 3,5, que si sonic, que si bla bla, al final uno crece y se da cuenta del montón de pamplinas que nos metían en el coco.

Lo que siempre he dicho.. lo importante son los juegos.. y la verdad es que los desarrolladores se las apañaban para sacar juegos buscando trucos para conseguir los mejores efectos (eso sí era exprimir el hardware y no lo de ahora)

De acuerdo en todo con el gran Rolfe, salvo en un detalle (opinion personal): los beat´em ups. La saga Street of rage me parece mejor que cualquier beat em up de SNES. (Turtles in time me parece un juegazo pero prefiero el estilo de los SOR)

estoybien escribió:Lo que dices es cierto Ralph, pero también al portear un sidescroller multi a menor resolución pierdes área de visión/reacción. Es precisamente el problema que dan los dispositivos portátiles por eso a esos juegos a veces les bajan la dificultad. Obviamente eso no pasa con juegos especialmente adaptables tipo juegos de lucha/ puzzles o desarrollados para esas resoluciones.

Hombre, area de visión, de acuerdo, pero decir "de reacción" ya es un poco forzado, ¿no?... además, siempre se puede adaptar a una escala en que se pueda recuperar ese area (con bandas negras, obvio).

A 256x224, con unas bandas negras que lo convierta a 256x200, mas una memoria de vídeo el doble de grande, da como resultado una mayor ventaja para obtener fondos con menos patrones de repetición de tiles (compresión), mejores animaciones, colores, e incluso mayor tamaño de sprites (cosa que se potencia todavía mas, si tenemos en cuenta que a menor resolución, el mismo sprite se vuelve mas grande).



Fíjate en la siguiente imagen:

A menor resolución, tienes algunas ventajas adicionales, como ya hemos dicho... pero en teoría tambien la desventaja de una menor definición.

Sin embargo, el margen extra en snes permite un mejor degradado, mayor calidad en el sombreado, etc, cosa que al final acaba compensando esa supuesta desventaja. Lo cierto es que a pesar de todo, la foto de la versión snes se ve mas nítida, además de contar con el factor de ahorrar mas memoria con graficos que ocupan menos, pero que en tamaño se ven igual de grandes en una TV (o incluso mas grandes, ya que en el caso de snes, la imagen se estira).

Otra ventaja que sirve para ahorrar memoria, es que gracias a su paleta, no necesitas meter un chorrazo de colores para obtener ese resultado, por lo que, con el mismo número de colores, consigues una mejora sin gastar mas memoria.





En definitiva. Los 128 kilobytes de video de snes, cunden bastante mas del doble que en megadrive.

Ralph escribió:

MinaseTaki escribió:Lo vi hace ya bastante, y la verdad es que es sorprendentemente imparcial, considerando que James Rolfe es nintendero hasta la muerte. Lo que me hace gracia es que se equivocó con lo de la resolución: aunque es verdad que la SNES podía hacer 512x448, ningún juego lo utilizó. La inmensa mayoría de juegos de SNES usaban 256x224, que es inferior a 320x224, que es lo que usaban la mayoría de juegos de MegaDrive. ¡JA!

si, pero la menor resolución otorga indirectamente una ventaja de la que megadrive no puede servirse.

Menor area de renderización + mayor memoria de vídeo = mas disponibilidad para mostrar gráficos coloristas, y almacenar todavía mas sprites, animaciones, etc.

Ñnnneeee, falso!

Gráficos más coloristas significan que ocupan más y reprensertar lo mismo que en otras consolas requiere más vram (1 tiles en super nintendo ocupa mucho más que en megadrive o pc-engine). además, la super tiene una limitación ENORME con los sprites que no tiene ni megadrive, ni pc-engine ni neogeo... solo puede mostrar 2 tamaños de sprites en pantalla y encima cuadrados (16x16, 32x32...), despilfarrando más vram si cabe, mientras que en mega por ejemplo puedes ajustar el tamaño a lo que te de la gana mientras sea multiplo de 8 (8x32 por ejemplo). Y muchaaaas más limitaciones estúpidas que le metieron para abaratar... la resolución tan escasa de pantalla de la snes es precisamente por la escasez de vram... aún teniendo el doble que en megadrive.

Lo mejor del video es el mini-Jimmy, ha conseguido arrancarme un par de sonrisas. Me parece muy gracioso que en aquella época el chaval ya se grabara a si mismo defendiendo sus opiniones

davorz escribió:Lo mejor del video es el mini-Jimmy, ha conseguido arrancarme un par de sonrisas. Me parece muy gracioso que en aquella época el chaval ya se grabara a si mismo defendiendo sus opiniones

a mi lo que me parece gracioso es que conserve las maquinitas de Tigger y las pegatinas de los mandos, al parecer la madre de James no tenia el sindrome de "esto a tirar" y el tampoco tuvo la etapa de "esto son trastos, a tirar"

Skullomartin escribió:

davorz escribió:Lo mejor del video es el mini-Jimmy, ha conseguido arrancarme un par de sonrisas. Me parece muy gracioso que en aquella época el chaval ya se grabara a si mismo defendiendo sus opiniones

a mi lo que me parece gracioso es que conserve las maquinitas de Tigger y las pegatinas de los mandos, al parecer la madre de James no tenia el sindrome de "esto a tirar" y el tampoco tuvo la etapa de "esto son trastos, a tirar"

Yo es que mi madre viene de un ambiente muuyyy muyyy humilde y desde joven tiende mas a acumular trastos (rozando el sindrome de diogenes) que al sindrome de "esto a tirar". De pequeño me fastidiaba cuando me venia con lo de "cuida las cosas" cada vez que hacía un poco el cafre, pero ahora cuando veo todos los juguetes que me quedan de crío tan bien conservados lo agradezco

Ralph escribió:Hombre, area de visión, de acuerdo, pero decir "de reacción" ya es un poco forzado, ¿no?... además, siempre se puede adaptar a una escala en que se pueda recuperar ese area (con bandas negras, obvio).

A 256x224, con unas bandas negras que lo convierta a 256x200, mas una memoria de vídeo el doble de grande, da como resultado una mayor ventaja para obtener fondos con menos patrones de repetición de tiles (compresión), mejores animaciones, colores, e incluso mayor tamaño de sprites (cosa que se potencia todavía mas, si tenemos en cuenta que a menor resolución, el mismo sprite se vuelve mas grande).



Fíjate en la siguiente imagen:

A menor resolución, tienes algunas ventajas adicionales, como ya hemos dicho... pero en teoría tambien la desventaja de una menor definición.

Sin embargo, el margen extra en snes permite un mejor degradado, mayor calidad en el sombreado, etc, cosa que al final acaba compensando esa supuesta desventaja. Lo cierto es que a pesar de todo, la foto de la versión snes se ve mas nítida, además de contar con el factor de ahorrar mas memoria con graficos que ocupan menos, pero que en tamaño se ven igual de grandes en una TV (o incluso mas grandes, ya que en el caso de snes, la imagen se estira).

Otra ventaja que sirve para ahorrar memoria, es que gracias a su paleta, no necesitas meter un chorrazo de colores para obtener ese resultado, por lo que, con el mismo número de colores, consigues una mejora sin gastar mas memoria.

En definitiva. Los 128 kilobytes de video de snes, cunden bastante mas del doble que en megadrive.

Área de visión y reacción están directamente relacionadas, miremos un juego como Contra III por ejemplo para que se vea lo que quiero decir. En la GBA , cuya resolución es de 240x160 contra los 256x224 creo de la versión Super Nintendo, ves que los personajes aparecen un poco más cerca sobre todo cuando se produce el scrolling y la jugabilidad se ve afectada (es complicado de ver si lo has jugado muy mucho porque ya sabes donde saldrán los enemigos) en éste caso se vuelve más difícil, sé que suena a perogrullada pero no lo es. Hay resultados dispares, en algunos ports la reducción de visión se puede tornar frustrante.

Es muy típico de nintendo el recurso de reducir la dificultad en sus ports para portátiles, por ejemplo en el Mario World si tienes la flor o la hoja al ser golpeado no te vuelves pequeño del todo como en snes. También se suelen hacer otros ajustes como rediseñar el juego, eliminar marcadores, escalar/rehacer los gráficos como el Donkey Kong Country (perdiendo el esplendor gráfico) o el favorito de las desarrolladoras dejarlo tal cual . De megadrive a snes también pasa y el earthworm jim vale como ejemplo, recordemos que si el juego se hace para snes no existe tal problema porque ya se programa teniendo en cuenta su resolución. Puede ser más dramático o no dependiendo del juego y en algunos como los de lucha no hay tal problema por la naturaleza de los mismos, 2 personajes en pantalla siempre enfocados en el scrolling y con todas las ventajas de tener que llenar menos pantalla, por eso incluso en megadrive optaban por usar la resolución menor.

pocket_lucho escribió:

Ralph escribió:

MinaseTaki escribió:Lo vi hace ya bastante, y la verdad es que es sorprendentemente imparcial, considerando que James Rolfe es nintendero hasta la muerte. Lo que me hace gracia es que se equivocó con lo de la resolución: aunque es verdad que la SNES podía hacer 512x448, ningún juego lo utilizó. La inmensa mayoría de juegos de SNES usaban 256x224, que es inferior a 320x224, que es lo que usaban la mayoría de juegos de MegaDrive. ¡JA!

si, pero la menor resolución otorga indirectamente una ventaja de la que megadrive no puede servirse.

Menor area de renderización + mayor memoria de vídeo = mas disponibilidad para mostrar gráficos coloristas, y almacenar todavía mas sprites, animaciones, etc.

Ñnnneeee, falso!

Gráficos más coloristas significan que ocupan más y reprensertar lo mismo que en otras consolas requiere más vram (1 tiles en super nintendo ocupa mucho más que en megadrive o pc-engine). además, la super tiene una limitación ENORME con los sprites que no tiene ni megadrive, ni pc-engine ni neogeo... solo puede mostrar 2 tamaños de sprites en pantalla y encima cuadrados (16x16, 32x32...), despilfarrando más vram si cabe, mientras que en mega por ejemplo puedes ajustar el tamaño a lo que te de la gana mientras sea multiplo de 8 (8x32 por ejemplo). Y muchaaaas más limitaciones estúpidas que le metieron para abaratar... la resolución tan escasa de pantalla de la snes es precisamente por la escasez de vram... aún teniendo el doble que en megadrive.

Cito de Wikipedia SNES (http://en.wikipedia.org/wiki/Super_Nintendo_Entertainment_System#Video):
[...]Sprites can be 8 × 8, 16 × 16, 32 × 32, or 64 × 64 pixels[...]

Otra cosa 32 no es múltiplo de 8.

sgonzalez escribió:
Cito de Wikipedia SNES (http://en.wikipedia.org/wiki/Super_Nintendo_Entertainment_System#Video):
[...]Sprites can be 8 × 8, 16 × 16, 32 × 32, or 64 × 64 pixels[...]

Otra cosa 32 no es múltiplo de 8.

Ehhh, eso he dicho, cuadrados y múltiplos de 8, (repasate las tablas de multiplicar anda, un número es múltiplo de 8 cuando es el resultado de multiplicar 8 por otro número)...

Lo que no hace es 8x16, 24x32... cosas así (además de que como he dicho, solo puede haber dos tipos de tamaño para todos los sprites en pantalla, cosa que con el resto no pasa, cada sprite puede tener el tamaño que quiera y permita su vdp). Además, la vram no es solo un almacén de tiles, ahí tb hay que meter el frame buffer de la pantalla, que a más colores... ocupa más, las capas... a más capas... más tamaño que ocupan, las paletas... a más paletas y de más colores... la tabla de atributos de los sprites... a más sprites... ¿sigo? La memoria de la snes cunde MUCHO menos siendo el doble que la de la mega, ¿qué como lo se? He programado para todas las 16 bit...

Y dejar ya la dichosa wikipedia, que no es la verdad universal leñe, que tb dice que el silpheed de megacd usa 3D en tiempo real para los escenarios...cuando es video en streaming o que el axelay es gracias al modo 7... otra tontería como una casa... no es más que cambiar el valor del scroll vertical durante la interrupción horizontal.

Probar esta demo si no os lo creeis:
http://www.youtube.com/watch?v=QN2Yoz0INrI

Incluso la pc-engine lo puede hacer (minuto 10, este video utiliza el supergrafx para las 2 capas, existe esa misma demo con una capa para pc-engine):

http://www.youtube.com/watch?v=f-YSnIDsz5U

La snes tiene muy bien su enorme paleta, el número de paletas, 8 modos gráficos (que sólo se acaban usando 3, el 1,3 y 7), mando de 6 botones nativo y ya... lo demás, incluido el sonido, va entre el desastre y lo cutresco. Y ahora me direis... alaaaaa, ¿como puedes decir eso del sonido? Programar la super y ya me entenderéis. Debido a la cantidad de memoria de chiste que le pusieron y a su extraño modo de funcionar, bastante bien suena ese simple reproductor de módulos IT que el spc700. Si hablamos de sistemas de sonido con mérito ninguno primero estaría el mp3, luego el audiocd y luego la super.

La mega tiene muy mal la paleta y el número de éstas, mando de 3 botones nativo y que su dac sólo puede reproducir un pcm a la vez. Además una cpu rápida te permite hacer cosas como esta por soft:

http://www.youtube.com/watch?v=_dBRY9fjHbs

La pc-engine, un solo mando, encima de 2 botones nativo, un único background y tal vez que de su sistema de sonido se encarga la cpu (no hay chip dedicado) y encima es psg, aunque a mi me gusta.

La neogeo... su precio, el resto es una animalada, aunque un poco extraña lo de no usar capas y solo tiras de sprites del alto de la pantalla.

pocket_lucho escribió:
Ehhh, eso he dicho, cuadrados y múltiplos de 8, (repasate las tablas de multiplicar anda, un número es múltiplo de 8 cuando es el resultado de multiplicar 8 por otro número)...

.....

Toda la razón perdona estaba dormido cuando lo he escrito

Me han gustado los vídeos, aunque ya le vale poner imágenes del SOR1 y no del 2 o el 3... o comparar el Super FX con la 32X y ni mencionar el SVP... o lo de los mandos, lo de pulsar uno al lado del otro no era común, y se podía hacer con el pulgar entre medio... no se, nunca vi en eso un problema. Y lo mismo con el nº de botones, son sagas contadas con una mano.

En fin, sea como sea demuestra que si uno es nintendero, dirá que SN, y él lo era de niño. Eso y lo que le gustan sus juegos y sólo califica de adictivos a juegos que a mi, lo siento mucho, me aburren. He intentado retomar algún DKC... y nada. Intenté el Super Metroid... y ahí está. Sin embargo me pongo con el Sonic 1 y no paro, incluso en 50 Hz.
Eso no quita que sea imparcial, hay cosas obvias y reconocer hechos es obligado... pero bueno, lo mismo que él, me alegro mucho de haber vivido aquella época y aquella sana guerra.

pocket_lucho escribió:Ehhh, eso he dicho, cuadrados y múltiplos de 8, (repasate las tablas de multiplicar anda, un número es múltiplo de 8 cuando es el resultado de multiplicar 8 por otro número)...

Lo que no hace es 8x16, 24x32... cosas así (además de que como he dicho, solo puede haber dos tipos de tamaño para todos los sprites en pantalla, cosa que con el resto no pasa, cada sprite puede tener el tamaño que quiera y permita su vdp). Además, la vram no es solo un almacén de tiles, ahí tb hay que meter el frame buffer de la pantalla, que a más colores... ocupa más, las capas... a más capas... más tamaño que ocupan, las paletas... a más paletas y de más colores... la tabla de atributos de los sprites... a más sprites... ¿sigo? La memoria de la snes cunde MUCHO menos siendo el doble que la de la mega, ¿qué como lo se? He programado para todas las 16 bit...

Y dejar ya la dichosa wikipedia, que no es la verdad universal leñe, que tb dice que el silpheed de megacd usa 3D en tiempo real para los escenarios...cuando es video en streaming o que el axelay es gracias al modo 7... otra tontería como una casa... no es más que cambiar el valor del scroll vertical durante la interrupción horizontal.

Probar esta demo si no os lo creeis:
http://www.youtube.com/watch?v=QN2Yoz0INrI

Incluso la pc-engine lo puede hacer (minuto 10, este video utiliza el supergrafx para las 2 capas, existe esa misma demo con una capa para pc-engine):

http://www.youtube.com/watch?v=f-YSnIDsz5U

La snes tiene muy bien su enorme paleta, el número de paletas, 8 modos gráficos (que sólo se acaban usando 3, el 1,3 y 7), mando de 6 botones nativo y ya... lo demás, incluido el sonido, va entre el desastre y lo cutresco. Y ahora me direis... alaaaaa, ¿como puedes decir eso del sonido? Programar la super y ya me entenderéis. Debido a la cantidad de memoria de chiste que le pusieron y a su extraño modo de funcionar, bastante bien suena ese simple reproductor de módulos IT que el spc700. Si hablamos de sistemas de sonido con mérito ninguno primero estaría el mp3, luego el audiocd y luego la super.

La mega tiene muy mal la paleta y el número de éstas, mando de 3 botones nativo y que su dac sólo puede reproducir un pcm a la vez. Además una cpu rápida te permite hacer cosas como esta por soft:

http://www.youtube.com/watch?v=_dBRY9fjHbs

La pc-engine, un solo mando, encima de 2 botones nativo, un único background y tal vez que de su sistema de sonido se encarga la cpu (no hay chip dedicado) y encima es psg, aunque a mi me gusta.

La neogeo... su precio, el resto es una animalada, aunque un poco extraña lo de no usar capas y solo tiras de sprites del alto de la pantalla.

Pocket_Lucho, en lo personal agradezco siempre tus aportaciónes, en éste caso debido seguro a mis nulos conocimientos, no acabo de entender que el chip de sonido sea "malo", sí tendrá carencias técnicas inexplicables que lastran su capacidad, o un planteamiento de funcionamiento extraño y complicado, pero siempre tuve entendido que la calidad del chip como tal, es muy notable, creo que las carencias vienen más por parte de lo que rodea al chip que al propio chip, incluyendo la memoria de los cartuchos.

Siempre pensé, veo que con poco acierto, que el mayor error de Nintendo fué usar un procesador de sonido 'demasiado bueno', al que 'darle de comer' en condiciones era excesivamente caro por los rigores de la época y de la economía, (me refiero a la cantidad de megas de los cartuchos), y por tanto los resultados quedaban injustamente limitados, sonando muchos efectos y músicas "embotadas", por usar una tasa de khz baja o muy baja para ahorrar memoria cuando el chip era capaz de mucho más, algo que no ocurría en MD ya tuvieran los juegos 4 o 32 mb, al tener el chip un funcionamiento y capacidad completamente diferente al de Snes. Supongo que el Chip MSU, aunque un poco tarde está haciendo justicia de una foma indirecta.

Más tarde tirando de Wikipedia, (si), supe que el chip de sonido tiene las limitaciones que comentas (alguna menos, yo entendí) y que el procesador central y la arquitectura de la máquina era muy diferente, y tambien inferior, a lo que me había imaginado.

Al no ser programador sólo puedo darte la razón, pero quería exponer mi punto de vista inicial.

Por cierto, el que un gráfico de Snes ocupe mucho más que uno de MD por su mayor número de colores tiene bajo mi punto de vista un paralelismo directo con lo que comentaba sobre el chip de sonido, si no me equivoco, fué la razón de que los Supernintenderos nos quedáramos sin la fase de conducción de Toy Story, sí imcluida en MD y de gran calidad por la rutina utilizada.


http://www.youtube.com/watch?v=vf-iaeRf ... ure=relmfu


32 megas para cada consola.... no iban a hacer una eprom especial de 36 o 40 para Snes...

Es imposible negar todas las limitaciones de la consola, y que MD por procesador es capaz de hacer cosas muy similares a lo visto en Snes por soft, (en Saturn repitieron la misma estrategia con distinto resultado, -no és una crítica velada, sólo recalco la estrategía en ingeniería de Sega-), pero para mi el mayor enemigo de la Snes al margen de todo esto siempre fué la capacidad de los cartuchos, como se suele decir (otro parelelismo) "grandes poderes, conllevan grandes responsabilidades", despues de leerte tendríamos que decir, "Grandes -o no tan grandes- poderes, conllevan considerables responsabilidades"

En TurboGrafx siempre me impresionó el 'scaling' en el altered Beast, en MD los piernas lentas no fueron bien tratados, aunque se perdona por ser el primer juego programado oficialmente. Estuve deseando varios años la Supergrafx, Marcos García le dedicó un reportaje en HC (Game Masters) poco antes de irse a Super Juegos, gloriosa conversión de Ghouls'n Ghosts.

Respecto al vídeo, como todos los de Rolfe me ha encantado e impresionado, tiene mucho talento. El intercalar sus vídeos de pequeño es un detalle fantástico. Y sí, se le nota la vena Nintendera (SOR2), pero eso lo sabíamos de sobra, además en el caso de SOR2, como habeis comentado, tal vez fuera una forma de resumir el hecho de que si bien SOR2 supera con holgura y en varios apartados a casi cualquier Beat Èm Up existente en SN, ésta, increíblemente, tiene un catálogo más nutrido de correcalles que MD y algunos son muy destacábles, y ports directos* de arcade de excelente factura.

*con directos, me refiero a conversiones que respetan integramente el juego original, no que sean conversiones pixel perfect, algo que ya sabemos no és posible en una mayoría de casos.


Saludos

A mi lo que me ha parecido increible es que ya siendo pequeñito se grabara haciendo su propio analisis (en este caso, de por que el creia que Snes era mejor), se nota que a nacido para esto, jeje.

El del del 32X es imperdible xD

muchas gracias por el aporte compañero,lo acabo de ver y la verdad que esta muy chulo

aparte de las valoraciones personales que a hecho,creo que lleva razón en varios aspectos y que a nivel técnico esta claro que super nes era mejor

pero claro para mí sega fué la que me enganchó

pocket_lucho escribió:Ñnnneeee, falso!

Gráficos más coloristas significan que ocupan más y reprensertar lo mismo que en otras consolas requiere más vram (1 tiles en super nintendo ocupa mucho más que en megadrive o pc-engine). además, la super tiene una limitación ENORME con los sprites que no tiene ni megadrive, ni pc-engine ni neogeo... solo puede mostrar 2 tamaños de sprites en pantalla y encima cuadrados (16x16, 32x32...), despilfarrando más vram si cabe, mientras que en mega por ejemplo puedes ajustar el tamaño a lo que te de la gana mientras sea multiplo de 8 (8x32 por ejemplo). Y muchaaaas más limitaciones estúpidas que le metieron para abaratar... la resolución tan escasa de pantalla de la snes es precisamente por la escasez de vram... aún teniendo el doble que en megadrive.

En primer lugar, tengo que rectificar el dato de la memoria de video (siempre me equivoco). Son 64Kbytes de vram, no 128. Es en la memoria ram donde snes dobla a megadrive.


Bien, sigamos...

Un objeto conformado por varios sprites de 96x96, a una resolución de 256x224, y de 320x240, aparecerá mas grande siempre en la resolución mas pequeña, por lo que no es necesario ocupar mas memoria en la vram con un objeto igual de grande para que se vea igual... 80x80 ocupará menos memoria que 96x96, y serán de un tamaño parecido. Ese es el margen del que hablo para conseguir una mayor profundidad de color sin un sobrecoste de memoria (con respecto a los sprites de 96x96).

Con respecto a la limitación de los sprites. Tengo entendido que los que no se dibujan, no ocupan espacio en memoria. Hay un color que delimita el dibujo del sprite con pixels "nulos", por lo que no hablamos de despilfarrar vídeo ram, sino capacidad de manejo de sprites... pero con la capacidad que tiene de poder mostrar 128 a la vez, desde luego que no es para hablar de limitación, sino en todo caso de despilfarro, pero pasan dos cosas:

-Hay margen para permitirse ese lujo.
-No automáticamente se tienen que despilfarrar sprites, si se diseña el software con inteligencia, y los artistas favorecen ese trabajo con buenos diseños.
-Gastar un sprite para dibujar 8x32 pixels, es lo mismo que gastar un sprite de 32x32, y dibujar únicamente 8x32 pixels


Y vuelvo a reiterarme sobre la importancia de la paleta de colores. Obviamente, si empleamos gráficos a 256 colores, la memoria de vídeo cunde menos que usando 64, pero como bien dices, una resolución menor compensa ese detalle. Lo bueno de tener una paleta de 32.000 colores, es que con los mismos colores en pantalla que en megadrive, se pueden obtener resultados mejores, y sin causar un derroche de vram (cosa que unida a la resolución, puede dar incluso un margen extra para otras cuestiones, y con la ventaja de lucir mejor).


Al final es lo de siempre, todo depende de si se programa con inteligencia, pero los pros y los contras de cada máquina están ahí. Un ejemplo es el mortal kombat:
-Tenemos que en snes el juego funciona a menor resolución, y sin embargo, se ve claramente mas nítido.
-No recuerdo ahora cuantos colores en pantalla muestra cada versión, pero creo recordar que es muy parecido. Eso significa que los tiles ocupan mas o menos lo mismo en la VRAM... pero que gracias a su paleta de colores, consigue una mejora visual sin sobrecostes de memoria.
-Otra cosa. En snes los objetos/personajes se ven mas grandes al ser estirada la imagen en el televisor, aunque realmente son graficos mas pequeños que ocupan menos en memoria (una ventaja indirecta de una desventaja directa: la menor resolución, que para colmo, encima se ve mas nítido gracias a su paleta).

pocket_lucho escribió:La snes tiene muy bien su enorme paleta, el número de paletas, 8 modos gráficos (que sólo se acaban usando 3, el 1,3 y 7), mando de 6 botones nativo y ya... lo demás, incluido el sonido, va entre el desastre y lo cutresco. Y ahora me direis... alaaaaa, ¿como puedes decir eso del sonido? Programar la super y ya me entenderéis. Debido a la cantidad de memoria de chiste que le pusieron y a su extraño modo de funcionar, bastante bien suena ese simple reproductor de módulos IT que el spc700. Si hablamos de sistemas de sonido con mérito ninguno primero estaría el mp3, luego el audiocd y luego la super.

Hombre, que snes sea un sistema complejo de dominar, no quiere decir que sea un sistema manco, ni mucho menos.
Para ti sólo tiene bueno la paleta de colores, pero tiene muchas mas virtudes... la memoria de sistema (el doble que en megadrive), el modo 7, el ghost layering, los 128 sprites en pantalla (que no 128 objetos en pantalla), y el hecho de que las funciones gráficas están implementadas por hardware, y no hay que programarlas por software.

Para empezar, el sistema de sonido no se limita únicamente a reproducir módulos, tambien aplica filtros para panning de audio, reverberación... e incluso compresión de audio. Di que echas de menos mas memoria para el sonido, pero no te metas con el spc700, porque es bárbaro lo que se puede hacer con el.

http://www.youtube.com/watch?v=g1EGNaPT ... ure=relmfu
http://www.youtube.com/watch?v=dataRTGf ... ure=relmfu

pocket_lucho escribió:La mega tiene muy mal la paleta y el número de éstas, mando de 3 botones nativo y que su dac sólo puede reproducir un pcm a la vez. Además una cpu rápida te permite hacer cosas como esta por soft:

http://www.youtube.com/watch?v=_dBRY9fjHbs

Está claro, pero hay que saber programar esas rutinas gráficas por software... y una desventaja de hacerlo por software, es que ocupas memoria de sistema extra para implementar esas rutinas. No es gratis.
Acceder a esas rutinas por hardware no resta memoria de sistema, acelera la programación, y su rendimiento será óptimo y eficiente en todo momento.

Por otro lado, y a pesar de que valoro el doble scroll, los objetos simultaneos (sin ia, ni patrones de comportamiento, cosa que tambien requiere computación), y la suavidad, tengo que decir que me mosquea la elevada compresión de los bmp's (repetición de patrones en las tiles).
Quiero ver eso con bmp's complejos... sino, lo que me da a pensar es que esas rutinas están ocupando demasiado espacio (y el escaling funciona bien, pero, ¿cuantos recursos come?).


Un pequeño ejemplo en snes, y además en un juego comercial:
http://www.youtube.com/watch?v=4NM01Jy8di0

Yay escribió:Siempre pensé, veo que con poco acierto, que el mayor error de Nintendo fué usar un procesador de sonido 'demasiado bueno', al que 'darle de comer' en condiciones era excesivamente caro por los rigores de la época y de la economía, (me refiero a la cantidad de megas de los cartuchos), y por tanto los resultados quedaban injustamente limitados, sonando muchos efectos y músicas "embotadas", por usar una tasa de khz baja o muy baja para ahorrar memoria cuando el chip era capaz de mucho más, algo que no ocurría en MD ya tuvieran los juegos 4 o 32 mb, al tener el chip un funcionamiento y capacidad completamente diferente al de Snes. Supongo que el Chip MSU, aunque un poco tarde está haciendo justicia de una foma indirecta.

Esto lo puse en otro hilo:

EWJ2 (PSOne):
http://www.youtube.com/watch?v=7odYSnhS ... ure=relmfu

EWJ2 (SNES):
http://www.youtube.com/watch?v=uBakQewEvzk


Y además:

http://www.youtube.com/watch?v=f45MMv9hQJA
http://www.youtube.com/watch?v=tr79Iacr ... re=related
http://www.youtube.com/watch?v=y0PixBaf8_Y
http://www.youtube.com/watch?v=_Hv7MhsX9N4
http://www.youtube.com/watch?v=nPinyngv ... re=related
http://www.youtube.com/watch?v=LDvKwSVu ... re=related
http://www.youtube.com/watch?v=TYjKjjgQPk8
http://www.youtube.com/watch?v=W0Is7-Om ... re=related


Yo creo que alcanza para darse cuenta de que si por el motivo que sea, hay músicas que sonaban "embotadas" en snes, es porque los programadores abusaban de la capacidad de comprimir, del spc700. Que los productores quisieran sus juegos en cartuchos lo mas pequeños posibles, no es culpa de la snes.

Yay escribió: Siempre pensé, veo que con poco acierto, que el mayor error de Nintendo fué usar un procesador de sonido 'demasiado bueno', al que 'darle de comer' en condiciones era excesivamente caro por los rigores de la época y de la economía, (me refiero a la cantidad de megas de los cartuchos), y por tanto los resultados quedaban injustamente limitados, sonando muchos efectos y músicas "embotadas", por usar una tasa de khz baja o muy baja para ahorrar memoria cuando el chip era capaz de mucho más, algo que no ocurría en MD ya tuvieran los juegos 4 o 32 mb, al tener el chip un funcionamiento y capacidad completamente diferente al de Snes. Supongo que el Chip MSU, aunque un poco tarde está haciendo justicia de una foma indirecta.

Más tarde tirando de Wikipedia, (si), supe que el chip de sonido tiene las limitaciones que comentas (alguna menos, yo entendí) y que el procesador central y la arquitectura de la máquina era muy diferente, y tambien inferior, a lo que me había imaginado.

Al no ser programador sólo puedo darte la razón, pero quería exponer mi punto de vista inicial.

Por cierto, el que un gráfico de Snes ocupe mucho más que uno de MD por su mayor número de colores tiene bajo mi punto de vista un paralelismo directo con lo que comentaba sobre el chip de sonido, si no me equivoco, fué la razón de que los Supernintenderos nos quedáramos sin la fase de conducción de Toy Story, sí imcluida en MD y de gran calidad por la rutina utilizada.


http://www.youtube.com/watch?v=vf-iaeRf ... ure=relmfu


32 megas para cada consola.... no iban a hacer una eprom especial de 36 o 40 para Snes...

Es imposible negar todas las limitaciones de la consola, y que MD por procesador es capaz de hacer cosas muy similares a lo visto en Snes por soft, (en Saturn repitieron la misma estrategia con distinto resultado, -no és una crítica velada, sólo recalco la estrategía en ingeniería de Sega-), pero para mi el mayor enemigo de la Snes al margen de todo esto siempre fué la capacidad de los cartuchos, como se suele decir (otro parelelismo) "grandes poderes, conllevan grandes responsabilidades", despues de leerte tendríamos que decir, "Grandes -o no tan grandes- poderes, conllevan considerables responsabilidades"

Saludos

Exactamente como dices, el enfoque de la música en snes provoque que ocupe mucho más espacio (todos los instrumentos son sampleados) y como bien dices, tenían que meterlo a muy baja tasa... pero para que entraran en la ram del spc más que por el cartucho! Al igual que el toy story, tenemos las fases extra en el earth worm jim tb... aunque siempre se podia tirar de compresión para reducir el tamaño en la rom, pero debido a la cpu de la snes, se necesitaban chips extra que ayudaran en eso, como el c4 de los megaman, que encarecían los cartuchos, además de usar memorias propietarias no como sega, de ahí el mayor precio de los juegos de snes. Pero vamos, que las 4 16 bit eran fabulosas en su dia y según su fecha de salida pues se notaban los avances.

Ralph, que no te mosquee el ejemplo, ocupa lo que tiene que ocupar... exactamente lo mismo que en el Axelay de Super pq usa la misma técnica... QUE NO USA MODO7 LEÑE (ni el suelo del sf2), que es un truco de rasters muy chulo y muy extraño de ver pq se lo traga la cpu, no los vdp, todo un portento de sus programadores en konami. Y si, la oam (tabla de atributos de sprites) SI que ocupa en vram lo de los 128 sprites (que encima son 2 tablas), lo que se hace es actualizar solo los sprites en uso, pero ocupar... ocupa... una cosa es esa tabla y otra son sus tiles, el tamaño de la tabla es fija. Y la excusa de que menor resolución es mejor... lo siento pero no, ejemplo:



Que se ven más grandes, claro y más pixelados tb! A más resolucion, más detalle...

Y leñe, que me gusta la super tb, que siempre parezco un antininti xDD (solo que sus limitaciones me repatean, si no hubieran capado ciertas cosas... madre mia la máquina que habría salido!).

Estoy editando mi mensaje, dame un par de minutos xD

Na, ya he visto los videos y están muy bien, a la altura de James, se puede estar más o menos de acuerdo pero lo que chirria bastante es la parte sobre los beatmups...

Ralph, lo de los tamaños de los sprites distintos a ver si me entiendes con esta imagen...



Montamos un bicho grande con muchos sprites como este, cada sprite debe tener sus tiles en memoria, si podemos ajustar con muchos tamaños diferentes, optimizamos los que tenemos que meter en memoria, si son todos iguales, o usamos muchismo pequeños o pocos grandes pero teniendo que meter muchas veces el vacio en memoria. No se si me explico bien MIra por ejkemplo el 1 y 3 de la izquierda, hay muchos tiles 'vacios', si todos tuvieran que ser de 32x32, tendriamos que meter muchos más aún.

Y tampoco sirve de mucho que el vdp pueda dibujar muchos sprites si luego la cpu se ahoga con ellos, como se puede deducir al ver los final fight con tan pocos personajes en pantalla, que si no ponen más, es por algo

Y tb decir, esa excusa de la definición, tamaño y blablabla... la megadrive tb puede trabajar a 256x224 como la super... como se puede ver en el street fighter 2 y en muchos multi

sgonzalez escribió:Cito de Wikipedia SNES (http://en.wikipedia.org/wiki/Super_Nintendo_Entertainment_System#Video):
[...]Sprites can be 8 × 8, 16 × 16, 32 × 32, or 64 × 64 pixels[...]

Otra cosa 32 no es múltiplo de 8.

32 sí es múltiple de 8.

Isaac, ya lo ha dicho el mismo en su siguiente post. Contestar es innecesario.

pocket_lucho escribió:Ralph, que no te mosquee el ejemplo, ocupa lo que tiene que ocupar... exactamente lo mismo que en el Axelay de Super pq usa la misma técnica... QUE NO USA MODO7 LEÑE (ni el suelo del sf2), que es un truco de rasters muy chulo y muy extraño de ver pq se lo traga la cpu, no los vdp, todo un portento de sus programadores en konami.

No he dicho lo contrario, nunca

El efecto del suelo del street fighter 2 no es modo 7, creo que esto es mas que sabido por todos.

pocket_lucho escribió:Y si, la oam (tabla de atributos de sprites) SI que ocupa en vram lo de los 128 sprites (que encima son 2 tablas), lo que se hace es actualizar solo los sprites en uso, pero ocupar... ocupa... una cosa es esa tabla y otra son sus tiles, el tamaño de la tabla es fija.

Hombre, pero es que eso es por descontado. El registro de los sprites tiene que constar en algún lado.


Una cosa que quiero puntualizar sobre los sprites. Usar un sprite de 64x64 para dibujar un area de 8x64, es gastar un sprite igualmente, del mismo modo que lo sería si puedes elegir el tamaño específico. En megadrive puedes elegir el tamaño del sprite, pero es un sprite gastado igualmente.
La cuestión es que a la hora de dibujar pixels de un sprite, lo que no se utiliza, no ocupa memoria de video. Si tengo un sprite de 32x32, y quiero dibujar un solo pixel, puedo hacer que el resto de pixels no consten (no ocupan memoria extra). Otra cosa es la tabla de atributos, pero no es de lo que hablábamos.

pocket_lucho escribió:Y la excusa de que menor resolución es mejor... lo siento pero no, ejemplo:

https://lh6.googleusercontent.com/-9sqo ... 2lucho.jpg

Que se ven más grandes, claro y más pixelados tb! A más resolucion, más detalle...

Hombre, es que no he dicho que menor resolución es mejor, he dicho que gracias a la paleta de colores de snes, se compensa con un aumento de nitidez esa falta de definición.

pocket_lucho escribió:Y leñe, que me gusta la super tb, que siempre parezco un antininti xDD (solo que sus limitaciones me repatean, si no hubieran capado ciertas cosas... madre mia la máquina que habría salido!).

Abrí un hilo hace no mucho para hablar justo de este tema, pero la gente pareció mas interesada en boicotear el hilo, que en imaginar como hubiera sido el software de su sistema favorito con un aumento de prestaciones específico. Una lástima.

hilo_el-ultimo-giro-de-tuerca-en-la-escena-de-snes_1778168_s30


Sin embargo, magno hizo un aporte muy interesante (y le debo una respuesta, porque realmente me interesa mucho, pero he estado muy ocupado últimamente):
viewtopic.php?f=80&t=1778168&p=1729269322#p1729269322

pocket_lucho escribió:Ralph, lo de los tamaños de los sprites distintos a ver si me entiendes con esta imagen...

Si, veo que eligiendo el tamaño justo de cada sprite, puedes llegar a ahorrar en manejo de sprites (si se da el caso), pero un sprite mas grande no tiene por qué ocupar mas vram si no ocupa mas pixels, que es de lo que hablábamos, ¿no?.

Ahora, snes tiene un margen de 28 sprites extras para gastar, y ésto tampoco significa que se vayan a "malgastar" tantos.

pocket_lucho escribió:Y tampoco sirve de mucho que el vdp pueda dibujar muchos sprites si luego la cpu se ahoga con ellos, como se puede deducir al ver los fight con tan pocos personajes en pantalla, que si no ponen más, es por algo

Me he fijado que existe mucho el argumento de que snes no puede mostrar los 128 sprites en pantalla. Es como decir que snes no puede hacer nada de lo que puede hacer, es un sinsentido.

Cuando se habla de 128 sprites, en ningún caso se habla de 128 objetos. Tal vez sea esa la cuestión a la hora de fijarse en los juegos tipo "final fight".

Un ejemplo:



Ahí veo 10 objetos en pantalla. Incluyo una segunda imagen donde sólo se ven 8, pero en su máximo tamaño.
El juego no va fino sustituyendo sprites, debe tener un desajuste con respecto a la profundidad del modo7, y el hecho de que los sprites pasan de tamaño "mini", a tamaño máximo (para ahorrar cartucho). Esto ocasiona que un sprites tarde bastantes frames en una situación de zoom, en ser sustituido (al no haber posiciones intermedias).

...pero en fín, a lo importante. Con 10 objetos representados en pantalla por sprites de un tamaño muy aceptable (en los que constantemente, dentro de la acción siempre hay un minimo de 7/8), a mi me queda claro que un final fight con mas de un jugador + 3 personajes, es perfectamente posible (repitiendo personajes, pero es que eso tambien pasa en el arcade original).

pocket_lucho escribió:Y tb decir, esa excusa de la definición, tamaño y blablabla... la megadrive tb puede trabajar a 256x224 como la super... como se puede ver en el street fighter 2 y en muchos multi

Ya, si tampoco digo que no, ¿eh?. Solo digo que con una menor resolución, se pueden conseguir objetos igual de grandes, con un tamaño de sprites menor (cosa que ahorra memoria de video).

Ah, que se me había escapado mientras repasaba si alguien lo había contestado

Isaac Lez escribió:Ah, que se me había escapado mientras repasaba si alguien lo había contestado

Ya, por eso. Va a pensar el hombre que se le está atacando

Blast Processing! xDDDDDDDDDDDD

Muy entretenido.
Me a gustado.

No importa lo que diga el gringo este, Thunder Force 3 y 4, Truxton, Darius 2, Gleylancer, Slap Fight, Gaires, Zero Wing, Super Fantasy Zone, Rolling Thunder 3, Super Shinobi y Shinobi 3, Ghouls'n Ghosts, Rainbow Islands, Splatterhouse 3, Contra Hard Corps, Alien Soldier, Alisia Dragoon y varios otro mas que no estan en Super Nintendo, asi que Megadrive es mejor.

Ralph escribió:La cuestión es que a la hora de dibujar pixels de un sprite, lo que no se utiliza, no ocupa memoria de video. Si tengo un sprite de 32x32, y quiero dibujar un solo pixel, puedo hacer que el resto de pixels no consten (no ocupan memoria extra). Otra cosa es la tabla de atributos, pero no es de lo que hablábamos.

No, no es asi, si quieres dibujar un sprite de 32x32 gastas 16 (4x4 tiles) tiles en VRAM porque a la SNES o la megadrive le dices el tile inicial del sprite, a partir de ahi monta ella sola (el chip grafico) el sprite con los tiles siguientes y para un sprite de 32x32 utiliza 16 consecutivos.
Si solo quisieras dibujar 1 pixel con ese sprite, malgastas 15 tiles, la megadrive podria utilizar un sprite de 8x8 gastando un solo tile, aunque este es el caso mas extremo, se ve como va el tema.
La verdad es que estoy con pocket_lucho, de cara al programador la megadrive es mucho mas amigable y ademas no tiene restricciones tan absurdas (que muchas vienen dadas por la idea inicial de hacer la snes retrocompatible con la nes).

wave escribió:

Ralph escribió:La cuestión es que a la hora de dibujar pixels de un sprite, lo que no se utiliza, no ocupa memoria de video. Si tengo un sprite de 32x32, y quiero dibujar un solo pixel, puedo hacer que el resto de pixels no consten (no ocupan memoria extra). Otra cosa es la tabla de atributos, pero no es de lo que hablábamos.

No, no es asi, si quieres dibujar un sprite de 32x32 gastas 16 (4x4 tiles) tiles en VRAM porque a la SNES o la megadrive le dices el tile inicial del sprite, a partir de ahi monta ella sola (el chip grafico) el sprite con los tiles siguientes y para un sprite de 32x32 utiliza 16 consecutivos.
Si solo quisieras dibujar 1 pixel con ese sprite, malgastas 15 tiles, la megadrive podria utilizar un sprite de 8x8 gastando un solo tile, aunque este es el caso mas extremo, se ve como va el tema.
La verdad es que estoy con pocket_lucho, de cara al programador la megadrive es mucho mas amigable y ademas no tiene restricciones tan absurdas (que muchas vienen dadas por la idea inicial de hacer la snes retrocompatible con la nes).

100% correcto. De hecho la cpu de la snes tiene un modo 100% compatible con la de nes, la pega es que ni las ppu ni el spc700 lo son.

La pc-engine es bastante amigable tb para desarrollar lo que le pasa es que le falta potencia en comparación (que no colores ni en paletas) a megadrive o super nintendo aunque su cpu es bastante competente...

HiROM, LoROM, FAST, SLOW... cada uno su mapa de memoria buff, la snes es un maldito rompecerebros.

Al final, más que datos técnicos, lo que determina una consola u otra son los juegos y el gusto de cada uno. Pero técnicamente, por mucho que se empeñen algunos, hay bastante igualdad...

pocket_lucho escribió:
Al final, más que datos técnicos, lo que determina una consola u otra son los juegos y el gusto de cada uno. Pero técnicamente, por mucho que se empeñen algunos, hay bastante igualdad...

Así ha sido y así debería seguir siendo. El que le guste bastante el mundillo y lo tenga como afición, creo que debería tener las dos. Porque perderse algunos títulos o despreciar una consola por ser de tal compañia sería muy absurdo (como las conversaciones de patio cuando críos. )

P.D. El análisis me ha gustado mucho. Solo que no me parece bien que en la valoración de los mandos no meta el mando oficial de 6 botones de mega por no venir de "serie" y más tarde en la parte de retrocompatibilidad si de importancia y valore un producto no oficial para poder emular NES en SNES. Y en juegos los siento, pero yo daría un empate, cada una tiene sus virtudes en el catalogo y títulos que tienes que jugar si o si.

Un saludo

chinitosoccer escribió:No importa lo que diga el gringo este, Thunder Force 3 y 4, Truxton, Darius 2, Gleylancer, Slap Fight, Gaires, Zero Wing, Super Fantasy Zone, Rolling Thunder 3, Super Shinobi y Shinobi 3, Ghouls'n Ghosts, Rainbow Islands, Splatterhouse 3, Contra Hard Corps, Alien Soldier, Alisia Dragoon y varios otro mas que no estan en Super Nintendo, asi que Megadrive es mejor.

No, a ver. Eso es cuestión de gustos, y nada mas.

Lo que el dice, básicamente, es que no es serio sacar un anuncio con el ecco the dolphin y sonic, para tratar de ridiculizar al super mario kart.
No hace falta decir que el poder de computación que hace falta para mover un juego con modo 7 a doble pantalla (split screen), 7 ia's, etc, supera enormemente a lo que enseña sega en ese anuncio (y eso por no hablar de que por supuesto interesaba aún menos poner el f-zero ).

De verdad, cada vez que veo ese anuncio me parto... y la gente por aquel entonces tampoco era lerda. Conocido era que sega manipulaba hasta rozar el paletismo, y con ese anuncio se cubrió de gloria completamente xD


Super mario kart es uno de los juegos mas redondos de su generación, y además de lento no tiene nada.

wave escribió:No, no es asi, si quieres dibujar un sprite de 32x32 gastas 16 (4x4 tiles) tiles en VRAM porque a la SNES o la megadrive le dices el tile inicial del sprite, a partir de ahi monta ella sola (el chip grafico) el sprite con los tiles siguientes y para un sprite de 32x32 utiliza 16 consecutivos.

No nos estamos entendiendo.

El malgasto de sprites es evidente, pero no ocupa igual en la memoria de vídeo usar 150 tiles a 256 colores, que 150 tiles a 32 colores, que 150 tiles a 0 colores.
La tlabla de atributos ocupará lo que tenga que ocupar, pero la información de los tiles, NO. Varía.

De un sprite de 32x32 (16 tiles), en el que sólo pretendo dibujar sobre 8x32 (4 tiles), únicamente ocupo en memoria la información correspondiente a 8x32, porque los otros 24x32 no tienen ningún valor (sus pixels no se "encienden").
En definitiva, malgastar 1/128 sprites, ocupa en memoria únicamente en cuanto a la declaración de un valor en la tabla de atributos. Si quiero puedo mostrar 16 sprites invisibles, y notar cómo practicamente no he alterado el uso de la vram.

wave escribió:Si solo quisieras dibujar 1 pixel con ese sprite, malgastas 15 tiles

Esta es la cuestión. Eso ya se ha dicho, y es la realidad (aunque tambien es un ejemplo extremo xD).

Pero tambien es cierto que con un límite de 128 sprites, hay buen margen para "desperdiciar" sprites. No es lo ideal de cara a la eficiencia, pero al menos hay capacidad.

pocket_lucho escribió:HiROM, LoROM, FAST, SLOW... cada uno su mapa de memoria buff, la snes es un maldito rompecerebros.

De ésto ya se habló con bastante profundidad en su momento. Aprovecho para facilitar el enlace a la documentación, para todo el que quiera enterarse de cómo funciona la sens en cuanto al mapeo de memoria (Gracias infinitas a magno, por descontado).

viewtopic.php?f=80&t=1413431&p=1721049637#p1721049637


P.D: Las imágenes se están rompiendo

pacopi escribió:P.D. El análisis me ha gustado mucho. Solo que no me parece bien que en la valoración de los mandos no meta el mando oficial de 6 botones de mega por no venir de "serie" y más tarde en la parte de retrocompatibilidad si de importancia y valore un producto no oficial para poder emular NES en SNES. Y en juegos los siento, pero yo daría un empate, cada una tiene sus virtudes en el catalogo y títulos que tienes que jugar si o si.

Hombre, es que no es lo mismo. Un cacharro para dar retrocompatibilidad es un extra... un mando, sin embargo, es esencial, y el mando que ha vendido sega oficialmente junto con sus megadrives durante toda su vida (el 99% de las veces), es el de 3 botones.

Yo es que en el tema de mandos no hay color, me regalaron el arcade stick 2 (6 botones) oficial de sega... como para dejarme los dedos en crucetas

Ralph... te lo digo otra vez, un tile es un tile y un pixel, sea del color transparente o no, ocupa... esto que dices:

' únicamente ocupo en memoria la información correspondiente a 8x32, porque los otros 24x32 no tienen ningún valor (sus pixels no se "encienden").
En definitiva, malgastar 1/128 sprites, ocupa en memoria únicamente en cuanto a la declaración de un valor en la tabla de atributos. Si quiero puedo mostrar 16 sprites invisibles, y notar cómo practicamente no he alterado el uso de la vram.'

No es correcto, ocupa lo mismo.

pocket_lucho escribió:Ralph... te lo digo otra vez, un tile es un tile y un pixel, sea del color transparente o no, ocupa... esto que dices:

' únicamente ocupo en memoria la información correspondiente a 8x32, porque los otros 24x32 no tienen ningún valor (sus pixels no se "encienden").
En definitiva, malgastar 1/128 sprites, ocupa en memoria únicamente en cuanto a la declaración de un valor en la tabla de atributos. Si quiero puedo mostrar 16 sprites invisibles, y notar cómo practicamente no he alterado el uso de la vram.'

No es correcto, ocupa lo mismo.

¿Usar sprites a 256 colores ocupa lo mismo que usar un único color?.

Es a lo que me refiero.

Para mi en la epoca de los 16 bits el trono se los disputaron estas dos geneiales consolas. Para mi es empate tecnico.