{"id":2927,"date":"2021-02-12T00:04:40","date_gmt":"2021-02-12T00:04:40","guid":{"rendered":"http:\/\/blog.rastersoft.com\/?p=2927"},"modified":"2023-12-25T19:47:30","modified_gmt":"2023-12-25T19:47:30","slug":"pintando-en-el-spectrum-14","status":"publish","type":"post","link":"https:\/\/blog.rastersoft.com\/?p=2927","title":{"rendered":"Pintando en el Spectrum (14)"},"content":{"rendered":"\n

El siguiente paso es implementar la l\u00f3gica del juego. Se trata de la parte del c\u00f3digo que hace que funcionen las cosas como deben funcionar<\/em>. Por ejemplo, se encarga de mover al personaje principal y a los secundarios, animar objetos, etc. Este c\u00f3digo se ejecutar\u00e1 justo despu\u00e9s de que hayamos pintado todos los gr\u00e1ficos en el buffer<\/em> secundario y mientras esperamos a que comience el barrido de un nuevo frame<\/em>.<\/p>\n\n\n\n

Esta parte se divide, al menos de momento, en dos piezas de c\u00f3digo: una que actualiza la posici\u00f3n de cualquier personaje, y otra que ejecuta las distintas tareas o tasks<\/em>.<\/p>\n\n\n\n

Movimiento de personajes<\/h2>\n\n\n\n

Dado que los personajes est\u00e1n animados, es necesario tener en cuenta en qu\u00e9 posici\u00f3n se encuentran en cada momento, si est\u00e1n ya donde deben estar o no, la fase de la animaci\u00f3n, etc. Adem\u00e1s, para ahorrar memoria, tenemos por un lado el cuerpo en s\u00ed y por otro las piernas, siendo estas \u00faltimas la \u00fanica parte animada realmente. Eso significa que cada personaje est\u00e1 compuesto realmente por dos sprites, pero s\u00f3lo uno es el que tiene secuencias de animaci\u00f3n. Adem\u00e1s, cada bloque est\u00e1 repetido en espejo<\/em>, para cuando el personaje tiene que moverse hacia el lado opuesto.<\/p>\n\n\n\n

\"\"<\/a>
Sprites que forman a un personaje. Arriba est\u00e1n los dos cuerpos, uno para cada lado, y debajo de cada uno est\u00e1n las secuencias de animaci\u00f3n de las piernas que corresponden a cada uno de los dos cuerpos.<\/figcaption><\/figure><\/div>\n\n\n\n

Cada personaje est\u00e1 definido en una estructura como la siguiente:<\/p>\n\n\n\n

    DEFB 0x01 ; bit 0: 1-> es el personaje principal\n              ; bit 1: 1-> es un personaje secundario\n              ; bit 2: 1-> est\u00e1 caminando; 0-> no camina\n              ; bit 5: 1-> mira hacia la izquierda; 0-> a la derecha\n              ; bit 6-7: etapa de animaci\u00f3n\n              ; si el byte vale cero, es FIN DE LA TABLA\n    DEFB NOWX ; coordenada X actual\n    DEFB NOWY ; coordenada Y actual\n    DEFB DESX ; coordenada X final\n    DEFB DESY ; coordenada Y final\n    DEFW sprites_table ; puntero al sprite para el cuerpo\n    DEFW (sprites_table + 6) ; puntero al sprite para los pies<\/pre>\n\n\n\n
Vemos que tenemos, por un lado, la etapa actual de la animaci\u00f3n y a qu\u00e9 lado est\u00e1 mirando actualmente el personaje, por otro lado dos juegos de coordenadas, y por \u00faltimo dos punteros a dos entradas de la tabla de sprites, uno apuntando a la entrada que muestra el cuerpo del personaje y otra que apunta a la entrada de las piernas. Cuando queremos que un personaje camine desde donde est\u00e1 actualmente (cuyo valor est\u00e1 almacenado en NOWX, NOWY) hasta otro sitio, debemos simplemente escribir las coordenadas de destino en DESX, DESY, y la rutina de movimiento de personajes se encargar\u00e1 del resto. Esta rutina se ejecuta justo despu\u00e9s de pintar todo el buffer secundario<\/em>, y lo que hace es comparar la coordenada X actual con la X final, y lo mismo con la Y. Si son iguales, pondr\u00e1 el bit 2 a 0 para indicar que el personaje est\u00e1 en su destino y pasar\u00e1 a la siguiente entrada. Sin embargo, si alguna de las dos coordenadas actuales no es igual a su hom\u00f3loga final, la rutina le sumar\u00e1 o restar\u00e1 1, en funci\u00f3n de lo que sea necesario para acercar al personaje a su posici\u00f3n final. A continuaci\u00f3n copiar\u00e1 las coordenadas actuales en cada una de las dos entradas de la tabla de sprites. Luego incrementar\u00e1 en uno la etapa de animaci\u00f3n, y en base al valor de \u00e9sta decidir\u00e1 qu\u00e9 sprite concreto se mostrar\u00e1 para los pies (modificando para ello la entrada correspondiente de la tabla de sprites), adem\u00e1s de ajustar la coordenada Z (porque nuestros personajes se mueven a saltos). Tras hacer todo esto, saltar\u00e1 a la siguiente entrada de la tabla y repetir\u00e1 estas operaciones hasta llegar al final.<\/p>\n\n\n\n
Vemos, pues, que esta rutina nos simplifica mucho el mover un personaje desde una zona del mapa hasta otra, pues s\u00f3lo tenemos que poner las coordenadas finales y esperar a que el bit 2 cambie de 1 a 0 para saber que ha llegado.<\/p>\n\n\n\n
Gestor de tareas<\/h2>\n\n\n\n
La rutina anterior nos ayuda un poco, pero todav\u00eda nos queda por implementar absolutamente toda la l\u00f3gica del juego en s\u00ed. La primera idea consiste en escribir una funci\u00f3n que se llame justo despu\u00e9s de terminar de actualizar las posiciones de los personajes (esto es, justo des pu\u00e9s de la rutina anterior), y que, en base al estado actual del juego (donde est\u00e1 el protagonista, el resto de personajes, los objetos, etc) decida cual debe ser el nuevo estado (donde estar\u00e1 el protagonista y el resto de personajes, si alg\u00fan objeto aparece o desaparece…), tras lo cual se pintar\u00e1 de nuevo el mapa y se repetir\u00e1 el proceso.<\/p>\n\n\n\n
Por desgracia, hacer algo as\u00ed complica sobremanera la tarea, y adem\u00e1s hace que cualquier cambio que se quiera hacer pueda afectar a otras partes, por lo que el c\u00f3digo probablemente quedar\u00eda muy complejo. Por eso decid\u00ed seguir la idea que Ron Gilbert<\/a> y compa\u00f1\u00eda utilizaron en Scumm<\/a>, la m\u00e1quina virtual que desarroll\u00f3 para el juego Maniac Mansion<\/a>: permitir crear m\u00faltiples tareas que se ejecuten en paralelo y de manera independiente.<\/p>\n\n\n\n
La idea b\u00e1sica es que cada personaje u objeto se maneje desde una tarea independiente, y que como mucho se a\u00f1adan puntos de sincronizaci\u00f3n entre ellas. Las tareas se ejecutan mediante multitarea cooperativa, y se ejecutan una vez por frame<\/em> del juego. Cuando una tarea ha terminado de hacer lo que tenga que hacer, simplemente tiene que hacer una llamada a una subrutina concreta para avisar, cediendo el control a la siguiente. Cuando todas las tareas se han ejecutado, se pintar\u00e1 el siguiente frame<\/em>, se actualizar\u00e1 la posici\u00f3n de los personajes, y volver\u00e1n a ejecutarse las tareas una a una, pero con el detalle de que cada una continuar\u00e1 su ejecuci\u00f3n justo donde se qued\u00f3 en el frame<\/em> anterior, y adem\u00e1s la pila o stack<\/em> conservar\u00e1 todos los valores que la tarea hubiese almacenado en su ejecuci\u00f3n previa.<\/p>\n\n\n\n
Veamos c\u00f3mo es la implementaci\u00f3n:<\/p>\n\n\n\n
task_list:\n    DEFW $+TASK_DATA_SIZE+2\n    DEFS TASK_DATA_SIZE\n    DEFW tarea1\n    DEFW $+TASK_DATA_SIZE+2\n    DEFS TASK_DATA_SIZE\n    DEFW tarea2\n    DEFW 0 ; fin de la tabla de tareas\n\n\ntask_run:\n    ld (old_stack), SP ; preservamos la pila global\n    ld iy, task_list\ntask_loop:\n    ld l, (iy+0)\n    ld h, (iy+1)\n    ld a, h\n    or l\n    jr z, task_end\n    ld sp, hl ; asignamos a SP la pila de la tarea a ejecutar\n    ret ; y saltamos al c\u00f3digo de la tarea\n\ntask_yield:\n    ld hl, 0\n    add hl, sp ; almacena en HL el stack actual\n    ld (iy+0), l\n    ld (iy+1), h ; y lo guarda en la entrada de la tabla de tareas\n    ld de, TASK_ENTRY_SIZE\n    add iy, de\n    jr task_loop ; siguiente entrada de la tabla de tareas\n\ntask_end:\n    ld SP, (old_stack) ; restauramos la pila global\n    ret<\/pre>\n\n\n\n
Vemos que la tabla est\u00e1 dimensionada para dos tareas, y cada entrada de la tabla de tareas est\u00e1 compuesta de dos partes:<\/p>\n\n\n\n