| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
Multiplexing sprites?
Hi,
Thanks for all the help ive gotten so far here on csdb.
Now I've runned into another problem.
How the *** does sprite multiplexing work?
I just need the basic idea. I tried to read Cadaver and other tuts, but they seemed too advanced for my taste in continuing.
What my goal is basically to display 64 sprites that stands still. So it will display a checkerboard, hence the sprites only need one of two colors. and they are filled with either of the color. The sprites are displayed beneath the characters so i can either have black and white chess-pieces (using $d800) this works fine with 8 sprites! but now i need to fill the entire checkerboard.
(edit: the entire board is in singlecolor, not multicolor btw)
I have not yet figured out how it works in theory? I just need to have interrupts on each row and display the sprites.
I have a feeling it would work something like this:
01234567
12345670
01234567
12345670
01234567
12345670
01234567
12345670
sprite 0 has darkgray, sprite 1 gray color, sprite 2 darkgray, ..etc.. so it will show a checkerboard in the end..
is it as simple as just setting an interrupt and move the sprite or do one need something else to take into consideration as well? |
|
... 42 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting HoogoA friend stopped coding on C64 in '92 with something like this. He didn't know that he can't start a new instance of a sprite before the old instance has displayed its 21 rows of pixels. If your fields on the checkerboard have a height of 16 pixels, you can't simply move a sprite just 16 pixels, you have to move at least 21 and change their graphics. Actually, a chessboard suits 24x21 pixels sprites pretty well. There is no reason to have fields of only 2x2 chars. The board fits into 24x24 chars with 3x3 fields (24x24 pixels each), which leaves only one character row unused. Displaying the chess pieces on top of it using sprites leaves you 3 rasterlines (none of them a badline) to leasurely set sprite registers. It's not an end-boss seamless wall of sprites scenario. :) |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
Quote:
Out of the otherwise available 20+3 CPU cycles on a PAL badline, only 16 are taken by all sprite DMA.
Nope.
6510 is still in idle from the badline and before the first sprite fetch there are exactly 3 cycles: BA will be kept low and the CPU will have to wait for the whole sprite DMA to finish. On a PAL machine right after a badline you can't do anything before sprite 0 fetch, you'll lose 19 cycles.
Moreover, this means that you can't open side borders on a badline if sprite 0 is active. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: Quoting Oswaldy stretch would solve the 16 vs 21 pixel problem :) but I'd rather use X expanded sprites so you dont need all 8, otherwise sprite and character row dma will steal all your cycles on badlines. Not quite ALL cycles, if i'm not mistaken.
Out of the otherwise available 20+3 CPU cycles on a PAL badline, only 16 are taken by all sprite DMA.
There remain 3 CPU cycles in the right border (the first of those being the one to switch $d016 for open sideborders) before sprite 0 DMA begins and 4 CPU cycles in the left border, after sprite 7 DMA has finished.
Switching $d018 for new sprite patterns after a badline is possible using read-modify-write instructions to get into the 3-cycle gap.
yeah tried once, didnt know about the RMW trick, I was either 1 cycle soon or 1 cycle late. Didnt help with my dislike towards coding raster effects :) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting FreshNope.
6510 is still in idle from the badline and before the first sprite fetch there are exactly 3 cycles: BA will be kept low and the CPU will have to wait for the whole sprite DMA to finish. On a PAL machine right after a badline you can't do anything before sprite 0 fetch, you'll lose 19 cycles.
Moreover, this means that you can't open side borders on a badline if sprite 0 is active. Okay, you're probably right there. Still 4 cycles left to switch $d018. I certainly have coded multiplexers which didn't display any glitches when moving a seamless wall of sprites vertically across badlines, thanks to RMW instructions. :) |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
Yes, it's doable and you don't even need a RMW instruction. You can put a STx $d018 before BL so that its third (R) cycle happens when BA goes low: at the end of sprite DMA the CPU will execute the last W cycle.
Beside the strict timing, the other annoying thing is that you need to prepare a second charpage to switch $d018 transparently. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting FreshYes, it's doable and you don't even need a RMW instruction. You can put a STx $d018 before BL so that its third (R) cycle happens when BA goes low: at the end of sprite DMA the CPU will execute the last W cycle.
Beside the strict timing, the other annoying thing is that you need to prepare a second charpage to switch $d018 transparently. That's a minor nuisance in the world of C-64 raster coding :D
For some reason, a plain STx didn't work for me. But it's a while ago now, rastercode was more trial&error than educated guesses back then, to me, anyways :) |
| |
Skate
Registered: Jul 2003
Posts: 494 |
trial&error style coding is more valuable. it's all about "wow! somehow it worked, wohoo!" feeling. :) |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Quoting FreshYes, it's doable and you don't even need a RMW instruction. You can put a STx $d018 before BL so that its third (R) cycle happens when BA goes low: at the end of sprite DMA the CPU will execute the last W cycle.
Beside the strict timing, the other annoying thing is that you need to prepare a second charpage to switch $d018 transparently.
You need to set D018 before BA goes low if sprite 0 is on, otherwise BA still low until sprite 0 data is fetched on pal machines... |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
This way you would end up changing sprite definitions one line earlier.
If you need to change them on the line after BL (which is the one giving problems) and you are working with 8 sprites, you must switch $d018 on the only available cycle: cycle 11, which is "located" after preceeding sprite DMA and before badline DMA.
In short, changing the sprite definition on the line after a BL can be done by using a normal STx so that its fourth cycle falls exactly on cycle 11 *before* badline. |
| |
Fungus
Registered: Sep 2002
Posts: 686 |
@Krill now do wall of sprites moving with d011 scroll changing too. :D
Looking forward to that GAME. :) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 - Next |
