English Amiga Board

Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

Thread Tools
Old 27 November 2019, 16:51   #1
OCS forever!

Antiriad_UK's Avatar
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 169
Yet another sprite disabling question

I'm getting myself in knots here. I've got a routine that is using some sprites and it's all good. When the routine moves into the next effect I've got a transition copperlist that makes sure sprite dma is turned off during vblank, and that's all fine.

For whatever reason, if I wanted to turn off sprite dma during the display of a sprite, what is the correct way of doing it so that you don't get garbage? As a test I've setup a full screen sprite and turn off the dma in the middle of display so I can see lovely corruption for testing.

If I disable sprite dma, then write 0 to SPRxDATA and SPRxDATB then I get no corruption, but the HRM says that writing DATA has armed the sprite so I guess what is actually happening is that the sprite is still being shown as per the whatever is in the SPRxPOS register but I just can't see it as the sprite data is 0000. Seems to work but feels icky.
move.w	#DMAF_SPRITE,dmacon(a6)
moveq	#0,d0
move.l	d0,spr0data(a6)		;SPRxDATA and SPRxDATB
move.l	d0,spr1data(a6)
move.l	d0,spr2data(a6)
move.l	d0,spr3data(a6)
move.l	d0,spr4data(a6)
move.l	d0,spr5data(a6)
move.l	d0,spr6data(a6)
move.l	d0,spr7data(a6)

If instead I write 0 to SPRxCTL the HRM says that this disarms the sprite. This also seems to work and I get no corruption, but the DATA/B registers still have some remnants in them but nothing is displayed. Also feels icky.

move.w	#DMAF_SPRITE,dmacon(a6)
moveq	#0,d0
move.w	d0,spr0ctl(a6)		;SPRxCTL
move.w	d0,spr1ctl(a6)
move.w	d0,spr2ctl(a6)
move.w	d0,spr3ctl(a6)
move.w	d0,spr4ctl(a6)
move.w	d0,spr5ctl(a6)
move.w	d0,spr6ctl(a6)
move.w	d0,spr7ctl(a6)

Which is the least bad way of doing this "if you have to"?
Antiriad_UK is online now  
Old 27 November 2019, 17:33   #2
Per aspera ad astra

ross's Avatar
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,418
Throws a coin
Both methods are good and right.

The canonical method would be to modify the SPRxCTL EV bits to right value in memory sprites structure during VB.

EDIT: Having to choose, I would use your second method. In any case at next DMA DATA/B are overwritten..

Last edited by ross; 27 November 2019 at 17:41.
ross is offline  
Old 27 November 2019, 19:18   #3
OCS forever!

Antiriad_UK's Avatar
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 169
Thanks, I was leaning towards option 2 as well. I've added "ross approved" to my function notes ;p
Antiriad_UK is online now  
Old 27 November 2019, 22:56   #4
ex. demoscener "Bigmama"

Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,041
I'm pretty sure I always used the second method..
hooverphonique is offline  
Old 28 November 2019, 11:26   #5
son of 68k
meynaf's Avatar
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,661
If you don't know it's CTL or DAT you have to clear, to be 100% sure you can clear them both
meynaf is offline  
Old 28 November 2019, 21:23   #6

Photon's Avatar
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 4,818
Neither is correct in my book. Writing to CTL should just move the corruption to X=0 where you can't see it (because DMA is still on, test by writing 0 except for X bits set to some visible position), and replacing the 0 with a 1 to DAT should show you that word repeating vertically until bitplane or sprite dma is turned off at EOF.

As an experiment you could try to replace YSTOP from the initial CTL word with endline+1 (at endline in the Copper), then on the next copper line write 0 to both CTL words before hpos $24 or whatever it was - and see if it stops pixel-perfect.
Photon is offline  
Old 28 November 2019, 22:20   #7
Registered User

Join Date: Jun 2016
Location: europe
Posts: 174
I typically handle this by always using pairs of copper lists, similar to you, one for initialization/transition and the main one. The init one contains all the constant stuff (usually colors, $1fc, modulos, and similar) and there I also cram in all 8 sprite pointers pointing to a single 0 longword if needed, dma takes care of the rest automatically (and I can manually wipe out all the registers if needed). Once I'm done with precalc/init part of whatever is coming up next, I switch to the main copper list (and optionally wait a frame to make sure the entire init copper list is executed). This way I also save a few chipmem accesses every frame.
a/b is offline  
Old 28 November 2019, 22:32   #8
OCS forever!

Antiriad_UK's Avatar
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 169
Yeah that’s what I’m doing . I’ve got a “framework ” dummy cl that has all the spite pointers set up for a dummy sprite. Then similar to what you say for each effect section I’ll swap to other lists.

But during testing I’ve got a loop running outside the vbl checking for a right mouse to exit section immediately and it didn’t use the transition copper. I noticed it was messing up the sprites and was just interested in a function that I could throw in there to disable spites and not leave garbage no matter when it ran
Antiriad_UK is online now  

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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Sprite clipping question (OCS Amigas) dirkwhoffmann Amiga scene 1 28 June 2019 20:10
The proper way of disabling a sprite? (Using DisplayLibrary) earok Coders. Blitz Basic 6 05 June 2018 11:36
Sprite Channel Question LuMan Coders. Blitz Basic 2 17 March 2016 17:51
AMOS Sprite Programming Question ricky500 support.Apps 1 26 June 2012 17:10
32 and 64 bit sprite control words question FrenchShark Coders. General 8 10 January 2008 03:32

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 14:38.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.07926 seconds with 13 queries