atari2600land's Blog

Are you using blit code? You don't have to be limited to 8 pixels, however obviously the bitmap is in groups of 8. Here's an example from my shark game:

 

sharklGraphic:
    .byte    %00000011 
    .byte    %00000000
    .byte    %11001111
    .byte    %00000011
    .byte    %00111111
    .byte    %11111111
    .byte    %11000011
    .byte    %00000000

 

on first sight, it doesn't look like anything, but when called...:

 

; shark
    ; blue
    li $80
    lr 2, A
    li $C3
    lr 1, A
    ; 4 y position
    lisu    2
    lisl    4
    lr A, S
    lr 4, A
    ; 3 x position
    lisu    2
    lisl    3
    lr A, S
    lr 3, A
    ; 5 width
    li 16
    lr 5, A
    ; 6 height
    li 4
    lr 6, A
    lisu 3
    lisl 0
    lr A, S
    ci %00000001
    bz sharkr
    dci    sharklGraphic
    pi blit

 

[other code]

 

sharkr:
    dci sharkrGraphic
    pi blit

 

The width that is saved into register 5  (or height in register 6) can be as big as you want* I kept it to a multiple of 8 for ease, but shouldn't be effected by it at all. It simply reads the first 16 bits (two bytes in this case) then moves on to the next line. In my case I've used 4 lines, so its 8 bytes of 8 bits which is pretty uniform, but it could be any number of bytes. For ease in code the bitmap could be grouped like this:

 

sharklGraphic:
    .byte    %00000011, %00000000
    .byte    %11001111, %00000011
    .byte    %00111111, %11111111
    .byte    %11000011, %00000000

 

In the same game my scoring font looks like this:

 

n0g:
    .byte    %01101001
    .byte    %10011001
    .byte    %10010110

 

Again, its clearly not like that in game, its loaded for blit like this:

 

    ; 5 width
    li 4
    lr 5, A
    ; 6 height
    li 6
    lr 6, A

 

So a byte of bitmap is used for 2 lines.

 

There is however one massive benefit of doing it how you've done it: You could make animations where only one side of the graphic changes but the other stays the same. Say if you wanted the elephant to move its trunk in a certain way but keep the back end the same graphic (or vice-versa) you can get multiple graphic variations with potentially less byte cost, check a value, branch off like I do for directions, and dci the other graphic instead.

 

*obviously no point being more than 102 due to resolution, unless you are doing something crazy I guess.

Lisu 3 Lisl 0 in this case was used to check for shark direction, hence the branching code at the end.