multiplexing sprites not working

[jotd]

I'm using sprpt registers to set sprites at the top of the frame

I naively thought that setting those registers in the middle of the frame would work for lower sprites but it doesn't seem so.

My idea was to try to display 8 sprites on first half of screen using this method (classic) then set new sprpt registers in the middle of the screen (with lower coords) so 8 more sprites could be displayed

It appears that after some beam position, the sprites are no longer displayed if I don't write to sprpt soon enough.

Is it me or this is just not possible to multiplex sprites that way because DMA fetches sprite pointers once per frame and that's it? or is there something to fix that?

[ross]

There are several ways to do what you want to do.

But first I have some questions:
1) don't you want to set the coordinates in the sprite list because you have the data 'scattered' in memory?
2) can you afford to modify the copper list to modify the sprite registers at will?
3) can you leave empty words at the head and tail of the sprites data in memory to allow you to have more control over the sprite list?

However, it's just a question of how you can manage the data and the copper list, what you want to do is doable and not to complex

[jotd]

Originally Posted by ross

There are several ways to do what you want to do.

But first I have some questions:
1) don't you want to set the coordinates in the sprite list because you have the data 'scattered' in memory?
2) can you afford to modify the copper list to modify the sprite registers at will?
3) can you leave empty words at the head and tail of the sprites data in memory to allow you to have more control over the sprite list?

However, it's just a question of how you can manage the data and the copper list, what you want to do is doable and not to complex

1) yes each sprite has its control word, data, and I can display a random set of sprites so it won't be possible to move data around.

2) yes, doable but I suppose that means allocating a lot of free space for each line

3) same as 1 probably. Answer is no. I'm generating 8 copies of the sprite data (to allocate them to any slot I want) and that's it. Chaining would not be practical. But maybe for a Galaga-style game it could be nice as most aliens are animated exactly the same, there aren't a lot of combinations.

[ross]

Originally Posted by jotd

1) yes each sprite has its control word, data, and I can display a random set of sprites so it won't be possible to move data around.

2) yes, doable but I suppose that means allocating a lot of free space for each line

3) same as 1 probably. Answer is no. I'm generating 8 copies of the sprite data (to allocate them to any slot I want) and that's it. Chaining would not be practical. But maybe for a Galaga-style game it could be nice as most aliens are animated exactly the same, there aren't a lot of combinations.

Good.
Probably in this situation the best thing to do is to allocate a pair of leading and trailing control words for each copy of sprite data.

Basically what you have to do is set the sprptr at the beginning of the frame to the first sprite (y in higher screen position) and which contains as last (control) words the coordinates of the next multiplexed sprite (with y further down the screen).
Then with copper set sprptr for the '2nd' sprite, directly to the data part skipping the control words, when the beam is after the last line of sprite+2 (or even last+1+'something').

If I wasn't clear, just ask for clarification.

EDIT:
Another alternative, equally effective and which does not require to use empy (control) words at the end of each sprite data, is to modify the sprptr exactly after the fetch of the last line data of the first sprite on the screen (this is to allow the sprite DMA sytem to fetch the new coordinates from the new sprite data).
But in this case everything is timing sensitive, you cannot, as in the previous case, modify the sprprt freely, but in the exact line x-position.
So in the case of moving sprites you must also change the y coordinates in the copper list dynamically.

[jotd]

That seems not too far from what I tried to do.

What I did:

Each sprite trailing control word was 0, which probably ended the sprite data fetch for that sprite right? nothing more possible to do in that frame?

BUT when positionning the top sprites, you're proposing to set the trailing control word to the coords of the next sprite (at the bottom of the screen), and then do what I did earlier: in the middle of the screen change sprite pointers.

Am I getting that correctly?

[ross]

Originally Posted by jotd

That seems not too far from what I tried to do.

What I did:

Each sprite trailing control word was 0, which probably ended the sprite data fetch for that sprite right? nothing more possible to do in that frame?

BUT when positionning the top sprites, you're proposing to set the trailing control word to the coords of the next sprite (at the bottom of the screen), and then do what I did earlier: in the middle of the screen change sprite pointers.

Am I getting that correctly?

Correct

[jotd]

aaaand it works perfectly! Now I can display more than 8 sprites now! thanks for the quick answer.

[jotd]

Been doing the multiplexing technique, it works but...

do you have an idea why the lower sprites would "blink" in cycle exact wheras it's fine in non-cycle exact.

I'm multiplexing blank sprites (on top) with non-blank sprites when it happens. If I remove multiplexing, the lower sprites stop blinking (If I remove cycle exact too)

[ross]

Originally Posted by jotd

Been doing the multiplexing technique, it works but...

do you have an idea why the lower sprites would "blink" in cycle exact wheras it's fine in non-cycle exact.

I'm multiplexing blank sprites (on top) with non-blank sprites when it happens. If I remove multiplexing, the lower sprites stop blinking (If I remove cycle exact too)

It seems like for some reason the pointers aren't updated in time or something (a race condition somewhere).
Anyway I would trust the CE version
You should do a minimum test exe and let me try it, I will be able to tell you the problem.

[jotd]

yes, you're right. I was zeroing the "next" upper sprite control word, and was setting it afterwards. This small time lapse between clear and re-set triggered the blink. Thanks!