Animated 48 Pixel Sprite Routine

[Mikes360]

Yet another post about 48 pixel sprites.. Im not obsessed I promise!

 

I am using two types of 48 pixel sprite routine the, the first uses a 12 byte RAM buffer and I store the address of 6 different tables in this buffer. I use indirect index addressing to load the sprite data from the tables and render the sprite

 

 

lda (spriteBuf),y

sta GRP0

 

lda (spriteBuf+2),y

sta GRP1

 

Pros: Can render multiple sprites with same kernel by adjusting buffer value

Cons: Expensive RAM cost and costly to modify the whole 12 byte buffer

 

The second uses absolute index addressing and has the obvious limitation of being able to only render one type of sprite meaning you need to write the whole kernel again to draw a different sprite.

 

 

lda SpriteGfx1,y

sta GRP0

lda SpriteGfx2,y

sta GRP1

 

I was wondering if anyone has ever invented a kernel that works in this way:

 

First we store the address of the first table of sprite data in 2 bytes of RAM. All 6 tables are in ascending order in ROM

We store the height of the sprite tables in another byte of RAM

 

In the sprite kernel we increment the y index by the height and index to get the data out of each table

 

Example:

 

 

lda (spriteBuf),y

sta GRP0

tya

adc spriteHeight

tay

lda (spriteBuf)y

sta GRP1

 

Has anyone ever seen a kernel that works in this way? I am not even sure this is possible to achieve with the limitations of the 2600. If it was possible to do something like this I think it would allow people to develop animated 48 pixel kernels more easily.

 

Obviously things like score kernels would not be able to work in this way because the sprite table needs to be in a continuos manner on ROM.

 

 

Thanks,

Mike

[Tjoppen]

You could store graphics so that something like this works:

lda (ptr),Y
sta GRP0
iny
lda (ptr),Y
sta GRP1
;keep doing INY + LDA (ptr),Y + STA GRPx blah blah

Since Y isn't free for temporary storage this might not work for 48 pixel sprites, but 40 pixel sprites should be fine.

Edited July 8, 2013 by Tjoppen

[Thomas Jentzsch]

Has anyone ever seen a kernel that works in this way? I am not even sure this is possible to achieve with the limitations of the 2600. If it was possible to do something like this think it would allow people to develop animated 48 pixel kernels more easily.

There is a problem with the CPU cycles required. You need 5 additional calculations, each require an extra of 7 cycles. That's 35 extra cycles where you only have 76 cycles in total.

 

Also the 12 byte RAM routine isn't that bad. The 12 bytes are only required temporarily. So if you arrange your RAM usage cleverly, this shouldn't be a problem.

[roland p]

Or use INC spriteBuf + 1 and have several pages with sprites.

 

I agree that the 12 byte RAM routine is ok.

[Mikes360]

Yes perhaps the 12 byte RAM routine is potentially the most flexible. The only issue I currently have with mine is that it does not do single line resolution colour. Here is the whole routine is anyone aware of how to get single line colour resolution in as well?

 

.scoreLoop
ldy temp2 ;3
lda (scoreBuf+10),y ;5
sta GRP0 ;3
sta WSYNC ;3
lda (scoreBuf+,y ;5
sta GRP1 ;3
lda (scoreBuf+6),y ;5
sta GRP0 ;3
lda (scoreBuf+4),y ;5
sta temp4 ;3
lda (scoreBuf+2),y ;5
tax ;2
lda (scoreBuf+0),y ;5
tay ;2
lda temp4 ;3
sta GRP1 ;3
stx GRP0 ;3
sty GRP1 ;3
sta GRP0 ;3
dec temp2 ;5
bpl .scoreLoop ;3 

[Thomas Jentzsch]

One trick is to use black, inverted sprites over a colored playfield. That way you have to write only one register. Then use lax instead of lda/tax. Finally remove WSYNC and make sure the loop is exactly 76 cycles.

 

Check my source code for Jammed for some details.

[Mikes360]

The idea of using inverted sprites seems a great way to shave 3 cycles in a 48 pixel kernel. I have had a go at shaving off some cycles in my sprite routine to get 8 cycles spare to set the color but cant quite manage it. Can anyone see a way to shave off the two cycles needed to set the color?

 

.scoreLoop
ldy temp2	 ;3
nop	   ;2
nop	   ;2
nop	   ;2 - 6 cycles free
;lda (scoreBuf+12),y  ;5 - need 8 to use this code
;sta COLUPF	 ;3
lda (scoreBuf+10),y   ;5
sta GRP0	 ;3 
lda (scoreBuf+,y   ;5
sta GRP1	 ;3
lda (scoreBuf+6),y   ;5
sta GRP0	 ;3
lda (scoreBuf+4),y
sta temp1

lax (scoreBuf+2),y 

lda (scoreBuf+0),y   ;5
tay	   ;2

lda temp1

sta GRP1	 ;3
stx GRP0	 ;3
sty GRP1	 ;3
sta GRP0	 ;3
dec temp2	 ;5
bpl .scoreLoop    ;3

[+SvOlli]

ldy temp1

sty GRP1         ;3
stx GRP0         ;3
sta GRP1         ;3
sta GRP0         ;3

[Mikes360]

Wow that was easier than I thought. Cant believe I didn't spot that. Now I have a lovely flexible 48 pixel multi-color routine!

 

Thanks for all your help guys.

[Mikes360]

One trick is to use black, inverted sprites over a colored playfield. That way you have to write only one register. Then use lax instead of lda/tax. Finally remove WSYNC and make sure the loop is exactly 76 cycles.

 

Check my source code for Jammed for some details.

 

So when you setup the playfield in this way do you need to set the correct bits in PF0, PF1 Aand PF2 each time depending on the sprites position or is there a better way to do it using object priority?

[Thomas Jentzsch]

So when you setup the playfield in this way do you need to set the correct bits in PF0, PF1 Aand PF2 each time depending on the sprites position or is there a better way to do it using object priority?

This only works good when you display a centered score or graphics.

 

Just use a reflected playfield, then you only need to set PF2 to a fixed value (%11111100).

Edited July 9, 2013 by Thomas Jentzsch

[Mikes360]

Luckily I need this for a centered score and some text data in the middle of the screen so its still a goer!

[+SvOlli]

There also is another option if it's not centered: you can set playfield mode to "repeat", and then set up a 48 pixel wide block using the missile sprites in 8 pixel width to cover up the "other half".

[Mikes360]

There are a lot of options when handling 48 Pixel sprites someone could do with creating a guide to all the know techniques and discussing there pros and cons.

[Thomas Jentzsch]

There also is another option if it's not centered: you can set playfield mode to "repeat", and then set up a 48 pixel wide block using the missile sprites in 8 pixel width to cover up the "other half".

I had forgotten that trick.