Señor Ventura escribió:Todo el código que va destinado al sonido, sistema de vídeo, I/O, acceso de datos, etc, manda la similitud entre ambos sistemas a tomar vientos. Y al final, tanta hostia de que son la misma cosa solo te sirve para que no necesites adaptar solo un 4% del código, el resto toca reescribirlo y adaptarlo de nuevo.
Y como si hay que reescribir el 100%, que seguro sea asi, no veo el punto, una cosa es escribir codigo, y otra planificar el codigo que se tiene que escribir
bertobp escribió:Que compartan la misma CPU no dice mucho si toda la arquitectura es diferente, rutinas graficas, de audio, de acceso a memoria,.. nada es aprovechable salvo rutinas de fisicas, IA y poco mas. Claro que el trabajar con el mismo compilador y opcodes ayuda a "ver" mas clara la conversion.
mmm... desde mi punto de vista, comparten CPU principal y secundario, un chip yamaha de sonido, unidad de cartucho con una capacidad accesible util, un VDP que permite misma resolucion, sprites en pantalla razonables, scroll por hardware...
Entre las diferencias, algo util, por ejemplo, VDP de la megadrive soporta mapa de tiles, algo que la neogeo no tiene, y es util para paliar la falta de vram de la MD.. yo que se, por decir algo
Sobre aprobechar codigo, no digo que se tenga que reutilizar, eso en ASM es dificil, pero es la planificacion lo que no cambia tanto. La IA es algo jodido, no es facil de lograr, y consumje bastantes recursos de CPU
Un CPU similar, hace que se pueda reaprobechar en cierta manera, a lo que voy es que si tengo un codigo de IA para un m68k a 12mhz, puedo confiar que en uno mismo de 7mhz pueda con las mismas rutinas
Pero si tengo que hacerlo con un CPU de 2mhz por decir algo, obliga a replantear todo de nuevo
O el yamaha, aunque sea otro modelo, no es lo mismo que tener simplemente que agarrar el tracker y reducir canales o componer de nuevo, pero sobre una misma base, que un chip de audio que trabaja de forma diferente, y oblige a cambiar la forma de componer
Desde un punto de vista de codigo, solo puedo dar mi experiencia personal, y a mi me resulta muchisimo mas facil programar para misma plataforma (68k a 68k) que cuando tengo que portar codigo (m68k a ARM por ejemplo)
emerald golvellius escribió:Hombre pero tu mueves un personaje hacia delante o hacia atras...y la animacion es la misma...,
en el Arcade o X68000 o cualquier version mas potente tienen cada personaje una animacion distinta para retroceder o avanzar...,eso fue lo primero que me desilusiono al conseguir la version Super nintendo de crio...,
por que ver a Guile o Ken retroceder en el Aracde me parecia chulisimo.
me encantaria ver una version para MD,SFC,PCE con esos detalles.
Ni me habia fijado en eso, pero ten en cuenta que una cosa es que falten frames porque la maquina esta ahogada, y otra que repitan para ahorrar ROM
Lo que dices es lo segundo, es un tema comercial $$ mas que de las maquinas en si
![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
).
. Como dices hubiera sido una conversión factible para 16 bits sin perder mucho, en un cartucho de 24 megas por ejemplo (pienso que hasta con 16 hábilmente exprimidos se podía).![[sonrisa]](/images/smilies/nuevos/risa_ani1.gif "sonrisa")
,![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
