Add some info to the sprite design document about my plans for handling clipping.

BuGS/sprites/sprites.md

@@ -56,3 +56,11 @@ If that item is exploding, the explosion is also drawn at this time.  Because we
 Then, these forground sprites can just set the upper two bits to overwrite the background colour.  This turns a load, and, or, store into a load, or, store cycle for each 4 pixels.  Spiders and scorpions never overlap with each other so they can avoid the "and" operation.  Fleas, scores and centipede segments may overlap with other sprites so they maybe need to perform an and operation to preserve background or other foreground pixels from other sprites.
 
 But there is one more optimization I have made.  The majority of foreground sprites are centipede segments and the centipede is mostly green (in the first level colour pallete).  This colour is always 11xx.  That means to make a foreground pixel green, we only need to set the two high bits of the pixel and that can always be done with just an or operation.  If the four pixels consist of only green pixels (one, two, three or four green pixels and no other colours), then that can always be done with just an or operation.  No masking is required.  Again, centipede segments are mostly green and there tends to be lots of segments so this is a useful optimization.
+
+## Clipping
+
+An exception to the "background is drawn first" rule though is the non-playable area of the screen.  This section contains tiles which may be blank or contain information about score, high score, number of lives left etc.  This is made up of background sprites but the non-playable area is drawn last.  That way, a spider or scorpion which is halfway onto the playable area on the left or right side is "trimmed" by overwriting the non-playable portion of the sprite with the non-playable background.  That tile will be marked dirty but unlike the background of the playable area, it is drawn last in order to clip those sprites.
+
+We also need to clip a flea which is dropping down from the top.  The solution there is that the game allocates memory before the SHR page, enough for an extra unseen tile above the screen.  A partially obscured flea is drawn offscreen into that part of memory before the SHR page.
+
+There is a similar problem when the flea reaches the bottom of the screen.  I haven't decided how to handle this yet.  After the SHR screen are the screen control bytes and the colour palettes so I can't just overwrite that memory with the off-screen flea sprite.  I could maybe allow the flea to corrupt this memory and then try to repair it.  Or maybe the flea sprite code will need to have special cases for the last few lines of the screen.  This problem is still to be solved.