Episode 3: Sprites

It's time to think about display code, as in displaying sprites. But before we actually do so, we need something to be displayd, namly sprites. For this purpose, I made a Tiny 8-Bit Sprite Editor, a tiny web app dedicated to editing monochrome 8-bit sprites of indefinite height, as used for the VCS. It generates a live listing of ready to copy assembler code and also imports assembler code, either generated by the editor or from some other source, even a stream of bare values will do (one byte definition per line, in hex, binary, decimal, just as you prefer.)

Try it here: Tiny 8-Bit Sprite Editor.

VCS Sprites

There's nothing special about VCS sprites (apart from the aspect ratio). We need to transfer a byte per scan line to the TIA ,and we probably want to so a by an indexed load instruction, as in "lda Sprite, X". So a sprite will be a stream of bytes in memory, and, because we'll have to switch off the sprite after its last line, we're probably going to terminate it by a zero-byte. (Meaning, the zero-byte is part of the sprite, so we won't have to write special code for switching the sprite off.)

However, things become a bit quirky — as so often on the VCS — as sprites are usually in reverse order in memory. Actually, the entire vertical display code is commonly in reverse order (bottom-up), and we're going to see next episode, why this is. In short, there's a proven method to display sprites while consuming a reliable number of CPU cycles, regardless of whether we're actually displaying some or not, known as the Skip-Draw method. Based on the countdown on the line number, we're going to determine, if a given sprite is currently on or not, providing the offset in an index-register. However, the index is going to count down, as well, effecting in the reverse byte order in memory.

We may illustrate this by a sketch for the score digits (roughly similar to the MICRE E-13-B characters for magnetic ink recognition):

Score digits.

To accomodate for this, the Tiny 8-Bit Sprite Editor has an option to generate the code in reverse order and also another one to import code in reverse order (so that we can edit it in visual order, but have the code ready for copy & paste anyway.)

However, our ships are symmetrical along their main axis and we don't have to bother for the byte order here, other than making sure that the terminating 0-byte is on top. Here are the canditates, I came up with. One a bit more modern and edgy, the other one more on the cute side. We may stick with both, maybe selectable by the difficulty switches.

Candidates for player ships.

Here's the assembler data generating these ships:

Sprites
    .byte $00
    .byte $10 ; |   X    |
    .byte $10 ; |   X    |
    .byte $58 ; | X XX   |
    .byte $BE ; |X XXXXX |
    .byte $73 ; | XXX  XX|
    .byte $6D ; | XX XX X|
    .byte $73 ; | XXX  XX|
    .byte $BE ; |X XXXXX |
    .byte $58 ; | X XX   |
    .byte $10 ; |   X    |
    .byte $10 ; |   X    |

    .byte $00
    .byte $70 ; | XXX    |
    .byte $78 ; | XXXX   |
    .byte $5C ; | X XXX  |
    .byte $9E ; |X  XXXX |
    .byte $C3 ; |XX    XX|
    .byte $BC ; |X XXXX  |
    .byte $C3 ; |XX    XX|
    .byte $9E ; |X  XXXX |
    .byte $5C ; | X XXX  |
    .byte $78 ; | XXXX   |
    .byte $70 ; | XXX    |

Finally, here's what it looks like in the Stella emulator (slightly stretched as the display has to match the hardware pixels of modern LCD displays):

Our ships displayed in Stella.

▶ Next:  Episode 4: Sprites II — Positioning

◀ Previous:   Episode 2: Sketching the Game / First Playfield

▲ Back to the index.

— This series is part of Retrochallenge 2018/04. —