CPCBasic: Compilador cruzado de BASIC

Pues lo que es el programa en Basic está perfecto. Y las rutinas seguramente también porque funciona en casi toda la pantalla sin ningún problema. Tampoco debe ser algo de la rutina BB19. Aún si la quitas, cuando la piedra llega a esa zona inferior o superior el programa también hace algo extraño, como que parpadea más el sprite. A ver si alguien más experto sabe decirte algo porque yo no encuentro nada extraño.

Me cago en la puta de oros... ains...

[Artaburu]

Me temo que el problema es del tiempo de borrado y dibujado... no le da tiempo a hacerlo dentro de un barrido para no ver parpadeos. ¿Soluciones? Dibujar y borrar a la vez o usar un buffer.

[Artaburu]

también puedes intentar jugar con la coordenada y, si está muy abajo o muy arriba hacer el bb19 en otro momento

Osea... a ve si lo entiendo... a mi pobre cpc no le da tiempo a borrar y pintar 1 sprite nada mas?... Y eso que solamente estoy haciendo eso...

Y lo que no le de tiempo... pq provoca el parpadeo en solo determinadas zonas de la pantalla y no en la pantalla completa?

Me parece a mi que me voy a tomar un colacao y me iré a pasear con la silla un rato... jejejejejeje. Demasiadas complicaciones en etapas tan, tan, tan tempranas pues... Que pasará cuando ademas dibuje a los enemigos, logica del juego, etc, etc? Si ya no puedo mover un triste sprite... xDDDDDDD

Por otro lado, me da a mi que la rutina de pintado de sprites es algo lenta y que hay otra en el otro hilo más rapida, aunque son suposiciones pq yo no se medirlas.

En fin... estaba ojeando las rutinas de teclado esas que tienes hechas en C (para ver si podrian adaptarse al basic)... Me ha desesperado un poco, pero visto el resultado de los sprites parpadeantes de la muerte (bueno, del SPRITE, que solo es uno, jajajajaja), anuncio mi retirada

Salu2!

[Artaburu]

Osea... a ve si lo entiendo... a mi pobre cpc no le da tiempo a borrar y pintar 1 sprite nada mas?... Y eso que solamente estoy haciendo eso...

Y lo que no le de tiempo... pq provoca el parpadeo en solo determinadas zonas de la pantalla y no en la pantalla completa?

Me parece a mi que me voy a tomar un colacao y me iré a pasear con la silla un rato... jejejejejeje. Demasiadas complicaciones en etapas tan, tan, tan tempranas pues... Que pasará cuando ademas dibuje a los enemigos, logica del juego, etc, etc? Si ya no puedo mover un triste sprite... xDDDDDDD

Por otro lado, me da a mi que la rutina de pintado de sprites es algo lenta y que hay otra en el otro hilo más rapida, aunque son suposiciones pq yo no se medirlas.

En fin... estaba ojeando las rutinas de teclado esas que tienes hechas en C (para ver si podrian adaptarse al basic)... Me ha desesperado un poco, pero visto el resultado de los sprites parpadeantes de la muerte (bueno, del SPRITE, que solo es uno, jajajajaja), anuncio mi retirada

Salu2!

No desesperes, chato. El problema no está solo en el dibujado sino en los demás procesos: restaurado del fondo, captura del fondo y dibujado de sprite. Si el fondo es siempre negro o de un determinado color, no lo captures, tenlo ya preparado. En cuanto a la velocidad de la rutina, verás que se puede mejorar un poco pero no es la panacea.

Ams, una cosa... Si el tema es la velocidad, al marcar la pestaña "TURBO" del winape que coloca el z80 a 7Mhz, deberia mejorar el tema, y no solo no mejora, sino que empeora... No puede ser tema de velocidad...

[Artaburu]

Ams, una cosa... Si el tema es la velocidad, al marcar la pestaña "TURBO" del winape que coloca el z80 a 7Mhz, deberia mejorar el tema, y no solo no mejora, sino que empeora... No puede ser tema de velocidad...

Es que no es tema de la velocidad global sino de las cosas que le da tiempo al procesador a hacer durante el redibujado de la pantalla. Esto es una constante, da igual que metas el turbo... a no ser que el turbo ese haga otra cosa.

Ams, una cosa... Si el tema es la velocidad, al marcar la pestaña "TURBO" del winape que coloca el z80 a 7Mhz, deberia mejorar el tema, y no solo no mejora, sino que empeora... No puede ser tema de velocidad...

Es que no es tema de la velocidad global sino de las cosas que le da tiempo al procesador a hacer durante el redibujado de la pantalla. Esto es una constante, da igual que metas el turbo... a no ser que el turbo ese haga otra cosa.

No no... ese Turbo, no es el control de velocidad global con la barra de desplazamiento, que acelera la emulacion a 120%, 200%... ese turbo es como plantar un z80 a 7Mhz, en lugar de a 4Mhz, es decir: el VSYNC, el TIMER, el CRTC, todo sigue funcionando a la misma velocidad, pero el z80 va el doble de rapido (hace el doble de calculos en el mismo tiempo).

Por eso me extraña tio... que un simple sprite con restaurado de fondo ya le pese tantisimo... O realmente el compilador no ejecuta codigo rapido o yo que se... ¿Es que voy a tener que meter sprites compilados o que? Jajajajajjajaja

[Artaburu]

pon el bd19 al principio del proceso para que no veas el borrado y el redibujado a ver si mejora.

pon el bd19 al principio del proceso para que no veas el borrado y el redibujado a ver si mejora.

Si si, eso ya lo he probado (estuve hasta las 3 de la mañana con las pruebas). Es mas, ya no empleo la llamada al CALL y he metido una rutina VSYNC en ASM para ver si mejora.

Al cambiar el VSYNC de sitio, se desplaza el defecto a otra zona de la pantalla... Léase:

VSYNC al principio del todo (defecto en la zona superior de la pantalla)
VSYNC antes del ultimo put_tile (defecto en la zona inferior de la pantalla)
VSYNC al final del todo (defecto en la zona central de la pantalla)....

Para partirse el culo, vamos

Pues sí que es curioso. Se me ocurre si alguno podeis probar el programa tal y como está ahora en un CPC real a ver si pasa lo mismo que en el emulador.

Bueno... como ando un poco cabreadillo ya con el tema de la velocidad... He hecho una prueba.

dinoneno, me duele en el alma decirlo (lo juro), de verdad, pero el codigo que genera el compilador es bastante lento.

Hay un compilador de BASIC, llamado: FABACOM (Fast Basic Compiler). Compila bajo CPM.

Pues bien... He compilado la version Locomotive BASIC del programa del mapeado (el que dibuja el mapa) y tio... va muchisimo mas rapido que el compilado con el CPCBASIC. ¿Y por qué no empleo entonces ese compilador? Porque te mete 8Kbytes de biblioteca delante y cualquier programa compilado ocupa minimo 8Kbytes.

Estoy convencido que el tema del sprite al moverse, es tema de velocidad, pero pq el codigo generado es lento (insisto en que el bucle for - next que generas es extremadamente lento y hemos mirado por encima mi coleguilla Augusto y yo y el codigo en general no está demasiado optimizado).

Dejo snapshot de la version compilada con el FABACOM para que veais la diferencia (el dibujado de pantalla es casi instantáneo!).

dinoneno, también te dejo el DSK del compilador para que le pegues un vistazo. Tal vez te sirva y puedes optimizar tu compilador hasta limites insospechados (ojalá, en serio). El propio DSK lleva el CPM, asi que "|CPM" y luego "BC.COM" para ejecutar el compilador. Hay un archivo TXT con el manual, pero te lo resumo en:

"The compiler is executed from CP/M (either CP/M 2.2 or CP/M Plus). This is
achieved by booting up CP/M (insert a system disc and type |CPM) and inserting
the disc with your program on. Your program should be a standard BASIC program
file (you don't need to save it as ASCII) with the file extension ".BAS". Then
type

BC <filename>

where <filename> is the name of your program, without extension.

There are two possible options:

L - this will make the compiled program omit line numbers and so save space
E - this is used if you do not want to use interrupts (AFTER, EVERY, ON SQ)

These are used as follows:

BC <filename> /L
BC <filename> /E
BC <filename> /LE

3.1/3.2 Commands supported

All Locomotive BASIC commands are supported, except:

AUTO, CHAIN, CHAIN MERGE, CONT, DELETE, EDIT, LIST, LOAD (BASIC program),
MERGE, RENUM, RESUME NEXT, SAVE (BASIC program), TROFF, TRON

The extra commands of BASIC 1.1 are supported, however, if you wish to maintain
compatibility with the 464, you should not use FILL, MASK, or transparent
graphics paper commands.

4.0 Speed advice

If at all possible, use integer variables. The speed difference is quite
considerable, as this example shows:

Floating point:

10 FOR i=0 TO 10000
20 NEXT i

Uncompiled 11.1s, compiled 8.2s

Integer:

10 FOR i%=0 TO 10000
20 NEXT i%

Uncompiled 5.9s, compiled 1.1s"

Venga, que me apetece muchisimo seguir con tu compilador, pero necesita algo más de chicha para que sea viable.

Salu2!

Ummm... dinoneno, no te me habrás mosqueao, ¿no? (si ha sido asi, no era mi intencion). Que te he visto antes por aqui y veo que no has comentado nada sobre el tema que te comento de la velocidad.

Ummm... dinoneno, no te me habrás mosqueao, ¿no? (si ha sido asi, no era mi intencion). Que te he visto antes por aqui y veo que no has comentado nada sobre el tema que te comento de la velocidad.

¿Por qué me voy a enfadar? Si soy el primero que pido vuestras opiniones y sugerencias. Voy a ponerme con la optimización a ver si consigo algo poco a poco. Muchas gracias por vuestra colaboración.
Por cierto, estaba pensando que, para probar, si te defiendes un poco en ensamblador, podrías tocar el código ASM generado para el bucle para hacerlo más rápido. Sólo para ver si con eso se mejora o hay que modificar por otro sitio.
Un saludo y gracias por la colaboración.

Ummm... dinoneno, no te me habrás mosqueao, ¿no? (si ha sido asi, no era mi intencion). Que te he visto antes por aqui y veo que no has comentado nada sobre el tema que te comento de la velocidad.

¿Por qué me voy a enfadar? Si soy el primero que pido vuestras opiniones y sugerencias. Voy a ponerme con la optimización a ver si consigo algo poco a poco. Muchas gracias por vuestra colaboración.
Por cierto, estaba pensando que, para probar, si te defiendes un poco en ensamblador, podrías tocar el código ASM generado para el bucle para hacerlo más rápido. Sólo para ver si con eso se mejora o hay que modificar por otro sitio.
Un saludo y gracias por la colaboración.

Realmente mis conocimientos de ASM son mas que escasos (se ha notado a la hora de adaptar rutinas). El código ASM se lo pasé a alguien que entiende algo más que yo, y me comentaba que en modo general, el codigo generado no era demasiado rápido.

Si pruebas el snapshot compilado con el FABACOM este, que es del año 88, veras que corre muchisimo más (por cierto, el tema del parpadeo se ha solucionado con el FABACOM tambien).

Yo creo que no es solo tema del bucle. Piensa, que cuando dibujaba el sprite no habia bucle ni nada, tan solo llamadas a rutinas externas en ASM y a la funcion XYDIR externa tambien. A mi me da que tu codigo hace demasiadas comprobaciones y conversiones innecesarias de tipos de datos. Ojeando el codigo, vi que en un bucle donde yo empleaba valores INT, tu llamabas varias veces a una rutina de conversion que se llama CONVERTIR_BYTE_A_INT o algo asi...

De verdad que deseo con toda mi alma que tu compilador vaya minimo a la misma velocidad (o mas) que el FABACOM, porque es mucho mas cómodo trabajar con tu compilador que desde el propio CPC. Si mirando el compilador FABACOM te puede ayudar...

Otra sugerencia muy util, seria poder emplear estructuras de este tipo:

Código: Seleccionar todo

IF A=0 THEN
    bla bla bla
    bla bla bla
    bla bla bla
ELSE
    bla bla bla
END IF


Salu2!

P.D.: Que ganas tengo de ver tu compilador generando código que funcione a la velocidad de la luz!