Used by the routine at SORT_AND_DRAW_THINGS.

Called by the depth sort (SORT_AND_DRAW_THINGS) for each object in turn, back to front. The projection (PROJECT_THING) gives the object's place relative to the knight's in DRAW_X and DRAW_Y; adding the drawing offsets (+C, +D) gives the pixel x and y of the sprite's bottom left corner, which are kept in +E and +F. The game's y counts upwards: the play area is 112 lines, from y 72 at the bottom (line 127 of the screen) to 183 (line 16), and its buffer 24 bytes a row from x 16, of which the first two bytes are a margin never shown (COPY_BUFFER).

An object is not drawn at all if its x is below 16 or above 202, or its y is 184 or more, or either high byte from the projection is not 0. If its bottom is below the play area, only its rows from y 72 up are drawn; if its top is above, only those below. The knight's graphics (16 to 47, legs and top) are cut instead at ARRIVING lines above the bottom, which counts up to 112 as he appears at a new life (UPDATE_KNIGHT), so he is shown from the ground up. The entry point DRAW_SPRITE_AT draws at +E and +F as they are, with no projection and no checks at the sides; the ending's pictures use it (ENDING_PIT_FRONT).

The row loop is unrolled for a sprite five bytes wide, twice: a plain run for a sprite whose x is on a byte boundary (SPRITE_ALIGNED_RUN), and a shifted run that reads its bytes through the tables of SHIFT_TABLES and touches one byte more a row (SPRITE_SHIFTED_RUN). This routine patches the offset of the JR in SPRITE_ROW to enter the right run as many units from its end as the sprite is wide, and the operand of the ADD at SPRITE_NEXT_ROW (SPRITE_SHIFTED_FOUR) with the step from the last byte drawn in a row to the first of the row above. Bits 1 and 2 of x choose the shift, 0 (the plain run), 2, 4 or 6 pixels; bit 0 is ignored, so things move across in steps of two pixels. The stack pointer reads the sprite: SP is pointed at the data and each POP DE fetches a mask into E and its image into D, the real SP kept in SAVED_SP meanwhile.

On the way out SPRITE_WIDTH holds the bytes drawn a row (one more than the sprite's width when shifted), SPRITE_ROWS the rows drawn, and bit 1 of the object's flags (+7) is set. Checked in the simulator, drawing a monster's sprite into an empty buffer at a range of places: the rows land from y less 72 up, the clipping at the bottom, the top and ARRIVING comes out as described, and the patched offsets and steps are the ones worked out here.

Nothing is clipped at the sides beyond the tests on x. A sprite starting in a row's last byte runs on into the first bytes of the row above: the two margin bytes hide two of them, but a four-byte sprite drawn shifted there would put its last two into the visible columns 2 and 3 of the row above (the simulator shows the run-on; whether it is ever seen in play is not known).