| |
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. |
| |
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. :) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
I dont think it can be done with stx, I have tried it with a stable raster and it was either too soon or too late with 1 cycle difference. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
fungus: thats fairly easy using the overlapping data "trick" :) |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
TWW: nice screens. the upper one looks more like what I need, but ill explain more of the details of mine below in this post. I dont really have the patience to draw each chess-piece in multicolor, and i allready drawed all the pieces in single color.
Oswald: Can I do multicolored sprites on top or below a single colored character? If so, of course I can use one sprite for two cells in the board. Great idea.
ChristopherJam: Yes, I'll look into that and all other possibilities.
Basically what I have now is this:
- 3x3 chars for one piece.
- A cell of board is displayed as one sprite below the characters that display the chess-piece.
The sprite is stretched in Y. so basically the data in memory for the sprite is 24x12 filled pixels. And after Y-stretch its 24x24 (fiting the 3x3 char).
Todo-list:
- Display two cells as multicolor sprite instead of one.
- My first attempt at doing sprite-multiplexing (with a simpler scheme than this project).
In screenshot 8 sprites are displayed behind the characters.
This is what I have at the moment (dont mind the colors). |
| |
algorithm
Registered: May 2002
Posts: 705 |
Quote: fungus: thats fairly easy using the overlapping data "trick" :)
Either that or have 1 of 8 timing based on lower 3 bits of $d011. Overlapping data method works very well as it is however. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
rudi,yes there's a sprite register to put them behind single color gfx, it just works. (d01b)
I recommend using Y expanded sprites, then sprite height is 42 and you can avoid bad lines completely if first sprite row starts on first displayed gfx line (this one bad line doesnt matter you can set up the first spr row way beforehand)
y stretch may be to much if you'll have an AI in there. Otherwise it spares memory with CPU cycles.. |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
Oswald: yes, saw that. i fixed it now. got 8 sprites for this screen (with expand for Y as well):
(edit: actually I havent gotten to the point where badlines is an issue. heheh, but now as i am finished with the basics, ill try multiplexing, just need a little break). |
| |
TWW
Registered: Jul 2009
Posts: 545 |
Rudi: Forget about sprites. You do not need that at all for the screen You have there. Use Singlecolor bitmap.
The only Challenge is to Draw up the pieces but if You want I can send You the Source for example #1 above which does just that.
Drawing up 3x3 cells With Graphics during gameplay is peanuts in RTIME and the lost RTIME With a screen full of sprites and not to mention the screensplitting/IRQ mess it's a Complete Waste.
Somtimes it's ok to rethink the strategy ;-)
Ps. Nice pieces. |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
TWW: Thanks. Bitmap? Oh sh** no, I totally forgot about Bitmap mode. If I can exclude the sprites altogheter of course I would do that. This is a good exercise for me on doing more than 8 sprites though. Ill check into bitmap mode as well. Yes, I only need the setup as in the screenshot, with more cells for the board and white pieces at the bottom ofc. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
yeah that screen can be done with a hires bitmap. just set up the colors in screen mem (once). and draw the pieces into it. multicolor screen would work too. 3 colors for pieces 1 color for background (d800)
or you could have a 7 color screen with the spritelayer, but drawing would be more complicated that way (sprite layer + bitmap) |
| |
TWW
Registered: Jul 2009
Posts: 545 |
Lol, I am an idiot!
There is even a MUCH faster and simpler way to do it: Extended char color mode.
You print the piece characters onto the screen and add #$40 when it's even or odd Board coordinates (assuming you use ZP to represent the Board layout (if not do it)). |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
I was about to mention extended colour mode, but TWW beat me to it :) |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
If this does not fuck up the resolution of the characters then I will go for it. |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
Yep, the board use only 54 characters in total. so it fits the description. |
| |
TWW
Registered: Jul 2009
Posts: 545 |
No worries, You have the full resolution as in singlecolor but You can define different background colors for the different characters.
So basically You need to Draw Your white pieceis (let's say Your charset is @ $2000) from $2000 and the black pieces from $2400. Then You set extended mode, define the colors and hardware does the rest. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
yeah, quite an awesome feature set for the gfx chip for 82, esp if you take into account that 2/3rd of the silicone is taken up by sprite HW. |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
yes. that was easy. no sprites:
thanks for the help. |
| |
Digger
Registered: Mar 2005
Posts: 437 |
@Groepaz/@Algoritm: What is this overlapping data trick?! Never heard of this before?! :D |
| |
Skate
Registered: Jul 2003
Posts: 494 |
@Rudi: Don't forget the movement animation. When a piece needs to move, put a sprite over that char, replace the char with an empty board cell, move the sprite, replace the sprite with the char version and disable that sprite. I hate chess games without movement animation. :) |
| |
algorithm
Registered: May 2002
Posts: 705 |
@digger. the first few lines at the bottom of the current set of sprites are also in the second row of sprites at the bottom..
now when the rasterline is at that section, you have ample time to change sprite pointers to the sprite definitions for the next row (and the gfx for these few lines will be the same, you will not see any glitches) useful for example when having digitized audio and sprite multiplexing or/and via adjusting d011 for vertical scroll for example. data for the lines can be transferred/plotted as the sprites are multiplexed. |
| |
TWW
Registered: Jul 2009
Posts: 545 |
Very good!
Now here is some notes I made when developed my prototypes which might help You from here;
Chessboard:
~~~~~~~~~~~
a b c d e f g h
+-----+-----+-----+-----+-----+-----+-----+-----+
| |#####| |#####| |#####| |#####|
8 | R |##N##| B |##K##| Q |##B##| N |##R##|
| |#####| |#####| |#####| |#####|
+-----+-----+-----+-----+-----+-----+-----+-----+
|#####| |#####| |#####| |#####| |
7 |##P##| P |##P##| P |##P##| P |##P##| P |
|#####| |#####| |#####| |#####| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |#####| |#####| |#####| |#####|
6 | |#####| |#####| |#####| |#####|
| |#####| |#####| |#####| |#####|
+-----+-----+-----+-----+-----+-----+-----+-----+
|#####| |#####| |#####| |#####| |
5 |#####| |#####| |#####| |#####| |
|#####| |#####| |#####| |#####| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |#####| |#####| |#####| |#####|
4 | |#####| |#####| |#####| |#####|
| |#####| |#####| |#####| |#####|
+-----+-----+-----+-----+-----+-----+-----+-----+
|#####| |#####| |#####| |#####| |
3 |#####| |#####| |#####| |#####| |
|#####| |#####| |#####| |#####| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |#####| |#####| |#####| |#####|
2 | P |##P##| P |##P##| P |##P##| P |##P##|
| |#####| |#####| |#####| |#####|
+-----+-----+-----+-----+-----+-----+-----+-----+
|#####| |#####| |#####| |#####| |
1 |##R##| N |##B##| K |##Q##| B |##N##| R |
|#####| |#####| |#####| |#####| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Piece ID:
~~~~~~~~~
White Pawn: #%00000001
White Rook: #%00000010
White kNight: #%00000011
White Bishop: #%00000100
White Queen: #%00000101
White King: #%00000110
Black Pawn: #%10000001
Black Rook: #%10000010
Black kNight: #%10000011
Black Bishop: #%10000100
Black Queen: #%10000101
Black King: #%10000110
Bit #3 signify virgin (0) or moved (1) piece.
Bit #4 Signify En Passant Candidate (1) or not (0)
Board Coordinates:
~~~~~~~~~~~~~~~~~~
0, 1, 2, 3, 4, 5, 6, 7
8, 9, 10, 11, 12, 13, 14, 15
16, 17, 18, 19, 20, 21, 22, 23
24, 25, 26, 27, 28, 29, 30, 31
32, 33, 34, 35, 36, 37, 38, 39
40, 41, 42, 43, 44, 45, 46, 47
48, 49, 50, 51, 52, 53, 54, 55
56, 57, 58, 59, 60, 61, 62, 63
Mapped to ZP adresses: $40 - $7f (0-63)
Basically both my prototyes will display the chessboards perfectly based on the pieces in those ZP address locations. From there it's easy to save/load a game, setup Challenges based on famous games etc. From here it's straight fwd. implementation of the move rules and path-checking. Then it's the AI.
And if You want to be cool, use a mouse routine to allow picking/dropping pieces ;-) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: Very good!
Now here is some notes I made when developed my prototypes which might help You from here;
Chessboard:
~~~~~~~~~~~
a b c d e f g h
+-----+-----+-----+-----+-----+-----+-----+-----+
| |#####| |#####| |#####| |#####|
8 | R |##N##| B |##K##| Q |##B##| N |##R##|
| |#####| |#####| |#####| |#####|
+-----+-----+-----+-----+-----+-----+-----+-----+
|#####| |#####| |#####| |#####| |
7 |##P##| P |##P##| P |##P##| P |##P##| P |
|#####| |#####| |#####| |#####| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |#####| |#####| |#####| |#####|
6 | |#####| |#####| |#####| |#####|
| |#####| |#####| |#####| |#####|
+-----+-----+-----+-----+-----+-----+-----+-----+
|#####| |#####| |#####| |#####| |
5 |#####| |#####| |#####| |#####| |
|#####| |#####| |#####| |#####| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |#####| |#####| |#####| |#####|
4 | |#####| |#####| |#####| |#####|
| |#####| |#####| |#####| |#####|
+-----+-----+-----+-----+-----+-----+-----+-----+
|#####| |#####| |#####| |#####| |
3 |#####| |#####| |#####| |#####| |
|#####| |#####| |#####| |#####| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |#####| |#####| |#####| |#####|
2 | P |##P##| P |##P##| P |##P##| P |##P##|
| |#####| |#####| |#####| |#####|
+-----+-----+-----+-----+-----+-----+-----+-----+
|#####| |#####| |#####| |#####| |
1 |##R##| N |##B##| K |##Q##| B |##N##| R |
|#####| |#####| |#####| |#####| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Piece ID:
~~~~~~~~~
White Pawn: #%00000001
White Rook: #%00000010
White kNight: #%00000011
White Bishop: #%00000100
White Queen: #%00000101
White King: #%00000110
Black Pawn: #%10000001
Black Rook: #%10000010
Black kNight: #%10000011
Black Bishop: #%10000100
Black Queen: #%10000101
Black King: #%10000110
Bit #3 signify virgin (0) or moved (1) piece.
Bit #4 Signify En Passant Candidate (1) or not (0)
Board Coordinates:
~~~~~~~~~~~~~~~~~~
0, 1, 2, 3, 4, 5, 6, 7
8, 9, 10, 11, 12, 13, 14, 15
16, 17, 18, 19, 20, 21, 22, 23
24, 25, 26, 27, 28, 29, 30, 31
32, 33, 34, 35, 36, 37, 38, 39
40, 41, 42, 43, 44, 45, 46, 47
48, 49, 50, 51, 52, 53, 54, 55
56, 57, 58, 59, 60, 61, 62, 63
Mapped to ZP adresses: $40 - $7f (0-63)
Basically both my prototyes will display the chessboards perfectly based on the pieces in those ZP address locations. From there it's easy to save/load a game, setup Challenges based on famous games etc. From here it's straight fwd. implementation of the move rules and path-checking. Then it's the AI.
And if You want to be cool, use a mouse routine to allow picking/dropping pieces ;-)
yeah its all down hill from here, thanks for doing most of it for him:) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting TWWThen it's the AI.
Oh, is that all? ;) |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
Skate: Thats an excelent idea.
TWW: Nice description. I wasn't going to actually make a game yet, only an chess-animation for intro to a demo, or else I would never be able to make enough stuff for a demo for X. Maybe i'll be hooked and make a game afterall, haha - But who knows. I might get bored if things start to get tricky anyway. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
I thought implementing the AI was the tricky part! ;) |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
JackAsser: When I wrote the AI for https://sites.google.com/site/rudibstranden/projects/chess-obse.. the tricky part was the En Passant and the special cases for castling.
I guess there might be some special logical (boolean) rules from a bitboard if its set up correctly, so one can reduce code. So that it dont get too massive for 6502/6510 code. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: JackAsser: When I wrote the AI for https://sites.google.com/site/rudibstranden/projects/chess-obse.. the tricky part was the En Passant and the special cases for castling.
I guess there might be some special logical (boolean) rules from a bitboard if its set up correctly, so one can reduce code. So that it dont get too massive for 6502/6510 code.
Can imagine! :) |
| |
TWW
Registered: Jul 2009
Posts: 545 |
Hehe Yeah sure, it's piece of cake ;-)
If You set up the Board in ZP as described above and mark the pieces With identifying bits informing if they have been moved before or not, You only need to define the rules and here are some examples for pawns and Rooks/King:
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CheckLegalPawn:
/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
RULES:
~~~~~~
Vertical+1: Pos+8
Vertical+2: Pos+16 <--- Only when virgin
CapDia+1: Pos+7
CapDia+1: Pos+9
En Passant: Pos+7 <--- Only when adjacent to fresh pawn opponent (Pos+16)
En Passant: Pos+9 <--- Only when adjacent to fresh pawn opponent (Pos+16)
Upgrade: Pos = last line (0-7 / 56-63)
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CheckLegalRook:
/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
RULES:
~~~~~~
Vertical: Pos+8 x [1-8]
Vertical: Pos-8 x [1-8]
Horizontal: Pos+1->8
Horizontal: Pos-1->8
Castling: Pos+2 <--- Only when K & R are virgin
Castling: Pos-3 <--- Only when K & R are virgin
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CheckLegalKing:
/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
RULES:
~~~~~~
Pos+1 & Pos-1
pos+7 & pos-7
Pos+8 & Pos-8
pos+9 & pos-9
Castling: Pos-2 <--- Only when K & R are virgin
Castling: Pos+3 <--- Only when K & R are virgin
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/
Implementing this in code is not very complicated.
Then You off course need check that the slope(s) are Clear:
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// Checks the path between the two horizontal Squares
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
HorizontalLineClearCheck:
// Find number of squares to check
lda OldSquare
sec
sbc SelectedSquare
bcs !+
eor #$ff
adc #$01
!: tax
// Find signed parameter to use in the slope checker
lda OldSquare
cmp SelectedSquare
bcc !+
lda #$ff
jmp CheckSlope
!: lda #$01
jmp CheckSlope
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// Checks the path between the two vertical squares
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
VerticalLineClearCheck:
// Find number of squares between the squares (absolute)
lda OldSquare
sec
sbc SelectedSquare
bcs !+
eor #$ff
adc #$01
!: lsr
lsr
lsr // Divide the difference with 8
tax
// Find signed parameter to use in the slope checker
lda OldSquare
cmp SelectedSquare
bcc !+
lda #$f8
jmp CheckSlope
!: lda #$08
jmp CheckSlope
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// Checks the path between the two diagonal squares
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DiagonalLineClearCheck:
// Check if the move is left or right
lda OldSquare
and #%00000111
sta $02
lda SelectedSquare
and #%00000111
sec
sbc $02
bcs !Left+
eor #$ff
adc #$01
!Right: // XPOS SelectedSquare > OldSquare
tax // Number of squares to check in X-REG
// Find if move is up or down
lda OldSquare
cmp SelectedSquare
bcs !RightUp+
!RightDown:
lda #$07
jmp CheckSlope
!RightUp:
lda #$f7
jmp CheckSlope
!Left: // XPOS OldSquare > SelectedSquare
tax // Number of squares to check in X-REG
// Find if move is up or down
lda OldSquare
cmp SelectedSquare
bcs !LeftUp+
!LeftDown:
lda #$09
jmp CheckSlope
!LeftUp:
lda #$f9
jmp CheckSlope
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// Routine for checking if squares between two points are empty
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// Parameters:
// A- $02 - Loaded with Signed byte for slopecheck:
// #$01 - Horizontal Right
// #$ff - Horizontal Left
// #$08 - Vertical Down
// #$f8 - Vertical Up
// #$07 - Diagonal Down-Left
// #$09 - Diagonal Down-Right
// #$f9 - Diagonal Up-Right
// #$f7 - Diagonal Up-Left
// X-Reg - Squares to check
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CheckSlope:
sta $02 // Parameter = Signed number for slope check
dex // Decrease with one square to check
beq !end+ // If already zero, there was no squares to check
// Find first square to check
lda OldSquare
clc
adc $02 // Skip first square since it's occupied by the piece in oldsquare
tay
!loop:
lda $40,y // Fetch Square,Y
beq !+
sec
rts
!: tya
clc
adc $02
tay
dex
bne !loop-
!end:
clc
rts
Also not any rocket science.
You off course need to check if target cell is legal and if it's occupied to determine legal moves (including putting onself in chess). There are also some rules in regards to stalemate situations.
Once all the rules are defined, the Next step is the AI. This is off course the most complicated but not neccessarely as the AI has to play by the same rules defined for the game. A chess game is split up into 3 parts, the opening game, mid game and end game. Opening game, one could store 3,4,5,6.. known openings and also verify there are no cheap shots by the player along the way. then mid game it's conquer the middle Field along With valuing the pieces to determine if You should capture or not/fortify. Then for end game it Depends the score if AI should try to Draw or position for chess mate. Then You can add the complexity and also plan moves Ahead (which could be set by an dificulty setting). The only real limitation here is memory whic should be no problem considering the early chess computer games and the maount of memory available there...
Perhaps this would be a good thought for the next C64 compo, to make the smartest AI for a chessgame ;-) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
TWW, yeah that is like a texturemap tutorial like this: well just rotate the vertices in 3d should be simple, then interpolate uv's along the edges, then across the scanline. phong should be a piece of cake after that ;) |
| |
TWW
Registered: Jul 2009
Posts: 545 |
It been done before (like when I was born before) and in really short Versions too:
http://www.6502.org/source/games/uchess/uchess.htm
Anyhu, just wanted to give some ideas. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: It been done before (like when I was born before) and in really short Versions too:
http://www.6502.org/source/games/uchess/uchess.htm
Anyhu, just wanted to give some ideas.
you are way off topic with all this here. |
| |
TWW
Registered: Jul 2009
Posts: 545 |
Yes, indeed. This was about sprite multiplexing. |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
Quote: you are way off topic with all this here.
Thats not his fault tho. :P
Seemed I didnt need sprites for this at all. So Ill take the blame for being off topic.
I could have changed the topic-header if that was possible.. |
