{"content":{"sharePage":{"page":0,"digests":[{"id":"4528003","dateCreated":"1212491769","smartDate":"Jun 3, 2008","userCreated":{"username":"Pawel_Koziol","url":"https:\/\/www.wikispaces.com\/user\/view\/Pawel_Koziol","imageUrl":"https:\/\/www.wikispaces.com\/i\/user_none_lg.jpg"},"monitored":false,"locked":false,"links":{"self":"https:\/\/chessprogramming.wikispaces.com\/share\/view\/4528003"},"dateDigested":1531477643,"startDate":null,"sharedType":"discussion","title":"movegen_push","description":"I have just added a pseudocode for sliding pieces move generation. The reason it is only pseudo is that I'm afraid that we are going too fast and it can be seen from the number of parameters in movegen_push. Do we really need two variables piece_from and piece_to? the only time they are needed is during promotion, which is flagged and when the move is unmade we know from the flag that we should clear a piece and add a pawn.
\n
\nI think the definition of movegen_push should be postponed until we have agreed upon the move representation.
\n
\nspeaking of it: one thing I like about TSCP is the way it uses bits in move flags, so that for instance a move can be easily marked as a capture and a promotion at the same time. Perhaps this scheme can be elaborated, so that flag contains the information about promoted piece as well.","replyPages":[{"page":0,"digests":[{"id":"4530221","body":"ok ..
\nso what are the variables to store for each move? what would you suggest?
\n
\nThe scheme from TSCP with the flags is nice, thats something I wanted to include too. But for the information about the promoted piece I would use a separate variable. Of cause you could squeeze the whole move information into a little bit more than 2 byte (6bit from, 6bit to, 3bit captured piece, 2 bit promotion = 17bit) and everything can be calculated from it, but it doesn't help readability.
\n
\nHaving the variables separate will be just a bit slower and the movegen_push() function will take more arguments, but on the other hand the make\/unmake move will be relatively simple.
\n
\neg.
\nNo matter whether there is a promotion, capture or a normal move. make will be: (just ep and castle will take more effort - thats what the flags are for)
\nb.pieces[to] = m.piece_to;
\nb.color[to] = b.stm;
\nb.pieces[from] = PIECE_EMPTY;
\n
\nand the unmake will be:
\nb.pieces[from] = m.piece_from;
\nb.color[from] = b.stm;
\nb.pieces[to] = m.piece_cap;
\nb.color[to] = b.stm^1;
\nb.fifty = m.fifty;
\n
\nThats what I had in mind","dateCreated":"1212505780","smartDate":"Jun 3, 2008","userCreated":{"username":"Edmund_Moshammer","url":"https:\/\/www.wikispaces.com\/user\/view\/Edmund_Moshammer","imageUrl":"https:\/\/www.wikispaces.com\/i\/user_none_lg.jpg"}},{"id":"4539743","body":"OK, now I see that You basically want to merge the move record and the history stack. In this case program as a whole will not necessarily suffer from redundancy. The idea looks interesting.
\n
\nI still do not see, however, what can be gained by using
\n
\nb.pieces[to] = m.piece_to;
\n
\ninstead of
\n
\ninstead of b.pieces[to] = b.pieces[from];
\n
\n
\nSpeaking of making and unmaking: it might be worthwile to write it as a series of calls to basic functions fillSqr() and clrSqr() - I have done it in my TSCP derivative and it simplified working with the incremental updates (of course two aforementioned functions grew quite big because of that). Hoiw do You feel about it?
\n
\n
\nas far as move record is concerned, we certailny need the following
\n
\n- from square
\n- to square
\n- captured piece, if any
\n- promoted piece, if any
\n- flag
\n- move ordering value
\n
\nif we merge it with the history stack, we must add
\n
\n- en-passant square before the move
\n- fifty move counter before the move
\n- castling rights before the move","dateCreated":"1212553266","smartDate":"Jun 3, 2008","userCreated":{"username":"Pawel_Koziol","url":"https:\/\/www.wikispaces.com\/user\/view\/Pawel_Koziol","imageUrl":"https:\/\/www.wikispaces.com\/i\/user_none_lg.jpg"}},{"id":"4540265","body":"With "b.pieces[to] = m.piece_to;" I just wanted to generalize the case of promotion. b.pieces[to] will always be b.pieces[from], just in the event of a conversion will it change.
\n
\nAbout fillSqr() and clrSqr(): I am certainly in favor of any functions that promote readability in this tutorial chess program
\n
\nAbout the variables for the moverecord. I think I have included all of them but the en-passant square (I must have forgot).
\n
\nAnother question is the purpose of flag or what states do we store in it. A) it should help the push function to give a score. B) it can help the unmake move function
\nBut as we already have variables like for example piece_cap we don't need the flag to hold information about whether a capture occurred. Same for promotion. It would only be very helpful to have a bit set for the case of castling, so that we just have to compare one bit and not check whether it was a kingmove - if yes was it a castling move - if yes in which direction.","dateCreated":"1212559859","smartDate":"Jun 3, 2008","userCreated":{"username":"Edmund_Moshammer","url":"https:\/\/www.wikispaces.com\/user\/view\/Edmund_Moshammer","imageUrl":"https:\/\/www.wikispaces.com\/i\/user_none_lg.jpg"}}],"more":0}]}],"more":false},"comments":[]},"http":{"code":200,"status":"OK"},"redirectUrl":null,"javascript":null,"notices":{"warning":[],"error":[],"info":[],"success":[]}}