| |
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? |
|
| |
Smasher
Registered: Feb 2003
Posts: 520 |
white queen moves in F4, checkmate!
:) |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
This can be achieved in several ways.
Basically you need to know that changing definition, X position or colors of a sprite affects it immediately in the next line, while changing its Y position can be safely done while the sprite is being displayed.
You can do it this way:
- Update Y position for next sprite row while the first is being displayed
- Change x position (or color: if you use multicolor mode you need to change only 2 registers) on the last line of each sprite row
If you sync your raster handler well you can do both things in the same IRQ. And BTW you can even use Y stretch to save some calls. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
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: 105 |
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: 545 |
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: 5094 |
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: 1409 |
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: 2980 |
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. |
... 42 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 - Next |
