Table of Contents
Split Line Technique
This consists of all even rows being used by sprites and animated graphics and all odd rows by the background graphics.
Background Graphic Rules
Rule 1 The background graphics must only ever occupy the odd rows beyond the conceivable row that the hero or other sprites may reside on. Even rows above this theoretical row may be populated. However to promote visual continuity it may be better to avoid using even rows.
Rule 2 Inversed bytes may be used but will have the effect of appearing in front of the Hero Sprite. This is useful for Columns, low walls and boxes in the background.
Rule 3 Background Graphics may contain embedded sentinals (Bytes) for ease of design. Codes like $1C to $1F will be invisible to the naked eye but may be picked up to form land and sky limit tables by the ScreenInit code. These tables may then be used to determine limits in the collision code.
Rule 4 Paper Attribute changes within the conceivable sprite areas of the screen should not be used since the sprite will be unable to mask the background rows in black (which is the default mask colour).
Hero Sprite graphic rules
Each Hero Sprite contains both odd and even rows in one block graphic.
Rule 1 The sprite will mask the background graphics against its own odd rows so long as they are not a colour change attribute. The byte will simply be left unchanged when an attribute byte is detected (<64).
The Sprite may also just be the Mask, and given a background rich screen will give the illusion of shadow sprites. If the mask is omitted from the mix and only the sprite graphic is plotted, this may give the illusion of invisibility.
Rule 2 If the Background contains an Inversed byte (Top bit set) then the sprite bitmap byte on the subsequent row is not plotted.
The exception to this rule is when the sprite byte is a colour change. when this is detected the colour change is written to the screen.
An extension to the exception is when an empty bitmap byte exists in the sprite data on a single row between a colour change and the sprite bitmap and an inversed background byte is detected. The code currently handles this by looking for a byte value in the sprite bitmap row of less than 65. 64 is the code for a void (empty) bitmap.
This alleviates the effect of the problem. The proper way to alleviate the source of the problem would be to ensure the 64 valued sprite bitmap byte is always replaced in the data with the colour attribute for that row.
