Comparativa "definitiva" de las 16 bits

Archivado
1, 2, 3, 4, 5
Señor Ventura escribió:
Naitguolf escribió:Sin embargo, jamás entenderé como nadie puede preferir un beat'em up en la snes con máximo 3 enemigos en pantalla. Eso es insufrible


¿Solo 3?. Puedes contar 4 en la mayoría de los juegos (y en esto puedes incluir a la megadrive).

Yo he llegado a ver 6 enemigos en el TMNT in time (tres masillas, y tres chucho-robots), y 7 enemigos en el king of dragons. Poderse se puede.


Fíjate mejor, verás como en la inmensa mayoría de los beat'em up de la snes solo tienen 3. El TMNT es una honrosa excepción (y fantástico port pero solo veo 4 enemigos max). Y el kings of dragons con los sprites tan pequeñitos que le pusieron (de mismo tamaño, tienes 8 enemigos en el SOR1, hasta 6 en el SOR2) ¡fíjate que en el kings cuando salen 3 enemigos, el juego se vuelve lentísimo! Aunque éste yo creo que es el mejor port de Capcom.
Combatribes tambien pone mas de tres personajes enemigos y junto con los dos protagonistas suman 6
Naitguolf escribió:Fíjate mejor, verás como en la inmensa mayoría de los beat'em up de la snes solo tienen 3.


Me he dado cuenta de que en la mayoría de juegos que salen 3 enemigos en pantalla, la factura técnica es bastante chusquerilla.

Luego tienes juegos como el ninja warriors again, que llegan a salir hasta 5, aunque lo usual es 4... o el legend, que tambien saca 4 enemigos en pantalla, y como estos unos cuantos mas, que ya se les nota un poquito mas cuidados.

Pero me da que todo se debía mas a una planificación para no elevar la dificultad de los juegos, que a otra cosa. El Wildcats la mayor parte del tiempo saca 2 enemigos, durante todo el juego, lo cual ya es directamente para sospechar que hay otras razones por las que hacían los juegos así.

Naitguolf escribió:El TMNT es una honrosa excepción (y fantástico port pero solo veo 4 enemigos max)


No es la única honrosa excepción, hay mas beat'em ups de gran nivel tambien, por ahí.

Pero me equivocaba, en realidad llega a 7 simultáneos.

Imagen
Imagen


Naitguolf escribió:Y el kings of dragons con los sprites tan pequeñitos que le pusieron (de mismo tamaño, tienes 8 enemigos en el SOR1, hasta 6 en el SOR2) ¡fíjate que en el kings cuando salen 3 enemigos, el juego se vuelve lentísimo! Aunque éste yo creo que es el mejor port de Capcom.


El número de sprites que conforman un objeto es irrelevante para la gestión del objeto. Si el sistema de vídeo puede mostrar todos esos sprites, a la cpu le da igual si ocupan poca pantalla, que si ocupan mucha.
Lo que si es cierto es que el king of dragons se ralentiza, pero dado que hay veces que con 7 enemigos va bien, y otras que con 3 bolas gelatinosas de esas el rendimiento se resiente, da mas a pensar que es otro penoso trabajo de optimización como los que nos tenía acostumbrados capcom.
¿Que son pequeños?, pues si, pero las rutinas de IA siguen siendo 7... los gráficos déjaselos a los PPU 1 y 2, y a la memoria de vídeo (que esos pueden de sobra).

De los 8 enemigos del SOR 1 noto una cosa bastante curiosa, y es que si te fijas, varios de ellos imitan el movimiento de los demás, por lo que no se están manejando 8 IA's simultáneas.
Creo que hilando fino se podría, en megadrive, pero de todos modos los 6 del SOR2 están muy bien.


P.D: Perdón por editarlo varias veces.
Los 3/4 sprites en pantalla no creo que sea por temas jugables, sería una limitación gratuita. Beat 'em ups, run 'n guns, shoot 'em ups... ese tipo de juegos van por normal general más fluidos, más rápido y con más elementos en pantalla en MD. Si es por optimización, seguro que en Mega también se podría haber llegado más allá de lo que se solía ver.

Los 7 sprites del Turtles In Time están muy cogidos con pinzas (los robots son poquita cosa). Hilando fino, en el SOR 1 puedes llegar a tener 11 sprites simultáneos (10 enemigos más tu personaje, y el 12 asomando la mano por la parte derecha :Ð ), y además de todo eso, un par de palos con fuego volando por el escenario, la salida de aire que es un elemento rompible del decorado, dos planos de scroll (con uno de ellos oscilando arriba y abajo), más los parallax del fondo que no he podido contar bien, pero mínimo 4 casi seguro que hay. Para un VDP que no da la talla no está mal [oki] (estaba a huevo).

Imagen
robotnik16 escribió:Los 3/4 sprites en pantalla no creo que sea por temas jugables, sería una limitación gratuita. Beat 'em ups, run 'n guns, shoot 'em ups... ese tipo de juegos van por normal general más fluidos, más rápido y con más elementos en pantalla en MD. Si es por optimización, seguro que en Mega también se podría haber llegado más allá de lo que se solía ver.


Pues tu dirás a que se debe que hayan tantos beat'em up en megadrive que no pasen de 3 o 4 enemigos simultáneos, cuando puede perfectamente con bastantes mas.

robotnik16 escribió:Los 7 sprites del Turtles In Time están muy cogidos con pinzas (los robots son poquita cosa).


Ya te lo he explicado.

El tamaño de los robots no importa, porque el número de sprites que compongan a un objeto no comprometen a la cpu.
Los robots están manejados por una rutina que si ocupa tiempo de proceso de cpu, y tanto si los robots son poca cosa, como si miden 5 veces mas, el coste de cpu sigue siendo el mismo.

¿Se comprende ya?

robotnik16 escribió:Hilando fino, en el SOR 1 puedes llegar a tener 11 sprites simultáneos (10 enemigos más tu personaje, y el 12 asomando la mano por la parte derecha :Ð ), y además de todo eso, un par de palos con fuego volando por el escenario, la salida de aire que es un elemento rompible del decorado, dos planos de scroll (con uno de ellos oscilando arriba y abajo), más los parallax del fondo que no he podido contar bien, pero mínimo 4 casi seguro que hay. Para un VDP que no da la talla no está mal [oki] (estaba a huevo).


Y no solo eso. En esa fase en concreto hay 4 planos de scroll, tres de los cuales se los han cargado a la CPU porque el VDP no gestiona mas de 2 (la ventana del marcador, y uno de los scrolles).
Eso cuesta tiempo de proceso, y si no se sobrecargara a la cpu con esas tareas, en vez de 11 personajes, podría haber metido alguno mas.

Lo que no puede ser es que yo diga una cosa, y me salteis con otra. Yo no he dicho que el VDP no de la talla, he dicho que para un 68000 es un desperdicio, y como ejemplo, lo ya mencionado.
kusfo79 escribió:Ostras,investigaré esto, a ver que se puede hacer, en principio con 80 sprites normalmente no vamos faltos, pero puede dar mucho juego...


Buena suerte!

multiplex, puede ser util para un juego de naves, especialmente los tiros

Por ejemplo, aca solo hay dos sprites

Imagen


El problema es el trabajo descomunal que significa. Personalmente, cortaria la pantalla en dos, y si el sprite pasa de ese punto, se calcula el multiplex

Algo asi
Imagen



Bueno, lastima que no tengo mas tiempo, ya me agarro el gusanillo de programar con hablar contigo [+risas]

Saludos
Señor Ventura escribió:El tamaño de los robots no importa, porque el número de sprites que compongan a un objeto no comprometen a la cpu.


Corrijo una errata.

El número de sprites que compongan a un objeto no comprometen a la rutina que los maneja (o IA).


P.D: He estado echando una partida al king of dragons, y he llegado a un límite de 7 enemigos + 2 players.
Y ha sucedido una curiosa... el juego se ha ralentizado, pero entonces me he cargado a uno de ellos, y se ha reestablecido la velocidad aún incorporándose otro mas (es decir, 7 enemigos sin ralentizaciones).

Al cabo de un ratito jugando al gato y al ratón (para no matarlos), se ha vuelto a ralentizar.
Veo una perdida de tiempo discutir sobre los sprites, que se puedan poner mas o menos en pantalla, siempre dentro de los limites del vdp, depende de los programadores, del tipo de rutinas que escribieran para esos sprites, y de las ganas/tiempo de optimizar
theelf escribió:
kusfo79 escribió:Ostras,investigaré esto, a ver que se puede hacer, en principio con 80 sprites normalmente no vamos faltos, pero puede dar mucho juego...


Buena suerte!

multiplex, puede ser util para un juego de naves, especialmente los tiros

Por ejemplo, aca solo hay dos sprites

Imagen


El problema es el trabajo descomunal que significa. Personalmente, cortaria la pantalla en dos, y si el sprite pasa de ese punto, se calcula el multiplex

Algo asi
Imagen



Bueno, lastima que no tengo mas tiempo, ya me agarro el gusanillo de programar con hablar contigo [+risas]

Saludos


Precisamente, como con 80 sprites mas o menos ya nos manejamos, se me había ocurrido que un algoritmo simple de partir la pantalla en dos, ya nos daría le pego para duplicar los sprites. Ojo, que de momento nos manejamos bien, pero para hacer alguna cosa tipo Danmaku molaria!

A ver si hago algún experimento. ¿Como lo haces? Cambiando la dirección de la sprite table, y teniendo dos sprites tables diferentes en la memoria?
Señor Ventura escribió:
robotnik16 escribió:Hilando fino, en el SOR 1 puedes llegar a tener 11 sprites simultáneos (10 enemigos más tu personaje, y el 12 asomando la mano por la parte derecha :Ð ), y además de todo eso, un par de palos con fuego volando por el escenario, la salida de aire que es un elemento rompible del decorado, dos planos de scroll (con uno de ellos oscilando arriba y abajo), más los parallax del fondo que no he podido contar bien, pero mínimo 4 casi seguro que hay. Para un VDP que no da la talla no está mal [oki] (estaba a huevo).


Y no solo eso. En esa fase en concreto hay 4 planos de scroll, tres de los cuales se los han cargado a la CPU porque el VDP no gestiona mas de 2 (la ventana del marcador, y uno de los scrolles).
.


No, en esa pantalla hay los dos planos de scroll A y B, más el window para el marcador, y aparte en el Plano B hay varias bandas de parallax. Todo eso se hace por el VDP, sin intervención de la CPU.
El VDP puede gestionar dos planos generales (A y B), más el window (Fijo en una posición, y reemplazando el A donde está puesto), con scroll por tiles (para parallax) o con scroll por lineas (Para efectos raster).
Por aportar mi granito de arena.
Nadie ha hablado de que en snes solo pueden haber 2 tamaños de sprite en un mismo frame mientras que en megadrive puedes poner todas las combinaciones que quieras?
Esto tan tonto ha hecho que muchos juegos ahorren en vram al poder configurar los metasprites solo utilizando los tiles necesarios, creo que el earthworm jim era uno de los que se beneficiaba.
Lo de meter 3/4 sprites puede ser por cuestiones jugables en algún caso, pero podría ser también por estabilidad, por conveniencia (dudo mucho que Konami no pudiese meter más enemigos en el Turtles de MD), o por falta de pericia a la hora de programar. En MD se "colaban" compañías que no tenían un gran bagaje, tal vez por la facilidad de programación que dicen que tiene la consola. A veces también depende del nivel de dificultad del juego, al jugar en "normal" no aparece toda la chicha (la captura del SOR que puse es en modo hardest).

Entendí tu explicación Señor Ventura, lo de los robots del Turtles me parece poca cosa ya no sólo por tamaño, también por rutinas, animación, etc... algún recurso tendrá que costar todo ésto, digo yo.

Y otra captura, venga quién da más!!! (13 mendas en pantalla)

Imagen
wave escribió:Por aportar mi granito de arena.
Nadie ha hablado de que en snes solo pueden haber 2 tamaños de sprite en un mismo frame mientras que en megadrive puedes poner todas las combinaciones que quieras?
Esto tan tonto ha hecho que muchos juegos ahorren en vram al poder configurar los metasprites solo utilizando los tiles necesarios, creo que el earthworm jim era uno de los que se beneficiaba.


¿Los pixels transparentes ocupan memoria?, ¿un sprite de 64x64 para hacer una imagen de 40x40, y el resto transparente, ahorraría memoria igualmente?.

La gran ventaja de usar sprites pequeños, es la detección de colisiones.
Si hacemos un cuadrado conformado por un sprite gigante, tendrías que armar la de dios para saber que esquina está tocándose con un objeto con el que debería reaccionar. Con varios sprites pequeños es mucho mas fácil, porque a cada uno le otorgas un valor, y te olvidas.

Otra ventaja de usar sprites pequeños, es que para animar un personaje no tienes que cambiar el pedazo de sprite enterito, basta con que animes las pequeñas partes que tendrían que moverse. Aquí si sería cuestión de memoria.

robotnik16 escribió:Lo de meter 3/4 sprites puede ser por cuestiones jugables en algún caso, pero podría ser también por estabilidad, por conveniencia (dudo mucho que Konami no pudiese meter más enemigos en el Turtles de MD), o por falta de pericia a la hora de programar. En MD se "colaban" compañías que no tenían un gran bagaje, tal vez por la facilidad de programación que dicen que tiene la consola. A veces también depende del nivel de dificultad del juego, al jugar en "normal" no aparece toda la chicha (la captura del SOR que puse es en modo hardest).


3/4 objetos, no 3/4 sprites, ojo.

Sea como sea, se puede, pero no se ha hecho. Unas veces será por falta de potencia, y otras por diseño, o por no querer abrumar. No lo sabremos nunca, pero lo que está claro es que mas de 4 se podía perfectamente.

robotnik16 escribió:Entendí tu explicación Señor Ventura, lo de los robots del Turtles me parece poca cosa ya no sólo por tamaño, también por rutinas, animación, etc... algún recurso tendrá que costar todo ésto, digo yo.


Pero es que estás mezclando churras con merinas. El número de sprites que conforman un objeto es irrelevante para la cpu, no cuesta ningún recurso extra de cpu indicar si está conformado por 2 sprites, que si está conformado por 15.
Lo que representa un de esos robots, es una rutina que lo controla, y eso si cuesta recursos de cpu. En total hay 6 totalmente independientes, y eso es lo que cuenta, no su tamaño.

Los recursos que te ahorras con los robots pequeños, son algunos kb de vram, y algunos sprites menos de la lista OAM (pero eso es competencia del VDP, no de la cpu, y lo que se ve en pantalla está bastante lejos de su límite).
En mi opinión, que no se haga se debe mas a querer evitar el molesto de bug del generador de imágenes, que no a la imposibilidad de poner a 6 masillas a la vez.

robotnik16 escribió:Y otra captura, venga quién da más!!! (13 mendas en pantalla)

http://s2.subirimagenes.com/otros/previ ... 10sor2.jpg


Hay otro beat'em up que muestra todavía mas enemigos en pantalla. Poner muchos objetos no tiene ningún misterio, lo que chupa mucho tiempo de proceso es controlarlos todos individualmente, cosa que en el SoR no pasa, lamentablemente.
Sigue siendo un gran trabajo, y además tienen un comportamiento bastante complejo (para lo que es), pero cuando empiezan a coincidir muchos, suele ocurrir que varios de ellos copian los movimientos de otros cuantos. Diría que no hay realmente 12 IA's ahí.

Lo mas que he visto en snes es esto: 9 personajes en pantalla (7 enemigos + 2 players).
Imagen


La ralentización es horrorosa, y además desaparecen muchos sprites por culpa del bug del generador de imágenes (he tenido que moverme varias veces para conseguir una imagen completa).
Con 5 enemigos (mas los dos jugadores) el juego es estable como una roca... y hablamos de enemigos que esquivan, se cubren con sus escudos, te rodean para emboscarte, saltan, y eligen de que forma atacar. Vamos, que son IA's bastante decentes.
De todos modos capcom no suele optimizar sus juegos, y ya es raro encontrarse con alguno que no se les ralentice. Para mi que no sería tan imposible que el king of dragons funcionase correctamente.
kusfo79 escribió:A ver si hago algún experimento. ¿Como lo haces? Cambiando la dirección de la sprite table, y teniendo dos sprites tables diferentes en la memoria?.


No, en el caso de los ejemplos esos, como los hice a lo rapido, simplemente cambio la info de los sprites despues de cada raster

Si el sprite tiene 8pixeles de alto, en el raster 9 mando la nueva informacion, si tiene 32, en el 33... no falla
He visto algunos errores en algunos comentarios sobre algunas cosas y por eso me sentí obligado a escribir en este hilo. :)

Sobre los sprites en el Genesis/Megadrive: en el modo H40 (320) hay un máximo de 80 sprites, 20 por linea y tambien existe el limite por pixel que es de 320, por ejemplo, puede haber un maximo de 20 sprites de 16x16 por linea, o 10 sprites de 32x32 por linea, etc, es decir puede cubrir 320 pixeles de sprites. En el modo H32(256) hay un maximo de 64 sprites y 16 por linea, y también está el limite por pixel que en este caso es de 256, por ejemplo pueden estar 16 sprites de 16x16 por linea, o 8 sprites de 32x32 por linea, etc, cubriendo un máximo de 256 pixeles.
Los sprites pueden tener cualquiera de estos tamaños: 8x8, 8x16, 8x24, 8x32, 16x8, 16x16, 16x24, 16x32, 24x8, 24x16, 24x24, 24x32, 32x8, 32x16, 32x24, 32x32.

Ahora sobre el DMA, en los documentos oficiales(sega2.doc) se decía que era de 205 bytes por linea para H40 y 167 para H32, pero esto no es correcto, primero existe diferencias cuando el DMA es hacia la VRAM y cuando es hacia CRAM/VSRAM(color ram/vscroll ram), cuando es DMA hacia la VRAM la transferencia es en bytes, y es de 204 bytes por linea en el modo H40, y 166 bytes por linea en H32, ahora cuando es DMA hacia CRAM/VSRAM la transferencia es en words, y es de 198(words) por linea para el modo H40 y 161 para el modo H32.

Existe una explicación muy detallada sobre todo esto en un "topic" del foro "spritesmind" realizada por "Mask of Destiny" y que tambien interviene "Nemesis", llamado "Vdp internals" (esta en ingles) y ademas todo esto fue probado en el "hardware real":
http://gendev.spritesmind.net/forum/vie ... php?t=1291


El Snes sobre los sprites: hay un máximo de 128 sprites, 32 por linea y también tiene un limite por pixel que es de 272(no estoy muy seguro de esto, en algunos lugares he visto 256), esto quiere decir por ejemplo que puede haber 17 sprites de 16x16 por linea, o 8 sprites "y medio" :p de 32x32, cubriendo un máximo de 272 pixeles.

A diferencia del genesis/megadrive en el snes cada sprite puede tener solo 2 tamaños ("pequeño" y "grande") y estos tamaños se configuran a traves de un registro y que será para todos los sprites, y los tamaños son los siguientes: 8x8 y 16x16, 8x8 y 32x32, 8x8 y 64x64, 16x16 y 32x32, 16x16 y 64x64, 32x32 y 64x64.

La mayoría de juegos utilizan la primera opcion de 8x8 y 16x16(para el sprite "pequeño" será de 8x8 y "grande" será de 16x16), por ejemplo: Super Mario World, Zelda, Donkey Kong Contry(los tres), Mario kart, Fzero, Batman Returns, Contra 3, Super Rtype, graduis 3, etc, utilizan esta configuracion. He visto otros juegos que utilizan la opcion de 16x16 y 32x32(16x16 "pequeño" y 32x32 "grande") como Rtype 3, Final fight 2 y 3.
La desventaja de usar la opcion de 8x8 y 16x16, es que para hacer sprites de 32x32 por ejemplo, se necesitan 4 sprites de 16x16, por ejemplo en Mario Kart el personaje del jugador tiene 4 sprites de 16x16, en f-zero la nave del jugador tiene 6 sprites de 16x16, y en Batman Returns he visto que incluso se llega al limite de 128 sprites y por eso se empiezan a desaparecer algunas partes de los objetos (esto lo he podido ver gracias al emulador no$sns, que se pueden "ver" los sprites en acción).

Otro limite que tiene el snes es que solo se pueden utilizar 512 tiles(16KB) para sprites (en el Genesis/Megadrive no hay ese limite, se pudiera utilizar toda la Vram para sprites, es decir 2048 tiles).
Es quizas por este limite que la mayoría de juegos utilizan la configuracion de 8x8 y 16x16 para los sprites, ya que si se utiliza otra configuracion se pueden utilizar mas tiles de lo necesario.

Ahora sobre el DMA, según algunos documentos que he visto es de 165.5 bytes por linea, esto es así: hay un clock de 21.4 mhz(que son 1364 "ciclos") que es dividido entre 8(que son 170.5 ciclos) que es el "clock" que utiliza el DMA, esto da como resultado 170.5 bytes por linea, pero como la Ram principal es del tipo dinámica, se necesitan unos pulsos de refresco, en este caso son 40 ciclos que se restan de los 1364, y quedan 1324, entonces cuando se divide entre 8 se obtienen los 165.5 bytes por linea.

Hay otra cosa que hace que los sprites no sean "tan fácilies de manejar", y es debido a como están distribuidos los atributos de los sprites:

En total hay 544 bytes de una Ram interna para los sprites, primero hay 512 bytes que contienen 4 bytes por sprite que son:

byte 0 = X coordenada (8 bit)
byte 1 = Y coordenada (8 bit)
byte 2 = tile number (8 bit)
byte 3 = atributos: bit7 y-flip, bit 6 x-flip, bit 5-4 prioridad, bit 3-1 paleta numero, bit 0 = el noveno bit del "tile number" (con este bit se obtienen los 512 tiles).

Despues de los 512 bytes, hay otros 32 bytes adicionales, en donde se usan 2 bits por sprite (es decir 4 sprites por byte):

bit 7 = obj 3 size (0 = pequeño, 1 = grande)
bit 6 = obj 3 x coordenada (bit 9 de la coordenada x) con este bit se tienen los 512 valores para la posicion x del sprite.

bit 5 = obj 2 size (0 = pequeño, 1 = grande)
bit 4 = obj 2 x coordenada (bit 9 de la coordenada x)

bit 3 = obj 1 size (0 = pequeño, 1 = grande)
bit 2 = obj 1 x coordenada (bit 9 de la coordenada x)

bit 1 = obj 0 size (0 = pequeño, 1 = grande)
bit 0 = obj 0 x coordenada (bit 9 de la coordenada x)

siguiente byte:
bit 7 = obj 7 size (0 = pequeño, 1 = grande)
bit 6 = obj 7 x coordenada (bit 9 de la coordenada x)

bit 5 = obj 6 size (0 = pequeño, 1 = grande)
bit 4 = obj 6 x coordenada (bit 9 de la coordenada x)

....etc

Como podrán ver la coordenada "Y" es de 8 bit, esto significa que solo puede variar de 0 a 255.


Esta "organización" de los atributos de los sprites hace mas difícil programar los sprites en el snes, por ejemplo para cambiar la coordenada "X" de un sprite se necesita modificar el bit 9 de la coordenada "X" de un byte que "comparten" 4 sprites, y por esto se requiere enmascarar bits(AND, OR, etc) ya que un solo byte tiene 4 sprites y se debe mantener los demás bits que no sean del sprite que se esta usando en ese momento, y para cambiar el tamaño de un sprite(entre "pequeño" y "grande") es lo mismo.

Toda esta información del snes, y también sobre el tamaño de sprites que tienen algunos juegos, los he podido ver gracias al emulador "no$sns", porque aunque no es un emulador muy bueno, tiene un excelente debugger, en donde se pueden ver ademas del código que se está ejecutando, también como se forman los sprites(los tamaños usados), los fondos, paletas, etc, ademas tiene una gran cantidad de documentación sobre todo lo que se necesita saber del snes.


Ahora en el Genesis/Megadrive, cada sprite contiene 8 bytes(o 4 words) y los atributos de los sprites es asi:

word 0 = -------Y YYYYYYYY
Y = Y coordenada (512 valores para Y)

word 1 = ----hhvv -LLLLLLL
h = tamaño h en tiles, v = tamaño v en tiles, (8, 16, 24, 32)
L = link = este valor indica el próximo sprite a dibujar, si este valor es cero no se dibujaran mas sprites.

word 2 = pccvhnnn nnnnnnnn
p = prioridad
c = paleta numero
v = v flip, h = hflip
n = pattern( o tile numero)

word 3 = ------X XXXXXXXX
X = X coordenada (512 valores para X)

Se usan 640 bytes de Vram para el modo de H40, o 512 bytes para el modo de H32.


En el Genesis/Megadrive para manejar los sprites se hace mucho mas fácil, ya que las coordenadas "X" y "Y" no se requiere "enmascarar" bits, también tiene la ventaja de que se pueden usar cualquier tamaño de sprite, es decir pueden haber sprites de 8x8, 16x24, 32x32, 32x8, etc, al mismo tiempo.
Para mi no tiene mucho sentido que siendo el Snes una consola que salió después, debería tener el manejo de los sprites mas fácil (ademas porque el CPU no ayuda mucho tampoco).
Creo que la principal razon de que muchos juegos se "ralentizan"(ademas del CPU) es por usar la opción de 8x8 y 16x16, ya que ademas de lo complicado que es para obtener la coordenada X completa y el tamaño de un sprite, ademas se usan mas sprites por objeto, por ejemplo, para un objeto de 32x32 se necesitaran 4 sprites, debido a todo esto se necesita mas uso de CPU de lo que se requiere en el genesis/megadrive. Tambien hay que entender que si se usa, por ejemplo los tamaños de sprites mayores, por ejemplo de 16x16 y 32x32, se pudieran "malgastar" tiles, y como hay un limite maximo de 512 tiles no habría tanta "variedad" de sprites.
gasega68k escribió:He visto algunos errores en algunos comentarios sobre algunas cosas y por eso me sentí obligado a escribir en este hilo. :)

Sobre los sprites en el Genesis/Megadrive: en el modo H40 (320) hay un máximo de 80 sprites, 20 por linea y tambien existe el limite por pixel que es de 320, por ejemplo, puede haber un maximo de 20 sprites de 16x16 por linea, o 10 sprites de 32x32 por linea, etc, es decir puede cubrir 320 pixeles de sprites. En el modo H32(256) hay un maximo de 64 sprites y 16 por linea, y también está el limite por pixel que en este caso es de 256, por ejemplo pueden estar 16 sprites de 16x16 por linea, o 8 sprites de 32x32 por linea, etc, cubriendo un máximo de 256 pixeles.
Los sprites pueden tener cualquiera de estos tamaños: 8x8, 8x16, 8x24, 8x32, 16x8, 16x16, 16x24, 16x32, 24x8, 24x16, 24x24, 24x32, 32x8, 32x16, 32x24, 32x32.

Ahora sobre el DMA, en los documentos oficiales(sega2.doc) se decía que era de 205 bytes por linea para H40 y 167 para H32, pero esto no es correcto, primero existe diferencias cuando el DMA es hacia la VRAM y cuando es hacia CRAM/VSRAM(color ram/vscroll ram), cuando es DMA hacia la VRAM la transferencia es en bytes, y es de 204 bytes por linea en el modo H40, y 166 bytes por linea en H32, ahora cuando es DMA hacia CRAM/VSRAM la transferencia es en words, y es de 198(words) por linea para el modo H40 y 161 para el modo H32.

Existe una explicación muy detallada sobre todo esto en un "topic" del foro "spritesmind" realizada por "Mask of Destiny" y que tambien interviene "Nemesis", llamado "Vdp internals" (esta en ingles) y ademas todo esto fue probado en el "hardware real":
http://gendev.spritesmind.net/forum/vie ... php?t=1291


El Snes sobre los sprites: hay un máximo de 128 sprites, 32 por linea y también tiene un limite por pixel que es de 272(no estoy muy seguro de esto, en algunos lugares he visto 256), esto quiere decir por ejemplo que puede haber 17 sprites de 16x16 por linea, o 8 sprites "y medio" :p de 32x32, cubriendo un máximo de 272 pixeles.

A diferencia del genesis/megadrive en el snes cada sprite puede tener solo 2 tamaños ("pequeño" y "grande") y estos tamaños se configuran a traves de un registro y que será para todos los sprites, y los tamaños son los siguientes: 8x8 y 16x16, 8x8 y 32x32, 8x8 y 64x64, 16x16 y 32x32, 16x16 y 64x64, 32x32 y 64x64.

La mayoría de juegos utilizan la primera opcion de 8x8 y 16x16(para el sprite "pequeño" será de 8x8 y "grande" será de 16x16), por ejemplo: Super Mario World, Zelda, Donkey Kong Contry(los tres), Mario kart, Fzero, Batman Returns, Contra 3, Super Rtype, graduis 3, etc, utilizan esta configuracion. He visto otros juegos que utilizan la opcion de 16x16 y 32x32(16x16 "pequeño" y 32x32 "grande") como Rtype 3, Final fight 2 y 3.
La desventaja de usar la opcion de 8x8 y 16x16, es que para hacer sprites de 32x32 por ejemplo, se necesitan 4 sprites de 16x16, por ejemplo en Mario Kart el personaje del jugador tiene 4 sprites de 16x16, en f-zero la nave del jugador tiene 6 sprites de 16x16, y en Batman Returns he visto que incluso se llega al limite de 128 sprites y por eso se empiezan a desaparecer algunas partes de los objetos (esto lo he podido ver gracias al emulador no$sns, que se pueden "ver" los sprites en acción).

Otro limite que tiene el snes es que solo se pueden utilizar 512 tiles(16KB) para sprites (en el Genesis/Megadrive no hay ese limite, se pudiera utilizar toda la Vram para sprites, es decir 2048 tiles).
Es quizas por este limite que la mayoría de juegos utilizan la configuracion de 8x8 y 16x16 para los sprites, ya que si se utiliza otra configuracion se pueden utilizar mas tiles de lo necesario.

Ahora sobre el DMA, según algunos documentos que he visto es de 165.5 bytes por linea, esto es así: hay un clock de 21.4 mhz(que son 1364 "ciclos") que es dividido entre 8(que son 170.5 ciclos) que es el "clock" que utiliza el DMA, esto da como resultado 170.5 bytes por linea, pero como la Ram principal es del tipo dinámica, se necesitan unos pulsos de refresco, en este caso son 40 ciclos que se restan de los 1364, y quedan 1324, entonces cuando se divide entre 8 se obtienen los 165.5 bytes por linea.

Hay otra cosa que hace que los sprites no sean "tan fácilies de manejar", y es debido a como están distribuidos los atributos de los sprites:

En total hay 544 bytes de una Ram interna para los sprites, primero hay 512 bytes que contienen 4 bytes por sprite que son:

byte 0 = X coordenada (8 bit)
byte 1 = Y coordenada (8 bit)
byte 2 = tile number (8 bit)
byte 3 = atributos: bit7 y-flip, bit 6 x-flip, bit 5-4 prioridad, bit 3-1 paleta numero, bit 0 = el noveno bit del "tile number" (con este bit se obtienen los 512 tiles).

Despues de los 512 bytes, hay otros 32 bytes adicionales, en donde se usan 2 bits por sprite (es decir 4 sprites por byte):

bit 7 = obj 3 size (0 = pequeño, 1 = grande)
bit 6 = obj 3 x coordenada (bit 9 de la coordenada x) con este bit se tienen los 512 valores para la posicion x del sprite.

bit 5 = obj 2 size (0 = pequeño, 1 = grande)
bit 4 = obj 2 x coordenada (bit 9 de la coordenada x)

bit 3 = obj 1 size (0 = pequeño, 1 = grande)
bit 2 = obj 1 x coordenada (bit 9 de la coordenada x)

bit 1 = obj 0 size (0 = pequeño, 1 = grande)
bit 0 = obj 0 x coordenada (bit 9 de la coordenada x)

siguiente byte:
bit 7 = obj 7 size (0 = pequeño, 1 = grande)
bit 6 = obj 7 x coordenada (bit 9 de la coordenada x)

bit 5 = obj 6 size (0 = pequeño, 1 = grande)
bit 4 = obj 6 x coordenada (bit 9 de la coordenada x)

....etc

Como podrán ver la coordenada "Y" es de 8 bit, esto significa que solo puede variar de 0 a 255.


Esta "organización" de los atributos de los sprites hace mas difícil programar los sprites en el snes, por ejemplo para cambiar la coordenada "X" de un sprite se necesita modificar el bit 9 de la coordenada "X" de un byte que "comparten" 4 sprites, y por esto se requiere enmascarar bits(AND, OR, etc) ya que un solo byte tiene 4 sprites y se debe mantener los demás bits que no sean del sprite que se esta usando en ese momento, y para cambiar el tamaño de un sprite(entre "pequeño" y "grande") es lo mismo.

Toda esta información del snes, y también sobre el tamaño de sprites que tienen algunos juegos, los he podido ver gracias al emulador "no$sns", porque aunque no es un emulador muy bueno, tiene un excelente debugger, en donde se pueden ver ademas del código que se está ejecutando, también como se forman los sprites(los tamaños usados), los fondos, paletas, etc, ademas tiene una gran cantidad de documentación sobre todo lo que se necesita saber del snes.


Ahora en el Genesis/Megadrive, cada sprite contiene 8 bytes(o 4 words) y los atributos de los sprites es asi:

word 0 = -------Y YYYYYYYY
Y = Y coordenada (512 valores para Y)

word 1 = ----hhvv -LLLLLLL
h = tamaño h en tiles, v = tamaño v en tiles, (8, 16, 24, 32)
L = link = este valor indica el próximo sprite a dibujar, si este valor es cero no se dibujaran mas sprites.

word 2 = pccvhnnn nnnnnnnn
p = prioridad
c = paleta numero
v = v flip, h = hflip
n = pattern( o tile numero)

word 3 = ------X XXXXXXXX
X = X coordenada (512 valores para X)

Se usan 640 bytes de Vram para el modo de H40, o 512 bytes para el modo de H32.


En el Genesis/Megadrive para manejar los sprites se hace mucho mas fácil, ya que las coordenadas "X" y "Y" no se requiere "enmascarar" bits, también tiene la ventaja de que se pueden usar cualquier tamaño de sprite, es decir pueden haber sprites de 8x8, 16x24, 32x32, 32x8, etc, al mismo tiempo.
Para mi no tiene mucho sentido que siendo el Snes una consola que salió después, debería tener el manejo de los sprites mas fácil (ademas porque el CPU no ayuda mucho tampoco).
Creo que la principal razon de que muchos juegos se "ralentizan"(ademas del CPU) es por usar la opción de 8x8 y 16x16, ya que ademas de lo complicado que es para obtener la coordenada X completa y el tamaño de un sprite, ademas se usan mas sprites por objeto, por ejemplo, para un objeto de 32x32 se necesitaran 4 sprites, debido a todo esto se necesita mas uso de CPU de lo que se requiere en el genesis/megadrive. Tambien hay que entender que si se usa, por ejemplo los tamaños de sprites mayores, por ejemplo de 16x16 y 32x32, se pudieran "malgastar" tiles, y como hay un limite maximo de 512 tiles no habría tanta "variedad" de sprites.


Gasega, eres una autentica MAQUINA [tadoramo]
gasega68k escribió:...


Que pena que me pillas fatal de tiempo xDD

Además, quiero comentar algo sobre las dos tablas OAM de la snes (es una, pero tu ya me entiendes).


Primera tabla (512 Bytes):
-Byte 1: Posición X del sprite en la pantalla (0-255)
-Byte 2: Posición Y del sprite en la pantalla (0-255)
-Byte 3: Número de tile que representa al sprite. Este tercer byte conforma el aspecto final de los sprites.
-Byte 4 está conformado por:
·1 bit para la posición horizontal
·1 bit para la posición vertical
·2 bits para la prioridad (superposición)
·3 bits para la paleta de colores
·1 bit para el número alto del tile (debe ser una cabecera que es usada de referencia en el tercer byte, para determinar con que otros se unen)

La segunda tabla (32 Bytes) proporciona 2 bits mas de información por sprite (128 sprites*2bits=256bits/8=32bytes), pero no tengo ni idea de que hace.

Tengo en la cabeza metido que agrega un valor positivo o negativo a algún tipo de función por hardware, pero ahora mismo estoy en blanco.
gasega68k escribió:He visto algunos errores en algunos comentarios sobre algunas cosas y por eso me sentí obligado a escribir en este hilo. :)

Sobre los sprites en el Genesis/Megadrive: en el modo H40
.....
se pudieran "malgastar" tiles, y como hay un limite maximo de 512 tiles no habría tanta "variedad" de sprites.


[tadoramo] [tadoramo]
Bravo GASEGA y al resto que ha aportado luz al tema.

[bye] [bye]
Por lo visto el video del Rendering Ranger de SNES a pelo no ayuda mucho.Erre con erre que SNES es cáncer en el manejo de sprites.
Yo siempre consideré mejor la SNES.
Solieyu escribió:Por lo visto el video del Rendering Ranger de SNES a pelo no ayuda mucho.Erre con erre que SNES es cáncer en el manejo de sprites.

El vídeo del RR no tiene nada especialmente destacable, las explosiones de las naves se multiplican y parece que hay mas sprites de los que realmente hay, en el Gynoug hay momentos similares y es un juego de 4 megas de 1991. Hay partes mucho mas espectaculares en ese juego que la mostrada en el vídeo.

Me como mis palabras, gasega, te comes ha Nintendo aun con sus millones!!! :Ð
robotnik16 escribió:El vídeo del RR no tiene nada especialmente destacable, las explosiones de las naves se multiplican y parece que hay mas sprites de los que realmente hay


Me temo que eso no funciona así.

P.D: Y ya que lo compares técnicamente con el gynoug, tiene delito. No hay ni un solo shooter de esa talla técnica en 16 bits que funcione tan fino.
No veo más que unos sprites/objetos que como tú mismo comentaste en otros ejemplos, tienen una IA justa, animación correcta, una caja de colisiones amplia, no hay balas y no son extremadamente grandes. Insisto en que las explosiones hacen un efecto óptico y parece que hay aun más chicha de la que realmente hay. No sé por qué esa parte del RR te parece tan impresionante a nivel técnico (que lo es), y los 13 sprites del SOR "no tienen tanto mérito" e incluso se podrían haber metido más...

No saquemos las cosas del tiesto, no comparo técnicamente el RR con el Gynoug, es más, el RR seguramente sea uno de los juegos de SNES mejor optimizados, teniendo muy presente las virtudes y carencias de la consola (también hay que mirar el año de programación y quién está detrás del juego), sólo quise hacer referencia al tema de los sprites que comentó un compañero unos mensajes antes. La talla técnica del RR es muy alta, al igual que hay otros shooters que también brillan con luz propia, pero no creo que haya que considerarlo mejor que otros, ya no de sólo de MD, también de SNES...
.
Calculinho escribió:En resumen tenéis una idea de un juego para 16bits (a lo Pier Solar) y vuestra idea original pone ambas consolas un poquito por encima de su limite. Cual os permitiría tener que "recortar" menos vuestra idea original?


Esa pregunta no te la van a poder responder con exactitud, porque depende mucho de la idea que se tenga y de lo que sea necesario recortar; no estamos hablando de una arquitectura mejor que otra en niveles lineales (como por ejemplo de un iphone al siguiente iphone), sino que cada una tienes sus pros y contras respecto a la otra.
Esa respuesta puedes tenerla tú mismo mirando respondiendote a la siguiente pregunta.. ¿qué sistema tiene más desarrollo homebrew? Hay bastante más movimiento en la Megadrive como habrás visto. La snes se deja manosear bastante menos.
por que megadrive mola mas
Mega es más pura, más arcade y no tiene chips de apoyo en sus juegos para maquillar la falta de potencia y optimizar el hard (Virtua Racing fue un quiero y no puedo, no supieron ni pudieron explotar el SVP).

Así que está claro para mi. Mega Drive y punto.

Salu2.
Naitguolf escribió:Esa respuesta puedes tenerla tú mismo mirando respondiendote a la siguiente pregunta.. ¿qué sistema tiene más desarrollo homebrew? Hay bastante más movimiento en la Megadrive como habrás visto. La snes se deja manosear bastante menos.


Ese razonamiento es incorrecto, mayor o menor actividad homebrew puede deberse simplemente a facilidad para programar en ella y no por ello ser más potente. Si no recuerdo mal Saturn es más potente que Psx, pero un infierno programar en ella, y creo que de la generación 128 bits la peor de todas es PS2 y es la segunda con mayor homebrew y la primera en número de ports y juegos.
releon escribió:Mega es más pura, más arcade y no tiene chips de apoyo en sus juegos para maquillar la falta de potencia y optimizar el hard (Virtua Racing fue un quiero y no puedo, no supieron ni pudieron explotar el SVP).

Así que está claro para mi. Mega Drive y punto.

Salu2.


¿Falta de potencia snes?... ¿SNES?...

Lo primero, es que menos de un 2% del catálogo de snes lleva un chip de apoyo en el cartucho, y además, unos cuántos de ellos los llevan de forma anecdótica, o sin necesitarlo realmente (como por ejemplo el mario kart, que lleva uno, pero la snes puede de sobra con eso).

Lo reducís todo a la cpu, pero os olvidais de que en snes, al contrario que megadrive, tiene un sistema de vídeo con un pixel fill rate TAN burro, que permite 4 efectos raster por pixel simultáneos (mas lo que pueda aportar la snes). Un street racer a 4 jugadores no es ninguna broma en cuanto a capacidad de proceso.
Calculinho escribió:Viendo que no hay una respuesta técnica clara de alguien con conocimientos de programación y hardware "antiguo" lanzo una pregunta al aire a ver si así infierno cual es la mejor como consola en conjunto.

Igual nadie puede responderme a ella pues va dirigida a un colectivo muy reducido: Los que sabéis como programar un juego para Snes y MD (me ha quedado claro que la Turbo ocupa el tercer puesto) a fecha actual, para cual programaríais vuestro juego suponiendo que para vuestra idea original pide más potencia en cualquiera de ellas y por tanto vais a tener que hacer un ligero, muy ligero, pero necesario downgrade?

En resumen tenéis una idea de un juego para 16bits (a lo Pier Solar) y vuestra idea original pone ambas consolas un poquito por encima de su limite. Cual os permitiría tener que "recortar" menos vuestra idea original?


te la respondo yo, como programador Homebrew: Megadrive. Y no por que sea mas potente, pero tiene una arquitectura mucho más clara y sencilla que la Super. En la super sufrí para conseguir hacer un simple scroll con los SDK's que había en ese momento.
Calculinho escribió:
Naitguolf escribió:Esa respuesta puedes tenerla tú mismo mirando respondiendote a la siguiente pregunta.. ¿qué sistema tiene más desarrollo homebrew? Hay bastante más movimiento en la Megadrive como habrás visto. La snes se deja manosear bastante menos.


Ese razonamiento es incorrecto, mayor o menor actividad homebrew puede deberse simplemente a facilidad para programar en ella y no por ello ser más potente. Si no recuerdo mal Saturn es más potente que Psx, pero un infierno programar en ella, y creo que de la generación 128 bits la peor de todas es PS2 y es la segunda con mayor homebrew y la primera en número de ports y juegos.


Es que eso y todas las deducciones que estás sacando te conducen a Megadrive como respuesta. ¿por qué van a querer portar juegos para SNES teniendo una Megadrive que les da más facilidades de desarrollo y está igualmente a un buen nivel?

Eso hablando de la situación real, basándonos en lo que dice gente que desarrolla y sabe como @kusfo79 , @gasega68k y @theelf , no elucubrando pensando en lo que pasaría si tuvieran más info de snes y tal.
Calculinho escribió:Ese razonamiento es incorrecto, mayor o menor actividad homebrew puede deberse simplemente a facilidad para programar en ella y no por ello ser más potente. Si no recuerdo mal Saturn es más potente que Psx, pero un infierno programar en ella, y creo que de la generación 128 bits la peor de todas es PS2 y es la segunda con mayor homebrew y la primera en número de ports y juegos.


No diria tanto la facilidad, como si no la afinidad a la arquitectura. Muchos programadores, donde me incluyo, crecimos con ordenadores de funcionamiento similar a la MD, especialmente con misma arquitectura, y eso no es que ayude, pero si que pesa mucho en la balanza para elegir la plataforma habitual

Ademas obviamente, de que la MD tiene una arquitectura sumamente simple, pero a la vez extremadamente potente, ideal para desarrollar

De ultimo, por lo que he visto, tambien hay que decir que la megadrive tiene una base de usuarios muchisimo mas amplia que snes, lo que repercute tambien en mas cantidad de gente interesada en ella
gynion escribió:¿por qué van a querer portar juegos para SNES teniendo una Megadrive que les da más facilidades de desarrollo y está igualmente a un buen nivel?


Porque saldrían mejores juegos.
FFantasy6 escribió:Porque saldrían mejores juegos.


Si los portas tu, seguramente
FFantasy6 escribió:
gynion escribió:¿por qué van a querer portar juegos para SNES teniendo una Megadrive que les da más facilidades de desarrollo y está igualmente a un buen nivel?


Porque saldrían mejores juegos.


Eso dependerá de las necesidades del juego y de la dificultad a la hora de programar de forma underground para snes.
J.Sanchez está baneado por "clon de usuario baneado"
Sobre el papel la cpu de megadrive se zampaba a la tortuga de nintendo.
snes era incapaz de mover un sonic 2 o 3 con esa velocidad y esa profundidad de scroles.
imposible.
la ventaja de snes eran los chips de apoyo a la cpu.
en MD era el z80 que tb hacia de chip sonoro pero en snes habia lo que hoy son las gpus, chip grafici de apoyo para efectos, paleta, sprites ... sin contar el sonido 100% libre de carga de cpu con el chip sony.
en MD todo recaía en la cpu.
en snes se repartía el trabajo y ni aún así toraría bien con un sonic 3.
MD tendrá el merito de tener juegos como dinamite heady, gunstar heroes, comix zone, thunder 4, rocket knight, ristar, que mostraban autenticas proezas visuales sin apoyo de chips suplementarios.
Con todo eso hay que reconocer que snes ganaba por goleada en paleta de color, numero y tamaño de sprites, sonido (aunque eso va en gustos) y sobre todo en el modo 7 tan egectivo para la epoca.
J.Sanchez escribió:Sobre el papel la cpu de megadrive se zampaba a la tortuga de nintendo.
snes era incapaz de mover un sonic 2 o 3 con esa velocidad y esa profundidad de scroles.
imposible.
la ventaja de snes eran los chips de apoyo a la cpu.
en MD era el z80 que tb hacia de chip sonoro pero en snes habia lo que hoy son las gpus, chip grafici de apoyo para efectos, paleta, sprites ... sin contar el sonido 100% libre de carga de cpu con el chip sony.
en MD todo recaía en la cpu.
en snes se repartía el trabajo y ni aún así toraría bien con un sonic 3.
MD tendrá el merito de tener juegos como dinamite heady, gunstar heroes, comix zone, thunder 4, rocket knight, ristar, que mostraban autenticas proezas visuales sin apoyo de chips suplementarios.
Con todo eso hay que reconocer que snes ganaba por goleada en paleta de color, numero y tamaño de sprites, sonido (aunque eso va en gustos) y sobre todo en el modo 7 tan egectivo para la epoca.

y para mi en catalogo tambien ,final fantasy ,rpgs de square y enix ,megaman x saga ,todo lo que pario konami(parodius ,axelay ,goemon ,gradius ) y los arcades de capcom como king of dragon ,capitan comando y compañia,demons crest .
aparte de exclusivos de nintendo como super metroid ,zelda ,mario ,f zero ,saga donkey kong .
para mi y para muchos una de las conoolas con el catalogo mas brutal de la historia.
y por cierto volvemos a lo de siempre a los chips de apoyo ,el catalogo de snes es tan amplio que es un porcentaje infimo y que yo recuerde lo mismo costaba un cartucho con chip que sin el a si que no se que problema hay .
juegos como f zero o axelay no utilizan chip de apoyo y a dia de hoy me sigue pareciendo bestiales .
theelf escribió:
FFantasy6 escribió:Porque saldrían mejores juegos.


Si los portas tu, seguramente


Idos a un hotel xDDD
J.Sanchez escribió:Sobre el papel la cpu de megadrive se zampaba a la tortuga de nintendo.
snes era incapaz de mover un sonic 2 o 3 con esa velocidad y esa profundidad de scroles.
imposible.
la ventaja de snes eran los chips de apoyo a la cpu.
en MD era el z80 que tb hacia de chip sonoro pero en snes habia lo que hoy son las gpus, chip grafici de apoyo para efectos, paleta, sprites ... sin contar el sonido 100% libre de carga de cpu con el chip sony.
en MD todo recaía en la cpu.
en snes se repartía el trabajo y ni aún así toraría bien con un sonic 3.
MD tendrá el merito de tener juegos como dinamite heady, gunstar heroes, comix zone, thunder 4, rocket knight, ristar, que mostraban autenticas proezas visuales sin apoyo de chips suplementarios.
Con todo eso hay que reconocer que snes ganaba por goleada en paleta de color, numero y tamaño de sprites, sonido (aunque eso va en gustos) y sobre todo en el modo 7 tan egectivo para la epoca.


La ventaja de la super era todo lo que su chip de video hacía ya de base (sin los chips de apoyo me refiero). Y eso de que en la mega todo lo hace la CPU ya lo hemos desmentido en este hilo.
titorino escribió:
J.Sanchez escribió:Sobre el papel la cpu de megadrive se zampaba a la tortuga de nintendo.
snes era incapaz de mover un sonic 2 o 3 con esa velocidad y esa profundidad de scroles.
imposible.
la ventaja de snes eran los chips de apoyo a la cpu.
en MD era el z80 que tb hacia de chip sonoro pero en snes habia lo que hoy son las gpus, chip grafici de apoyo para efectos, paleta, sprites ... sin contar el sonido 100% libre de carga de cpu con el chip sony.
en MD todo recaía en la cpu.
en snes se repartía el trabajo y ni aún así toraría bien con un sonic 3.
MD tendrá el merito de tener juegos como dinamite heady, gunstar heroes, comix zone, thunder 4, rocket knight, ristar, que mostraban autenticas proezas visuales sin apoyo de chips suplementarios.
Con todo eso hay que reconocer que snes ganaba por goleada en paleta de color, numero y tamaño de sprites, sonido (aunque eso va en gustos) y sobre todo en el modo 7 tan egectivo para la epoca.

y para mi en catalogo tambien ,final fantasy ,rpgs de square y enix ,megaman x saga ,todo lo que pario konami(parodius ,axelay ,goemon ,gradius ) y los arcades de capcom como king of dragon ,capitan comando y compañia,demons crest .
aparte de exclusivos de nintendo como super metroid ,zelda ,mario ,f zero ,saga donkey kong .
para mi y para muchos una de las conoolas con el catalogo mas brutal de la historia.
y por cierto volvemos a lo de siempre a los chips de apoyo ,el catalogo de snes es tan amplio que es un porcentaje infimo y que yo recuerde lo mismo costaba un cartucho con chip que sin el a si que no se que problema hay .
juegos como f zero o axelay no utilizan chip de apoyo y a dia de hoy me sigue pareciendo bestiales .


Lo que eran muy diferentes eran ya los precios de base: (Ojo, que ya se que no son exactamente del mismo año, pero ya vale)
Imagen
Imagen
lo que queria decir es que por ejemplo el stun race fx vale mas barato que otro juegos que no tenia chip especial ,y los precios variaban segun que tienda ,yo me compre el donkey kong country en toys'rus y me pegaron una clavada acojonante 14.900 ptas [+risas]
pero claro las ansias y el hype me pudieron ,los juegos de megadrive de base eran mas economicos ,pero ya tedigo que segun que tiendas ,llegue a ver el street fighter champion edition a 13.000 ptas
que buenos recuerdos me has hecho revivir con esos scans [buuuaaaa]
Ya ves, como molaba Centro Mail!
.
Calculinho escribió:Que ganas tenéis de decir que la "vuestra" es la más larga. Que no me interesa saber cual es más fácil de programar o más potente su CPU. Sino en cual habría que hacer menor downgrade para un proyecto que se les quede grande a ambas aunque para ello se necesitara 100 personas trabajando sin parar durante 2 años para hacerlo. Me parece muy bien que MD sea la mejor para programar usando para casi todo su CPU que es más potente y no lo discuto, pero en conjunto usando ambas al 100% todos sus componentes (chips en cartuchos incluidos) cual permitiría sacar el juego más "potente" en total. Si queréis otro ejemplo, cual de las dos permitiría tener un juego en cartucho lo más parecido a los primeros que salieron en la generación 32bits.

Edit: No empecéis a analizar juego por juego cual se podría portear y cual no que no es el tema, pero por si ayuda a hacerse una idea de que juegos se lanzaron en los inicios de las 32bits estos son algunos: Tekken, Battle Arena Toshinden, Discworld, Actua Soccer, Ridge Racer, Clockwork Knight, International Victory Goal, Daytona USA.



Tenemos hasta un ejemplo real, porque ocurrio: Super Nintendo con SF Alpha 2. :)
@ZIDEVS Gracias y ¿Cual es ese ejemplo?


Edit: Sorry no había visto lo de SF Alpha 2.
titorino escribió:lo que queria decir es que por ejemplo el stun race fx vale mas barato que otro juegos que no tenia chip especial ,y los precios variaban segun que tienda ,yo me compre el donkey kong country en toys'rus y me pegaron una clavada acojonante 14.900 ptas [+risas]
pero claro las ansias y el hype me pudieron ,los juegos de megadrive de base eran mas economicos ,pero ya tedigo que segun que tiendas ,llegue a ver el street fighter champion edition a 13.000 ptas
que buenos recuerdos me has hecho revivir con esos scans [buuuaaaa]


Y eso los que vivian en el primer mundo...

Nunca voy a olvidar la primera y ultima vez que vi una SNES... fui a preguntar, y cada juego costaba al menos 10 veces lo que uno de megadrive, recuerdo patente el calculo

No hay mas que decir, que la SNES era algo que se leia en las revistas que venian de españa [+risas] jamas volvi a ver una
Calculinho escribió:Que ganas tenéis de decir que la "vuestra" es la más larga. Que no me interesa saber cual es más fácil de programar o más potente su CPU. Sino en cual habría que hacer menor downgrade para un proyecto que se les quede grande a ambas aunque para ello se necesitara 100 personas trabajando sin parar durante 2 años para hacerlo. Me parece muy bien que MD sea la mejor para programar usando para casi todo su CPU que es más potente y no lo discuto, pero en conjunto usando ambas al 100% todos sus componentes (chips en cartuchos incluidos) cual permitiría sacar el juego más "potente" en total. Si queréis otro ejemplo, cual de las dos permitiría tener un juego en cartucho lo más parecido a los primeros que salieron en la generación 32bits.


Megadrive + SVP.
Calculinho escribió:Que ganas tenéis de decir que la "vuestra" es la más larga. Que no me interesa saber cual es más fácil de programar o más potente su CPU. Sino en cual habría que hacer menor downgrade para un proyecto que se les quede grande a ambas aunque para ello se necesitara 100 personas trabajando sin parar durante 2 años para hacerlo. Me parece muy bien que MD sea la mejor para programar usando para casi todo su CPU que es más potente y no lo discuto, pero en conjunto usando ambas al 100% todos sus componentes (chips en cartuchos incluidos) cual permitiría sacar el juego más "potente" en total. Si queréis otro ejemplo, cual de las dos permitiría tener un juego en cartucho lo más parecido a los primeros que salieron en la generación 32bits.

Edit: No empecéis a analizar juego por juego cual se podría portear y cual no que no es el tema, pero por si ayuda a hacerse una idea de que juegos se lanzaron en los inicios de las 32bits estos son algunos: Tekken, Battle Arena Toshinden, Discworld, Actua Soccer, Ridge Racer, Clockwork Knight, International Victory Goal, Daytona USA.

Es que con los juegos que pones, que son 3d,la pregunta és algo rara. Yo coincidiría en mega con SVP, pero es que igualmente Super con super fx2 no és muy diferente
Calculinho escribió:
Naitguolf escribió:Esa respuesta puedes tenerla tú mismo mirando respondiendote a la siguiente pregunta.. ¿qué sistema tiene más desarrollo homebrew? Hay bastante más movimiento en la Megadrive como habrás visto. La snes se deja manosear bastante menos.


Ese razonamiento es incorrecto, mayor o menor actividad homebrew puede deberse simplemente a facilidad para programar en ella y no por ello ser más potente. Si no recuerdo mal Saturn es más potente que Psx, pero un infierno programar en ella, y creo que de la generación 128 bits la peor de todas es PS2 y es la segunda con mayor homebrew y la primera en número de ports y juegos.


Yo aquí no estoy diciendo que el motivo sea que es más potente. Digo que mirando la cantidad de homebrew que hay en una u otra consola es indicador de cuál será más sencillo y más rápido tener resultados tangibles. Y uno de los motivos es por que es más sencilla de programar amén de tener mejores kits para programar, y más documentados, más foros donde consultar, etc, etc. Cada poco están sacando juegos nuevos para la mega. En la snes sacan prácticamente nada y menos... y ahora con las nulas limitaciones gracias a los cartuchos flash se podrían sacar burradas en la Snes y más con el fantástico MSU-1 (¡¡¡Ojalá hicisen lo mismo metiendo el chip de sonido del MegaCD en un cartucho flash para poder hacer lo mismo!!!)
Naitguolf escribió:Yo aquí no estoy diciendo que el motivo sea que es más potente. Digo que mirando la cantidad de homebrew que hay en una u otra consola es indicador de cuál será más sencillo y más rápido tener resultados tangibles. Y uno de los motivos es por que es más sencilla de programar amén de tener mejores kits para programar, y más documentados, más foros donde consultar, etc, etc. Cada poco están sacando juegos nuevos para la mega. En la snes sacan prácticamente nada y menos... y ahora con las nulas limitaciones gracias a los cartuchos flash se podrían sacar burradas en la Snes y más con el fantástico MSU-1 (¡¡¡Ojalá hicisen lo mismo metiendo el chip de sonido del MegaCD en un cartucho flash para poder hacer lo mismo!!!)


El MSU puede hacer de segundo procesador de audio, reproducir vídeo, e imitar el funcionamiento de chips de apoyo, pero eso son solo migajas... lo mejor que tiene es algo de lo que la gente no se percata.
Lo que hace el msu, y que influye muchísimo en el rendimiento, es que se quita de enmedio el DMA, pasando a tener un bus que transfiere a 72 megabits por segundo (73,728KB) sin provocar además que la cpu, ni ningún componente se pare.

Para el que no sepa el alcance de esto, significa que puede mover 1'2 megabits POR FRAME (1228Kbits).
Llenas la memoria de vídeo en un solo frame (64KB, o 512Kbits), y te queda un ancho de banda de 716Kbits para llenar la memoria ram, o la ram del SPC700. Y eso solo es en una mínima fracción de un segundo.

Es una auténtica brutalidad. La memoria de vídeo de 64KB, a efectos pasa a ofrecer un rendimiento equivalente a como si fuese de varios megabits.
Eso si, no es posible meter mano en la memoria ram durante cada uno de los 50/60 frames porque tienen una cierta latencia (es una cuestión física, no de la latencia impuesta por el DMA, puesto que en este caso no se usa), y por fuerza no podrá sincronizar siempre... pero hablamos de fallar solo unos pocos frames de los 50/60.

Vamos, que sigue siendo una inmensidad. No quiero ni imaginar la clase de rendimiento que se podría conseguir... es que un cartucho de 95 megas se quedaría cortísimo (pero por suerte, con el msu puedes hacer un juego de hasta 4GB, aunque mapeados en bloques de 95 megas, que son los que puede direccionar snes).
Lo más importante el MSU-1 es que sigue en desarrollo y nada impedirá sacar el MSU-2 que vaya limando las limitaciones que tiene.

Lo malo que más allá de los fantásticos hacks que irán saliendo, donde ahí se van a usar para meter música, videos (innecesarios en realidad, pero queda bonito) y malaprovechar el resto que hay, poco uso homebrew me da que van a darle, debido a la propia baja base de homebrew que tiene.

Pero bueno, gracias a los flashcards están dando muchísima vida a los dos viejos cacharros... y también quiero un MSU con SVP para Mega para que Gasega haga un DooM en condiciones o ¡meter el chip superscale de la recres de Sega para hacer un Galaxy Force II! 1:1 :P
207 respuestas
Archivado
1, 2, 3, 4, 5
Volver a Consolas clásicas