English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 18 November 2010, 23:54   #21
Lonewolf10
AMOS Extensions Developer
Lonewolf10's Avatar
 
Join Date: Jun 2007
Location: near Cambridge, UK
Age: 39
Posts: 1,919
Hi,

Here's the requested snippet...

Code:
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
Lonewolf10 is offline  
Old 18 November 2010, 23:59   #22
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,013
Quote:
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?
StingRay is offline  
Old 19 November 2010, 00:41   #23
Lonewolf10
AMOS Extensions Developer
Lonewolf10's Avatar
 
Join Date: Jun 2007
Location: near Cambridge, UK
Age: 39
Posts: 1,919
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
Lonewolf10 is offline  
Old 19 November 2010, 20:06   #24
pmc
rebooting...
pmc's Avatar
 
Join Date: Apr 2007
Location: Elsewhere
Posts: 1,595
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...?
pmc is offline  
Old 20 November 2010, 03:39   #25
Lonewolf10
AMOS Extensions Developer
Lonewolf10's Avatar
 
Join Date: Jun 2007
Location: near Cambridge, UK
Age: 39
Posts: 1,919
Quote:
Originally Posted by pmc View Post
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
Lonewolf10 is offline  
Old 20 November 2010, 10:16   #26
pmc
rebooting...
pmc's Avatar
 
Join Date: Apr 2007
Location: Elsewhere
Posts: 1,595
Let us know how you get on.
pmc is offline  
Old 21 November 2010, 22:10   #27
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,161
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.

Code:
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
Leffmann is offline  
Old 22 November 2010, 20:26   #28
Lonewolf10
AMOS Extensions Developer
Lonewolf10's Avatar
 
Join Date: Jun 2007
Location: near Cambridge, UK
Age: 39
Posts: 1,919
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
Lonewolf10 is offline  
Old 22 November 2010, 21:13   #29
pmc
rebooting...
pmc's Avatar
 
Join Date: Apr 2007
Location: Elsewhere
Posts: 1,595
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...
pmc is offline  
Old 23 November 2010, 13:39   #30
TheDarkCoder
Registered User
 
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 211
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
TheDarkCoder is offline  
Old 23 November 2010, 22:40   #31
Lonewolf10
AMOS Extensions Developer
Lonewolf10's Avatar
 
Join Date: Jun 2007
Location: near Cambridge, UK
Age: 39
Posts: 1,919
Quote:
Originally Posted by TheDarkCoder View Post
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

Last edited by Lonewolf10; 23 November 2010 at 23:27.
Lonewolf10 is offline  
Old 24 November 2010, 08:50   #32
pmc
rebooting...
pmc's Avatar
 
Join Date: Apr 2007
Location: Elsewhere
Posts: 1,595
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.
pmc is offline  
Old 24 November 2010, 18:43   #33
Plagueis/KRX
coder
Plagueis/KRX's Avatar
 
Join Date: Jul 2009
Location: a galaxy far far away
Age: 44
Posts: 84
Quote:
Originally Posted by pmc View Post
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!
Plagueis/KRX is offline  
Old 12 February 2011, 21:46   #34
Lonewolf10
AMOS Extensions Developer
Lonewolf10's Avatar
 
Join Date: Jun 2007
Location: near Cambridge, UK
Age: 39
Posts: 1,919
Quote:
Originally Posted by TheDarkCoder View Post
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
Lonewolf10 is offline  
Old 13 February 2011, 11:55   #35
SyX
Registered User

 
Join Date: Sep 2004
Location: Brasil
Age: 44
Posts: 144
Hi!!!

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

You can read online if you want in Elowar
SyX is offline  
Old 14 February 2011, 00:00   #36
Lonewolf10
AMOS Extensions Developer
Lonewolf10's Avatar
 
Join Date: Jun 2007
Location: near Cambridge, UK
Age: 39
Posts: 1,919
Thanks for the direction, I don't know how I missed it, and those are the hands I was thinking of


Regards,
Lonewolf10
Lonewolf10 is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Is there a Pacmania with sprite-collision disabled? Predseda request.Other 3 30 January 2012 17:10
CJ's Elephant Antics - weird collision glitch MethodGit project.WHDLoad 0 21 August 2011 01:57
what games need 'full' collision level ? kirk support.WinUAE 25 07 February 2010 02:01
Hires and fast movement Galahad/FLT support.WinUAE 4 22 November 2009 08:47
Slamtilt and RTC collision Predseda support.Games 5 22 August 2009 22:28

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 05:32.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.08123 seconds with 14 queries