| |
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....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11127 |
i recommend to start exploring this using only ONE sprite. make some code that multiplexes it once by changing Y position mid screen. then try to place one sprite above the other (and learn how you can change Y position as soon as the first sprite started, and that sprites can not overlap). then multiplex it a few times, and change color/pointer/x-pos at various places and see what happens. then try doing it with more sprites...... starting with 8 sprites is a bit troublesome, because of the damned badlines that will come in the way sooner or later :) |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
Yes okay, I will try experiment with this |
| |
Hoogo
Registered: Jun 2002
Posts: 102 |
A 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. |
| |
TWW
Registered: Jul 2009
Posts: 541 |
Hi
Might I suggest another approach;
Use Hires or chars to do the chessboard and also possibly the characters.
I've made 2 prototype chess-games
The first one was all doen in hires (allowing a spritepointer) and another in hires Board With pieces in sprites (all 64 multiplexed etc.) allowing some interesting textures (However not possible to use a spritepointer unless you shrink the Board and free up a sprite).
Enclosed a couple of screenshots of how it looks;
 |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
y 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. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1380 |
Quoting RudiSo it will display a checkerboard, hence the sprites only need one of two colors. and they are filled with either of the color.
If you are just using solid sprites for alternating background colours, why not set $d021 to dark grey, and just use sprites for the mid grey squares? You then only need half as many. If you X expand them as well you might need even fewer - what is your tile size?
sprite IDs for underlay for 16x16 chars:
00 00 11 11
00 00 11 11
22 22 33 33
22 22 33 33
44 44 55 55
44 44 55 55
66 66 77 77
66 66 77 77
00 00 11 11
00 00 11 11
22 22 33 33
22 22 33 33
44 44 55 55
44 44 55 55
66 66 77 77
66 66 77 77
|
| |
ready.
Registered: Feb 2003
Posts: 441 |
here you find an example of full screen sprite mux, with line drawing on sprites.
https://www.dropbox.com/sh/25xzs0qlao2zydt/AACKIGyd3FZQC18RBB0W.. |
| |
Krill
Registered: Apr 2002
Posts: 2850 |
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. |
| |
Krill
Registered: Apr 2002
Posts: 2850 |
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. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 - Next |
