Sprites Tiles and other superfast screen output approaches

[abalore]

The sprite drawing technique in Alcon is this:

- Three buffers (two for double buffering and a third with an intact image of the background)
- The third buffer can be in normal RAM (for an all-system cartridge game) or in expanded RAM for 128K only.
- The sprites are compiled and address for screen line increments are in a lookup table, so they don't need to be computed all time.

an example of a 6x2 lsprite:

ld bc,&3020
xor a
ld (hl),a : inc l : ld (hl),b : inc l : ld (hl),c : pop de : add hl,de
ld (hl),a : inc l : ld (hl),&30 : inc l : ld (hl),c

- You can cache the 3 most common values in a,b,c for quicker drawing
- All transparent bytes don't require ld (hl)..., you can just skip with "inc l", great for rounded or hollow sprites
- Bytes with only one transparent pixel require special treatment, but I won't reveal everything >D
- Non common values are written directly in (hl), like "ld (hl),&30", no need for intermediate registers
- All the painting requires the interruptions to be disabled, since you use stack to retrieve line increments
- You can do "inc l" in 32 char width screens, for other sizes you need to do "inc hl" with less performance
- I have an utility on PC to import and create the compiled sprites but it's not available
- Obviously some previous code is required to load the initial address in HL and the increment table offset in SP

Further optimizations:

- You can use inc l and dec l in alternate lines for smaller lookup tables
- If you agree with having few colors, you can use bitwise operations to draw and delete sprites with same routine
- If you have to skip many bytes, instead of inc l : inc l :inc l : inc l : inc l  you can do ld a,l : add 5 : ld l,a

[gurneyh]

The sprite drawing technique in Alcon is this:

- Three buffers (two for double buffering and a third with an intact image of the background)
- The third buffer can be in normal RAM (for an all-system cartridge game) or in expanded RAM for 128K only.
- The sprites are compiled and address for screen line increments are in a lookup table, so they don't need to be computed all time.

an example of a 6x2 lsprite:

ld bc,&3020
xor a
ld (hl),a : inc l : ld (hl),b : inc l : ld (hl),c : pop de : add hl,de
ld (hl),a : inc l : ld (hl),&30 : inc l : ld (hl),c

- You can cache the 3 most common values in a,b,c for quicker drawing
- All transparent bytes don't require ld (hl)..., you can just skip with "inc l", great for rounded or hollow sprites
- Bytes with only one transparent pixel require special treatment, but I won't reveal everything >D
- Non common values are written directly in (hl), like "ld (hl),&30", no need for intermediate registers
- All the painting requires the interruptions to be disabled, since you use stack to retrieve line increments
- You can do "inc l" in 32 char width screens, for other sizes you need to do "inc hl" with less performance
- I have an utility on PC to import and create the compiled sprites but it's not available
- Obviously some previous code is required to load the initial address in HL and the increment table offset in SP

Further optimizations:

- You can use inc l and dec l in alternate lines for smaller lookup tables
- If you agree with having few colors, you can use bitwise operations to draw and delete sprites with same routine
- If you have to skip many bytes, instead of inc l : inc l :inc l : inc l : inc l  you can do ld a,l : add 5 : ld l,a

Great. Can you explain how you manage sprite clipping in Alcon? 

[abalore]

The sprite drawing technique in Alcon is this:

- Three buffers (two for double buffering and a third with an intact image of the background)
- The third buffer can be in normal RAM (for an all-system cartridge game) or in expanded RAM for 128K only.
- The sprites are compiled and address for screen line increments are in a lookup table, so they don't need to be computed all time.

an example of a 6x2 lsprite:

ld bc,&3020
xor a
ld (hl),a : inc l : ld (hl),b : inc l : ld (hl),c : pop de : add hl,de
ld (hl),a : inc l : ld (hl),&30 : inc l : ld (hl),c

- You can cache the 3 most common values in a,b,c for quicker drawing
- All transparent bytes don't require ld (hl)..., you can just skip with "inc l", great for rounded or hollow sprites
- Bytes with only one transparent pixel require special treatment, but I won't reveal everything >D
- Non common values are written directly in (hl), like "ld (hl),&30", no need for intermediate registers
- All the painting requires the interruptions to be disabled, since you use stack to retrieve line increments
- You can do "inc l" in 32 char width screens, for other sizes you need to do "inc hl" with less performance
- I have an utility on PC to import and create the compiled sprites but it's not available
- Obviously some previous code is required to load the initial address in HL and the increment table offset in SP

Further optimizations:

- You can use inc l and dec l in alternate lines for smaller lookup tables
- If you agree with having few colors, you can use bitwise operations to draw and delete sprites with same routine
- If you have to skip many bytes, instead of inc l : inc l :inc l : inc l : inc l  you can do ld a,l : add 5 : ld l,a

Great. Can you explain how you manage sprite clipping in Alcon?

The sprites clip a maximum of 8 pixels in horizontal, by painting on black over them (there are a two 1 char black columns at both sides), and 32 pixels in vertical (that's easy)

The sprites with 1 pixel horizontal movement have preshifted versions thanks to the huge capacity of cartridges

[Anthony Flack]

you can also use a different order to make HL ends up back on line 1 again so you can keep using it, or you could make it end up on the line you want HL to be on i guess. 

Yeah, with a bit of thought you can cover all kinds of different situations with a series of single SETs and RESs. You just have to be prepared to draw your lines out of order.