| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Updating sprite X msb
Slack bastard time. Recs for updating $d010 if I've got an eight bit x-position in my object table, but all my sprites are offset a constant number of pixels to the right? Current draft is this:
clc
lda mobX,x
adc xoffset
sta $d000,y
lda #0
adc #255
eor #255
eor $d010
and hibit,x
eor $d010
sta $d010
(x is both object ID and sprite number (I'll change how I index mobX later), y is double the sprite number. hibit contains 2**i) |
|
... 4 posts hidden. Click here to view all posts....
|
| |
The Human Code Machine
Registered: Sep 2005
Posts: 109 |
It's faster to unroll the code:
lda mobX
clc
adc xoffset
sta $d000
ror xhi
lda mobX+1
clc
adc xoffset
sta $d002
ror xhi
and so on
lda xhi
sta $d010 |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
Quoting The Human Code MachineIt's faster to unroll the code:
lda mobX
clc
adc xoffset
sta $d000
ror xhi
lda mobX+1
clc
adc xoffset
sta $d002
ror xhi
and so on
lda xhi
sta $d010
Nice! Yes, and you can use zeropage for xhi :-) |
| |
The Human Code Machine
Registered: Sep 2005
Posts: 109 |
Yes, but it's only one cycle faster. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Quoting Color BarWhen you update all sprites in one loop, you may update $d010 as follows..
Ah yes, I should probably have mentioned that my use case is a multiplexer component; for the first eight sprites I will indeed shift the bits in one by one. |
| |
Hoogo
Registered: Jun 2002
Posts: 102 |
I wonder if that multiplexer reuses the sprites in order, so that for every call y will increased by 2 and start with 0 again? Not sure if that can make a difference, just thinking...
I guess offset is variable and not available when mobX is generated?
And are you already in need of rastertime, or is it just about making this a little more pretty?
clc
lda mobX,x
adc xoffset
sta $d000,y
lda $d010
bcc clear
ora hibit,y
bcs store
clear and hibit+1,y
store sta $d010
hibit !by 1, 255-1, 2, 255-2, 4, 255-4...
|
| |
Hein
Registered: Apr 2004
Posts: 933 |
8 pieces of code to jump to, all other stuff is done outside multiplexer. Y holds the current list index.
lax (sprite_index_lo),y
lda sprite_y,x
sta $d001
lda sprite_x,x
sta $d000
lda sprite_a,x
sta screen+$3f8
cmp sprite_x_msb,x ;$00 if cleared, $ff if set
lda $d010
and #%11111110
bcs +
ora #%00000001
+ sta $d010
lda sprite_c,x
sta $d027
|
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
|
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
Quoting HoogoI wonder if that multiplexer reuses the sprites in order, so that for every call y will increased by 2 and start with 0 again? Not sure if that can make a difference, just thinking...
If you can use a separate piece of code for each sprite, maybe you could do (for example for sprite 3)?
clc
lda mobX+3
adc xoffset
sta $d006
lda $d010
and #f7 ; clear first
bcc store
ora #$08
store
sta $d010
|
| |
Skate
Registered: Jul 2003
Posts: 490 |
Quote: Quoting HoogoI wonder if that multiplexer reuses the sprites in order, so that for every call y will increased by 2 and start with 0 again? Not sure if that can make a difference, just thinking...
If you can use a separate piece of code for each sprite, maybe you could do (for example for sprite 3)?
clc
lda mobX+3
adc xoffset
sta $d006
lda $d010
and #f7 ; clear first
bcc store
ora #$08
store
sta $d010
I remember writing a macro like this one, using sprite number as a parameter and generating these and/or values according to the number. this way code looks fine, things speed up, memory usage sucx, speed rocx. :) |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
Quoting Color Bar
If you can use a separate piece of code for each sprite, maybe you could do (for example for sprite 3)?
Now I look more carefully I see that this is what Hein is doing ... |
| Previous - 1 | 2 - Next |
