Sprite movement and Collision Routine

[Blip]

Hi
Does anyone have a basic sprite movement, animation and collision asm sample?
Thanks

[bippym]

I'm sure the Hardware Manual covers this in detail. Not sure if there are examples but it explains the principles and what registers etc you need to check/modify

[StingRay]

I have attached 2 sprite routines to this message, one for 64pixel wide (i.e. AGA) sprites (attached/normal) and one very simple routine that sets a normal 4 color 16 pixel sprite. First routine is straight from my demosystem, the other one I pasted from a very old intro I did back in 1992. Hope it helps.

[Blip]

Thanks guys! its a start.

[StingRay]

Ok, me again, I've quickly adapted an old demopart of mine and removed everything except the spriteanimation routines. Also singlefiled it. I'll attach it to this message. I didn't bother to clean up the copperlist so there are some things that are not needed in it (original demopart features the spriteanim and a lightsourced vectorcube ;D). Oh, and the spriteanim is not ripped from Dynablaster, friend of mine drew it.

[Blip]

Nice one! Thanks again StingRay.

[Steve]

I've tried compiling the spriteanim code in Devpac 3.18 but its not having it. I get an error on line 162:

Error: wrong processor at line 162 in file spriteanim_eab.s

Here is that line:

.getit movec vbr, d0

Any ideas?

[Codetapper]

It's a 68020+ instruction so you will need to tell your assembler that it is OK to use. I hate Devpac so can't tell you what option/flags you need to set - or you could try changing the line to:

dc.l $4e7a0801

and seeing if that fixes it. From memory that is the opcode for that instruction but someone with an assembler handy can verify if it's not!

[Steve]

Ah thanks codetapper!

I changed to 68020 mode in the options and it worked. I'm not sure if thats the right opcode for the instruction.

I did encounter some warnings due to various spaces between comma's and numeric values in about 7 or 8 dc.l definitions. Not sure why the spaces were in there.

I also encountered 4 error messages due to a piece of code defined as AnimTabPtr_Sp and Devpac couldn't find the code as it was looking for AnimTabPtr_SP. Looks like case definitely matters to Devpac.

@StingRay: What is the FX Lib?

[Kalms]

Case sensitivity can be turned on/off in the options.

Some versions of GenAm (Devpac's assembler) are sensitive to extraneous spaces in operand lists, some are not. I think GenAm from Devpac 3.14 handled the spaces.

[Asman]

Originally Posted by StingRay

I have attached 2 sprite routines to this message, one for 64pixel wide (i.e. AGA) sprites (attached/normal) and one very simple routine that sets a normal 4 color 16 pixel sprite. First routine is straight from my demosystem, the other one I pasted from a very old intro I did back in 1992. Hope it helps.

Hi StingRay,

Very nice routines. I found a tiny mistake in SetSprite.i.txt comment. Should be "Also, Bit 2+3 in $dff1fc have to be set!"

I found very interesting doc about sprites. http://www.winnicki.net/amiga/achtun..._one_line.html and If I understand correctly that is possible to make 320-pixel wide ( five 64pixel sprites ) background with 16 colors. Can someone post some source about this nice effect ?

Regards
asman

[StingRay]

Originally Posted by Asman

Hi StingRay,

Very nice routines. I found a tiny mistake in SetSprite.i.txt comment. Should be "Also, Bit 2+3 in $dff1fc have to be set!"

Not a mistake (not for me at least as I perfectly understand the comment I made there) as I just counted the bits from 1 instead of 0.

Originally Posted by Asman

and If I understand correctly that is possible to make 320-pixel wide ( five 64pixel sprites ) background with 16 colors. Can someone post some source about this nice effect ?

Why would you need a source for that? Sprite routines are here in the thread, that's all you need.

[Asman]

Originally Posted by StingRay

Not a mistake (not for me at least as I perfectly understand the comment I made there) as I just counted the bits from 1 instead of 0.

Thats change everything. Sorry for my math perversion

Originally Posted by StingRay

Why would you need a source for that? Sprite routines are here in the thread, that's all you need.

Good point. When I answer for that question I just realized that you're right. Thanks

[Photon]

Is there like a 'HRM for AGA' somewhere? Sorry for my ignorance, but since Stingray did a fine job helping out with the sprite extravaganza, and I've only seen some shady .txt files on AGA differences back in the day, I'd really like to know if there is, or if we should start an 'AGA differences wiki' before the information dies with the coders

Haven't really looked before, a link will suffice if there is already documentation online.

[Leffmann]

The most complete source of info is the AA specification document. You can find it in the ASM-One 1.48 archive here http://www.theflamearrows.info/ftp/asmonev148.lha.

AGA is a pretty small upgrade really, it's not like learning a new hardware or anything. People coming from OCS/ECS should pay attention to the new FMODE register, it's the usual culprit when you can't get your stuff to display properly on AGA.

[Photon]

Yeah, well I just think there ought to be a proper (Commodore should have released a HRM) version for AGA and not some ascii in an .lha file somewhere which only coders can find

I know, I know, I've come in 12+ years after the fact, but still. Seems a little like learning AGA tricks is like searching for some obscure playing tips for an old adventure game... if you know what I mean...

[Leffmann]

I think the explanation was that Commodore were trying to get developers to start doing things through the Kickstart APIs instead of hitting the hardware directly, in order to prevent more software from being locked to specific machines.

The AA spec is a bit brief but it works great as a complement to the HRM, and I don't think there are any mysteries left in the AGA anymore unless you take weird intricate timing details into consideration.

[Photon]

OK, I'll have a look when it's time to aga.

Surely they must have documented the hardware changes? I'm hanging on to this question like a terrier just in case someone apart from our usual visitors here DOES know of some obscure but proper book.

[Lonewolf10]

Hi,

I have a small problem in that the HSTART,VSTART and HSTOP data is getting displayed along with the sprite! Can anyone please tell me why and how do I correct this, please?


Regards,
Lonewolf10

[pmc]

Hey Lonewolf10

can you post a code and sprite data snippet...?

[Lonewolf10]

Hi,

Here's the requested snippet...

dac_sprite:

	move.w	#$01a0,$dff096		;DMACON, disable sprite,copper &
					;	 bitplane DMA

					;setup 320x256 screen with 2 colours
	move.w	#$1200,$dff100		;BPLCON0
	move.w	#$0000,$dff102		;BPLCON1
	move.w	#$003f,$dff104		;BPLCON2
	move.w	#0,$dff108		;BPL1MOD
	move.w	#0,$dff10a		;BPL2MOD
	move.w	#$2c81,$dff08e		;DIWSTRT
	move.w	#$f4c1,$dff090		;DIWSTOP
	move.w	#$38c1,$dff090		;DIWSTOP (overscan)
	move.w	#$0038,$dff092		;DDFSTRT
	move.w	#$00d0,$dff094		;DDFSTOP
					;was copper2
	lea.l	s1,a1			;put sprite addresses into the
	lea.l	copspr,a2		;copperlist
	add.l	#2,a2
	move.l	a1,d1
	move.l	#7,d0				;number of sprites (8-1)

sprcoploop:
	swap	d1
	move.w	d1,(a2)
	addq.l	#4,a2
	swap	d1
	move.w	d1,(a2)
	addq.l	#4,a2
	add.l	#68,d1
	dbra	d0,sprcoploop

	lea.l	screen,a1			;Screen address added to
	lea.l	bplcop,a2			;the copperlist
	move.l	a1,d1
	move.w	d1,6(a2)
	swap	d1
	move.w	d1,2(a2)

	lea.l	copper,a1			;Load copperlist and place
	move.l	a1,$dff080			;into COP1LCH
	move.w	#$81a0,$dff096			;DMACON, activate sprite
						;copper and bitplane DMA

wait:						;wait for scanline 0
	move.l	VPOSR,d0
	asr.l	#8,d0
	and.l	#$1ff,d0
	cmp.w	#0,d0				;line 0 reached?
	bne	wait

text:
	bsr	movesprite			;movesprite subroutine
	rts					;exit subroutine

movecount:
	dc.w	0				;offset to table containing
						;sprite coords

movesprite:					;movesprite subroutine
	lea.l	movecount,a5			;movecount address in a5
	move.w	(a5),d5				;get value from address in a5
	add.w	#4,(a5)				;add 4 to movecount in a5

	cmp.w	#206,d5				;length of movetable -> d5
	blt	notend				;if d5<length goto notend

	moveq	#0,d5				;d5=0 (was clr.w)
	clr.w	(a5)				;clear address a5 points to

notend:
	moveq	#0,d1				;d1 & d2=0
	moveq	#0,d2
	lea.l	movetable,a5			;address of movetable in a5
	move.l	#15,d3				;d3=15

	move.w	(a5,d5.w),d1			;d1=(a5)+d5
	move.w	2(a5,d5.w),d2			;d2=(a5)+d5+2
	lea.l	s8,a1				;address of s8 placed in a1
	bsr	setspr				;jump to setspr subroutine

						;and repeat for the other 7 sprites
	rts

setspr:						;updates sprite positions
	movem.l	d0-d5,-(a7)			;held in the sprite table
	add.w	#$81,d1				;add $81 to get 0 x-coord
	add.w	#$2c,d2				;add $2C to get 0 y-coord
	moveq	#0,d5				;d5=0
	move.b	d2,(a1)				;move first byte of d2 ->(a1)
	move.l	d2,d4				;copy d2 value to d4
	lsr.w	#8,d4				;move high-byte to low-byte
	lsl.w	#2,d4				;shift value left twice
	add.w	d4,d5				;d5=d5+d4
	add.w	d3,d2				;d2=d2+d3
	move.b	d2,2(a1)			;move low byte to (a1)+2
	move.l	d2,d4				;copy d2 to d4
	lsr.w	#8,d4				;shift right by 8 bits
	lsl.w	#1,d4				;shift left by 1 bit
	add.w	d4,d5				;add lower word of d4 to d5
	move.l	d1,d3				;copy d1 to d3
	andi.l	#1,d1				;mask out bits 1-31
	add.w	d1,d5				;add lower word of d1 to d5
	move.b	d5,3(a1)			;move low byte in d5->(a1)+3
	lsr.l	#1,d3				;shift right by 1 bit
	move.b	d3,1(a1)			;move low byte of d3->(a1)+1
	movem.l	(a7)+,d0-d5			;restore registers
	rts

s1:
	dc.w $0000,$0000
	dc.w $F3C0,$0000
	dc.w $F3C0,$0820
	dc.w $F3C0,$0820
	dc.w $F3C0,$0820
	dc.w $F3C0,$0820
	dc.w $F3C0,$0820
	dc.w $F3C0,$0820
	dc.w $F3C0,$0820
	dc.w $FFC0,$0020
	dc.w $FFC0,$0020
	dc.w $7F80,$0060
	dc.w $3F00,$00C0
	dc.w $1E00,$0180
	dc.w $0C00,$0300
	dc.w $0000,$0600
	dc.w $0000,$0000

				;and repeat for other 7 sprites

movetable:			;sprite movetable (coords=X word,Y word)

	dc.w	128,180,128,178,128,176,128,174,128,172,128,170,128,168
	dc.w	128,166,128,164,128,162,128,160,128,158,128,156,128,154
	dc.w	128,152,128,150,128,148,128,146,128,144,128,142,128,140

Regards,
Lonewolf10

[StingRay]

move.l #7,d0 ;number of sprites (8-1)

You have only 1 sprite so your other sprite pointers contain "random" data.

Edit: or did you remove the data for the other 7 sprites to keep the source small for pasting here?

[Lonewolf10]

PMC asked for a code snippet, so I tried to keep it as small as possible and in doing so I did indeed remove the data for the other 7 sprites (including the code to setup said sprites that would be between "notend:" and "setspr:").

If you take a look at the screenshot posted earlier you can see more than 1 sprite onscreen. Not sure why the "S" (bottom sprite) has gone funky. Sometimes it's the "S" that is funky and sometimes the "S" is fine and the other sprites go funky. I am using an out of date version of WinUAE (2.0.1), but I don't believe that is the source of the problem.

The HSTART,VSTART and VSTOP are all clear (set to $0000,$0000) in the sprite data, but are set up during the execution of the program. It's then that I get the extra unwanted sprite data at the top of the letters


Regards,
Lonewolf10

[pmc]

Hmmmm... do things only go wrong with the sprites when you start moving them about...?

What happens if you just manually set some horizontal and vertical coordinates into the sprites and set the pointers to display them...?

Do you end up with correct looking static sprites...?

[Lonewolf10]

Originally Posted by pmc

Hmmmm... do things only go wrong with the sprites when you start moving them about...?

What happens if you just manually set some horizontal and vertical coordinates into the sprites and set the pointers to display them...?

Do you end up with correct looking static sprites...?

Regardless of whether the sprites are moving or not, I still get the extra unwanted data. I am wondering whether the copperlist is part of the problem here. I'll try using a different copperlist tomorrow. The one I am currently using contains alot of wait's and COLOR00 changes (used for the start of the title screen, but now redundant for the next part), aswell as setting the sprite addresses.


Regards,
Lonewolf10

[pmc]

Let us know how you get on.

[Leffmann]

First thought is that there could be an error in the setspr subroutine, and that it somehow calculates the sprite control words wrong. Try replacing it with the code below and see if that fixes the problem.

If not then make sure the sprites are 15 lines tall, since you move 15 into D3 and use that to calculate the vertical stop for all 8 sprites. Otherwise the error is probably in some other part of your program.

setspr   movem.w   d0-d3, -(sp)

         sf        d0          ; clear lower 8 bits in D0
         add.w     #$81, d1    ; calculate HSTART
         add.w     #$2c, d2    ;           VSTART
         add.w     d2, d3      ;           VSTOP

         lsl.w     #8, d2      ; get bit 8 of VSTART
         addx.b    d0, d0

         lsl.w     #8, d3      ; get bit 8 of VSTOP
         addx.b    d0, d0

         lsr.w     #1, d1      ; get bit 0 of HSTART
         addx.b    d0, d0

         move.b    d1, d2      ; merge and write control words
         move.b    d0, d3
         movem.w   d2-d3, (a1)

         movem.w   (sp)+, d0-d3
         rts

[Lonewolf10]

Hi folks,

I altered my copperlist. Previously I had the bitplanes and other items set up first, then a wait for line $2C and then sprite pointers! I have switched it so that the sprite pointers are first in my copperlist.

Now there is no unwanted data above each sprite, but occasionally (about once per second) any vertically moving sprites become "funky" (see the "S" from the attached pic in my post from 18th Nov.).
I switched out my code with that from Leffmann (thanks, it's much shorter and tidier looking), but the funkiness still occurs


Regards,
Lonewolf10

[pmc]

Hey Lonewolf10

If moving data around resolves or changes corruption issues it sounds like there might be a pointer to that data getting screwed up somewhere.

I had issues like that once in an intro I coded - messed up display data but only in certain situations - turned out I'd screwed some pointers up...

[TheDarkCoder]

Seems to be an issue related to the syncronization between the copper list and the code updating the sprite data structure. Make sure that the code modifies the sprite data before they are fetched from memory and the sprite pointer values in the clist before their vaues are fetched by the copper DMA

[Lonewolf10]

Originally Posted by TheDarkCoder

Seems to be an issue related to the syncronization between the copper list and the code updating the sprite data structure. Make sure that the code modifies the sprite data before they are fetched from memory and the sprite pointer values in the clist before their vaues are fetched by the copper DMA

It is a synchronisation issue of sorts, but I gave ample time for the sprite data to be updated (switched COLOR00 to red to show "spritemove:" routine runtime length and COLOR00 to green to show "pixel:" runtime length. Both colors are in the middle of the screen (not in the picture I uploaded though)).
After examining the sprite pointers more closely (thanks PMC), I found I was giving an invalid PF2P2-P0 code. BPLCON2 was set to $3F and I changed it to $24 (all sprites infront of playfield 1). The glitch still occurred so I carried on working...

I eventually found out that the glitch seemed to caused by odd pairs of sprite coordinates. For example, if I move a sprite from A to B all is fine, but if I move it from A to B to C then it glitches! Each movement occurs once per frame.
Unfortunately shortly after making this post, I found out that that doesn't seem to be causing it either. I guess one of my other pointers is borked somewhere... back to examining the register values.


Regards,
Lonewolf10

[pmc]

I wonder whether, at this point, it might be worth you stripping back your code to just setting up a basic playfield and copperlist to display your sprites statically.

That way, you can see that your copperlist and sprite data is OK.

Once that's working fine, look at adding back in the routines that setup the initial sprite coordinates and then move the sprites.

As each routine is added back in you can see when the glitches appear and that'll narrow your search down to specific routines.

Then it's worth, if possible, isolating those bits of your code and looking at them with a debugger to make sure they're doing everything you think they're doing. This will help narrow the search for the problem down even further.

Sorry man - not trying to talk down to you and teach you how to debug code - it seems like you're already pretty experienced with all your AMOS extension developing and the like.

Just trying to suggest things that have helped me fix code in the past.

[Plagueis/KRX]

Originally Posted by pmc

I wonder whether, at this point, it might be worth you stripping back your code to just setting up a basic playfield and copperlist to display your sprites statically.
<snip>
Just trying to suggest things that have helped me fix code in the past.

Not that what I'm about to say is super relevant either, since I'm working on my very first demo/intro prod on OCS, but that is exactly what I did with my (now working) sprite animation routine. I displayed one sprite statically, then another, then a few more, then I drew the actual data I wanted for them in place of the mockup I had previously used. Next I wrote a routine that altered the controlling word of one of the sprites so I had one moving, and then bit by bit increased the complexity until I had the display I wanted.

I always try and evolve my routines, especially when I'm stepping up to a new architecture/chipset, or a new demo effect I've never tried before.

Cheers!

[Lonewolf10]

Originally Posted by TheDarkCoder

Seems to be an issue related to the syncronization between the copper list and the code updating the sprite data structure. Make sure that the code modifies the sprite data before they are fetched from memory and the sprite pointer values in the clist before their vaues are fetched by the copper DMA

It was actually me corrupting the end of the copperlist which caused all the problems. I fixed it a while back, but couldn't find this thread then.


The reason for me posting in this thread is that I was wondering whether it is possible to display some sprites behind both playfields and some infront of both playfields?
Also, can anyone explain how BPLCON2 works? I understand the PF2PRI bit (no pun intended), but not PFxP0 to PFxP2. I seem to recall an image from the hardware manual that has 2 two hands interlinked with each other, but I can't seem to find it


Regards,
Lonewolf10

[SyX]

Hi!!!

The famous hands picture is in the chapter 7 of the HRM:

You can read online if you want in Elowar

[Lonewolf10]

Thanks for the direction, I don't know how I missed it, and those are the hands I was thinking of


Regards,
Lonewolf10