› Foros › Retro y descatalogado › Consolas clásicas
theelf escribió:Ah para... ahora cambiastes de deficiente a basico... otro mundo
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
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).
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ñ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ñ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.
.
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
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.
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!!
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!
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
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.
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.
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
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
theelf escribió:Si es por eso, ya se puede decir que el VDP de la negeo es deficiente, ni modo tiles soporta...
theelf escribió:El KOF95 para java?
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 . 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
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 . 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
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.
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.
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.
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
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
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
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
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.
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
http://akihabara-online.com/Megadrive/ejemplos/multiplex.zip
TmEE en otro foro escribio estoYou 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.
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?
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
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?
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
4 5 6 7 8
4 5 6 7 8
4 5 6 7 8
1 4 5 6 7 8
2
-Atari 8-bit
-Commodore Amiga
-Commodore 64
-MSX
-NES
-SNES
-Sega Master System
-Sega Mega Drive
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_H0kdWPzfstheelf 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?
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.
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.
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.
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
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 MD4 5 6 7 8
4 5 6 7 8
4 5 6 7 8
1 4 5 6 7 8
2
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.
robotnik16 escribió:De todas formas, la posibilidad de hacer el "modo7" creo que no era exactamente lo que se venía hablando.
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.
Señor Ventura escribió:¿Que snes no puede hacer un simple efecto raster en un plano?, ¿desde cuando no pasa eso?.
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.
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?.
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...
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.
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...
robotnik16 escribió:¿Por qué F Zero sí y Pier Solar no?
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...
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.
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
robotnik16 escribió:Me gustaría verlo, he visto a la Super pasarlo mal con cosas más simples.
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).
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...