Faxanadu collision detection - Part III (Sprite behaviour II)

Let's start with the first top-level rule (ID: $00). This rule is used as the first top-level rule of nearly all sprites and basically initializes a sprite. The code of this rule is located between the offsets $A6FF and $A72B and between $9917 and $9946.

A new sprite data array ($2E4 - $2EB) is introduced here. I call it the phase counter array. A phase is a distinct part in a sprite's behaviour. Monster $2A for example has four phases: Short crouch, short jump, long crouch, long jump. The array keeps track of the phase the monster is currently in. Every time the following code is executed the phase counter is increased by one.



In the following code there's a call to a very important function ($A879) which is frequently called when handling information from the sprite description table. Containing only seven instructions the function is as trivial as important though. It only adds the value passed in register A to the pointer stored in $CA/$CB (I call $CA/$CB the rule pointer). It's used to navigate through the sprite description table.
There are two more values read from the sprite description table. The first one is the sub-rule to be executed after the execution of the main rule finished. The second one (stored in $364 - $36B) is the duration of the phase that the sprite entered. For example the value written to $364,X for the short crouch of sprite $2A is 5 while the value for the long crouch is $14.



At the end there's a check whether the sub-rule to execute next is 6. If that's the case there's a jump to some more initialization data. This sub-type is however used one single time and for a monster (sprite ID $12) that isn't even part of the game. The distinguishing feature between this monster and all other sprites in the game is that this monster has body parts that move quasi-independently from each other while the bodies of all other sprites move as one "block".



The body of monster $12 has four different parts which are initialized in the code at $9917. The initialization code is pretty interesting because it features five sprite data arrays which have not yet been mentioned.
The first of these arrays is $304 - $30B. It contains a value that's used to determine the size of a sprite. How exactly that works is discussed at a later point. This value is probably set to zero as the sprite is treated differently than all other sprites.
The second array ($C2 - $C9) contains the vertical position of the active sprites. In the code below the vertical position of three of the four body parts of the sprite are set to the vertical position of the main body part - n times $10 and stored in $37C - $37E.
The third array ($BA - $C1) contains the horizontal position of the active sprites. The three secondary body parts are set to the same horizontal position as the main body part.
The fourth array ($2EC - $2F3) holds another counter that's used to determine the sprite's behaviour. It's exact meaning is sprite-specific.
The last array ($2F4 - $2FB) is used to calculate how a sprite moves in vertical direction (jumps or flies).



Let's have a look at the main rule with ID $01 now which is considerably shorter than the one we've already discussed. This rule is used for unconditional jumping to another main-rule. One byte after the rule identifier there's a pointer that points to the next rule to be executed. This pointer is loaded into the rule pointer addresses and the next main rule is loaded (the one the rule pointer now points to). This rule is actually used just a single time, for the sprite of the old man next to springs.



The next main rule ($02) is the most complex of all main rules. So complex in fact that it deserves an update on it's own. Therefore the next rule I'm going to present here is the rule with ID $03. This rule is used to select one of two sub-rules depending on the distance between the player and the sprite. This is, for example, used for the king sprite which stands up from his throne when the player comes close and sits down again when the player leaves.



The first of the two sub-rules of main rule $03 checks whether or not the sprite is within a certain distance to the player on the X axis.



Load pointer to the first alternative main-rule:



Load pointer to the second alternative main-rule:



The second of the two sub-rules checks whether or not the sprite is within a certain distance of the player on the Y axis. This rule is used significantly less often than the first rule. It's used in only two sprites and one of them is a monster that's not even used in the actual game. It's also very interesting that the code of this rule is way shorter than the code of the first sub-rule even though both could have been written like the second rule.



Main rule $04 is extremely short. It only completes the current phase by setting the MSB bit in the sub-rule byte that belongs to the sprite.



The code of main rule $05 ($A754 - $A771) equals the code of main rule $01 except for two instructions. Before loading the next main rule the byte of the sprite in the phase counter array ($2E4 - $2EB) is reset to zero.

Main rule $06 is definitely the weirdest of all main rules. I know what it does but I'm not sure why it does what it does. Let's have a look.

At first two more bytes forming an offset are loaded from the sprite description table and stored in $02/$03. Afterwards another byte is loaded from that table and added to the offset the pointer points to (plus Y, the number of the current sprite). So it's basically used to add a pre-defined value from the sprite description table to a value from one of the sprite data arrays. In practice the only sprite data array used by this kind of main rule is $BA - $C1, the X coordinates of the sprite.
Now why would adding a predefined value to the sprite's X position value ever be necessary? I already have a decent idea but I'm not 100% sure. The precision of the sprite placement meta-data is 16 pixels (1 block). A higher precision is necessary for some sprites though, for example for NPCs sitting at a table. That's where main rule $06 kicks in and adjusts the exact position of the sprite I guess.



Unless I made a mistake the last main rule (ID: $07) isn't actually used by any sprite at all. It's very short and easy to understand though. It just loads a value representing a sprite phase from the sprite behavior table and stores that value in the sprite data array where the phases of the active sprites are stored.