Faxanadu collision detection - Part III (Sprite behaviour I)

OK, let's begin. The main part of the function I'm going to discuss in this update is located between offset $A66B and offset $A68E.

There are two checks at the beginning, if neither of these are passed the function instantly returns. The first check once again tests if the hour glass is active. If it's inactive the second check comes into play. The sprite ID of the current sprite ($2CC,X) is used to address the table at $B544. This table stores a one byte value per sprite that contains the general category the sprite falls into.

Valid values for bytes in that table are:

$00: Sprite is a small monster
$01: Sprite is a reward (gold or meat)
$02: Sprite is a NPC
$03: Sprite is some kind of non-interactive animation, for example the death animations of the monsters or fountains.
$04: Apparently unused; not one byte in the table has value four.
$05: Sprite is an item
$06: Sprite is some kind of magic
$07: Sprite is a large monster

Apparently the second check determines whether or not the current sprite is a monster. That makes sense because only monsters are frozen by the hour glass.



If at least one of the two checks succeeded the sprite can be moved. This is done (indirectly) in the part that comes now, the main part of that function.

The next two sprite data arrays are introduced here. The first one ranges from $354 to $35B and the second one follows right thereafter ($35C - $363). The combination of the two values ($354,X is the lower byte; $35C,X is the upper byte) forms a pointer to what I call the sprite description table. This table contains meta-data that describes how the individual sprite types behave. More on this later when the rest of the function was discussed. For now it's sufficient to know that the sprite description table contains top level rules (or main rules) and (depending on the top level rule) sub-rules.

In the first part of the code the top level rule of the sprite's behavioral meta-data is loaded and executed.



Afterwards the currently active sub-rule (as written by the function call to $A6BC above) is loaded from the next sprite data array ($2D4 - $2DB). This sub-rule is then used as an index into the sub-rule table ($A5E7) which contains pointers to the actual code that belongs to a given sub-rule. The check that makes sure that the sub-rule ID is not larger than $84 (or better $42) only leads to some error-correcting code I'm not going to discuss here.



That's the end of the function so let's now have a look into the function at $A6BC which is used to load the main rule of the current sprite. Remember that $CA/$CB contains an offset to the beginning of the sprite's sprite description table entry.



The table offset $A6D9 contains eight entries for eight top-level rules. What exactly these rules do is the topic of the next two updates.