Final Fight en MSX2

Página 3/16
1 | 2 | | 4 | 5 | 6 | 7 | 8

Por AxelStone

Prophet (2956)

Imagen del AxelStone

09-01-2015, 08:44

Kai Magazine wrote:

Lo que si que me gustaria poder hacer a mi personalmente es hacer copys de imagenes almacenadas en ROM desde el turbo basic.

Voy a hacer esta tarde unos experimentos y te cuento, si hay suerte igual tenemos algo Wink

Por FX

Champion (264)

Imagen del FX

09-01-2015, 12:20

Si AxelStone no puede, igual el fin de semana os puedo ayudar con una rutinita...
Los datos del copy se pueden poner en memoria mediante Pokes? O necesitan meterse con variables en el DEFUSR (si es de esta ultima forma, tendría que mirar bien el tema de paso de variables, aunque creo que no era complicado).
Supongo que se necesitaría:
Dirección desde donde pasar imagen.
Posición X y Posición Y
Altura y Ancho
Esto en principio sería fácil. Habría que saber si necesitáis borrar lo que esté debajo o con transparencias.
El "problema" es que las imágenes (me pasó al principio en el Batman cuando las pasaba desde ROM), no pueden estar dentro de un SC5 completo,sino que tienen que estar formadas por el ancho de esa imagen en concreto. Por ejemplo: Ancho de 30 pixeles (en SC5 un byte es dos pixeles). Pues serían 15 bytes (la primera linea de pixeles), otros 15 pixeles (segunda linea), etc.... No 128 bytes de ancho, que sería el formato de un SC5.
Me he explicado?
Un saludo
FX

Por Kai Magazine

Paragon (1373)

Imagen del Kai Magazine

09-01-2015, 13:00

Seria genial en cualquiera de sus modalidades, tanto sirva para almacenar el fondo y hacer copys rapidos sin transparencia para restaurar el fondo o crear el fondo, o almacenar fotogramas y copiarlos con transparencia.
Si el ancho tiene limitaciones, se puede montar con varios copys, no pasa nada.

ANIMO CAMPEONES!

Por AxelStone

Prophet (2956)

Imagen del AxelStone

09-01-2015, 14:23

Da gusto la cómo arrima el hombro la peña. ¡Con una comunidad así da gusto!

Por fernando.collazo.5682

Master (255)

Imagen del fernando.collazo.5682

09-01-2015, 19:31

No lo sé, pero a mí el Streets of Rage es mucho mas juego, tiene mejor jugabilidad y además los personajes son mas pequeños, simples y menos colorista. Aunque Final Fight es todo un clásico! Ambos molan un montón, quizáz un día tendremos los dos!

Por mesiasmsx

Prophet (3291)

Imagen del mesiasmsx

09-01-2015, 19:40

{mod:@fernando.collazo.5682 supongo esta es tu cuenta de facebook, dispones de tu cuenta en MRC? Si no hiciste tu presentacion en MRC te invito a leerte el post del foro en general para nuevos y antiguos usuarios. Saludos}

Por mesiasmsx

Prophet (3291)

Imagen del mesiasmsx

09-01-2015, 19:43

Esto esta bien como experimentos y ojala lo consigais sere el primero en sacarme el sombrero pero dudo se acabe realizando, perdonad si parezco enterrador de ilusiones o falto de optimismo. No veo estos juegos francamente factibles pese a estar el SFII . UN SOR como se dice por aqui tal vez si fijandose mas en una version como la de SMS. Y tirando tal vez mas de 2+.

Por Kai Magazine

Paragon (1373)

Imagen del Kai Magazine

09-01-2015, 22:39

Voy a poner aqui una muy buena pregunta que me ha planteado Axel, y la respuesta, ya que creo que es de interés para la comunidad de desarrolladores de Turbo-Basic.

AxelStone wrote:

Qué tal Kai, me temo que no ha habido suerte con la rutina para leer datos desde ROM en Turbo Basic. La última vez que toqué ASM fue en la facultad, de x86, y la verdad es que estoy oxidado de narices. La buena noticia es que voy a hacerla: voy a estudiar lo justo de ASM del MSX para poder hacer esta rutina y la comparto. No pongo plazo concreto, quiero seguir avanzando con Turbo Basic, pero calculo que en un par de semanas debería estar lista. ¡Si no se adelanta algún monstruo del foro!

Por otro lado una preguntilla, igual se me escapa algo. Hago los copys con el truco famoso de coordenadas y bloques pares, que efectivamente se nota la velocidad de copiado por lo que comentó Guillian HCOPY en vez de Logical Copy, pero la CPU se bloquea. Bucle sencillo para probarlo:

10 SCREEN 5
15 IN=TIME
19 CALL TURBO ON
20 FOR H=0 to 200 step 2
30 ** un copy pequeño, no más de 32x32 **
35 A=SIN(100):B=COS(100)
40 NEXT H
50 CALL TURBO OFF
60 PRINT TIME-IN

Si ejecutas este For haciendo el copy tarda más que sin hacer el copy, cuando se supone que la CPU debería seguir su curso sin esperar al copy, en cambio parece que lo espera. He leído algo de interrupciones, no sé si van por ahí los tiros, pero si realmente fueran en paralelo CPU y VDP este test debería durar lo mismo con y sin la linea 30.

¿Se me escapa algo? ¿Algún test donde pueda comprobar el paralelismo?

¡Gracias!

Hola, son buenas noticias!
Si en un par de semanas lo consigues, eres un genio!!

En cuanto a lo del paralelismo, si, se te escapa una cosilla:

Cada nueva instruccion que pongas en el listado, sea la que sea, consumirá tiempo.
Leer la instruccion, interpretarla y mandar la orden a la vdp consume tiempo.
Por eso si anulas la linea va mas rapido (porque tiene una linea menos que ejecutar).

La prueba del paralelismo la tienes en tu propio ejemplo.

He hecho el listado, y he puesto un copy de 32 pixels x 32 pixels. Me ha dado 75 de resultado en el contador de tiempo.
Anulando la linea me da 71

Ahora bien, si NO anulas la linea, pero haces el copy lo mas pequeño posible:
copy (0,0)-(1,1),1 to (0,0),0
tambien tarda 75 igual que con el copy de 32 x 32.

Como es posible que tarde lo mismo en hacer ese copy tan pequeño, si el copy es mucho mas grande en el primer ejercicio, y lo hace 200 veces??!!

Pues ahi lo tienes. Tarda lo mismo en hacer un copy pequeño que uno de 32x32 porque trabaja en paralelo.

La prueba final la tienes haciendo lo siguiente:

Vamos a medir lo que tarda en hacer los copys, sin la operacion matematica. Anula la linea 35.

Con el copy de 2x2 pixels tarda 32
Con el de 32x32 tarda 45

Esto demuestra que efectivamente copiar un trozo mas grande tarda mas.

Si no trabajase en paralelo, el resultado con calculo matematico de la linea 35 seria diferente al hacer el copy de 2x2 y el copy de 32x32

Creo que, si me he explicado bien, esto demuestra sin duda alguna que trabaja en paralelo, y que el motivo de que tarde mas con la linea de copy activa es porque la tiene que procesar, pero no se espera a terminar el copy para hacer el calculo de la linea 35

De todos modos cuando empieces con el doble bufer y el set page, veras que al cambiar pagina cuando en teoria la pagina de trabajo ya está montada, el set page se ejecutará antes de que terminen las operaciones de copiado, mostrando unos parpadeos de como se compone la pagina de trabajo porque está siendo mostrada antes de tiempo.

Ya lo veras Smile

Un saludo!

Por AxelStone

Prophet (2956)

Imagen del AxelStone

10-01-2015, 13:10

mesiasmsx wrote:

Esto esta bien como experimentos y ojala lo consigais sere el primero en sacarme el sombrero pero dudo se acabe realizando, perdonad si parezco enterrador de ilusiones o falto de optimismo. No veo estos juegos francamente factibles pese a estar el SFII . UN SOR como se dice por aqui tal vez si fijandose mas en una version como la de SMS. Y tirando tal vez mas de 2+.

Hombre lo que estas viendo son pruebas de concepto, está claro que para el juego final habrá que hacer ajustes. La idea es ver hasta donde se puede llegar, pero de entrada aviso que los sprites que deberán usarse son los pequeños, los que pongo en la primera página Wink

Por AxelStone

Prophet (2956)

Imagen del AxelStone

13-01-2015, 19:29

FX wrote:

Si AxelStone no puede, igual el fin de semana os puedo ayudar con una rutinita...
Los datos del copy se pueden poner en memoria mediante Pokes? O necesitan meterse con variables en el DEFUSR (si es de esta ultima forma, tendría que mirar bien el tema de paso de variables, aunque creo que no era complicado).
Supongo que se necesitaría:
Dirección desde donde pasar imagen.
Posición X y Posición Y
Altura y Ancho
Esto en principio sería fácil. Habría que saber si necesitáis borrar lo que esté debajo o con transparencias.
El "problema" es que las imágenes (me pasó al principio en el Batman cuando las pasaba desde ROM), no pueden estar dentro de un SC5 completo,sino que tienen que estar formadas por el ancho de esa imagen en concreto. Por ejemplo: Ancho de 30 pixeles (en SC5 un byte es dos pixeles). Pues serían 15 bytes (la primera linea de pixeles), otros 15 pixeles (segunda linea), etc.... No 128 bytes de ancho, que sería el formato de un SC5.
Me he explicado?
Un saludo
FX

Hola FX te cedo el testigo, todavía ando aprendiendo y prefiero no dispersarme mucho Wink . Estaba pensando no obstante, esta función ya la incorpora Nestor Basic, por lo que podíamos pedirle a Nestor la rutina que lo hace ¿no?

Página 3/16
1 | 2 | | 4 | 5 | 6 | 7 | 8