Retroinformática - Como aplicar e implementar algoritmos de físicas en ordenadores retro (1º parte) - Movimiento Rectilineo Uniforme con Amos Basic
Movimiento Rectilineo Uniforme
Con este primer artículo empezaremos a ver una serie de artículos en los que se verán poco a poco la manera de aplicar e implementar físicas en los ordenadores retro (Amiga, Atari, MSX, spectrum, ...), con lenguajes como el Basic.
Hoy en día, las tecnologías y lenguajes de programación actuales, tienen muchas librerías que ya implementan físicas para los juegos. Y no queremos reinventar la rueda.
Por eso, hemos decidido explicar estas físicas, sobre ordenadores antiguos, que no disponían de este tipo de librerías o éstas no se conocían o no se daban a conocer.
Así veremos que tambien en los ordenadores retro, con sus escasas capacidades de cpu y de gráficas, se podían hacer cosas interesantes.
Hoy empezaremos este primer capítulo explicando posiblemente las física más fácil que hay. Hablamos de la velocidad rectilinea uniforme: v=s/t
Con este primer artículo empezaremos a ver una serie de artículos en los que se verán poco a poco la manera de aplicar e implementar físicas en los ordenadores retro (Amiga, Atari, MSX, spectrum, ...), con lenguajes como el Basic.
Hoy en día, las tecnologías y lenguajes de programación actuales, tienen muchas librerías que ya implementan físicas para los juegos. Y no queremos reinventar la rueda.
Por eso, hemos decidido explicar estas físicas, sobre ordenadores antiguos, que no disponían de este tipo de librerías o éstas no se conocían o no se daban a conocer.
Así veremos que tambien en los ordenadores retro, con sus escasas capacidades de cpu y de gráficas, se podían hacer cosas interesantes.
Hoy empezaremos este primer capítulo explicando posiblemente las física más fácil que hay. Hablamos de la velocidad rectilinea uniforme: v=s/t
Es decir, la velocidad es igual al espacio recorrido entre el tiempo transcurrido. La velocidad
se suele medir en kilometros por hora (km/h) o bien en metros por segundo (m/s). En la pantalla de un ordenador solo tiene sentido hablar de píxeles, al menos al trabajar en 2D.
Por lo tanto, a la hora de aplicar la velocidad sobre nuestro código, hablaremos de pixeles por
segundo. Por ejemplo, si decimos que llevamos una velocidad de 30 pixeles por segundo, estamos expresando que en cada segundo hemos avanzado 30 pixeles. ¿Pero como hacemos este incremento?
Esta claro que no podemos en cada segundo, avanzar de golpe 30 pixeles nuestro objeto. Quedaría muy feo ver esos saltos de 30 en 30 pixeles. Aún así, tendríamos que llevar la cuenta de cada segundo.
Pero un ordenador no mide sus tics de reloj en segundos, sino que lo hace en 1/50 de segundo. O lo que es lo mismo, un ordenador "late" cada 0.02 segundos. Es decir, cada 20 milisegundos, tenemos un tic de reloj. Por lo tanto, la posición del objeto se va a ir comprobando cada 20 milisegundos.
Para poder lograr esto, todos los lenguajes de programación, incluido el basic, proporcionan alguna función que nos da los tics de relojs o milisegundos transcurridos desde una fecha fijada por el sistema.
Por tanto, ¿ como convertimos nuestros 30 pixeles por segundo a pixeles por cada 20 milisegundos ?.
Pues con una sencilla regla de 3, como la siguiente:
30 ---> 1000 milisegundos (1 segundo)
x ---> 20 milisegundos
x ---> 20 milisegundos
x = (30 * 20) / 1000 = 0.6
Es decir, para una velocidad de 30 pixeles por segundo, el objeto se movería 0.6 pixeles por cada tic de reloj.
Ahora, vamos a plasmar esta idea sobre código. Específicamente sobre el AMOS Basic de los ordenadores Amiga. Igualmente, la idea se podría implementar sobre ordenadores de 8 bits, como MSX o spectrum.
Lo que vamos a hacer es implementar un procedimiento(Procedure en AMOS) que controle el incremento de velocidad según vaya transcurriendo el timer. Cada vez que transcurra un tic de reloj, el procedimiento devolverá al programa principal la actualización del timer, así como el nuevo incremento en el eje horizontal y el eje vertical. Fijaos que este incremento se devuelve en las variables compartidas _INC_X# e _INC_Y#
Procedure APPLY_VELOCITY[PIX_SEC#, _TIMER] Shared _INC_X#, _INC_Y# _VEL_PIXELS_TIC#=(20.0*PIX_SEC#)/1000.0 : Rem pixeles por tic de reloj CURRENT_TIME=Timer _ELAPSED_TIME=(CURRENT_TIME-_TIMER) TIME_TIC#=0.02 If _ELAPSED_TIME>=TIME_TIC# : Rem si ha transcurrido un tic de reloj ... ' ...actualizamos timer e incrementos en pixeles horizontal y vertical _TIMER=CURRENT_TIME _INC_X#=_VEL_PIXELS_TIC# _INC_Y#=_VEL_PIXELS_TIC# Else _INC_X#=0 _INC_Y#=0 End If End Proc[_TIMER]
En este enlace , teneis todo el código, así como el banco de sprites que se utiliza. Al descomprimirlo vereis dos ficheros, el fuente del código que es un fichero con extensión amos, y un fichero con extensión .bak, que es el banco de sprites. Cargarlo en el AMOS y probarlo.
Fijaos como en el programa principal, inicializamos el timer para cada uno de los dos objetos del ejemplo, en las variables _TIMER_VEL1 y _TIMER_VEL2, respectivamente.
El primer objeto se mueve a 60 pixeles por segundo, y el segundo objeto a 50 pixeles por segundo.
Abajo os dejo el video de ejemplo de lo que vais a ver al ejecutar el código. Dicho ejemplo está ejecutado sobre el emulador WinUAE. La primera estrella va a una velocidad de 60 pixeles por segundo y la segunda a una velocidad de 50 pixeles por segundo.
Abajo os dejo el video de ejemplo de lo que vais a ver al ejecutar el código. Dicho ejemplo está ejecutado sobre el emulador WinUAE. La primera estrella va a una velocidad de 60 pixeles por segundo y la segunda a una velocidad de 50 pixeles por segundo.
Por hoy nada mas. En el siguiente artículo, veremos el movimiento rectilineo uniforme acelerado. Es decir, la aceleración y desaceleración de un objeto.
Comentarios
Publicar un comentario