Comparativa "definitiva" de las 16 bits

1, 2, 3, 4, 5
theelf escribió:Ah para... ahora cambiastes de deficiente a basico... otro mundo


No, ahora no he cambiado nada, que ya es la tercera vez que lo repito.

Es básico, y eso es deficiente a la hora de acompañar a un 68000, se mire como se mire.

theelf escribió:Ahh...lo que hay que leer por estos foros...

El codigo es bueno para saber si una discucion sirve de algo o no, hay codigo? es productiva... sin codigo? es perdida de tiempo


Entonces nadie debería opinar.

Hay hechos que están contrastados, y no hace falta inagugurar un laboratorio para certificar los datos.

Sabemos que el motorola tiene que estar cumpliendo tareas mas allá de su función porque el VDP no se encarga, eso es un hecho. Y sabemos que si además quieres meter según que efectos gráficos, tampoco tienes al VDP ayudando en nada, de nuevo es la cpu la que tiene que perder ciclos de reloj en llevar a cabo esa función. Al final, ya no tienes 1MIPS en la cpu, partes de menos porque tienes que contar con que una parte de su potencia queda mermada de antemano.

Y si hablamos de fuerza bruta en si misma...
El VDP a 256x224 reduce su rendimiento a propósito. Pasa a manejar 64 sprites, y solo 10 por línea, pero además el DMA baja su ancho de banda a una tasa inferior a la de la snes.
Ahorras memoria de video, y eso viene bien si un juego es demasiado "grande" para los 64k de vram, pero joder, es deficiente teniendo en cuenta que al otro lado tienes un 68000 a casi 8mhz. ¿En serio no duelen a la vista estos números?.

A 320x240 la cosa funciona como tiene que funcionar. El DMA es un 20% mas rápido que el de snes, y durante la pantalla activa puede transferir a un 3% o 4% del total (irrisorio, pero vale para cuestiones menores).
Ahora, es lo que dije antes, una cosa es el dma, y otra muy diferente el desempeño de los chips gráficos, porque si comparamos el pixel fill rate, no hay color. Y este es el punto, el VDP de la megadrive no está a la altura de su CPU.


robotnik16 escribió:pero si hay algo que se suele oir, tanto a programadores actuales como a los de la época, es que si hay algo que caracterizaba precisamente a la MD era el equilibrio de su hardware, por eso mismo la afirmación de Señor Ventura me ha chocado. Sólo hay que ver cuando compañías importantes metían mano, juegos como Sonic, Ranger-X, Rocket Knight, Vectorman, Alien Soldier o Batman & Robin no pueden ser producto de una máquina deficiente (ojo, consola comercializada en 1988).


Megadrive es una máquina mucho mas versatil que snes, pero no mas equilibrada.

De hecho, si algo las define, es eso. Con megadrive tienes un hardware absolutamente nada rígido (cosa que si es la snes), mientras que la snes tiene un equilibrio tal, que prácticamente toda la capacidad de su cpu está dedicada a tareas de cpu, y así con todos los aspectos de su hardware.

Eso es lo que se decía... y claro, los programadores a veces prefieren elegir de que forma gastar los ciclos de reloj, aunque eso les suponga tener que escribir manualmente cada tarea.
Señor Ventura escribió:Es básico, y eso es deficiente a la hora de acompañar a un 68000, se mire como se mire.


Igual aquí cometes el mismo error que cometí yo en este mismo hilo, al querer analizar los componentes por separado, en vez de hacer una valoración general de la maquina; se haga de una u otra manera cada tarea, lo importante es que la pueda hacer, ¿no?

Además, también tendrías que pensar en que alternativas crees que había en su época (1988) para acompañar al 68000.

Lo del código seguramente te lo dicen porque es la mejor forma de analizar como se comporta la maquina en su conjunto, y en comparación a SNES, teniendo en cuenta el periodo de tiempo entre una y otra, creo que la Megadrive da la talla, y de hecho compartieron gen prácticamente de tú a tú.
Señor Ventura escribió:
Es básico, y eso es deficiente a la hora de acompañar a un 68000, se mire como se mire.


Se podía ofrecer algo mejor en 1989 por menos de 200$?
Señor Ventura escribió:Sabemos que el motorola tiene que estar cumpliendo tareas mas allá de su función porque el VDP no se encarga, eso es un hecho. Y sabemos que si además quieres meter según que efectos gráficos, tampoco tienes al VDP ayudando en nada, de nuevo es la cpu la que tiene que perder ciclos de reloj en llevar a cabo esa función. Al final, ya no tienes 1MIPS en la cpu, partes de menos porque tienes que contar con que una parte de su potencia queda mermada de antemano.

Y si hablamos de fuerza bruta en si misma...
El VDP a 256x224 reduce su rendimiento a propósito. Pasa a manejar 64 sprites, y solo 10 por línea, pero además el DMA baja su ancho de banda a una tasa inferior a la de la snes.
Ahorras memoria de video, y eso viene bien si un juego es demasiado "grande" para los 64k de vram, pero joder, es deficiente teniendo en cuenta que al otro lado tienes un 68000 a casi 8mhz. ¿En serio no duelen a la vista estos números?.

A 320x240 la cosa funciona como tiene que funcionar. El DMA es un 20% mas rápido que el de snes, y durante la pantalla activa puede transferir a un 3% o 4% del total (irrisorio, pero vale para cuestiones menores).
Ahora, es lo que dije antes, una cosa es el dma, y otra muy diferente el desempeño de los chips gráficos, porque si comparamos el pixel fill rate, no hay color. Y este es el punto, el VDP de la megadrive no está a la altura de su CPU.

.


Voy a aclarar unas cuantas cosas que se han comentado en este post, y que no son del todo ciertas.

Primero de todo, hablas de por que se programó el VDP con esas deficiencias, que por qué programó alguién que el límite de sprites fueran 60, etc. Ahí partes de una base erronea. El chip VDP está "programado" en hardware, no hay una línea de código en él. Por tanto, muchas de las limitaciones són físicas. Por ejemplo, la cantidad de sprites que puede pintar por linea, el número de planos que puede mover, etc.

A consecuencia de ello, el VDP no va nunca sobrecargado ni relajado. Siempre realiza el mismo trabajo en cada frame. Esté moviendo un plano o dos (la mega permite 2 planos), y esté moviendo un sprite o ochenta. En el 90% de los juegos que verás, todo el trabajo gráfico lo hace el VDP, menos quizás algun efectillo de tanto en tanto.

Por tanto, casi siempre, todo el trabajo lo está realizando el VDP, no el 68000. Es más, haciendo pruebas para Antarex, una demo que se dedicara solo a llenar la pantalla de ochenta enemigos (sin IA, recargas de tiles, etc, cosas que chupan CPU) apenas consume recursos del Motorola, que áun tiene poder para más.

Pero ojo, el VDP está pensado para lo que está pensado. Juegos con dos planos de scroll, 80 sprites en pantalla, y scrooll completo, por filas de tiles o por lineas de pixels. En memoria a la vez te caben unos 1200 tiles de 8x8 para ello. ¿Que pasa entonces cuando quieres hacer algo para lo que no está pensado? Pues que no solo lo tienes que hacer en la CPU, sino que encima has de engañar al VDP

Por ejemplo, para hacer 3D, has de guardart un buen tajo de tiles en memoria RAM, escribir sobre ellos las imagenes en 3D, y luego subirlas a la VRAM, cada frame. Algo terriblemente lento. Y ahí es donde se notan las desventajas de programar en una consola de esa generación.
Analizando los juegos que salieron y las explicaciones técnicas que dais, yo veo claro que a nivel arquitectura/programación no hay limitaciones o carencias palpables, sino herramientas distintas que conducen a unos resultados u otros. Las limitaciones del VDP de MD yo no las encuentro, o no las sé apreciar, si pones un TFIV y ves que hay niveles en los que aparecen mogollón de parallax, sprites de gran tamaño, deformaciones en los fondos, un colorido genial, musicón y una velocidad de scroll de vértigo, lo último que pienso es que alguno de los componentes de la consola (en este caso el VDP) no da la talla.

Pues eso, sin ser un especialista en estos temas, no tengo la sensación de que el VDP sea una castaña, y sin ánimo de ser fanboy, veo más limitado el procesador de la SNES respecto al resto de componentes, que el VDP sobre el Motorola. Hay cositas de juegos de SNES que también rechinan ehh, como cuando sacas un córner en el ISS Deluxe y ves que hay una ligera ralentización por acumulación de jugadores, las secuencias a paso de tortuga del Flashback, o las bajadas en algunos shoot 'em ups cuando hay que calcular la trayectoria de muchas balas... Por cosas de éstas, no sé que decirte en cuanto al equilibrio del hardware de ambas consolas...

Ahora bien, tampoco quita a que objetivamente SNES me parezca un hardware más avanzado por prestaciones puntuales (modo 7, ghost layering, paleta, sonido digital, etc...).
Sencillo, MD, le aguanto el tiron a la Snes, al principio, despues sega, se subio al carro de los 32 bits, y nintendo tuvo que tirar con lo que tenia, exprimiendo la snes, hasta cotas, que nunca se ha repetido en su haber.

Muchos de los titulos punteros, de snes, salieron con saturn y psx en la calle. Mientras salia Rockman & forte, en psx, teniamos Metal Gear Solid.

Tardo mucho la n64, y hubo que paliar el tiempo.

El resto (que se puede o no hacer) queda para siempre en los juegos, y habria que disfrutarlos, independientemente de que sabor sean
@theelf y @Señor Ventura por favor no dejéis el tema que yo al menos estoy disfrutando como un niño chico, que envidia de conocimientos tíos. ¿Dónde hay que apuntarse para aprender de esto? Jejeje seguid así maquinas. Sigo con mi cubata y las palomitas leyendoos.
@Hilldegar si tengo tiempo, puedo hablar de programacion y eso

kusfo79 escribió:Pero ojo, el VDP está pensado para lo que está pensado. Juegos con dos planos de scroll, 80 sprites en pantalla, y scrooll completo, por filas de tiles o por lineas de pixels. En memoria a la vez te caben unos 1200 tiles de 8x8 para ello. ¿Que pasa entonces cuando quieres hacer algo para lo que no está pensado? Pues que no solo lo tienes que hacer en la CPU, sino que encima has de engañar al VDP


Es que ahi esta el quid de la cuestion, todo se tiene que programar pensando en el hardware primero, y la megadrive ofrece un vdp simple, pero capaz de manejar con soltura para lo que esta echo

Deficiente seria, si para lo que fue concebido, no es capaz de hacerlo bien

Por supuesto que tiene sus cosas, ya puestos a poner un flag de colision mas bien inutil, se podrian haber estirado y hacerlo usable. Pero bueno, el flag aunque poco practico, cumple su cometido, solo que es mas basico de lo necesario


Cuando el hardware no da, nos queda el software, y ahi es donde la megadrive puede sacar el brillo, y se demuestra que el conjunto no tiene nada de deficiente


Luego que una consola tenga o no soporte por hardware de algo, es otra historia, cada maquina tiene lo que tiene.

Esto solo es un problema para hacer ports, donde estas obligado a simular funciones de la maquina original, no cuando programas nativamente

No tiene sentido buscar un "modo7" en el vdp de la megadrive, no lo hay, pero tampoco lo tiene, emperrarse en usar ese efecto, cuando hay otros que se pueden usar, y tener un resultado visual atractivo tambien


Si es por eso, ya se puede decir que el VDP de la negeo es deficiente, ni modo tiles soporta... [+risas]




me hace acordar a una demo q hice tiempo atras,

http://akihabara-online.com/tmp/ms.zip

Apenas se usa el motorola en este ejemplo, el vdp se encarga de todo


En el ejemplo, uso los dos modos de scroll (A, B) y los hago funcionar juntos, para simular a la neogeo, y el tercer plano *alias el olvidado* window, para algunos efectos, y solo uso 2 sprites para marco (imaginate si quedan libres...)

La mayoria de las instrucciones basicas, las hago directo en los registros, asi q siquiera tomo demasiado cpu cuando es necesario usarlo
Como curiosidad sonora, aquí hay un vídeo que "muestra" la Megadrive reproduciendo sonidos wav a 26 Khz. El propio sonido del vídeo, narración incluida, se reproduce mediante la consola, según el autor:
https://www.youtube.com/watch?v=oKsUAywSyEg
Hilldegar escribió:@theelf y @Señor Ventura por favor no dejéis el tema que yo al menos estoy disfrutando como un niño chico, que envidia de conocimientos tíos. ¿Dónde hay que apuntarse para aprender de esto? Jejeje seguid así maquinas. Sigo con mi cubata y las palomitas leyendoos.

Me parece de obligación mencionar también a kusfo79, que si no me equivoco, está liado con el Antarex y mejor que nadie podría aclararnos muchas cosas.. que por cierto, nos conocimos en el pasado Retrodays de Torrejón!!

Lo más importante está en cuáles son las manos que hacen un juego, que esa es otra, Nintendo contaba con el "favoritismo" de algunas de las mejores compañías, en MD, debido quizás a su mayor facilidad a la hora de programar, hubo compañías que no estaban a la altura y eso ensuciaba de alguan forma las posibilidades reales de la máquina. Ejemplos de compañías que sacaban mucho jugo al hardware de la consola los podemos encontrar en la propia SEGA, Treasura, Technosoft, Cirynx o 1985 Alternativo [sonrisa]. Me hubiera gustado ver a Capcom o Konami programar para MD con la misma dedicación que en SNES...

TheElf, muy bueno lo del Metal Slug y muy bueno también lo que vi hace tiempo del Blazing Star y el Samurai Shodown [oki]
robotnik16 escribió:
Hilldegar escribió:@theelf y @Señor Ventura por favor no dejéis el tema que yo al menos estoy disfrutando como un niño chico, que envidia de conocimientos tíos. ¿Dónde hay que apuntarse para aprender de esto? Jejeje seguid así maquinas. Sigo con mi cubata y las palomitas leyendoos.

Me parece de obligación mencionar también a kusfo79, que si no me equivoco, está liado con el Antarex y mejor que nadie podría aclararnos muchas cosas.. que por cierto, nos conocimos en el pasado Retrodays de Torrejón!!


Gracias Majo!
kusfo79 escribió:
robotnik16 escribió:
Hilldegar escribió:@theelf y @Señor Ventura por favor no dejéis el tema que yo al menos estoy disfrutando como un niño chico, que envidia de conocimientos tíos. ¿Dónde hay que apuntarse para aprender de esto? Jejeje seguid así maquinas. Sigo con mi cubata y las palomitas leyendoos.

Me parece de obligación mencionar también a kusfo79, que si no me equivoco, está liado con el Antarex y mejor que nadie podría aclararnos muchas cosas.. que por cierto, nos conocimos en el pasado Retrodays de Torrejón!!


Gracias Majo!



Lastima q no me gustan los juegos de nave.. jaja

Oye esto q tengo en el disco duro, sera alguna beta? [+risas]

Imagen
interesante los comentarios, aunque la postura del usuario theelf me parece chocante si la comparamos con la del usuario aventura, ya que demuestra arrogancia y hostilidad en algunos comentarios ( como en los links que puse) , y es que mas que querer armar una "flame wars" lo que me gustaria es aprender como funcionan ambas consolas.....aunque a theelf no le paresca trascendente mi pregunta.

por cierto, que opinan de esto:

http://i57.tinypic.com/2uh5utd.jpg

gundam puede mover personajes tan grandes como eternal champion de md verdad?

https://m.youtube.com/watch?v=L7N46Bcf6xo

o este video (minuto
4:50 a 5:15):

https://m.youtube.com/watch?v=0w-U-9izr ... u.be&t=292
Si domináis el inglés y os interesa el tema, hace tiempo vi un video sobre esto en youtube que me pareció muy interesante, técnico y entretenido. Ahí lo dejo para quien quiera echarle un vistazo :) https://www.youtube.com/watch?v=yGzgKCsrNHM
@he_man_mx

Que pregunta?


he_man_mx escribió:por cierto, que opinan de esto:

http://i57.tinypic.com/2uh5utd.jpg2


El KOF95 para java? [+risas]


leyngel escribió:Si domináis el inglés y os interesa el tema, hace tiempo vi un video sobre esto en youtube que me pareció muy interesante, técnico y entretenido. Ahí lo dejo para quien quiera echarle un vistazo :) https://www.youtube.com/watch?v=yGzgKCsrNHM


Me lo estoy viendo, esta muy bueno. Es la otra parte de la vision, la del electronico

Gracias
kusfo79 escribió:Voy a aclarar unas cuantas cosas que se han comentado en este post, y que no son del todo ciertas.

Primero de todo, hablas de por que se programó el VDP con esas deficiencias, que por qué programó alguién que el límite de sprites fueran 60, etc. Ahí partes de una base erronea. El chip VDP está "programado" en hardware, no hay una línea de código en él. Por tanto, muchas de las limitaciones són físicas. Por ejemplo, la cantidad de sprites que puede pintar por linea, el número de planos que puede mover, etc.


Nadie ha dicho que el manejo de sprites estuviese implementado con líneas de código, o que se programara por software.

En el modo H32 baja sus especificaciones, y eso puede deberse a unos cuantos motivos, pero lo que es un hecho es que se fuerza al hardware a funcionar así. Y nadie dice que eso se haga por software.

kusfo79 escribió:A consecuencia de ello, el VDP no va nunca sobrecargado ni relajado. Siempre realiza el mismo trabajo en cada frame. Esté moviendo un plano o dos (la mega permite 2 planos), y esté moviendo un sprite o ochenta. En el 90% de los juegos que verás, todo el trabajo gráfico lo hace el VDP, menos quizás algun efectillo de tanto en tanto.


El VDP hace el trabajo que tiene que hacer, y esa es una tarea que no necesita de ninguna lógica porque no es programable. Tu le pides que dibuje algo, y el te lo dibuja. Hasta aquí todo ok.
El problema es que cuando pides cosas que no sabe hacer, tienes que usar la cpu para conseguirlo, y por lo tanto pierdes ciclos de reloj para conseguir un objetivo relacionado con el sistema gráfico, en vez de aprovecharlo para elementos lógicos.

En definitiva. Si hablamos de un juego con un solo plano (mas la ventana para el marcador), y nos limitamos a poner sprites en pantalla, y a hacerlos desaparecer, entonces si, tienes casi toda la potencia de la cpu para IA's, físicas, y demás tareas basadas en el comportamiento de las reglas del juego.
Pero si lo que quieres es empezar a añadir detalles, efectos gráficos, etc, corre todo a cuenta de la cpu, y ya no tienes tanto margen para añadir complejidad al mencionado comportamiento del programa.

Todo esto no es nada que no se sepa.


Según leo, el VDP tiene una tasa de relleno de 2 ciclos de reloj a la hora de escribir en memoria. Imagino que esto es en modo H40, ¿cual es el ratio en el modo H32?.
En snes, los PPU 1 y 2 tardan 4 ciclos de reloj, pero hablamos de dos chips que funcionan a 21 Mhz, por lo que finalmente parece ser que la tasa de relleno es notablemente superior en snes.
Por otro lado, el sistema de vídeo le dedica 4 ciclos de reloj a cada pixel para aplicar efectos, y eso es algo que va mas allá de los datos conocidos (¿os acordais del efecto de split screen de los dragon ball?, en megadrive eso corre a cuenta de la CPU, mientras que en snes no todo).

Es a ese tipo de cosas a las que hago mención cuando digo que es deficiente. Se que es una palabra que tal vez no sea adecuada, pero cuando uno piensa en lo desaprovechado que puede llegar a estar el motorola...

theelf escribió:Es que ahi esta el quid de la cuestion, todo se tiene que programar pensando en el hardware primero, y la megadrive ofrece un vdp simple, pero capaz de manejar con soltura para lo que esta echo


No con la soltura que sería de esperar con un 68000 ahí metido. En mi opinión, ojo.

theelf escribió:No tiene sentido buscar un "modo7" en el vdp de la megadrive, no lo hay, pero tampoco lo tiene, emperrarse en usar ese efecto, cuando hay otros que se pueden usar, y tener un resultado visual atractivo tambien


Si, pero por software. Ocupas tiempo de proceso de la cpu.

theelf escribió:Si es por eso, ya se puede decir que el VDP de la negeo es deficiente, ni modo tiles soporta... [+risas]


Si un modo tiles para hacer un bitmap ofrece ventajas en determinados aspectos de un programa, entonces evidentemente en esos momentos es deficiente.

Se que estoy hilando fino, porque el VDP de la neo geo es muy competente, y no va a sufrir en rendimiento por eso, pero tal vez se entienda a que me refiero.

El sistema de vídeo de la snes es una bestia parda. 128 sprites mientras que aplica otros efectos, como rotaciones, e incluso planos moviendose sobre 3 ejes al mismo tiempo, deformaciones, ghost layering, y otra serie de efectos (como el mecionado efecto para el split screen, y otros mas).
Pero tiene limitaciones muy cabronas y muy incomprensibles, sobre todo con el modo 7, y eso es deficiente.

theelf escribió:El KOF95 para java? [+risas]


Eso fué un proyecto de KOF94 para snes que se quedó en el aire. Ni idea de si conservan algo de ese trabajo.
Sois todos programadores de videojuegos o qué pasa? [carcajad] [carcajad]

Me estáis dando ganas de empollar apuntes de consolas de 16 bits, aunque yo voy muy retrasado respecto a vuestros conocimientos. [oki]
robotnik16 escribió:
Hilldegar escribió:@theelf y @Señor Ventura por favor no dejéis el tema que yo al menos estoy disfrutando como un niño chico, que envidia de conocimientos tíos. ¿Dónde hay que apuntarse para aprender de esto? Jejeje seguid así maquinas. Sigo con mi cubata y las palomitas leyendoos.

Me parece de obligación mencionar también a kusfo79, que si no me equivoco, está liado con el Antarex y mejor que nadie podría aclararnos muchas cosas.. que por cierto, nos conocimos en el pasado Retrodays de Torrejón!!

Lo más importante está en cuáles son las manos que hacen un juego, que esa es otra, Nintendo contaba con el "favoritismo" de algunas de las mejores compañías, en MD, debido quizás a su mayor facilidad a la hora de programar, hubo compañías que no estaban a la altura y eso ensuciaba de alguan forma las posibilidades reales de la máquina. Ejemplos de compañías que sacaban mucho jugo al hardware de la consola los podemos encontrar en la propia SEGA, Treasura, Technosoft, Cirynx o 1985 Alternativo [sonrisa]. Me hubiera gustado ver a Capcom o Konami programar para MD con la misma dedicación que en SNES...

TheElf, muy bueno lo del Metal Slug y muy bueno también lo que vi hace tiempo del Blazing Star y el Samurai Shodown [oki]


El tema de las third parties tras el monopolio de Nintendo fue un tema peliagudo. Y un fuerte handicap para NEC y Sega (aunque esta lo palió bastante con sus arcades y creaciones propias). Y pienso que aunque ya Nintendo no tenía el monopolio sí se benefició de los efectos. Y los efectos es la mejor relación con colosos como Konami o Capcom que sacaban siempre más y mejor para sus consolas. Capcom creo que casi todos sus juegos de MD eran licencias que luego Sega programaba o mandaba a programar a terceros (creo que la única excepción fue el SF2 SCE y no se esmeraron mucho que digamos). Y Konami yo creo que se encargaba ella misma pero con producción irregular.
gaditanomania escribió:
robotnik16 escribió:
Hilldegar escribió:@theelf y @Señor Ventura por favor no dejéis el tema que yo al menos estoy disfrutando como un niño chico, que envidia de conocimientos tíos. ¿Dónde hay que apuntarse para aprender de esto? Jejeje seguid así maquinas. Sigo con mi cubata y las palomitas leyendoos.

Me parece de obligación mencionar también a kusfo79, que si no me equivoco, está liado con el Antarex y mejor que nadie podría aclararnos muchas cosas.. que por cierto, nos conocimos en el pasado Retrodays de Torrejón!!

Lo más importante está en cuáles son las manos que hacen un juego, que esa es otra, Nintendo contaba con el "favoritismo" de algunas de las mejores compañías, en MD, debido quizás a su mayor facilidad a la hora de programar, hubo compañías que no estaban a la altura y eso ensuciaba de alguan forma las posibilidades reales de la máquina. Ejemplos de compañías que sacaban mucho jugo al hardware de la consola los podemos encontrar en la propia SEGA, Treasura, Technosoft, Cirynx o 1985 Alternativo [sonrisa]. Me hubiera gustado ver a Capcom o Konami programar para MD con la misma dedicación que en SNES...

TheElf, muy bueno lo del Metal Slug y muy bueno también lo que vi hace tiempo del Blazing Star y el Samurai Shodown [oki]


El tema de las third parties tras el monopolio de Nintendo fue un tema peliagudo. Y un fuerte handicap para NEC y Sega (aunque esta lo palió bastante con sus arcades y creaciones propias). Y pienso que aunque ya Nintendo no tenía el monopolio sí se benefició de los efectos. Y los efectos es la mejor relación con colosos como Konami o Capcom que sacaban siempre más y mejor para sus consolas. Capcom creo que casi todos sus juegos de MD eran licencias que luego Sega programaba o mandaba a programar a terceros (creo que la única excepción fue el SF2 SCE y no se esmeraron mucho que digamos). Y Konami yo creo que se encargaba ella misma pero con producción irregular.

Está claro. Como dices, el SFII, que era el icono de Capcom por aquellos años, sí que se encargaron de programarlo para MD, cuando precisamente en ese juego hubiera sido más que interesante que hubiera sido Sega quien hiciera la conversión, al igual que pasó con otros juegos anteriores... ¿Por qué esta vez sí quisieron programarlo directamente desde Capcom? La respuesta no se sabe pero la podemos intuir...
Tengo tanto el Super Street Fighter 2 de Mega como el de Super Nintendo y mi ojo inexperto no ve diferencias apreciables ni graficamente ni por supuesto en el control, en ambos casos el juego va fluidisimo y en cuanto al sonido siendo ambos diferentes el de Mega es mas sencillito sí, pero tiene su encanto, de hecho a mi me flipa como suena la Mega sobre todo la 1.

@kusfo79 siento no haberte mencionado tus aportaciones también me estan pareciendo interesantísimas, la verdad que en este tema hay nivel :)
interesante todo el contenido que van aportando. y es que me entro el gusanito de saber como funcionan ambas maquinas.en fin, aqui pongo otros ejemplos interesantes para los que todavian creen que el 65c816 era inferior por su velocidad de procesamiento.

por ejemplo los sprite de Thunderforce IV de md dice que son imposibles en una super nes, pero a poco el ejemplo del rendering
ranger, donde literalmente se llena
la pantalla de objetos, explosiones,
y todo sin una sola ralentización no cuenta?

https://m.youtube.com/watch?feature=you ... w-U-9izrGs

y otra cosa que me parece interesantes es que este usuario ( cyclops) dice que El W65C816 no es un
procesador "full" 16 bits,
los registros con lo que
puede operar sí lo son, pero
sus buses son
indiscutiblemente de 8 bits,
está capado de operaciones,
y funciona a una
frecuencia de reloj
insuficiente para lo que supuestamente pretendía
mostra la SNES en pantalla
(128 sprites a 512x224p).

entonces esto que es:?

https://m.youtube.com/watch?v=QfRi_dXLq1M

eso es realizar calculos complejos verdad?.

la verdad mi conocimiento es muy basico y disculpen si hago muchas preguntas.
Señor Ventura escribió:No con la soltura que sería de esperar con un 68000 ahí metido. En mi opinión, ojo.


Si, pero por software. Ocupas tiempo de proceso de la cpu.



Pero para que queres simular a una SNES en una Megadrive? cuando se programa para una maquina se usa los recursos de esa maquina

Solo tiras de software cuando es necesario. No programas en megadrive pensando en los efectos que NO tenes, si no que programas pensando en que efectos te da el VDP , raster, parallax, modos de scroll por linea, etc y los usas de forma creativa

Es ilogico decir "la megadrive no tiene pseudo 3D (modo 7), asi que el CPU tiene que hacer el trabajo" porque simplemente, si no existe X efecto en hardware, no se implementa, se hace algo similar con lo que si se tiene


Bueno, ya que se hablo del KOF, aca tenes un ejemplo de un escenario, lo programe recien, y en menos de una hora, asi que obviamente no me detuve a optimizar mucho...


Todos los tiles estan totalmente en la vram (y aun sobra... solo use 1032 tiles), y la musica por el Z80... asi que el 68k se esta tocando los huevos


http://www.akihabara-online.com/Megadrive/ejemplos/kofmexico.zip


Imagen


Que tiene de deficiente el vdp? que no maneja con soltura? que razon tenes para decir que el VDP esta trabando al 68k? tirate algun ejemplo real, y lo vemos, porque yo por mas que me siente a pensar, no se me ocurre. Como dije antes, prefiero algo que programes tu, es mas facil de captar el ejemplo
Señor Ventura escribió:
Nadie ha dicho que el manejo de sprites estuviese implementado con líneas de código, o que se programara por software.


En definitiva. Si hablamos de un juego con un solo plano (mas la ventana para el marcador), y nos limitamos a poner sprites en pantalla, y a hacerlos desaparecer, entonces si, tienes casi toda la potencia de la cpu para IA's, físicas, y demás tareas basadas en el comportamiento de las reglas del juego.
Pero si lo que quieres es empezar a añadir detalles, efectos gráficos, etc, corre todo a cuenta de la cpu, y ya no tienes tanto margen para añadir complejidad al mencionado comportamiento del programa.


Sobre lo del software, me refiero a que desde el punto de vista de diseñar hardware, no es tan fácil como cuando programas algo. Te puedes encontrar que por el hecho de haber modificado la señal para variar la resolución, te encuentres con limitaciones no previstas. Por ejemplo, en el VDP de Master System, si usas el flag de sprites zoomeados, este solo afecta a los cuatro primeros sprites de una scanline, debido a limitaciones a la hora de diseñarlo. Hasta la segunda versión, la que llevan las últimas SMS I y todas las SMS II, no se eliminó esta limitación.

Sobre lo que comentas, puedes hacer un juego con dos planos independientes, más el plano window para el marcador, y que los dos planos hagan scroll parallax(Shadow of the Beast), e incluso uno de ellos tenga un raster en el suelo (Street Fighter II), y que los escenarios tengan animación por rotación de paletas y por sustitución de tiles al vuelo, todo ello lleno con 80 sprites de hasta 32x32 sin usar la CPU.

Ojo, que como te digo, el VDP tiene sus limitaciones, pero yo creo que son basicamente dos: solo 4 paletas de 16 entre 512 colores, y que la implementación del VDP no permite multiplexación de Sprites como el C64.
javierator1981 escribió:Como curiosidad sonora, aquí hay un vídeo que "muestra" la Megadrive reproduciendo sonidos wav a 26 Khz. El propio sonido del vídeo, narración incluida, se reproduce mediante la consola, según el autor:
https://www.youtube.com/watch?v=oKsUAywSyEg

Eso no es dice nada.Hasta la NES es capaz de reproducir música en esa calidad.

Por ahi ronda la música de la intro de la serie de las tortugas ninja de 1989.
Estoy con TheElf en que no hay nada mejor que programar algo para saber de primera mano cómo se comportan realmente las tripas de una consola. En mi opinión, diría que es muy importante una cosa que se lleva comentando, y es que no tiene sentido "obligar" a un chip a hacer cosas que no sabe, ese es uno de los puntos donde me descoloco leyendo a Señor Ventura. Para hacer "modo 7" con el VDP de la Mega lógicamente tendrás que recurrir al motorola perdiendo con ello capacidad de procesamiento para otras cosas, pero esto es atribuible a cualquier máquina incluida SNES, y es que si tu le pides a una SNES que se salga de los recursos gráficos que sabe hacer, también debes recurrir a su procesador, y en ese caso te encuentras en las mismas, sólo que con casi 4 Mhz menos.

No conozco hasta dónde puede llegar el VDP de la Mega, pero he visto efectos muy chulos en bastantes juegos, que insisto, no me hacen pensar que sea un chip limitado e inferior a otros elementos de la consola.

he_man_mx, seguro que gente de aquí te podrá dar alguna explicación, pero yo creo que no es del todo fiable comparar juegos puntuales, ya que cada juego tiene una naturaleza y unas características en su programación, por esa regla, en un beat 'em up podrían meterse muchos más sprites de los que habitualmente solemos ver, si no se hace seguro que es por algo... (y que conste que el R.Ranger me parece brutal).

Acaban de abrir un hilo en el que se entrevista a Watermelon, os recomiendo que le echéis un ojo porque precisamente comentan por qué eligieron programar en Mega Drive, y tiene que mucho que ver con cosas que estamos hablando aquí...
theelf escribió:Pero para que queres simular a una SNES en una Megadrive? cuando se programa para una maquina se usa los recursos de esa maquina

Solo tiras de software cuando es necesario. No programas en megadrive pensando en los efectos que NO tenes, si no que programas pensando en que efectos te da el VDP , raster, parallax, modos de scroll por linea, etc y los usas de forma creativa

Es ilogico decir "la megadrive no tiene pseudo 3D (modo 7), asi que el CPU tiene que hacer el trabajo" porque simplemente, si no existe X efecto en hardware, no se implementa, se hace algo similar con lo que si se tiene


Y entonces pasa algo como esto:
https://youtu.be/1f9pkDFKVek?t=36

Y en snes esto:
https://youtu.be/zturPhgEaVo?t=121

E intentarlo en megadrive conlleva a esto, tirando de cpu (pese a ser muy meritorio, aunque necesite incorporar memoria de apoyo en el cartucho, porque si no, no se puede):
https://www.youtube.com/watch?v=d_H0kdWPzfs


theelf escribió:Bueno, ya que se hablo del KOF, aca tenes un ejemplo de un escenario, lo programe recien, y en menos de una hora, asi que obviamente no me detuve a optimizar mucho...


Todos los tiles estan totalmente en la vram (y aun sobra... solo use 1032 tiles), y la musica por el Z80... asi que el 68k se esta tocando los huevos


http://www.akihabara-online.com/Megadrive/ejemplos/kofmexico.zip


http://akihabara-online.com/Megadrive/e ... /kof94.gif


Pero theelf, si nadie duda de eso. Ya solo faltaría que para poner un tilemap tuviese que hacerlo el 68000.

theelf escribió:Que tiene de deficiente el vdp? que no maneja con soltura? que razon tenes para decir que el VDP esta trabando al 68k? tirate algun ejemplo real, y lo vemos, porque yo por mas que me siente a pensar, no se me ocurre. Como dije antes, prefiero algo que programes tu, es mas facil de captar el ejemplo


No que no maneje con soltura, digo que no maneja con la misma soltura que el sistema de video de snes (ciclos por pixel, o incluso en pixel fill rate, hablando puramente de números). Para mi, el VDP de la megadrive no está a la altura del 68000 en cuanto a rapidez, y no es que no sea rápido, digo que esa cpu merece mas.

¿Tu que echas de menos a la hora de programar en megadrive?
kusfo79 escribió:Ojo, que como te digo, el VDP tiene sus limitaciones, pero yo creo que son basicamente dos: solo 4 paletas de 16 entre 512 colores, y que la implementación del VDP no permite multiplexación de Sprites como el C64.


No se si te referis que la C64 permite algo por hardware, pero por software si que se puede multiplexar sprites

Algo asi? solo con un sprite se puede llenar una linea, o sea, que con 10 sprites, se puede llenar una pantalla

Imagen


http://akihabara-online.com/Megadrive/ejemplos/multiplex.zip


TmEE en otro foro escribio esto

You can multiplex sprites too if you can fit at least one VRAM write next to sprite table changes, or the internally cached table is not updated. I could fill 32 x 240 area with just one sprite.
theelf escribió:
kusfo79 escribió:Ojo, que como te digo, el VDP tiene sus limitaciones, pero yo creo que son basicamente dos: solo 4 paletas de 16 entre 512 colores, y que la implementación del VDP no permite multiplexación de Sprites como el C64.


No se si te referis que la C64 permite algo por hardware, pero por software si que se puede multiplexar sprites

Algo asi? solo con un sprite se puede llenar una linea, o sea, que con 10 sprites, se puede llenar una pantalla

Imagen


http://akihabara-online.com/Megadrive/ejemplos/multiplex.zip


TmEE en otro foro escribio esto

You can multiplex sprites too if you can fit at least one VRAM write next to sprite table changes, or the internally cached table is not updated. I could fill 32 x 240 area with just one sprite.


Oh!, yo había leiío que no se podía hacer precisamente por la tabla interna. Es posible que el problema sea que solo se puede multiplexar en Y y no en X, por que hasta el hblank no se refresca la tabla interna?
kusfo79 escribió:Oh!, yo había leiío que no se podía hacer precisamente por la tabla interna. Es posible que el problema sea que solo se puede multiplexar en Y y no en X, por que hasta el hblank no se refresca la tabla interna?


Justo despues de que la tabla interna se actualiza es donde tenes que escribir en vram

Podes multiplexar el sprite en cualquier sitio de la pantalla que quieras, mientras la tabla se halla actualizado. En la practica, vamos, que no se pisen dentro del mismo rango de scanlines

Imagen


Hace algun tiempo, hice un codigo para poner el mismo sprite en el mismo scanline, y era posible, pero con flickering.. no le pasaba lo mismo a la C64?
me encanta leer y seguir este tipo de post y me emociona que a dia de hoy siga la disputa tecnica entre MD y SNES, es muy bonito ^^ jejeje
theelf escribió:
kusfo79 escribió:Oh!, yo había leiío que no se podía hacer precisamente por la tabla interna. Es posible que el problema sea que solo se puede multiplexar en Y y no en X, por que hasta el hblank no se refresca la tabla interna?


Justo despues de que la tabla interna se actualiza es donde tenes que escribir en vram

Podes multiplexar el sprite en cualquier sitio de la pantalla que quieras, mientras la tabla se halla actualizado. En la practica, vamos, que no se pisen dentro del mismo rango de scanlines

Imagen


Hace algun tiempo, hice un codigo para poner el mismo sprite en el mismo scanline, y era posible, pero con flickering.. no le pasaba lo mismo a la C64?


En la C64 no he programado nunca, pero sé que la multiplexación era muy potente, eran capaces de hacer el Katakis con solo 8 sprites en pantalla, gracias a la multiplexación. Entiendo que el Vic-II era muy flexible con los cambios en caliente
kusfo79 escribió:En la C64 no he programado nunca, pero sé que la multiplexación era muy potente, eran capaces de hacer el Katakis con solo 8 sprites en pantalla, gracias a la multiplexación. Entiendo que el Vic-II era muy flexible con los cambios en caliente


Lamentablemente la C64 la conozco como usuario, la tuve en la epoca, pero no estoy puesto en su hardware. Una pena, algun dia me pondre con ella si hay tiempo, es una marabilla de maquina

Viendo el juego que comentas

Imagen


Me puse a investigar un poco, y cai en esta web

http://cadaver.homeftp.net/rants/sprite.htm


Despues de comerme el documento, efectivamente, el multiplex que se puede efectuar en la megadrive, parece ser el mismo que se puede hacer en la C64

Este diagrama del posicionamiento de los sprites del turrican, se corresponderian a los que haria en megadrive si quisiera ahorrar sprites

Fijate que los sprites 4,5,6,7 y 8 no se encuentran en la misma linea X, y se cambian durante el raster, igual que en MD

                 4 5 6 7 8
                 4 5 6 7 8
                 4 5 6 7 8
            1    4 5 6 7 8
            2
Hay un artículo en la wikipedia sobre las máquinas que soportan sprite multiplexing.

https://en.wikipedia.org/wiki/Sprite_multiplexing

-Atari 8-bit
-Commodore Amiga
-Commodore 64
-MSX
-NES
-SNES
-Sega Master System
-Sega Mega Drive
La cosa seria ver los ciclos de reloj y como los aprovechan...las carencias que tienen y como pueden saltarselas...y por otra parte, ver si pueden exceder los limites teoricos a base de trucos...


De todas formas, cuantas mas vueltas le damos al hardware y a sus limites, mas nos damos cuenta que estas maquinas estan mas parejas de lo que jamas pensaron muchos en su epoca, eso si, cada una tirando hacia segun que sitios que la otra no.

Es como el tema del audio, tanta gente ha dicho que la Megadrive sonaba a mierda, y el caso es que se han llegado a escuchar composiciones de una calidad muy parecida a lo que puede ofrecer snes, otra cosa diferente ya es como supiesen exprimir el chip de sonido los compositores, que la mayoria me da que no sabian ni tocarlo con los pies...
O mirando el caso de SNES, ver como llena literalmente la pantalla de sprites a tope, cosa que asi de primeras, siempre se dice que no se puede o que si tal o cual...

Esto me lleva a decir que el verdadero limite de estas bestias de 16bits realmente eran los programadores y nada mas, si no, mirad el reciente caso de evolucion constante de nuestro querido Gasega, cada vez que toca el Motorola es para exprimirlo mas y mas, y parece no tener fin.
He sacado una captura del street racer en el bsnes, y según pone la resolución es de 256x478... ¿eso está bien? ¬_¬
Señor Ventura escribió:
theelf escribió:Pero para que queres simular a una SNES en una Megadrive? cuando se programa para una maquina se usa los recursos de esa maquina

Solo tiras de software cuando es necesario. No programas en megadrive pensando en los efectos que NO tenes, si no que programas pensando en que efectos te da el VDP , raster, parallax, modos de scroll por linea, etc y los usas de forma creativa

Es ilogico decir "la megadrive no tiene pseudo 3D (modo 7), asi que el CPU tiene que hacer el trabajo" porque simplemente, si no existe X efecto en hardware, no se implementa, se hace algo similar con lo que si se tiene


Y entonces pasa algo como esto:
https://youtu.be/1f9pkDFKVek?t=36

Y en snes esto:
https://youtu.be/zturPhgEaVo?t=121

E intentarlo en megadrive conlleva a esto, tirando de cpu (pese a ser muy meritorio, aunque necesite incorporar memoria de apoyo en el cartucho, porque si no, no se puede):
https://www.youtube.com/watch?v=d_H0kdWPzfs


theelf escribió:Bueno, ya que se hablo del KOF, aca tenes un ejemplo de un escenario, lo programe recien, y en menos de una hora, asi que obviamente no me detuve a optimizar mucho...


Todos los tiles estan totalmente en la vram (y aun sobra... solo use 1032 tiles), y la musica por el Z80... asi que el 68k se esta tocando los huevos


http://www.akihabara-online.com/Megadrive/ejemplos/kofmexico.zip


http://akihabara-online.com/Megadrive/e ... /kof94.gif


Pero theelf, si nadie duda de eso. Ya solo faltaría que para poner un tilemap tuviese que hacerlo el 68000.

theelf escribió:Que tiene de deficiente el vdp? que no maneja con soltura? que razon tenes para decir que el VDP esta trabando al 68k? tirate algun ejemplo real, y lo vemos, porque yo por mas que me siente a pensar, no se me ocurre. Como dije antes, prefiero algo que programes tu, es mas facil de captar el ejemplo


No que no maneje con soltura, digo que no maneja con la misma soltura que el sistema de video de snes (ciclos por pixel, o incluso en pixel fill rate, hablando puramente de números). Para mi, el VDP de la megadrive no está a la altura del 68000 en cuanto a rapidez, y no es que no sea rápido, digo que esa cpu merece mas.

¿Tu que echas de menos a la hora de programar en megadrive?


Tras leer todo el hilo y entiendo y comparto la opinión de Ventura. Creo que lo explica bastante claro.

Saludos
Solieyu escribió:
javierator1981 escribió:Como curiosidad sonora, aquí hay un vídeo que "muestra" la Megadrive reproduciendo sonidos wav a 26 Khz. El propio sonido del vídeo, narración incluida, se reproduce mediante la consola, según el autor:
https://www.youtube.com/watch?v=oKsUAywSyEg

Eso no es dice nada.Hasta la NES es capaz de reproducir música en esa calidad.

Por ahi ronda la música de la intro de la serie de las tortugas ninja de 1989.


Pues dice bastante a cómo no se ha usando realmente el chip de audio. Pero MUCHO si te has molestado en ver las diferencias.
Naitguolf escribió:
Pues dice bastante a cómo no se ha usando realmente el chip de audio. Pero MUCHO si te has molestado en ver las diferencias.

Por eso lo dije: No es gran cosa,no dice nada.La NES ya reproduce wav hasta los 33,5 Khz.
Solieyu escribió:
Naitguolf escribió:
Pues dice bastante a cómo no se ha usando realmente el chip de audio. Pero MUCHO si te has molestado en ver las diferencias.

Por eso lo dije: No es gran cosa,no dice nada.La NES ya reproduce wav hasta los 33,5 Khz.


Supongo que este es el vídeo que comentas:
https://www.youtube.com/watch?v=PdY-_fpKrXE

De todas formas, teniendo en cuenta las posibilidades de almacenamiento en los cartuchos de NES frente a los de Megadrive, algo de razón tiene @Naitguolf, sí que dice algo sobre cómo no se ha usado el hardware, ya que en Megadrive sí que sería posible tener alguna canción metida en un cartucho, ¿no?
Por este tipo de cosas no es acertado cuestionar a la ligera la labor de los programadores de cada época, porque a ver de donde iban a sacar el espacio libre para meter esas pistas de sonido.
No veo tan importante si puede reproducir un sample (q al final de cuentas cualquier maquina con un DAC, mejor o peor, puede) si no, si mientras se reproduce se puede hacer algo mas

Por eso puse ese ejemplo del escenario de mexico del KOF94, porque aunque suena la musica de fondo, no se ve comprometido el scroll, ni la copia de ram a vram, etc, y el motorola esta libre
theelf escribió:
kusfo79 escribió:En la C64 no he programado nunca, pero sé que la multiplexación era muy potente, eran capaces de hacer el Katakis con solo 8 sprites en pantalla, gracias a la multiplexación. Entiendo que el Vic-II era muy flexible con los cambios en caliente


Lamentablemente la C64 la conozco como usuario, la tuve en la epoca, pero no estoy puesto en su hardware. Una pena, algun dia me pondre con ella si hay tiempo, es una marabilla de maquina

Viendo el juego que comentas

Imagen


Me puse a investigar un poco, y cai en esta web

http://cadaver.homeftp.net/rants/sprite.htm


Despues de comerme el documento, efectivamente, el multiplex que se puede efectuar en la megadrive, parece ser el mismo que se puede hacer en la C64

Este diagrama del posicionamiento de los sprites del turrican, se corresponderian a los que haria en megadrive si quisiera ahorrar sprites

Fijate que los sprites 4,5,6,7 y 8 no se encuentran en la misma linea X, y se cambian durante el raster, igual que en MD

                 4 5 6 7 8
                 4 5 6 7 8
                 4 5 6 7 8
            1    4 5 6 7 8
            2


Ostras,investigaré esto, a ver que se puede hacer, en principio con 80 sprites normalmente no vamos faltos, pero puede dar mucho juego...
El Street Racer de MD no podría llegar a ser nunca igual que en SNES, de la misma forma que el de SNES nunca podría ser como el de MD, haciendo lo que hace tirando de procesador. De todas formas, la posibilidad de hacer el "modo7" creo que no era exactamente lo que se venía hablando.

El ejemplo del F Zero me parece en un poco injusto, primero porque volvemos a lo mismo, el modo 7 no es un efecto natural de la MD, además de que hay que tener en cuenta el contexto, hablamos de una persona anónima que hace un juego en su casa en sus ratos libres, frente a una empresa como Nintendo, que acababa de lanzar una consola al mercado, poniendo todos los medios a su alcance con el fin de superar a la competencia.
robotnik16 escribió:El Street Racer de MD no podría llegar a ser nunca igual que en SNES, de la misma forma que el de SNES nunca podría ser como el de MD, haciendo lo que hace tirando de procesador.


¿Que snes no puede hacer un simple efecto raster en un plano?, ¿desde cuando no pasa eso?.

robotnik16 escribió:De todas formas, la posibilidad de hacer el "modo7" creo que no era exactamente lo que se venía hablando.


Si dices eso, es que no te has enterado de lo que se venía hablando. Tu estás entendiendo un md vs snes, pero se estaba hablando de que el VDP de la megadrive no estaba a la altura de su microprocesador.

robotnik16 escribió:El ejemplo del F Zero me parece en un poco injusto, primero porque volvemos a lo mismo, el modo 7 no es un efecto natural de la MD, además de que hay que tener en cuenta el contexto, hablamos de una persona anónima que hace un juego en su casa en sus ratos libres, frente a una empresa como Nintendo, que acababa de lanzar una consola al mercado, poniendo todos los medios a su alcance con el fin de superar a la competencia.


El ejemplo del f-zero es el que mejor funciona hasta la fecha. Injusto sería si cojo el ejemplo de modo 7 del pier solar.

Y no se trata de si megadrive puede, o no puede. Se trata de que se tiene que encargar la cpu, y es un ejemplo de las veces que la cpu tiene que perder tiempo en hacer cosas que tal vez debería hacer el VDP. Tampoco es un efecto gráfico natural en megadrive manejar mas de dos planos por hardware... ¿se entiende ya?.
Señor Ventura escribió:¿Que snes no puede hacer un simple efecto raster en un plano?, ¿desde cuando no pasa eso?.

Claro que puede hacer un raster en un plano, pero dudo mucho que pudiera dividir la pantalla en 4 jugadores simultáneos y moverlo como lo hace la MD, es más, ya en MD se resiente, así que imagínate con 3.5 MHZ. También puede hacer un juegazo como el Super R-Type, pero cuando tienen que calcular muchas balas, trayectorias y colisiones, el juego se viene abajo.

Señor Ventura escribió:Si dices eso, es que no te has enterado de lo que se venía hablando. Tu estás entendiendo un md vs snes, pero se estaba hablando de que el VDP de la megadrive no estaba a la altura de su microprocesador.

Si me entero, lo que pasa es que me da la sensación de que reincides mucho en determinadas virtudes de la SNES, y no te ajustas del todo a lo que estaban comentado. Tomando como raíz del tema las supuestas deficiencias del VDP, TheElf te decía que no tiene sentido que una consola intente hacer lo que no sabe, y veo que sueles insistir en ciertas aspectos en los que la mayoría estaremos de acuerdo, por ejemplo, el que SNES puede hacer "modo7" (u otros efectos concretos) con mayor soltura que MD. Yo también lo creo, pero también te digo que he visto "deficiencias/limitaciones" en juegos de SNES, que en MD no se dan, por ejemplo, menos planos de parallax, menos "chicha" en pantalla (sprites, explosiones, disparos, etc...), menor velocidad de juego, ralentizaciones, etc... supongo que estas cosas también tienen que ver con el "equilibrio" entre componentes que comentábamos. Y ojo, que no estoy hablando de cuestiones meramente estéticas, sino aspectos que afectan directamente a la jugabilidad...

Señor Ventura escribió:El ejemplo del f-zero es el que mejor funciona hasta la fecha. Injusto sería si cojo el ejemplo de modo 7 del pier solar.

Y no se trata de si megadrive puede, o no puede. Se trata de que se tiene que encargar la cpu, y es un ejemplo de las veces que la cpu tiene que perder tiempo en hacer cosas que tal vez debería hacer el VDP. Tampoco es un efecto gráfico natural en megadrive manejar mas de dos planos por hardware... ¿se entiende ya?.

¿Por qué F Zero sí y Pier Solar no? Valoro muchísimo el trabajo de Gasega68k, pero de verás le estás comparando con los medios que podían tener los programadores de la todopoderosa Nintendo en el año 93? Demasiada desventaja creo yo...

Tú mismo has dicho que la MD es más versatil, por lo que no necesariamente tiene que ajustarse a lo que pone sobre el papel, de hecho, intuyo que es algo que tuvieron muy en cuenta a la hora de diseñar la consola.
robotnik16 escribió:¿Por qué F Zero sí y Pier Solar no? Valoro muchísimo el trabajo de Gasega68k, pero de verás le estás comparando con los medios que podían tener los programadores de la todopoderosa Nintendo en el año 93? Demasiada desventaja creo yo...


Probablemente tenga Gasega68k mil veces más ventaja de programar ahora, a de antes. No es por nada, pero más de 20 años de destripamiento del hardware de la Megadrive, desarrollo de herramientas, muchas mejores ideas y las nuevas generaciones que siempre empujan más fuerte.

Yo creo que claramente se ve que cada consola tenía una cosa específica en mente. La snes buscaba postales muy bonitas gráficas para juegos con poca morralla encima, pero usando inteligemente varios efectos que resultaban altamente vistosos. 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. Por otro lado la mega buscaba rapidez, a un grave coste de limitación de las 4 paletas gráficas. Y los efectos los sacaba afortunadamente por la versatilidad de la CPU. Pero como los grafistas no se apretasen las tuercas, salían juegos con colores muy apagados :S (Y encima elegían horrorsamente mal la paleta, gracias a los nuevos hacks de recolor se pueden recuperar hasta detalles perdidos, vease el hack de recolor de Captain América por ejemplo o del Super SF2)
robotnik16 escribió:Claro que puede hacer un raster en un plano, pero dudo mucho que pudiera dividir la pantalla en 4 jugadores simultáneos y moverlo como lo hace la MD, es más, ya en MD se resiente, así que imagínate con 3.5 MHZ. También puede hacer un juegazo como el Super R-Type, pero cuando tienen que calcular muchas balas, trayectorias y colisiones, el juego se viene abajo.


Claro que puede, y además por hardware. Es algo relativo a sus capacidades para aplicar morphing a los planos, y al parecer eso incluye los efectos de rasterización (que con el pixel fill rate que tiene, creo que puedes tener por seguro que aplicarlo en una pantalla partida a 4, es un juego de niños para los ppu1 y 2).

No estoy seguro de si se limita a un plano, como el modo 7, o a varios, pero si que no incluye a los sprites.

robotnik16 escribió:Si me entero, lo que pasa es que me da la sensación de que reincides mucho en determinadas virtudes de la SNES, y no te ajustas del todo a lo que estaban comentado. Tomando como raíz del tema las supuestas deficiencias del VDP, TheElf te decía que no tiene sentido que una consola intente hacer lo que no sabe, y veo que sueles insistir en ciertas aspectos en los que la mayoría estaremos de acuerdo, por ejemplo, el que SNES puede hacer "modo7" (u otros efectos concretos) con mayor soltura que MD. Yo también lo creo, pero también te digo que he visto "deficiencias/limitaciones" en juegos de SNES, que en MD no se dan, por ejemplo, menos planos de parallax, menos "chicha" en pantalla (sprites, explosiones, disparos, etc...), menor velocidad de juego, ralentizaciones, etc... supongo que estas cosas también tienen que ver con el "equilibrio" entre componentes que comentábamos. Y ojo, que no estoy hablando de cuestiones meramente estéticas, sino aspectos que afectan directamente a la jugabilidad...


Joder, pues te habrás enterado, pero insistes en llevarlo al terreno de snes vs megadrive. El tema es que la megadrive tiene mucha cpu, y poco VDP... y ya está, no es una batalla entre sistemas... que para esa ventaja que tiene, tenga que tirar de CPU, es precisamente el debate, y no otro.

Con ese microprocesador, lo esperable es un VDP con pixel fill rate mas alto, con mas planos por hardware, tal vez con unos modos gráficos que permitan mas colores, o incluso la gestión de mas sprites en pantalla, además de otra serie de cuestiones, como la bajada de rendimiento a una menor resolución (que con esa VRAM que tienen, quien quiera 256x224 para ahorrar memoria para mejorar gráficos, se dispara en el pie con el rendimiento).

En mi opinión, si snes tiene el sistema gráfico que tiene con esa cpu, entonces a la megadrive no le pega su VDP con esa cpu. Otra cosa es que en 1988, y con su precio, eso no fuera viable... ese es otro tema.

robotnik16 escribió:¿Por qué F Zero sí y Pier Solar no?


Pues porque el modo 7 del f-zero está mas depurado. Es el mejor modo 7 que he visto en megadrive.

robotnik16 escribió:Valoro muchísimo el trabajo de Gasega68k, pero de verás le estás comparando con los medios que podían tener los programadores de la todopoderosa Nintendo en el año 93? Demasiada desventaja creo yo...


Cuidado, que cometes el error de pensar que hoy se tienen menos herramientas, menos medios, y menos conocimiento sobre el hardware, cuando es justo al revés. Los programadores de la todopoderosa nintendo no tenía que programar el efecto del modo 7, porque ya estaba en el hardware, solo había que hacer un llamamiento al mismo, y fuera.

¿Quieres un driver de sonido que suene limpio y cristalino para las voces digitalizadas y los FX?, pues no necesitas un equipo de ingenieros para desarrollarlo porque los equipos de programación no comparten sus recursos... ya lo tienes disponible en internet para incluírlo en tu código sin gastar ni un solo segundo mas de tu tiempo en idear nada.

¿Quieres hacer un efecto de escalado para los sprites?, pues tampoco partes de cero, ese "trozo de código" ya está ideado, programado, y depurado, para que tu lo incluyas.

¿Modo 7?, ¿ray caster?, ¿técnicas gráficas varias?... pues lo mismo, la escena de la megadrive ya ha dado con esas respuestas... respuestas que NUNCA tuvieron las empresas programadoras en su día.

robotnik16 escribió:Tú mismo has dicho que la MD es más versatil, por lo que no necesariamente tiene que ajustarse a lo que pone sobre el papel, de hecho, intuyo que es algo que tuvieron muy en cuenta a la hora de diseñar la consola.


Y lo es. La potencia tan desmedida que tiene la snes para aplicar las increíbles rutinas de modo 7... solo sirven para el modo 7. Esa gran potencia no puede ser usada para nada mas.
La potencia de cálculo para conseguir efectos de transparencias, solo puede ser usada para calcular las transparencias, y nada mas.
La potencia de proceso para deformar un plano a base de morphing, solo puede usarse para para esa técnica gráfica, y nada mas.
...y así podemos seguir hasta encontrarnos con la cpu, que esa si permite cosas, pero no es un 68000, claro.

La potencia usada para conseguir el modo 7 en megadrive, puede usarse para conseguir ese modo 7, o cualquier otra cosa. Eso es versatilidad.
Otra cosa es que no llegue a ser tan potente como para igualar los efectos por hardware de la snes, claro, pero lo que si es cierto es que la megadrive no está tan atada como la otra, y a esto es a lo que se refería theelf.
Me gustaría verlo, he visto a la Super pasarlo mal con cosas más simples.

No es que lo lleve yo a un MD vs SNES, entiendo que lo es pero orientado al hardware (tb está PC Engine pero parece que queda en la sombra). Como yo no puedo dar explicaciones tan técnicas como vosotros, me limito a mi experiencia y a lo que compruebo con los juegos, al igual que veo rotar de forma espectacular un escenario, o un efecto de transparencia muy chulo, también veo que cuando se trata de potencia bruta para juegos "normales" sin efectos puntuales, la velocidad de juego es menor, tienes menos chicha en pantalla, los juegos corren a menos frames o se ralentizan ligeramente... Si con tus conocimientos has llegado a pensar que el VDP de la Mega no está a la altura, yo puedo pensar que en SNES también hay algo en su interior que no da la talla (CPU), ya que una consola que salió 2 años después no se puede permitir estas pequeñas deficiencias (2 años de ventaja para una consola que era además un poco más cara y también sus juegos).

Entonces gasega está en ventaja respecto a la empresa que había diseñado el hardaware, que casualmente era una de las compañías con mayor tradición del sector de los videojuegos, que según decían, tenían un presupuesto mayor que el de no se cuantos estudios de cine de Hollywood juntos, y que contaba en su haber con los mejores equipos de programación del momento trabajando 8 horas (o las que fueran) diarias en el desarrollo de los juegos... Me cuesta creerlo ehhh...
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.

robotnik16 escribió:Me gustaría verlo, he visto a la Super pasarlo mal con cosas más simples.


Ya has mencionado el super r-type, el cual es uno de los 4 primeros juegos de snes, por cierto.

Hay juegos que llenan la pantalla de sprites, y se manejan con una soltura enorme, libre de ralentizaciones. ¿Un ejemplo?, pues uno que han puesto en este mismo hilo (rendering ranger).

robotnik16 escribió:No es que lo lleve yo a un MD vs SNES, entiendo que lo es pero orientado al hardware (tb está PC Engine pero parece que queda en la sombra). Como yo no puedo dar explicaciones tan técnicas como vosotros, me limito a mi experiencia y a lo que compruebo con los juegos, al igual que veo rotar de forma espectacular un escenario, o un efecto de transparencia muy chulo, también veo que cuando se trata de potencia bruta para juegos "normales" sin efectos puntuales, la velocidad de juego es menor, tienes menos chicha en pantalla, los juegos corren a menos frames o se ralentizan ligeramente... Si con tus conocimientos has llegado a pensar que el VDP de la Mega no está a la altura, yo puedo pensar que en SNES también hay algo en su interior que no da la talla (CPU), ya que una consola que salió 2 años después no se puede permitir estas pequeñas deficiencias (2 años de ventaja para una consola que era además un poco más cara y también sus juegos).


Es que la cpu de la snes te obliga a dominar el ensamblador, y si a eso le sumas que de por si no es tan potente como el 68000, pues evidentemente en algo se nota si no programas en condiciones.
El chip de motorola siempre será mejor calculando objetos, y otras rutinas complejas. El 65c816 tiene otras virtudes muy notables que tienen que ver precisamente con los gráficos, pero no le puedes pedir que gestione la IA de 10 objetos (casi ni a megadrive se lo puedes pedir, y menos si encima ocupas tiempo de proceso en ayudar al VDP en otras tareas).

Objetos, y sprites, no suponen la misma cosa para una cpu. Para lo primero es mejor el 68000, para lo segundo es mejor el 65c816.

robotnik16 escribió:Entonces gasega está en ventaja respecto a la empresa que había diseñado el hardaware, que casualmente era una de las compañías con mayor tradición del sector de los videojuegos, que según decían, tenían un presupuesto mayor que el de no se cuantos estudios de cine de Hollywood juntos, y que contaba en su haber con los mejores equipos de programación del momento trabajando 8 horas (o las que fueran) diarias en el desarrollo de los juegos... Me cuesta creerlo ehhh...


Diseñar un juego desde cero es una cosa muy compleja, e incluye desde la planificación, hasta la concepción de los gráficos, música, etc. Todo eso requiere tiempo, y muchos profesionales.

La demo del F-zero ha reutilizado gráficos, no se ha centrado en programar la jugabilidad (físicas, manejo, y comportamiento en general), y ha implementado unas rutinas de modo 7 basandose en información que ya estaba ahí, y la cual ha ido mejorando para hacer una demo de una fase.

Claro que no es comparable la magnitud de un proyecto y oro proyecto, pero las empresas de videojuegos no tuvieron la información que tenemos hoy. Piensa que en megadrive se hacían muchas cosas por software, y la información por aquel entonces era secreto industrial, por lo que costaba pasta para investigación y desarrollo hacer tus propias rutinas.

Eso hoy no pasa. Lo tienes todo a mano, y lo creas, o no, eso se traduce en que ya no hacen falta equipos de 25 personas para hacer un juego de megadrive, ni una millonada en equipos informáticos para programar.
207 respuestas
1, 2, 3, 4, 5