¿Juegos comerciales porteados por usuarios a 8 y 16 bits?

Ya que mecionas el Sonic, pues el Sonyc de MSX2 de finales de los 90, de Manuel Pazos:

@dinodini Duke Nukem para Master System:






Enlace y fuente:

https://www.smspower.org/Homebrew/DukeNukem-SMS

kusfo79 escribió:Ya que mecionas el Sonic, pues el Sonyc de MSX2 de finales de los 90, de Manuel Pazos:

¿Es mejor o peor que el de Master System?

El Doom de Spectrum de port no tiene nada, se parece y ya. Los niveles son todo cuadrados, mientras que la gran cosa de Doom es que los niveles no eran cuadrados, como en Wolfenstein 3D.

Hay muchos, llenaríamos páginas! Por citar algunos muy meritorios:


Street Fighter II para MSX2 a pelo, sin hardware extra (bueno si, el OPL4 para los samples)


Super Mario World MSX2 a pelo.


Ghost Goblins MSX usando V9990 (chip de video extra)


Slapfight Amstrad CPC (aunque diga GX4000 es jugable en CPC normal)

Y muchos más!

El Duke Nukem que yo puse antes es el 1 de PC, de 1991:

Estos juegos en su época hubieran sido un bombazo. ¿Cómo se explica que las conversiones de recreativas no llegaran a este nivel? ¿Eran tan malo los programadores? Que esa gente eran profesionales que cobraban por su trabajo, y estos ports lo hacen fans de esos micros y sin cobrar nada. No entiendo porque los juegos de aquella época no alcanzaban este nivel.




Estos eran los pinballs de la época.

dinodini escribió: Vi hace poco el Bloodborne de PS4 en PS1.

¿Pero no es en realidad solo la estética de PSX, es en realidad un juego en PC?

En CPC tienes el tremendo port que sacaron del R-Type 128K (el port oficial era el típico juego de Spectrum, que ojo, no estaba mal del todo, pero se jugaba lento y no aprovechaba el CPC para nada)

dinodini escribió:Estos juegos en su época hubieran sido un bombazo. ¿Cómo se explica que las conversiones de recreativas no llegaran a este nivel? ¿Eran tan malo los programadores? Que esa gente eran profesionales que cobraban por su trabajo, y estos ports lo hacen fans de esos micros y sin cobrar nada. No entiendo porque los juegos de aquella época no alcanzaban este nivel.

Estos eran los pinballs de la época.

Ni los medios ni los conocimientos sobre el hardware son los mismos que los actuales.

Las herramientas de desarrollo, los pcs actuales que se usan para la programación de esos ports que mencionas, y mucho menos los conocimientos sobre el hardware son los mismos. Esa reflexión que acabas de hacer es, sin acritud, totalmente absurda.

Si en la época los desarrolladores hubiesen dispuesto de las herramientas y conocimientos actuales, habríamos
visto juegos como esos. Sin más.

El Ghost Ghoblis de c64 hicieron u remake con todas las fases y mejoraron el salto y es estupendo,hiceron cosas estupendas en este fantastico ordenador como un remake del scramble,del dondey jon jr,del comando y




Puzzle Bubble




Por cierto el Rtye de c64 sigue siendo la mejor version de micros de 8 bits ,y es de la epoca,programada por el creador de Turrican :

Gelion escribió:

dinodini escribió:Estos juegos en su época hubieran sido un bombazo. ¿Cómo se explica que las conversiones de recreativas no llegaran a este nivel? ¿Eran tan malo los programadores? Que esa gente eran profesionales que cobraban por su trabajo, y estos ports lo hacen fans de esos micros y sin cobrar nada. No entiendo porque los juegos de aquella época no alcanzaban este nivel.

Estos eran los pinballs de la época.

Ni los medios ni los conocimientos sobre el hardware son los mismos que los actuales.

Las herramientas de desarrollo, los pcs actuales que se usan para la programación de esos ports que mencionas, y mucho menos los conocimientos sobre el hardware son los mismos. Esa reflexión que acabas de hacer es, sin acritud, totalmente absurda.

Si en la época los desarrolladores hubiesen dispuesto de las herramientas y conocimientos actuales, habríamos
visto juegos como esos. Sin más.

Yo discrepo un poco en uno de los temas, el del conocimiento. Yo pensaba más o menos como tú, pero luego te vas a encontrando programadores de la época entrando en foros, etc, y te descubren cosas nuevas que la gente en la actualidad aún no había entendido, aplicado, etc. O sea, creo que los programadores top de la época, conocían más la máquina que los actuales.

Lo que si que ha cambiado mucho es el tiempo disponible, y las herramientas. Si os leeis "It's behind you, the making of Rtype"(aquí), veréis en que condiciones se hicieron muchos de esos juegos.

No es lo mismo prgramar directamente en Spectrum, usando solo cintas (una cosa de masocas incluso en la época), o Microdrives, que usar un PC, poder usar un emulador, etc. O incluso para dibujar, no es lo mismo dibujar en papel cuadriculado que en un editor. (o hacer pesadillas como hacer los gráficos del Silver Surfer de Nes en Amstrads CPCs...¡con paletas que no tienen nada que ver!)

En una entrevista a Toni Galve, que le han echo recientemente en un programa de Juanje Juega le preguntaba Juanje porque costaba tanto a los desarrolladores actuales sacar rendimento al Amiga 500, y Toni respondia que programar en Amiga en la actualid, es como programar para la Saturn juegos en 3d,,muy complicado.Tiene muchos custons chips,no es como la megadrive que te lo dan todo hecho.

saludos.

@AxelStone

Gracias por enseñarnos estas maravillas de MSX2

El Street Fighter 2 y Super Mario World... buff... el último parece el de Super Nintendo

Y respecto a Street Fighter 2, ya podían haber hecho algo así para ST y Amiga. El que hicieron fué un gran truñaco.


@dinodini

Me alegro que te guste tanto el resultado que he conseguido con el engine de juegos Run&Gun que he programado, y ejemplificado en forma de port de Metal Slug, tanto para STE como Megadrive (aún en curso).

Estos feedback son muy satisfactorios para los desarrolladores,





Ahora puedo responder al alguna de las dudas que te han estado inquietando; el por qué en su día había tanto truñaco.



Empezaré indicando que el gran rendimiento que has visto en Atari STE (también podría ejecutarse en un ST a secas, pero mejor a 25 fps que a 50) se debe a un formato de sprites muy especial, que hace un uso del blitter de forma no documentada y muy rara, pues lleva al blitter a un híbrido de estados que se suponían no permitidos.

Pero que funciona, y proporciona mayor eficiencia a la hora de dibujar sprites en pantalla; y también permite dibujar sprites de hasta 256 píxeles de ancho. Cuando el límite teórico del blitter del ST (los modelos que lo llevan) y del STE es de 48 píxeles.

Este formato lo empezó Anima, con su Ghouls and Ghost arcade para Atari STE, y digo arcade, porque en esta versión Anima ejecuta directamente el código de la versión arcade, y reemplaza las llamadas a funciones gráficas; después DML hizo que el formato fuese accesible al resto de mortales, y lo integro en sus herramientas AGT para Atari ST/E




Luego también está el hecho de que gestiono de forma independiente el limpiado de la pantalla... como en las máquinas con blitter o usando sólo CPU, el hecho de dibujar un sprite hace que se quede pintado para siempre sobre el escenario, pues te ves obligado a limpiar, lo que es restaurar el fondo donde había pintado el sprite. Y eso consume una barbaridad de CPU y blitter (si lo tienes).

Pero, ¿y si el sprite no se ha movido? ¿o si ha cambiado su fotograma, pero sigue cubriendo la parte que había manchado anteriormente? ¿O si sólo se ha movido un poco hacia un lado? La respuesta en estos casos es no limpiar, o limpiar sólo el rastro que han dejado. Que es lo que hago con el engine de Metal Slug. Esta si es un aportación mía al engine.

Con esta técnica, que a priori consume un poco de CPU adicional, acabas ahorrando muchísimo tiempo, que utilizas para dibujar más sprites y mantenerte en 50 fotogramas.



El mezclador de audio digital, que programé desde cero, está super optimizado escrito totalmente en ensamblador. Se come sólo el 5% de la CPU disponible en cada fotograma. Debo decir que el 68000 es bastante amigable en su ensamblador, me tuve que pelear, pero no es ni de lejos tan complejo como el Z80






-Ahora regresamos al pasado... ¿por qué todo esto no se vió en su día?

Según me explicaba DML en nuestras largas conversaciones (DML es Douglas Little, lleva programando videojuegos desde que tenía 19 años, en ICE software; puedes ver su nombre en los créditos de Cisco Heat para ST y Amiga, Chase HQ 2, Hydra...) en aquellos tiempos, cuando programabas para una de estas máquinas, recibías a los sumo un manual con una descripción del hardware y un ensamblador y con suerte un compilador de C.

Y las muy contadas ocasiones en que tenías ejemplos, éstos eran muy churreros o funcionaban mal.

Las compañías, por raro y antinatural que nos parezca no te entregaban un kit de desarrollo con ejemplos sobre cómo utilizar el hardware... esto sumado a que los tiempos de desarrollo solían ser cortos (6 - 8 meses para hacer un juego), daba lugar a inmensos truñacos. Tmabién había desarrolladores que cobraban poco y mal, eso tampoco ayudaba.


Me explicó que la primera compañía que se tomó esto en serio, lo de entregar un kit de verdad cuando te hacías con la licencia de desarrollo, fué Nintendo, con el kit de Super Nintendo... que era muy caro, pero te venía un ensamblador, un compilador de C, un depurador para ejecutar paso a paso incrustado en un emulador de la consola... todo esto para MS-DOS. También venían ejemplos de cómo utilizar el hardware, como usar todos los modos, planos de scroll, sprites, sonido... y un número de teléfono para contactar con entendidos de este hardware y software, y te atendían en estos idiomas: japonés, inglés, francés y español


Sega empezó a entregar ejemplos software para Megadrive/Genesis cuando vió el giro de acontecimientos de Nintendo, aunque según me explicaban, nunca llegó a un soporte tan completo como el de Nintendo.

El hecho es que resulta patente, que ambas consolas solían entregar mejores juegos que Amiga o ST/E
Para el Amiga, ST/E, Spectrum, Amstrad... tu mismo te las tenías que componer, poca ayuda recibías; también es cierto que no hacía falta pagar un licenciamiento por publicar para esos ordenadores.

Pero un set de librerías gráficas y de sonido, es lo que tenían que haber entregado todos los fabricantes, para asegurarse productos de calidad.



Por mi parte, lo último que he hecho ha sido homogeneizar el código entre Atari ST/E y Megadrive, de forma que ambas máquinas compartan el mismo código en C de los juegos; así portar de una a otra es más sencillo.
Sigue habiendo alguna diferencia debido al hardware, (en Megadrive tengo que comentar todo lo relativo al limpiado de los sprites xD, porque no le hace falta) pero facilita mucho la labor.

@masteries Lo del SMW es una auténtica locura de un señor que se empeñó en que a base de fuerza de voluntad era posible portarlo a MSX2. Es curioso ya que en vez de apuntar a lo lógico, SMB3 de NES que sigue siendo 8bit, el tio apuntó a 16bit con todo lo que supone calzarle eso a un 8bit.

La verdad es de quitarse el sombrero.

Pero ese street fiter 2 y mario world es con u msx2 pelado ? o necesita ayuda externa el ordenador?

Porque el Ghost and ghoblins de Msx2 no es realmente un msx2,es una tarjeta grafica que se e mete al ordenador y eso ya es otra historia.

Gracias.

dinodini escribió:Estos juegos en su época hubieran sido un bombazo. ¿Cómo se explica que las conversiones de recreativas no llegaran a este nivel? ¿Eran tan malo los programadores? Que esa gente eran profesionales que cobraban por su trabajo, y estos ports lo hacen fans de esos micros y sin cobrar nada. No entiendo porque los juegos de aquella época no alcanzaban este nivel.

Muchos de esos ports de recreativas estaban hechos por 1 solo tio en apenas 2 meses.. y sin darle una puta linea del codigo original. El final fight de US GOLD por ejemplo.

Ya me diras.

Muchas de las empresas que vendian software en aquellos años se gastaban pasta en cualquier cosa menos en pagar al que hacia el curro o preocuparse del curro en si, sabian que con meter una portada reshulona y comprar la licencia de turno ya se vendia como pan caliente aunque fuera mierda infecta.

Algunos de los ports geniales que vemos en los ultimos años pueden estar hechos por equipillos de unos 3 o 4 programadores y se hacen con calma y buena letra muchos en un añito o dos, por eso quedan tan bien pulidos. Antes se desarrollaba en unas condiciones pateticas.