Allocate all enemies on sprite cycling

The previous commit only tackled the first enemy, this one handles the
"rest_o_enemies" code flow, which was entirely missing.

Signed-off-by: Miquel Sabaté Solà <mssola@mssola.com>

3 files changed, 43 insertions, 4 deletions

diff --git a/include/globals.s b/include/globals.s
index d9052f1..d4a7f55 100644
--- a/include/globals.s
+++ b/include/globals.s
@@ -16,7 +16,7 @@
     zp_tmp0 = $05
     zp_tmp1 = $06
     zp_tmp2 = $07
-    ;; zp_tmp3 = $08
+    zp_tmp3 = $08
 
     ;;;
     ;; Reserve a byte of memory for preserving indices on memory. This is needed
diff --git a/src/driver.s b/src/driver.s
index a52051c..75e56b6 100644
--- a/src/driver.s
+++ b/src/driver.s
@@ -163,7 +163,8 @@
 
     .proc sprite_cycling
         ;; The 'y' register will contain the index on OAM of the sprite to be
-        ;; allocated.
+        ;; allocated. Note that we skip the player as that is handled directly
+        ;; as we want to guarantee that the player never flickers.
         ldy #(Player::PLAYER_SPRITES_COUNT * 4)
 
         ;;;
@@ -308,9 +309,41 @@
         inx
         jmp @rest_o_bullets
 
+        ;; Allocate the rest of the valid enemies from the pool.
     @rest_o_enemies:
-        ;; TODO: rest of enemies
-        ;; TODO: rest of items
+        ldx #0
+    @rest_o_enemies_loop:
+        ;; If we are already passed the amount of bytes we could allocate for
+        ;; enemies, then jump to items. If the current indexed enemy is the one
+        ;; we allocated as the first fixed one, then skip it.
+        cpx #Enemies::ENEMIES_POOL_CAPACITY_BYTES
+        beq @rest_o_items
+        cpx zp_first_enemy
+        beq @next_enemy
+
+    @do_enemy:
+        ;; Ok, so the enemy has not been allocated yet and we have space for
+        ;; it. Is it valid?
+        lda Enemies::zp_enemies_pool_base, x
+        cmp #$FF
+        beq @next_enemy
+
+        ;; Yes! Then call the enemy allocator with the values we have now. Note
+        ;; that the 'y' register will be updated as desired, but the 'x'
+        ;; register will become bananas. Hence, save its value before calling
+        ;; and restore it back after the call.
+        stx Globals::zp_tmp3
+        jsr Enemies::allocate_x_y
+        ldx Globals::zp_tmp3
+
+    @next_enemy:
+        inx
+        inx
+        inx
+        jmp @rest_o_enemies_loop
+
+    @rest_o_items:
+        ;;; TODO
 
         ;; Are all spots already filled? As in, did the 'y' register wrap
         ;; around? If so, just go to the end.
diff --git a/src/enemies.s b/src/enemies.s
index aa2e0aa..0c0873f 100644
--- a/src/enemies.s
+++ b/src/enemies.s
@@ -147,6 +147,12 @@
     ;; The 'y' register will be updated by increasing its value by 16,
     ;; indicating the amount of bytes allocated in OAM space.
     ;;
+    ;; The 'x' register will be changed, so make sure to back it up if you care
+    ;; about its value before calling this function.
+    ;;
+    ;; The 'Globals::zp_tmp0', 'Globals::zp_tmp1' and 'Globals::zp_tmp2' memory
+    ;; regions are also tampered by this function.
+    ;;
     ;; NOTE: this function assumes that the enemy is in a valid state. That's up
     ;; to the caller to check on this before calling this function.
     .proc allocate_x_y