Final Fight en MSX2

Página 11/16
4 | 5 | 6 | 7 | 8 | 9 | 10 | | 12 | 13 | 14 | 15 | 16

Por anonymous

incognito ergo sum (116)

Imagen del anonymous

18-01-2015, 02:17

Kai Magazine wrote:

https://www.youtube.com/watch?v=yErDyaJDpbU

Esbozo de motor hecho en 2 o 3 horas de una especie de final fight:

https://www.youtube.com/watch?v=SA_26j39LyQ

Demo de Sega Mega CD de illusion city para msx2 64k.
Comparadlo con la intro del illusion city original de turbo-r.

Honestamente, yo donde veo el mérito de esas demostraciones es en la calidad de los gráficos.
Si esos mismos juegos/demos/motores en vez de tener tus geniales dibujos tuviesen gráficos de, digamos, los primeros KOEI, la sensación sería la de unos simples copys moviéndose con no demasiada velocidad.

Pero sí... ya sabemos que en el mundillo de MSX los usuarios somos mucho de guiarnos por lo que nos entre por la vista, por encima de todo lo demás.

Por ENDDEMOGAMITAINA

Paragon (1279)

Imagen del ENDDEMOGAMITAINA

18-01-2015, 03:27

Illusion city...que juego mas castigado,metido a piñon para que solo funcione en MSX TURBO R,
resulta que funciona en todo sistema conocido,sin aprovechar ninguno,puedes jugarlo en FMTOWNS,en NEC PC9801,en X68K,
en MEGACD,pero no en MSX2 ni en MSX2+,hay MICROCABIN si fue MUY ratonera,
ya me contareis viendo XAK2 o GAZZEL...como no hicieron una version de Illusion para MSX2...,seguro que habrian tenido que quitar todos los efectos de Industrial light & magic (¬_¬)

Por anonymous

incognito ergo sum (116)

Imagen del anonymous

18-01-2015, 10:48

ENDDEMOGAMITAINA wrote:

Illusion city...que juego mas castigado,metido a piñon para que solo funcione en MSX TURBO R,
resulta que funciona en todo sistema conocido,sin aprovechar ninguno,puedes jugarlo en FMTOWNS,en NEC PC9801,en X68K,
en MEGACD,pero no en MSX2 ni en MSX2+,hay MICROCABIN si fue MUY ratonera,
ya me contareis viendo XAK2 o GAZZEL...como no hicieron una version de Illusion para MSX2...,seguro que habrian tenido que quitar todos los efectos de Industrial light & magic (¬_¬)

Supongo que la razón es que los últimos juegos de MicroCabin están MUY mal programados. Poco optimizados, lentos, pesados. La razón principal es que debían usar algún tipo de herramienta o capa por encima del assembler para poder lanzar el juego en multiplataforma reutilizando todo el código posible (quizás algún lenguaje custom o partes en C o vete a saber qué).

Y claro, salía perdiendo nuestro querido MSX2 que era el que más se resentía con ese estilo de juego y de programación. Nada más que el replayer FM se chupa una barbaridad de CPU. A eso le sumas copys por un tubo, rutinas sin optimizar, etc... pues para que fuese medianamente jugable lo tuvieron que sacar para MSXTurboR.

Martos me contó además que el juego original está plagado de bugs que tuvo él que corregir cuando lo desprotegió.

Por AxelStone

Prophet (2963)

Imagen del AxelStone

18-01-2015, 11:20

warau wrote:

Lo malo de eso es que tendríamos... producciones hechas en Turbo Basic... que nunca será lo mismo que el ASM y pueden valer para dar el pego en según qué tipo de juegos. Pero nunca podrás hacer un Aleste 2 (por decir algo al azar) en Turbo Basic (sin entrar en temas de diseño).

¿De verdad os parece tan difícil el ASM? A mí lo que me resulta difícil es el BASIC, por lo limitado que es y el continuo encaje de bolillos que te obliga a hacer.

Creo que estamos muy equivocados y podemos llevar a confusión a los nuevos programadores que lleguen. El ensamblador no es el único lenguaje del MSX y no es la panacea. Aleste 2 claro que es ideal para ASM, pero hay una larga lista de juegos que en ASM no podrían hacerse: Risk 2, Xak, Ys 3, SD Snatcher y una larga lista. ASM es para lo que es: mecánicas simples.

El MSX tiene 4 lenguajes perfectamente válidos para trabajar: ASM, Basic, Pascal y C. En cualquiera de ellos puedes hacer juegos y posiblemente lo que cambie sea la orientación de uno u otro. El Pascal y C son estructurados, ideales para RPG, estrategia y mecánicas complejas. ASM da acceso completo al hard, ideal para arcades. Y el Basic está en el medio, es un poco el todo terreno: buen rendimiento y razonablemente estructurado. ASM no es fácil ni difícil, es para lo que es.

Lo que si es cierto es que conocer un poco de ASM permite crear rutinas específicas para incorporar a tus programas. Un juego en Turbo Basic donde las rutinas críticas se hagan en ASM es un gran paso, pero hacer la lógica enteramente en Basic me parece lo más sensato.

Por Kai Magazine

Paragon (1389)

Imagen del Kai Magazine

18-01-2015, 11:25

warau wrote:
Kai Magazine wrote:

https://www.youtube.com/watch?v=yErDyaJDpbU

Esbozo de motor hecho en 2 o 3 horas de una especie de final fight:

https://www.youtube.com/watch?v=SA_26j39LyQ

Demo de Sega Mega CD de illusion city para msx2 64k.
Comparadlo con la intro del illusion city original de turbo-r.

Honestamente, yo donde veo el mérito de esas demostraciones es en la calidad de los gráficos.
Si esos mismos juegos/demos/motores en vez de tener tus geniales dibujos tuviesen gráficos de, digamos, los primeros KOEI, la sensación sería la de unos simples copys moviéndose con no demasiada velocidad.

Pero sí... ya sabemos que en el mundillo de MSX los usuarios somos mucho de guiarnos por lo que nos entre por la vista, por encima de todo lo demás.

En serio??
No ves merito en lo que conseguí con nuts y con no name con turbo basic?? el scroll multiple del no name de 4 en 4 pixels en lugar de los tipicos 8 en 8?
En el nuts, todos esos fotogramas montados a trozos (cabeza, cuerpo y piernas) reutilizando partes de los mismos para montar los fotogramas en tiempo real, invirtiendo los copys en una direccion para ahorrar vram y tener mejores graficos, 2 jugadoes y hasta 5 enormes personajes en pantalla, todo con un scroll de 4 en 4 pixels ??
No ves merito en eso?

No ves merito en hacer un motor de action rpg con scroll suave, personaje grande, con todos esos fotogramas metidos en la vram, moviendose suavemente?

No ves merito en hacer una demo de mega-cd en msx2 con turbo basic? la cual por cierto le pega patadas a la de turbo-r, la cual tiene unos copys mas lentos y eso que los graficos son solo a un cuarto de pantalla, cuando los mios son a media pantalla...

Me dejas absolutamente perplejo.
No te conozco y no se que has desarrollado en msx, y por eso no se que pensar, si eres un genio que nos ves a los demas como hormiguitas, o no tienes ni idea de lo que implica hacer estas cosas arriba meniconadas en turbo basic...

Sea como sea, hacer cosas que no se han hecho nunca en msx2, como esos motores, siempre tiene merito.
Lamento que no puedas apreciarlo.

Por anonymous

incognito ergo sum (116)

Imagen del anonymous

18-01-2015, 11:26

AxelStone wrote:

Creo que estamos muy equivocados y podemos llevar a confusión a los nuevos programadores que lleguen. El ensamblador no es el único lenguaje del MSX y no es la panacea. Aleste 2 claro que es ideal para ASM, pero hay una larga lista de juegos que en ASM no podrían hacerse: Risk 2, Xak, Ys 3, SD Snatcher y una larga lista. ASM es para lo que es: mecánicas simples.

Sin embargo todos esos juegos que has citado están hechos 100% en ASM y, aún así, algunos van lentos. Imagínate el resultado haciéndolos en Pascal... (Y según tu propio argumento, el Aleste 2 es un juego de "mecánica simple"... lo flipo).

¿Por cierto, y eso de que el ASM es sólo para mecánicas simples? ¿Eso es lo que enseñan ahora en las facultades de informática? Qué triste...

Por anonymous

incognito ergo sum (116)

Imagen del anonymous

18-01-2015, 11:32

Kai Magazine wrote:

Sea como sea, hacer cosas que no se han hecho nunca en msx2, como esos motores, siempre tiene merito.
Lamento que no puedas apreciarlo.

Yo también lamento.

Personalmente, hubiese preferido más juegos con tus fenomenales gráficos, pero menos "escena animada" y más acción y velocidad. Ese es mi gusto personal y es lo que espero y le pido a un videojuego de MSX.

Obviamente soy consciente de que es sólo mi gusto personal y que no coincide con el de la mayoría, por tanto aquí "there is no wrong or right".
Lo lógico es dar a la mayoría lo que pide. Y, en efecto, la mayoría pide gráficos lentos pero vistosos antes que velocidad y jugabilidad, por lo que tu acercamiento al diseño de juegos se puede decir que es lo acertado para tener éxito en la escena MSX.

Por AxelStone

Prophet (2963)

Imagen del AxelStone

18-01-2015, 11:46

warau wrote:

Sin embargo todos esos juegos que has citado están hechos 100% en ASM y, aún así, algunos van lentos. Imagínate el resultado haciéndolos en Pascal... (Y según tu propio argumento, el Aleste 2 es un juego de "mecánica simple"... lo flipo).

¿Por cierto, y eso de que el ASM es sólo para mecánicas simples? ¿Eso es lo que enseñan ahora en las facultades de informática? Qué triste...

Empiezo a pensar como Kai: o eres un genio, o simplemente la ignorancia es muy osada. ¿Qué se hicieron en ASM? Entonces es muy probable que sea la causa de todos sus males, un código churrero. ¿Desde cuando la raqueta hace buena al raquetista? Para que un programa funcione bien lo primero es un algoritmo eficiente. Si te pones a programar juegos de rol y estrategia en ASM te has equivocado de lleno. Es un hecho demostrado que un lenguaje estructurado es más fácil de interpretar mentalmente, ergo se presta a un código más ordenado.

¿Lo flipas con la mecánica simple de Aleste 2? ¿Desde cuando los arcades no se conciben con "mecánicas simples"? Scroll, sprites y disparos. ¿Qué mas necesita un matamarcianos? Igual me he perdido algo y estamos hablando de un Baldur's Gate de PC, que seguramente esté hecho en ASM...

No sé lo que enseñan hoy en las facultades, yo soy ingeniero desde hace 15 años Cool

Kai muchos si apreciamos tu trabajo básicamente por un hecho: porque llevas tus proyectos hasta el final, cosa que es muuuy de agradecer en la scene MSX. Internet está lleno de cientos de retales en ASM que nunca se terminan. Igual no es tan sencillo en el fondo...

Por Kai Magazine

Paragon (1389)

Imagen del Kai Magazine

18-01-2015, 11:48

Pero lo que no entiendes es que no se puede tener todo:
Mas velocidad y esos graficos.
Los copys son igual de rapidos en ASM que desde turbo basic (como ya establecimos en otro hilo)
Si fuese a por mas velocidad, no podria tener esos graficos, ya que, o bien elimino el scroll, o hago los personajes con sprites por hardware, con lo cual serian mucho mas pequeños, simples, con menos fotogramas y menos colores...
Volviendo a lo mismo de siempre en msx... Graficos simples o sin scroll...

Ademas, "no name" va mas rapido y suave que los juegos de microcabin y falcom, y los personajes son mucho mas grandes, y hay doble y triple scroll a veces!!

No se, si me equivoco, coje los graficos del nuts y del no name y hazlo en ASM a tu manera, y asi vemos como lo harias tu, con esos graficos.

Por anonymous

incognito ergo sum (116)

Imagen del anonymous

18-01-2015, 11:52

AxelStone wrote:

Empiezo a pensar como Kai: o eres un genio, o simplemente la ignorancia es muy osada. ¿Qué se hicieron en ASM?

Claro... yo soy un ignorante al igual que todos los desarrolladores de Konami, Compile, etc. cuyos juegos son 100% ensamblador. (Cuando ya se comienza con los ataques personales demuestra, ante todo, falta de argumentos).

AxelStone wrote:

Entonces es muy probable que sea la causa de todos sus males, un código churrero. ¿Desde cuando la raqueta hace buena al raquetista? Para que un programa funcione bien lo primero es un algoritmo eficiente. Si te pones a
programar juegos de rol y estrategia en ASM te has equivocado de lleno. Es un hecho demostrado que un lenguaje

O más bien tú te has equivocado de plataforma. Empiezo a sospechar que aún no eres consciente de lo limitado tecnológicamente que es un MSX. Tampoco entiendo por qué si se programa en ASM el código tiene que ser churrero y no puede ser estructurado.

AxelStone wrote:

¿Lo flipas con la mecánica simple de Aleste 2? ¿Desde cuando los arcades no se conciben con "mecánicas simples"? Scroll, sprites y disparos. ¿Qué mas necesita un matamarcianos?

Venga, venga... ponte a gestionar los sprites y los copys para conseguir meter en pantalla todo lo que mete el Aleste 2 y a la velocidad que lo hace. Estoy ansioso por ver cómo lo haces en un lenguaje de alto nivel en MSX, sin usar ASM.

AxelStone wrote:

Igual me he perdido algo y estamos hablando de un Baldur's Gate de PC, que seguramente esté hecho en ASM...

En PC resulta que llega un momento en que tienes que pasarte al C por narices. Y la potencia tan desmesurada que tiene un PC te permite, por fortuna, hacerlo en C. O incluso en C++. Pero nuevamente te digo: si piensas que programar un PC y un MSX es lo mismo, es que conoces muy poco el hardware del MSX.

Página 11/16
4 | 5 | 6 | 7 | 8 | 9 | 10 | | 12 | 13 | 14 | 15 | 16