Sprites Issue

sandruzzo · 29 March 2018, 10:42

Hi All,

I'm trying to change sprites pointer during the screen via copper:

dc.w $0120,0000
dc.w $0122,0000
....
dc.w $af01,$fffe <- copper wait

dc.w $0120,0000
dc.w $0122,0000
....

Nothing seems to happens. Is that possible? Do I have to take care of somenthing in particular? I'm using Aga with burst at 64 bits

Thanks

StingRay · 29 March 2018, 12:15

If nothing happens your code to set the sprite pointer either isn't called at all or it is wrong or sprite DMA is not enabled! Make sure the code is called and check that the copperlist writes to the sprite pointers are done correctly.

sandruzzo · 29 March 2018, 12:21

Quote:

Originally Posted by StingRay

If nothing happens your code to set the sprite pointer either isn't called at all or it is wrong or sprite DMA is not enabled! Make sure the code is called and check that the copperlist writes to the sprite pointers are done correctly.

All is fine!

sandruzzo · 29 March 2018, 12:27

If I double spritex Y size, seems to work. I'm doing some more checks

phx · 29 March 2018, 20:58

I don't know about AGA, but I did the same in an OCS project a few days ago. Did you forget to rearm the sprite 0 channel? Otherwise make sure the new pointer is loaded before the 0,0 control words are read, i.e. during the last line with sprite data, after the sprite's DMA slot (for example, hpos>=$38).

ross · 30 March 2018, 18:44

Well, many time a proper pre-made sprite list in memory suffice.
But in fact a 'gapless' multiplexed sprites engine or something really dynamic could require copper list tampering

Photon · 31 March 2018, 17:47

What the other guys said. Having a second sprite below another using the same channel(s) is called multiplexing, and the hardware can automatically chain sprites like you want to do without have to reinitialize. If it fits your purpose, you can replace the dc.w 0,0 after the sprite data with the next sprite's control words, sprite data and dc.w 0,0.

sandruzzo · 01 April 2018, 08:14

Quote:

Originally Posted by Photon

What the other guys said. Having a second sprite below another using the same channel(s) is called multiplexing, and the hardware can automatically chain sprites like you want to do without have to reinitialize. If it fits your purpose, you can replace the dc.w 0,0 after the sprite data with the next sprite's control words, sprite data and dc.w 0,0.

Thnaks. I know how they works, but i needed to change sprites pointers

Photon · 01 April 2018, 17:43

Yep, there are many reasons why the built-in chaining is not optimal, the biggest one is that you sometimes have to copy spritedata to chain them, which sort of defeats its purpose

I think Phx answered your question. Likely sprite DMA has been turned off before you load the pointers, so you must set the sprite DMA bit in DMACON.

If it hasn't turned off, you must turn it off, wait a scanline, and then set the bit.

29 March 2018, 10:42	#1
sandruzzo Registered User Join Date: Feb 2011 Location: Italy/Rome Posts: 2,291	Sprites Issue Hi All, I'm trying to change sprites pointer during the screen via copper: dc.w $0120,0000 dc.w $0122,0000 .... dc.w $af01,$fffe <- copper wait dc.w $0120,0000 dc.w $0122,0000 .... Nothing seems to happens. Is that possible? Do I have to take care of somenthing in particular? I'm using Aga with burst at 64 bits Thanks

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Some sprites	Frog	project.Sprites	6	22 August 2022 20:01
Aga Sprites Attached issue	sandruzzo	Coders. Asm / Hardware	11	28 April 2016 14:17
amiga computing vol 2 issue 1 (issue 13 anyone)	Mort	request.Other	0	30 November 2010 11:27
Pang sprites	qtelSparrow	project.Sprites	3	12 March 2010 22:10
Where are all the sprites?	Gambit37	project.Sprites	8	14 October 2005 14:49

29 March 2018, 12:15	#2
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,863	If nothing happens your code to set the sprite pointer either isn't called at all or it is wrong or sprite DMA is not enabled! Make sure the code is called and check that the copperlist writes to the sprite pointers are done correctly.

29 March 2018, 12:27	#4
sandruzzo Registered User Join Date: Feb 2011 Location: Italy/Rome Posts: 2,291	If I double spritex Y size, seems to work. I'm doing some more checks

29 March 2018, 20:58	#5
phx Natteravn Join Date: Nov 2009 Location: Herford / Germany Posts: 2,500	I don't know about AGA, but I did the same in an OCS project a few days ago. Did you forget to rearm the sprite 0 channel? Otherwise make sure the new pointer is loaded before the 0,0 control words are read, i.e. during the last line with sprite data, after the sprite's DMA slot (for example, hpos>=$38).

30 March 2018, 18:44	#6
ross Defendit numerus Join Date: Mar 2017 Location: Crossing the Rubicon Age: 53 Posts: 4,475	Well, many time a proper pre-made sprite list in memory suffice. But in fact a 'gapless' multiplexed sprites engine or something really dynamic could require copper list tampering

31 March 2018, 17:47	#7
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 5,604	What the other guys said. Having a second sprite below another using the same channel(s) is called multiplexing, and the hardware can automatically chain sprites like you want to do without have to reinitialize. If it fits your purpose, you can replace the dc.w 0,0 after the sprite data with the next sprite's control words, sprite data and dc.w 0,0.

01 April 2018, 17:43	#9
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 5,604	Yep, there are many reasons why the built-in chaining is not optimal, the biggest one is that you sometimes have to copy spritedata to chain them, which sort of defeats its purpose I think Phx answered your question. Likely sprite DMA has been turned off before you load the pointers, so you must set the sprite DMA bit in DMACON. If it hasn't turned off, you must turn it off, wait a scanline, and then set the bit.

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