Hi there,
no panic, it's just a minor glitch that I can't wrap my head around.
It concerns the attachment of 4 64 pixel sprites to a 128 wide and 4 bitplanes deep sprite object.
I'm moving this large attached sprite from leftmost ( out of visual range) position over the screen from
left to right until it vanishes at the rightmost side. No vertical modification.
We have now 4 sprites in an arrangement of 2*64pxSpr + 2*64pxSpr
The thing is, that, when the sprite enteres the visible range on the left side, the sprites go through a
very short glitch. But not all of them. Only the right half of each attachments ( 32 pixels wide) shortly flares up as if, for a moment, one or two sprite bitplanes are missing.
The currious thing is, that this doesn't happen to the normal 64pixel wide attached sprites I use simultaneously ( two objects using sprites 0+1 and 2+3). When they are moved accros this X position nothing flares up. No glitch whatsoever. The method I use for them is virtually the same, only adjusted to a gfx width of 64 pixels and therefore only using 2 sprites instead of 4.
ATM I do it like this:
I have two MACROS doing the positioning and sprite-bitplane assigment
LSPRH equ 24 ; height of sprite gfx
LSPRCTL equ [LSPRH+2]*8*2 ; controlword offset
; \1 Y pos d1-7
; \2 X pos d1-7
; \3 sprite src <label>
LSPRPOS MACRO
; prepare position word
move.w \1,d0
lsl.w #8,d0
add.w \2,d0
move.w d0,\3+LSPRCTL*0 ; spr0pos
move.w d0,\3+LSPRCTL*1 ; spr1pos
addi.w #32,d0 ; pivot X offset
move.w d0,\3+LSPRCTL*2 ; spr2pos
move.w d0,\3+LSPRCTL*3 ; spr3pos
; prepare control word
move.w \1,d0 ; Y pos
addi.w #LSPRH,d0 ; + SPRHeight
lsl.w #8,d0 ; * 256
move.w d0,\3+8+LSPRCTL*0 ; spr0ctl
move.w d0,\3+8+LSPRCTL*2 ; spr2ctl
addi.w #128,d0 ; + 128
move.w d0,\3+8+LSPRCTL*1 ; spr1ctl
move.w d0,\3+8+LSPRCTL*3 ; spr3ctl
ENDM
LSPRPL MACRO
move.l \1,d0 ; sprite gfx data
lea \2,a0 ; sprite bitplane pointer
moveq #\3-1,d7 ; loop counter
.\@:
move.w d0,6(a0)
swap d0
move.w d0,2(a0)
swap d0
add.l #8,a0
add.l #LSPRCTL,d0
dbf d7,.\@
ENDM
the data is organised as follows
section spritedata,data_c
; sprite gfx are saved as attached 64 px sprites plus control words
wall1: incbin "path/spritegfx/wall1_128x24x4.spr"
wall2: incbin "path/spritegfx/wall2_128x24x4.spr"
wall3: incbin "path/spritegfx/wall3_128x24x4.spr"
section copperdata,data_c
copperlist:
....
sprite1:dc.w $0120,$0000,$0122,$0000 ; spr0
sprite2:dc.w $0124,$0000,$0126,$0000 ; spr1
sprite3:dc.w $0128,$0000,$012a,$0000 ; spr2
sprite4:dc.w $012c,$0000,$012e,$0000 ; spr3
sprite5:dc.w $0130,$0000,$0132,$0000 ; spr4
sprite6:dc.w $0134,$0000,$0136,$0000 ; spr5
sprite7:dc.w $0138,$0000,$013a,$0000 ; spr6
sprite8:dc.w $013c,$0000,$013e,$0000 ; spr7
....
the MACROS get used in these simple routines
; pointers to the sprite gfx in chipmem
spriteWalls:
dc.l wall1,wall3,wall2
; X/Y coordinates for current sprite in motion
wallXY:
dc.w 230,157
; this routine is called with each vertical blank interupt
; writing position data to sprite ctrl words and
; checking if to replace the current sprite gfx wih the
; next one
moveWallSprite:
move.w wallXY+2,d1
move.w wallXY(pc),d2
; write position data to sprite gfx ctrl-words
LSPRPOS d1,d2,wall1
LSPRPOS d1,d2,wall2
LSPRPOS d1,d2,wall3
cmpi.w #240,wallXY
blt .noWrap
; this rotates through he sprite gfx pointers
lea spriteWalls(pc),a0
lea wallXY(pc),a1
bsr tableRotateL
; re-set X to 0
move.w #0,wallXY
; set the new/next sprite gfx
move.l spriteWalls(pc),a1
LSPRPL a1,sprite5,4
.noWrap:
; one pixel to the right
addq #1,wallXY
rts
; this routine gets only called once during the
; init of the whole scene, just to assign the
; first gfx to sprites 4-7
setWallSprite:
move.l spriteWalls(pc),a1
LSPRPL a1,sprite5,4
rts
Maybe it's just the sorting of which gfx plane gets pointed on which sprite ?
However, it's not a gamebreaker issue. If it's not fixed then all we have is a little glitch.
